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.

The post Gerência de Requisitos no MPS.BR appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Estabelecendo as bases

Não pretendo, nesse post, debater os agrupamentos administrativos de pessoas ou estágios para a construção de times…formação, conflito, normalização, desempenho. Meu foco são os times aos quais uma empresa recorre para tratar seus projetos de maior complexidade, urgência e riscos… os reais times de alta performance.

Fina estampa

Entretanto, na "reinvenção nossa de cada dia", já é comum esbarrarmos com desenvolvedores auto-entitulados "ninja" ou "jedi", em substituição aos tradicionais termos de analista de sistemas ou engenheiro de software. Não surpreende que muitos adotem o Scrum numa simples leitura do Scrum Guide… achando-se professores daquilo que ainda não vivenciaram.

Um rumo e uma direção

Assim, acredito no real valor das pessoas e dos processos que nos forçam para longe das zonas de conforto, das triviais resistências e modismos… do "ScrumBut". Sorry, Jurgen!

Somente com a aderência às cerimônias, papeis e artefatos do Scrum é que se estabelecem os inquestionáveis diferenciais de produtividade, confiança e comunicação! Quem viveu, sabe.

A ignorância é uma benção
 

Eu achava que fazia um ótimo Scrum… tirei 6 na primeira avaliação do Nokia Test. Recorri às avaliações do restante do time… ainda 6 em consenso. Repensamos nossa práticas, percebemos melhorias e atingimos o marco para uma nova avaliação… nota 7!

Foi impressionante perceber como um simples teste pode ser tão revelador ao evidenciar deficiências e oportunidades…lições aprendidas na veia!

Convite

Entenda os checklists (p.ex.: Bafômetro Ágil Parte 1) e busque os níveis mais altos dos modelos de maturidade, mas aceite que, nesse ponto, as melhorias são contínuas… de verdade!

Como disse um novo amigo, "o prazer do professor é quando o aluno tira 10 numa prova bem difícil"!

Desse espírito é que nascem as melhores relações de networking profissional, quando o processo é "institucionalizado" na cabeça das pessoas por escolha própria e quando o time de alta performance passa a ser reconhecido como um valoroso "ativo organizacional"… prata da casa!

The post Do bom para o ótimo Scrum appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.