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.

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.

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 comprometimento muito maior, pois estabelece um entendimento e uma comunicação mais transparente. É o que podemos chamar de “fazerem todos falarem a mesma língua”.

Para qu ...

Este artigo é exclusivo para assinantes. Descubra as vantagens
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo