Este artigo sugere uma forma mais ampla de enxergar o tratamento destes requisitos, também considerados fatores críticos de sucesso das aplicações.
A produção de software através de modelos ágeis de desenvolvimento, como o Scrum, é popularmente adotada por empresas e equipes de diversos tamanhos e seguimentos.
Porém, existem alguns pontos que merecem uma atenção por se tratarem de peças fundamentais no desenvolvimento de um software: os requisitos não funcionais. Estes podem levar o software do sucesso ao fracasso.
A equipe de desenvolvimento também precisa possuir um ambiente favorável para lidar com tudo isso e, por vezes, pode não ter notado o que seria necessário para poder alcançar um ambiente mais produtivo e seguro.
Veja os números apresentados na Figura 1 publicados no último relatório gerado pelo Standish Group em Março/2013. Este gráfico demonstra o percentual de falha, mudanças e sucesso nos projetos de desenvolvimento de software.
Figura 1. Percentual de Falhas, Mudanças e Sucesso em projetos de TI.
Podemos perceber que houve uma sensível melhora, desde a 1ª aferição em 1994 até a última em 2012 onde, de apenas 16% de sucesso nos projetos, alcançou-se os 39%. Isso significa uma melhoria de quase 100%. mas considerar que de todos os projetos, apenas 39% destes são entregues conforme o planejado, torna-se um fator preocupante.
Em complemento, a Tabela 1 apresenta os fatores considerados críticos para o sucesso dos projetos.
Tabela 1. Fatores de Sucesso dos Projetos de TI.
De acordo com os dados deste relatório, podemos destacar os seguintes pontos:
- A conscientização, por parte das empresas, sobre a importância da TI como peça fundamental no sucesso. Isso fez com que a maior parte das empresas colocassem seus executivos (os patrocinadores dos projetos) à frente para auxiliar a TI, oferecendo maior suporte e acompanhamento;
- Em decorrência desta conscientização gerou-se um maior envolvimento dos usuários, promovendo otimização das aplicações em pequenos projetos, com investimentos em conhecimento, aumentando o capital intelectual das equipes, seguido por uma melhor visão e entendimento mais sólido sobre gerenciamento de projetos e a adoção de Processos Ágeis.
Observe que muitos desses fatores estão alinhados com as práticas ágeis de desenvolvimento.
A importância e os desafios na adoção das metodologias Ágeis
É possível verificar a importância do entendimento e adoção das metodologias ágeis para garantir o sucesso nos projetos de desenvolvimento de software. Nelas o foco está em “entregar software funcionando”.
Seguindo esta linha, imaginemos uma aplicação produzida com o Scrum ou outra metodologia ágil. Este software encontra-se em produção e em uso por usuários e num dado momento surgem questões como:
- O relatório “X” está muito lento e está atrapalhando os usuários;
- O sistema “cai” quando atinge 1.000 usuários simultâneos;
- O sistema ficou 24 horas “fora do ar” devido a não possuir ou não terem funcionado as devidas contingências;
Esta lista de questões são puramente requisitos não funcionais não observados e/ou não atendidos.
Em praticamente toda a literatura associada ao uso do Scrum, existe um assunto que não é claramente tratado mesmo sendo de extrema importância: os requisitos não funcionais.
Na estrutura de trabalho do Scrum, temos os papeis bem definidos: Product Owner, Scrum Master e a equipe, que é composta sempre por membros com diversos conhecimentos e habilidade (multidisciplinar), mas nem sempre se observa a presença (ou a necessidade) de recursos detentores de conhecimentos específicos, como de um arquiteto, um DBA ou um especialista de infraestrutura, o qual domine a parte de arquitetura da solução implementada.
As empresas as quais adotaram ou irão adotar o Scrum precisam ter em mente a questão de que se um novo requisito não funcional ou um problema grave de performance na aplicação surgir, pode comprometer o sucesso do produto. Na verdade, um requisito não funcional é tão ou mais importante que um requisito funcional.
Entendendo os requisitos funcionais e não funcionais
É preciso entender o papel dos requisitos funcionais e não funcionais para poder tratá-los de forma correta:
- Funcionais: O que o produto deve fazer, que necessidades de negócio deve atender, os cadastros, relatórios, funcionalidades tangíveis ao usuário: estes são cadastrados no “Product Backlog” e posteriormente se transformam em “estórias”, que são priorizadas pelo Product Owner, entendidas e orçadas pela equipe e, durante o planejamento, transformam-se na meta da “Sprint”;
- Não Funcionais: São aqueles não tangíveis diretamente ao usuário final (Cliente), mas que determinam “como” e “onde” a aplicação (produto) deve funcionar, critérios de segurança e criptografia, escalabilidade, disponibilidade, compatibilidade, etc.
Ambos são itens do backlog, são premissas e fazem parte do Escopo do Produto. Então, precisamos entendê-los e abordá-los adequadamente durante o processo de desenvolvimento do software." [...] continue lendo...
