Voltar

Por que eu devo ler este artigo:Requisitos não funcionais nem sempre são abordados de forma clara durante a adoção ou uso das metodologias ágeis, como o Scrum.

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.

Percentual de Falhas, Mudanças e Sucesso em projetos de TI

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.

Fatores de Sucesso dos Projetos de TI

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.

Desenvolver software representa diversos desafios e, cuidar do produto e da equipe, sem sombra de dúvidas, é tão ou mais importante do que todo o resto.

Quando aprendemos a observar estas variáveis de forma mais clara, não apenas a equipe, mas principalmente a empresa, temos uma visão e um compr ...

Quer ler esse conteúdo completo? Tenha acesso completo