Como lidar com histórias que compartilham funcionalidades

Tenho duas histórias (sei que elas estão perdendo a parte do benefício)

1. Como usuário de gerenciamento de crédito, posso visualizar as diferenças de folha de pagamento atuais e anteriores dos escritórios.
2. Como usuário de gerenciamento de crédito, posso receber um email contendo um PDF das diferenças atuais e anteriores da folha de pagamento dos escritórios.

Os dois estão relacionados na medida em que teriam os mesmos critérios de Consulta / Filtro. A única diferença é que, na história "Visualizar", os resultados são exibidos ao usuário e, na história "E-mail", os resultados são gravados em um PDF enviado por e-mail ao usuário.

Estou lutando com a separação dos aspectos comuns dessas duas histórias ou se devo fazê-lo.

Por exemplo, ambos terão a mesma consulta, o que eles fazem com os resultados é diferente.

Devo separar a consulta em outra história puramente técnica?

A criação do PDF e o envio do email devem ser feitos offline, isso deve se tornar uma história técnica?

Eu pude ver dividindo essas duas histórias em duas histórias funcionais e duas histórias técnicas.

1. Como sistema, posso calcular as diferenças na folha de pagamento atual e anterior para escritórios.

2. Como usuário de gerenciamento de crédito, posso visualizar as diferenças na folha de pagamento atual e anterior dos escritórios.

3. Como sistema, posso criar um documento PDF das diferenças na folha de pagamento atual e anterior para escritórios.

4. Como usuário de gerenciamento de crédito, posso solicitar o recebimento de um email com um PDF das diferenças na folha de pagamento atual e anterior dos escritórios.

O problema ao qual eu sempre volto é que as 4 histórias não são independentes e não "cortam o bolo".

Portanto, não tenho muita certeza de como lidar com esses dois.

As histórias de usuário não são especificações do sistema ou requisitos funcionais. Em vez disso, eles são o início de uma conversa que pode levar a essas especificações ou requisitos.

Dessa forma, eu esperaria que houvesse sobreposição na implementação do sistema. As histórias de usuário não têm como objetivo descrever essa sobreposição funcional ou eliminá-la. O objetivo do User Stories é capturar expectativas funcionais do ponto de vista do usuário, não descrever os detalhes da implementação.

Não faça: tente dividir as histórias, faça uma história e depois a outra.

Fazer: verifique se a equipe de desenvolvimento está ciente da segunda história.

O problema de tentar planejar as tarefas detalhadas e criar um modelo genérico capaz de lidar com ambos de maneira elegante é que é difícil.

O objetivo das histórias de usuário é fazer as coisas. Elegante é um objetivo secundário e deve ser deixado para refatoração.

Obviamente, é super irritante se você levar isso ao máximo e não contar a ninguém sobre as dez outras tarefas semelhantes que precisam ser executadas, mas também é totalmente concebível que a segunda ou terceira tarefa não seja pensada até que a primeira seja concluída. Se você quiser planejar tudo, vá com cascata.

Em violento acordo com Robert Harvey, o objetivo de uma história de usuário é entender o que o usuário precisa ser capaz de fazer. À medida que você faz a limpeza, o cliente entende e se preocupa com a história do usuário, mas os desenvolvedores se preocupam um pouco mais. Depois de fazer perguntas suficientes para entender e estimar o trabalho, você pode criar tarefas para apoiá-los.

Nesse caso em particular, você pode criar tarefas que habilitem o núcleo de ambas as histórias de usuário que seriam executadas juntamente com o que você resolver primeiro.

As coisas importantes a serem adicionadas à história do usuário são:

• Critérios de aceitação
• Suposições

A rigor, as histórias de usuários são a promessa de uma conversa para entender o resultado necessário.

Por exemplo, usando sua segunda história de usuário

Como usuário de gerenciamento de crédito, posso receber um email contendo um PDF das diferenças atuais e anteriores da folha de pagamento dos escritórios.

Pense no seguinte:

• Qual é a "necessidade" do usuário que está impulsionando esse requisito? (O PDF em um email como solução vem deles? Isso pode não atender à necessidade e sua equipe pode encontrar uma solução melhor)
• Qual é a fatia mínima que pode atender à "necessidade" desse usuário e validar sua solução? Loops de feedback curtos são valiosos.

Ao abordar a divisão de histórias, lembre-se de seus critérios de INVISTA sempre que possível.

1. Eu independente
2. N egotiable
3. V aluable
4. E stimatable
5. S shopping
6. T estable

Não há problema em ter histórias com uma ordem natural. Leve isso em consideração - geralmente a primeira história é maior, pois traz a funcionalidade necessária e a segunda história se baseia nela.

Eu desafiaria as histórias "técnicas", pois geralmente elas são tarefas que ajudam a apoiar a implementação das histórias com foco no resultado do usuário.

TL; DR

Supondo que as duas histórias de usuário sejam inseridas no escopo na mesma iteração, é tarefa da equipe decompor as histórias em um plano de implementação e em suas tarefas correspondentes. Histórias de usuários fornecem contexto e escopo; eles não são implementações, especificações ou itens da lista de perfurações.

Histórias devem ser decompostas em tarefas de iteração

Esteja você seguindo o Scrum ou alguma outra metodologia ágil, é um erro comum pular a fase de planejamento de uma iteração. No Scrum, quando um Item de Backlog do Produto (não precisa ser uma história do usuário, estritamente falando) é inserido no Sprint atual, a equipe deve usar parte do Sprint Planning para fatorar pontos em comum entre itens de trabalho, identificar dependências e em seguida, desenvolva um Sprint Backlog para capturar o trabalho no nível da tarefa.

Como você apontou na sua postagem, não é incomum (e é de fato desejável) que uma iteração ágil contenha histórias de usuário intimamente relacionadas. No Scrum, isso aparece através do uso da Meta Sprint. Fora da estrutura do Scrum, muitas vezes ainda faz sentido extrair histórias relacionadas por causa de seus objetivos ou dependências compartilhadas. Ao extrair e depois trabalhar nas dependências compartilhadas em uma única iteração, as equipes podem evitar a necessidade de refatorar ou iterar o código para recursos semelhantes, mas não idênticos no futuro.

Tarefas Implementar Histórias

Aqui está outra maneira de pensar sobre o planejamento de dependências para histórias de usuários. Em geral:

1. Um épico / tema é usado para planejamento ou agrupamento de longo prazo em uma lista de pendências.
2. Uma história de usuário é usada para comunicar objetivos, contexto e escopo.
3. O planejamento just-in-time é usado para desenvolver uma implementação que se encaixa em uma única iteração.
4. As tarefas implementam o plano just-in-time que atende à Definição de Concluído para uma ou mais histórias de usuários.

Tratar histórias de usuários como um plano de implementação ou uma lista de tarefas é considerado pela maioria dos profissionais como um antipadrão ágil. Como você quiser, não pule a fase de planejamento just-in-time da sua estrutura ágil e verifique as dependências e os detalhes da implementação compartilhada em algum lugar do processo de sua equipe.