Olá,
referente a escrita das histórias, devo detalhar os mínimos detalhes como no método tradicional de levantamento de requisitos?
Onde há informações como por exemplo: descrever os campos de entradas, descrição do caminho das excessões, as mínimas validações como por exemplo data2 deve ser maior que data1, mensagem de erro ou sucesso a ser apresentada, as condições de tomadas de decisões que o software precisa executar, etc.
Olá Márcio, uma história deve ter O INVEST => ser testavel, estimável, entregar valor, ser negociável, independente das outras histórias, e com um tamanho que de pro time fazer em um Sprint. Uma história deve ser detalhada o suficiente para estimar o tempo de desenvolvimento apenas, definindo os critérios de aceitação Espero ter ajudado!
Obrigado Thiago pelas sugestões
Legal sobre o INVEST, procuro seguir, porém evoluindo um pouco o assunto.
Como você entende ou pratica? Por exemplo, nos critérios de aceites devo descrever algo como: comparar campo A com o campo B, se A for maior que B apresente a mensagem "x" senão apresente a mensagem "y" e retorne ao menu "xpto".
Salve Marcio, tudo em paz?
Chefe, entendo sua --se é que posso chamar assim-- agonia. A maior virtudade de uma metodologia mais aberta como Scrum pode ser também um problema, principalmente no início de seu uso.
Como bem lembrou o Thiago, uma história deve ter o Invest. Se você vai escreve-la de forma a ter algo mais próximo de um documento padrão de especificação, por exemplo seguindo UML, com fluxo normal, fluxos alternativos, fluxos de exceção, tipos de campo, etc. ou se vai ter algo mais enxuto, é uma decisão que considero pessoal.
Escrever uma história mais detalhada pode lhe tomar mais tempo e dependendo, até aumentar o acoplamento com outras histórias - o que não queremos. Por outro lado, esta abordagem poderia facilitar o trabalho de codificação e ainda, do ponto de vista de documentação / manutenção sistêmica, agregar mais valor.
Particularmente considero o meio termo o melhor dos mundos. Uma história deve ter a menor granularidade possível, ser o mais simples e se for complexa, quebra-la em histórias menores. Traço um paralelo aqui, mais ou menos como sistemas especializados ou micro-serviços. Precisa ser clara, ter seu valor óbvio para todo o time, ter a regra combinada com o usuário.
Este caminho você e o time precisarão percorrer aos poucos, aprendendo juntos o que funciona melhor para cada projeto / situação. Infelizmente, desconheço uma receita a ser seguida, apenas caminhos mesmo.
Espero ter ajudado.
Grande abraço,
Obrigado a todos que contribuíram com a discussão.