Por Gilberto Santos

Atualmente é comum, entre os profissionais desenvolvedores de software, o uso de processos ágeis para o desenvolvimento, como o Scrum e o Extreme Programming (mais conhecido como XP), todavia a falta de informação, a necessidade de se mostrarem atualizados, aliados a falta de experiência no uso dessas técnicas, estão confundindo desde desenvolvedores experientes até os novatos na área. No impeto de serem “ágeis” muitos profissionais, com frequência, negligenciam as tradicionais técnicas de elicitação e análise de requisitos. O manifesto ágil diz:

  • Indivíduos e interação entre eles mais que processos e ferramentas
  • Software em funcionamento mais que documentação abrangente
  • Colaboração com o cliente mais que negociação de contratos
  • Responder a mudanças mais que seguir um plano

Note que em momento algum é dito que devemos sacrificar um planejamento prévio, o que acontece é que se leva ao pé da letra o segundo item do manifesto, Software em funcionamento mais do que documentação abrangente, este item não diz que não devemos documentar, a ideia é que devemos documentar somente o necessário, deixando aquela documentação que ninguém lê de lado. Muitos acham que quanto o mais rápido possível for iniciado o desenvolvimento melhor, e pode até eficaz em pontualmente, porem ao resolver um problema isolado de cada vez tende-se a perder a visão geral do projeto, e a agilidade inicial se perde devido ao retrabalho para integrar os diferentes módulos feitos pontualmente. Vejamos como as técnicas tradicionais podem ser utilizadas juntamente com processos ágeis.

A Elicitação de Requisitos

O processo de elicitação de requisitos, é importante pois é nele que os interessados no projetos podem expor as suas expectativas e desejos. Tradicionalmente são feitas entrevistas com os futuros usuários, onde estes expõem suas necessidades. Essa técnica consome muito tempo, então é necessário um prévio planejamento, utilizando questionários e checklists para agilizar as entrevistas. O importante nessa fase é ouvir as pessoas de diferentes níveis hierárquicos, pois a visão destes é diferente e expõem necessidades diferentes.

Outra técnica é a da observação das atividades realizadas, o que serve para a compreensão do domínio do problema, coletando informações de acordo com o cotidiano da organização. Também podemos extrair requisitos através da analise de documentação existente, o uso generalizado planilhas eletrônicas  e controles paralelos são um indicio de processos que podem ser automatizado. Existem outras técnicas de elicitação de requisitos, porem estas ultimas são as mais utilizadas e promovem um entendimento da visão geral do projeto.

A Análise de Requisitos

Após a elicitação, obtemos uma lista de requisitos brutos funcionais e não funcionais, e frequentemente conflitantes entre si e até mesmo inviáveis, dessa forma é necessária uma analise mais apurada para resolver esses problemas, muitas vezes é necessário retornar a fase de elicitação para eliminar dúvidas que podem surgir durante a analise.

Durante a analise, os requisitos brutos são detalhados, o que pode acarretar na descoberta de novos requisitos, bem como no desmembramentos de requisitos complexos. Neste ponto, para tornar o processo ágil, o detalhamento deve ser o suficiente para o entendimento do problemas, não é necessário descrever cada requisito nos mínimos detalhes, principalmente os bem entendidos e comuns, deve-se, no entanto, detalhar aqueles que são nebulosos, tanto para a equipe de desenvolvimento quanto para futuros usuários.

Ao término desse processo temos, o que os adeptos as técnicas ágeis chamam de product backlog ou  “lista de desejos”, ou seja, tudo o que se espera do novo software.

Priorizar, Organizar, Verificar e Validar os Requisitos

  • Priorizar os requisitos – Deve ser feita pelos principais stakeholders do projeto, pois são eles que sabem o que tem mais valor para negócio, e quais funcionalidades tem mais urgência de serem colocadas logo em produção.

  • Organizar os requisitos – Esta tarefa deve ser realizada pela equipe de desenvolvimento, respeitando a priorização feita no passo anterior. Normalmente a priorização dos stakeholders não leva em consideração as interdependências entre os requisitos e cabe aos desenvolvedores e o gerente do projeto identificar essas dependências e ajustar a ordem das tarefas para que os módulos entregues sejam plenamente utilizáveis.

  • Verificar os requisitos – Essa atividade consiste em checar junto aos clientes se o que esta descrito no requisito é correto. Também é possível identificar se os requisitos são viáveis de serem implementados.

  • Validar os requisitos – Por fim, após a implementação, é feita a validação, onde é analisado se o que foi descrito do requisito foi corretamente codificado.

E a agilidade?

Pode parecer estranho falar em tantos processos falar em tantas técnicas tradicionais de levantamento e analise de requisitos juntamente com processos ágeis, porem as técnicas acima podem ser adaptadas, por exemplo: no primeiro contato com a organização, poderia ser feitas as etapas de elicitação, analise, priorização, organização de forma macro, para se obter uma versão geral do projeto, e então a cada iteração, repetir esse processo e ir refinando os requisitos.

Enfim, todas as técnicas descritas acima podem, e devem, ser utilizadas juntamente com os atuais processos ágeis de desenvolvimento de software. Ser ágil não é apenas “sentar e programar”, exige técnica e disciplinas que não devem ser negligenciadas. Um bom planejamento, bem dimensionado e sem excessos são fundamentais para um desenvolvimento ágil com qualidade.

(Visited 61 times, 1 visits today)

Comente esta matéria

Please enter your comment!
Informe seu nome aqui