Solucionado (ver solução)
Solucionado
(ver solução)
5
respostas

Vida útil das histórias

Qual seria a vida útil das histórias?

Elas só servem como um registro para implementação? Ou objetivo é que elas sirvam como documentação do sistema implementado?

Caso sirvam como documentação do sistema implementado, quer dizer que quando houver a implementação de melhorias em algumas sprints (mesmo após as releases), várias histórias devem ser resgatadas e alteradas para condizer com estas novas melhorias?

5 respostas

Oi Cássia,

Como sempre, depende muito.

Eu prefiro acreditar que minha histórias tem vida curta. Ou seja, elas fazem total sentido durante a sprint que elas estão sendo desenvolvidas.

Depois de prontas, a história "some". Para novas alterações, crio novas histórias. Não acredito na rastreabilidade delas.

Faz sentido?

Até faz sentido, Maurício. =)

Pois na verdade, mesmo que fôssemos reutilizar algo, não será a mesma história porque estamos implementando alterações nela.

Mas, não há um pouco de desperdício de trabalho gerado aí? Pois um trabalho de entendimento já foi feito. Por exemplo, no detalhamento e entendimento das regras usadas. Muitas regras vão continuar as mesmas, mas vou precisar detalhá-las novamente...

(Aqui, estou imaginando não um sistema simples, mas um com regras "escondidas", que não ficam muito claras somente ao se acessar uma tela, por exemplo. Neste caso, não é "rápido" o entendimento da funcionalidade.)

solução!

Oi Cássia,

Aí que tá.

Eu vejo histórias de usuário como algo que serve durante o desenvolvimento da funcionalidade. E nada mais.

Para manutenção futura, prefiro acreditar que minha equipe terá bateria de testes automatizados e fará programação pareada para disseminar conhecimento técnico do produto.

Documentação também não é manual de usuário. Se vc precisar de manual, fará um.

Documentação também não é nunca lida por um novo desenvolvedor. Afinal, ela é gigante, e provavelmente não reflete a realidade.

Faz sentido?

Oi,

Sim, a documentação que falo é a documentação técnica, não o manual do usuário, pois são coisas diferentes. Faz sentido que as histórias sejam voltadas para a implementação e, portanto tem uma vida útil finita.

Talvez eu esteja pensando em outra coisa e aí não sei se algum método ágil entra neste mérito. Talvez seja mais de análise de negócios, sobre manter de alguma forma documentadas as regras envolvidas e processos de negócio relacionados. Imagine um sistema bancário, é muito complicado não termos uma documentação das regras que foram utilizadas na implementação de uma funcionalidade. Não há como sempre que formos alterar esta funcionalidade, algum desenvolvedor desbravar o código tentando entender o que se tem hoje...

Mas, obrigada pela resposta! =)

Oi... Uma dúvida com relação a essa questão. Foram feitas as histórias, elas "morreram", ou seja, não foram arquivadas e nem nada. Por alguma razão os programadores estão em outros projetos ou não estão mais na empresa e o cliente solicita novas alterações no projeto.

Considerando que é um projeto onde existem regras de negócio complexas, como os novos selecionados para esse projeto vão entendê-lo? O cliente fará suas histórias fazendo as solicitações novas, ou alterando recursos já existentes. Os programadores irão sair, como a Cassia falou, desbravando o código? Fazendo novas reuniões com o cliente para entender as histórias/escopo antigo do projeto?

Qual seria uma solução para esses casos?