Documentação de requisitos

Rafael, a gente aqui na Alura e na Caelum usa basicamente o Trello.

Alguns projetos possuem cards mais longos, com checklists elaborados e descrições maiores, algumas vezes linkando para arquivos no google docs.

Outros projetos, a maioria, possuem cards muito simples, com descricoes de um ou dois paragrafos, já que os sprints são muito curtos. Como são curtos, a equipe inteira esteve na reunião há pouco tempo e entende o requisito muito bem.

Em empresas onde o trabalho é remoto, onde o sprint é mais longo, ou onde o cliente é uma terceira pessoa que a equipe não tem contato, softwares mais "caretas", como o próprio JIRA, costumam ser utilizados, com uma quantidade maior de campos pré definidos e um workflow bem customizável.

Oi, Paulo!

Muito obrigado pela resposta! Achei bastante interessante essa abordagem.

No meu caso, trabalho no setor público e costumamos manter toda a documentação do sistema em casos de uso que ficam no Enterprise Architect.

Aproveitando essa discussão, quando surgem upgrades de funcionalidades - inclusão de novos campos, novas validações, mudança de layout da aplicação, entre outras alterações - vocês criam cards novos ou vocês evoluem os cards que já estavam escritos?

E para o caso de o usuário relatar um bug em produção e vocês precisarem verificar se aquilo realmente é um bug ou se é um comportamento esperado do sistema? Vocês olham direto no código-fonte ou consultam o que está documentado no Trello/GoogleDocs?

É que, muitas vezes, precisamos "provar" pro nosso usuário que aquilo que ele achou que era um bug era o que, de fato, ele havia pedido para implementar. Ou seja, o sistema está implementado corretamente, conforme ele havia pedido. Assim, o que ele acha ser um bug é, na verdade, uma mudança de requisito (a qual precisa ser analisada, aprovada, ter a documentação ajustada, etc, até a sua devida homologação).

Valeu, obrigado novamente!

Rarissimamente volto com um cartao. Sao sempre cartões novos. O cartão só volta se o clinete/PO não aprovar a implementação daquela história.

Mesmo bugs a serem corrigidos, se só foram descobertos depois da implantação, voltam como cartões novos.

Para verificar se é um bug ou uma feature, deixo a cargo do usuário final. Se para ele é um bug, devemos estar fazendo algo errado, não importando se antigamente o requisito dizia que deveria ser assim. Mas entendo que seu caso é um cliente de fora, o que pode gerar problemas de gerenciamento de recursos. Nesse caso eu voltaria e olharia os cartões e documentação de quando a feature foi pedida. E como ele aprovou aquele cartão antes de ir para produção, fica mais fácil de dizer que é mudança de requisito.