Recentemente tivemos um problema aqui na Globo.com em relação ao entendimento de uma história. Basicamente, o time tinha entendido a história de uma forma um pouco diferente do que o Product Owner (PO) tinha solicitado. No Sprint Review, quando as histórias que foram implementadas são demonstradas para o PO, descobriu-se essa pequena discrepância entre os entendimentos do time e do PO. Ou seja, a história da forma como tinha sido implementada não trazia o valor esperado pelo PO. O problema não foi nada muito sério e já temos uma história no próximo sprint para resolvê-lo.
Mesmo assim, esse tipo de surpresa não deve ocorrer em um Sprint Review. Seguindo a idéia dos métodos ágeis de que deve haver uma melhoria contínua, temos duas sugestões que foram aceitas por todos e que estão sendo adotadas já no próximo sprint para avaliarmos se resolvem este tipo de problema.
A primeira é definir critérios de aceitação para cada história. Esses critérios são validados pelo PO e são parâmetros objetivos para que uma história seja aceita ou não. Os critérios são utilizados, também, como input para a definição de testes de aceitação automatizados. Esses testes devem ser escritos no começo de cada história. Depois, o time implementa a história até fazer os testes passar.
A segunda é termos o PO mais presente ao longo do sprint, acompanhando se o que o time está desenvolvendo atende aos critérios de aceitação de cada história. Dessa forma, possíveis erros de entendimento podem ser eliminados mais cedo, evitando surpresas no Sprint Review.
March 29, 2008 at 5:06 pm |
Sem duvida o PO estar mais presente é o que tem nos ajudado mais. Antes mesmo de ter uma tarefa como done, exibi-la para a validação do PO tem sido uma ótima experiência.
April 21, 2008 at 5:28 pm |
[...] de Aceitação Recentemente escrevi aqui que passamos a definir critérios de aceitação para cada história durante o sprint planning. Os [...]