Como lidar com histórias que compartilham funcionalidades

27

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.

Joe Young
fonte
4
se você usar "histórias técnicas do usuário", saiba que existem três coisas aqui, não 4. As diferenças que você calcula do seu modelo e dois tipos de visualizações, uma visualização em PDF e uma GUI. Você está apenas apresentando o relatório de maneira diferente.
candied_orange
11
Enfrente um deles. Em seguida, enfrentar o outro. É simples assim.
Ant P
Por que eles são duas histórias?
Jeffo

Respostas:

55

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.

Robert Harvey
fonte
3
Na verdade, estava começando a escrever algo muito semelhante, mas essa resposta já cobre todos os aspectos meus, então +1.
Doc Brown
O mesmo aqui, mantenha a implementação fora disso.
candied_orange
11
@ JoeYoung: os detalhes da implementação vão para a implementação, onde mais? E como você diz isso a outro desenvolvedor depende da estrutura de comunicação da sua equipe. Obviamente, pode haver um requisito funcional envolvido aqui, como "ao visualizar diferenças de folha de pagamento on-line ou ao recuperá-las como PDF, é importante obter exatamente o mesmo conteúdo nos dois casos" . Se for esse o caso, adicione isso como uma observação a pelo menos uma (melhor ambas) histórias de usuários. No entanto, não descreva como esse requisito será implementado na história.
Doc Brown
3
Design não é dizer a um desenvolvedor como resolver problemas. É dizer a um desenvolvedor quais problemas resolver.
candied_orange
11
Quando você avalia o custo do tempo dessas histórias, como as classifica? Digamos que a parte de consulta comum demore 5 horas, a parte de visualização na Web leva 6 horas e a parte de visualização em PDF leva 7 horas. Você estima o tempo, diz arbitrariamente que um custa 11 horas (5 + 6) e o outro 7 (ou vice-versa: 12 e 6), ou estima-os em 6 e 7, mas observe em algum outro local como as despesas gerais de 5 horas para os dois combinadas? 11 e 12 (os 5 adicionados a ambos)? Se você disser "Este modelo não se destina a lidar com esses casos. Apenas fale". ainda pode ser gravado em um storyboard, mas como?
Aaron
15

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.

Ewan
fonte
4

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
Berin Loritsch
fonte
Vale a pena notar que você não precisa necessariamente documentar mais do que a história. A história fornece o contexto em nível de negócios. O rastreamento mais granular que você precisa depende de você (e depende em grande parte das restrições organizacionais). Você deve minimizá-lo (pessoas em processo e tudo isso).
Ant P
@ AntP, concordou, mas isso vai para a Definição de Concluído (DoD) e deve caber na parte traseira do seu cartão 3x5 que contém a história do usuário.
Berin Loritsch
2

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.

Ilessa
fonte
2

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.

CodeGnome
fonte