Acredito que o maior desafio da Engenharia de Requisitos não está na elicitação, na definição dos requisitos do cliente, do produto de software e de seus componentes.

Além do desenvolvimento dos requisitos, existe um esforço incansável de controlar sua evolução ao longo de todo o projeto!

Assim, com base no Guia de Implementação Parte 1, Fundamentação para Implementação do Nível G, procuro, nesse post, incentivar o debate e o alcance da competitividade pela qualidade, associando os resultados esperados do processo de Gerência de Requisitos (GRE) com minha experiência de uso da ferramenta ScrumHalf… perdoem minha curva de aprendizado e qualquer sugestão de melhoria descabida, hehehe! 😉

Ao longo das práticas descritas a seguir, o mais importante é a percepção dos conceitos de rastreabilidade, de impacto das mudanças, de critérios para aceitação e controle da mudança em requisitos, garantindo um consistente alinhamento entre agilidade e maturidade.

GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos.

Está lá, no painel “Participantes”, a clara definição dos papeis, onde deve ser explicitado quem define e altera os requisitos… os fornecedores de requisitos!

Daí, basta alternar para a aba “Product Backlog” para perceber a situação de cada história: proposta, aprovada, concluída e a realizar.

Importante também é evidenciar a contínua comunicação dessa evolução! Fica, então, a dica para a ferramenta incorporar, num ambiente totalmente integrado, a troca de mensagens associada a cada história, sem recorrer à guarda externa de emails ou atas de reunião.

Por fim, a funcionalidade oferecida pelo Relatório de Product Backlog garante enorme ganho de produtividade, pela economia do esforço manual na geração de qualquer documentação.

GRE 2. Os requisitos são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com estes requisitos é obtido.

Revisão por par é sempre boa prática… e rápida na detecção antecipada de defeitos!

Assim, além do desejado uso intensivo dos relatórios pré-configurados mencionados na prática acima, vale também valorizar o uso de “checklists”… assunto discutido em vários artigos desse blog.

Que tal estender a situação “aprovada”, diferenciando-a em demais comprometimentos: de revisão técnica e de todo o time Scrum?

GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida.

Os índices de identificação das histórias do Product Backlog são fundamentais para manter a desejada rastreabilidade, desde as necessidades do cliente até o código-fonte… passando pelas evidências de aderência à definição de história pronta do projeto (p.ex.: testes unitários, funcionais e de integração).

Em qualquer sistema de configuração, basta associar o “commit” ao ID da funcionalidade que está sendo implementada.

Opcionalmente, uma integração do ScrumHalf com APIs do Subversion e Git, pode ser uma funcionalidade “matadora”, estabelecendo um “log” de plena visibilidade das atividades de construção relacionadas!

GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos.

Adoro a marcação “bug”, no formulário de edição da história!

Falta só associar qual critério (de revisão ou de aceitação) levou à tal marcação (viva os “checklists”) e incluir, no Relatório de Product Backlog, esse específico filtro…pra ficar 10!

GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.

Aqui, a premissa evolutiva do Scrum já facilita a prática do modelo, pois só se planeja o horizonte conhecido…não há mudança pro que ainda não está definido.

Mas, considerando os iniciais requisitos do cliente e eventuais alterações de rumo durante uma Sprint, o bom uso das “tags” e da descrição podem satisfazer o resultado esperado, evidenciando uma “solicitação de mudança” e sua respectiva análise de impacto para a história proposta.

Concluindo,

está claro por que recomendo a adoção da ferramenta, por que acredito em sua melhoria contínua e por que admiro o trabalho de todos do ScrumHalf: o apoio a demais áreas de processo (como Gerência de Projetos, Qualidade, Medição etc )  também é percebido.