É uma boa idéia escrever especificações de requisitos por histórias?

No momento, estamos usando métodos ágeis no meu projeto atual e temos montes de histórias como estas:

• Como assistente, quero pagar um reembolso a um cliente para que ele possa receber algum dinheiro quando solicitá-lo

• Como cliente, quero pagar por uma compra para poder receber meu item.

O modo como fizemos isso até agora é escolher as histórias mais importantes a cada sprint e elaborá-las em várias especificações formais de requisitos (agrupamos algumas das histórias que são semelhantes na mesma especificação). Dependendo da história, pode ser apenas um botão em uma tela ou um fluxo de trabalho inteiro.

O problema agora é que, por haver tantas histórias, não fica claro de imediato para qualquer parte do sistema em que as histórias se relacionam.

Funciona no momento dos desenvolvedores, a cada sprint os desenvolvedores recebem apenas uma especificação descrevendo o que precisam fazer e as mudanças que precisam fazer. Mas, em termos de manutenção dessa lista de histórias e de teste, está começando a ficar realmente difícil rastrear bugs e, em geral, apenas mantendo as especificações, porque uma parte da funcionalidade na tela pode ter sido documentada em vários lugares diferentes devido ao fato de ser dividido por história.

Escrever especificações baseadas em histórias é uma boa ideia? Escrevemos as histórias da maneira errada?

Isso pode ser controverso, mas aqui vai!

Trabalhamos em sistemas em tempo real, onde um dos meus chefes anteriores sugeriu que façamos o AGILE! Foi fácil ganhar gerenciamento com isso; no entanto, era mais fácil falar do que fazer.

O conceito de histórias é bom - mas, para ser muito franco, é bastante vago. O que é realmente uma história? O problema real é que o uso de histórias alone(e o mesmo vale para casos de uso) também tem vários problemas - a seguir:

1. Os requisitos não podem estar fora de contexto (a menos que você esteja fazendo repetições grosseiras tantas vezes). Existem suposições, conhecimentos básicos e outros requisitos que também estão vinculados a um determinado requisito; eles só fazem sentido em um contexto e somente em uma ordem específica. A implementação da mais importante primeiro faz sentido para os negócios, mas quando você as arquivar pelo menos - mantenha uma referência completa desde o início, quando você as coletar. A palavra de requisito em si é complexa e não está realmente limitada a Casos de Uso / Histórias. Na verdade, as histórias são acionáveis, mas existem requisitos que podem não ser acionáveis, como desempenho, restrições a serem cumpridas, regras de negócios etc.

2. Os requisitos precisam ser apropriados em tamanho e de maneira quantificável; caso contrário, você nunca precisará de mais de uma história grande! O que forma exatamente uma história?

   • é um cenário completo e detalhado? (por exemplo, uma história quando o caixa eletrônico rejeita uma transação)
   • é um conjunto de ações que o usuário executa? (por exemplo, história completa sobre retirada)
   • ou é uma tela na interface do usuário? (por exemplo, tela de retirada como uma história completa).
   • Como realmente quantificar regras de negócios muito nítidas com histórias? Honestamente, pode ser qualquer um dos itens acima. A questão é o quanto você fica confinado e granulado e é um estilo bastante pessoal. Se funcionar, está tudo bem;

3. Conhecimento de domínio é realmente requisito! Um exemplo simples, de um arquiteto que conhece várias propriedades do vidro, aço e madeira. esse conhecimento não faz parte do documento de requisitos para o edifício, por exemplo! Da mesma forma, se você estiver escrevendo um software bancário - existem vários conceitos sobre bancário. Declarando-os, como opróprio Requisito o torna intratável, porque não informa o que o software deve fazer em vez de como o mundo funciona . A história inclui esses meandros do domínio? ou isso exclui?

4. Modelar o mundo é um pré-requisito que não é totalmente suportado.
   Há muita literatura sobre modelagem que se concentra apenas em entender como o mundo funciona é um conhecimento de base. A modelagem forma uma base sólida sobre a qual os requisitos adquirem um significado claro; no entanto, tal coisa deve ser antecipada. Infelizmente, a maioria das práticas ágeis recusa valor na modelagem inicial, no interesse de entregas mais rápidas e mais enxutas; mas que eu ainda acho que é um grande obstáculo para as coisas quando as coisas precisam crescer. Muitos projetos não são bem-sucedidos porque a modelagem é irrelevante - mas os engenheiros experientes os conhecem muito bem e não precisam de muita orientação explícita.

Então, voltando à sua pergunta:

Escrever especificações baseadas em histórias é uma boa ideia? Escrevemos as histórias da maneira errada?

Acho que as histórias de usuários têm valor como veredicto explícito dado pelo cliente. Mas se eles são mal organizados e insuficientemente detalhados (ou vagos), há um problema. A menos que você tenha uma estrutura maior para acumular um entendimento mais amplo (conhecimento do domínio) e escopo (especificação total). Histórias de usuários apenas para segmentos ou elementos em sistemas maiores.

PS: Eu tenho uma opinião exata sobre casos de uso (como eles são representados em diagramas ovais) que, a menos que você os coloque no contexto apropriado e na granularidade adequada, eles não fazem um bom trabalho. (Eu os chamo de casos inúteis ). A única fonte credível que acho para tornar a escrita de casos de uso verdadeiramente escalável e significativa é escrever casos de uso eficazes da Cockburn

> Writing specs by stories? a good idea?

Sim, se você pode gerenciar interdependências e prioridades de suas histórias.

Aqui está um artigo sobre mapas de histórias que podem ajudá-lo a solicitar e gerenciar muitos estoques de usuários.

No momento em que escrevi esta resposta, percebi que não se trata de testes, mas de documentação. Você deve ler primeiro o manifesto ágil :

[Valorizamos] o software de trabalho em vez de uma documentação abrangente

Portanto, você deve tornar suas especificações executáveis, ou seja, escrevê-las como um conjunto de testes totalmente automatizado.

Escrever especificações baseadas em histórias é uma boa ideia?

Sim, sim, é. É chamado de "desenvolvimento orientado a comportamento" ou "especificação por exemplo". Em rubi, há um ótimo pepino para ferramentas que ajuda muito nisso.

O problema agora é que, por haver tantas histórias, não fica claro de imediato para qualquer parte do sistema em que as histórias se relacionam.

Por que você quer que fique claro? Quero dizer, você realmente precisa de uma matriz de rastreabilidade "teste / código"? A vantagem de escrever testes como uma especificação é que você não precisa de uma rastreabilidade "requisitos / testes" separada, porque os testes se tornam requisitos. Para fins de teste de integração, você deve tratar seu software como um todo, não como partes separadas.

Você pode precisar de uma ferramenta de cobertura para verificar se existem módulos "mortos", partes do seu sistema não cobertas pelos testes de especificação. Mas você realmente não deve se importar com a especificação a que esse código específico corresponde. Deve ser vice-versa: de uma especificação específica, você deve saber qual parte do sistema corresponde a ela. Você não deve se preocupar com alguma duplicação em suas especificações. E se você aplicar um princípio DRY ao seu código, haverá dezenas de especificações executando o mesmo código.

Funciona no momento dos desenvolvedores, a cada sprint os desenvolvedores recebem apenas uma especificação descrevendo o que precisam fazer e as mudanças que precisam fazer. Mas, em termos de manutenção dessa lista de histórias e de teste, está começando a ficar realmente difícil rastrear bugs e, em geral, apenas mantendo as especificações, porque uma parte da funcionalidade na tela pode ter sido documentada em vários lugares diferentes devido ao fato de ser dividido por história.

Não é incomum que centenas de testes de integração sejam interrompidos por uma pequena alteração em um módulo crítico. É aí que entra o teste de unidade.

Você deve estruturar seus testes como tal para poder saber se um teste específico cobre um requisito de alto nível ou apenas um detalhe sutil. Nesse último caso, você deve separar esse teste do seu conjunto de testes de integração. O objetivo do teste de unidade é localizar erros. Portanto, se você introduzir um bug, haverá uma e apenas uma falha no teste.

Escrevemos as histórias da maneira errada?

Eu acho que você só precisa organizar suas histórias em épicos por usuário, por exemplo, "Cliente", "Assistente" ou por recursos / telas / fluxos de trabalho ("Compra", "Reembolso").

E, novamente, os testes de especificação não substituem os testes de unidade. Consulte Mais informação

Você mencionou um problema e a maneira como o resolve, mas esquece de mencionar alguns exemplos de suas especificações e agrupamento e como isso está relacionado à maneira como você desenvolve seu produto.

Escrever especificações por histórias? uma boa ideia?

O Agile não o proíbe. No Agile, você pode fazer o que for necessário para oferecer o máximo valor comercial em ritmo sustentável. Portanto, se escrever especificações é algo que você precisa para agregar mais valor aos negócios, não há problema em fazê-lo.

Seu exemplo mostra duas histórias de usuário. Talvez eles estejam de alguma forma relacionados à sua lógica de negócios, mas esse é um cenário muito comum.

Se você precisar bactrack a funcionalidade para histórias de usuário, poderá novamente usar o que melhor lhe convier, incluindo documentação, alguns diagramas ou sua "especificação", mas você deve estar preparado para manter esses artefatos custando mais à medida que a complexidade do aplicativo desenvolvido aumenta. Portanto, a única pergunta que você deve responder neste caso é: Se eu não usar minhas especificações, isso nos custará mais? Se a resposta for sim, você escolheu uma opção melhor.

O ágil funciona melhor para projetos pequenos e médios com equipe pequena, onde toda a arquitetura é realizada como conhecimento tácito compartilhado na equipe. Durante o planejamento da iteração, você analisará suas histórias selecionadas, discutirá um impacto na implementação atual e escreverá algumas tarefas necessárias para concluir a história. A documentação real nesse caso será a suíte de testes com aceitação automática e integração / testes de unidade. Depois que seu SW ou equipe crescer, o conhecimento tácito terá que passar parcialmente para alguma documentação.

Agora é aqui que a abstração desempenha um papel importante. Você precisa examinar as histórias com respeito à perspectiva relevante. Reúna os substantivos e verbos nas frases e confirme-os. Você não pode basear seus modelos em suposições pessoais. Também preste atenção aos detalhes.

Escrever especificações com base nas histórias do usuário não pode ser preciso. Você precisa cavar detalhes extras e, às vezes, ignorar os detalhes que não são relevantes. As especificações devem ser escritas quando o modelo estiver completo e preciso após a confirmação do analista.