Quebrando uma história complexa no início do projeto

Eu estou tentando entender o gerenciamento ágil de projetos (com o Pivotal Tracker), mas continuo me encontrando correndo pelas paredes ao tentar definir as primeiras histórias de um projeto. Tomemos, por exemplo, esta história muito simples:

"Um usuário deve poder marcar um produto"

Supondo que eu já tenha definido "produto" em outro lugar, essa história possivelmente envolveria a criação de um sistema de marcação polimórfica sob o capô, após a conclusão dessa identificação do sistema, seria possível finalmente adicionar a capacidade de marcar um produto.

Meu problema é com a quantidade de trabalho oculta nesta história. Posso definir tarefas para concluir a história, mas as histórias como um todo devem ter um ou dois dias de trabalho? Não me sinto bem com a história, apenas revelando a ponta do iceberg, mas essa é a única parte relacionada ao Usuário.

Como você supera esse tipo de coisa? quais são as melhores práticas?

ATUALIZAÇÃO 25/08 Obrigado a todos por sua orientação, recebi todos os conselhos de como definir histórias. Agora estou mudando para Jira Grasshopper, que oferece melhor suporte para tarefas dentro de histórias (atribuição, estimativas, etc.) e acompanhamento de tarefas de desenvolvimento assim que o sprint é iniciado.

Se você precisa de suas histórias para ser de 1 a 2 dias de desenvolvedor trabalho cada, talvez você deve quebrar cada história em tarefas específicas do usuário que são 1 a 2 dias de trabalho do desenvolvedor.

Considere a seguinte "história do usuário:"

Um usuário deve poder receber uma fatura de um produto adquirido.

Pense no que está envolvido apenas no design do banco de dados, oferecendo ao usuário esse recurso. Você precisa de uma tabela de clientes, uma tabela de cabeçalho da fatura e uma tabela de itens de linha da fatura, e ainda nem falamos em aceitar pagamentos.

Na realidade, as histórias de usuários não são tão simples. As histórias completas do usuário incluem uma explicação das etapas do usuário envolvidas:

• Usuário coloca o produto no carrinho
• Usuário especifica quantidade
• Usuário especifica o tipo de remessa

e assim por diante. Em resumo, você precisa dividir suas histórias de usuário em detalhes mais finos.

As histórias não deveriam ser "1-2 dias de trabalho". Sob Scrum, as histórias são normalmente estimadas usando Story Points, um sistema de dimensionamento relativo. Se você usar o planejamento de histórias de poker , receberá um valor em pontos - o tempo que a história leva para implementar depende da velocidade que sua equipe estabeleceu.

Se você acha que a história está escondendo complexidade (você pode chamar de história épica ), divida-a em histórias menores. Certifique-se de que as novas histórias sigam os critérios do INVEST .

Mas você pode estar superengenhando isso; o princípio XP de YAGNI se aplica aqui. Para ser explícito, você não deve implementar um "sistema de marcação polimórfica sob o capô", a menos que você realmente precise. Mesmo assim, ele deve ser projetado melhorando o sistema existente, que você desenvolveu com um bom conjunto de testes.

Se você tiver certeza de que precisa desse sistema de marcação complexo, convide a complexidade em histórias separadas. Mike Cohn descreve a abordagem do design como " Intencional, mas emergente "

Parece que você está confundindo histórias e tarefas.

História do usuário

Uma história de usuário é um "recurso" completo, algo que, quando adicionado ao produto, agrega mais valor ao produto.

Uma história de usuário não deve ser maior do que pode ser implementada durante um sprint . Durante a primeira parte do planejamento do sprint, você decide em quais histórias de usuário deseja trabalhar durante o sprint. O objetivo do sprint é concluir essas histórias de usuários, agregando mais valor ao produto.

Tarefa

Durante a segunda parte da fase de planejamento do sprint, os desenvolvedores dividem a história em tarefas . As tarefas são tarefas de desenvolvimento. Eles podem ser do tipo "Adicionar coluna ao banco de dados", "Estender serviço x" etc. etc. Uma tarefa não deve ser maior do que pode ser concluída em um dia.

Durante o scrum diário, você avalia o progresso dessas tarefas. Se uma tarefa estiver em andamento há mais de um scrum diário, está demorando muito e você, como equipe, tem a responsabilidade de resolver essa situação.

Lembre-se de que as histórias de usuários representam valor comercial para as partes interessadas. Os interessados ​​devem estar interessados ​​na conclusão das histórias de usuários, não nas tarefas.

A divisão de tarefas é uma ferramenta para a equipe de desenvolvimento gerenciar o sprint, monitorar o progresso das histórias de usuários durante um sprint e visualizar possíveis problemas.

Os interessados ​​não devem se preocupar com essas tarefas de desenvolvimento. Infelizmente, é minha experiência que eles costumam fazer, principalmente para organizações novas no desenvolvimento ágil. Lidar com esta situação é uma questão diferente.

Épico

Se uma história de usuário é maior do que você pensa que pode ser concluída em um sprint, ela é chamada de épica. Ele precisa ser dividido em várias histórias de usuário menores antes que você, como equipe, possa começar a trabalhar nela.

Lembre-se de que uma história de usuário agrega valor ao usuário final, portanto, dividir um épico em um "front-end" e um "back-end" não é o caminho certo. A adição do back-end para um novo recurso não fornece, por si só, valor aos usuários finais.

Dividir um épico em histórias de usuário gerenciáveis ​​no período de um sprint nem sempre é fácil quando você não tem experiência em fazê-lo.

Usando o Rastreador Pivotal

Eu acho que o Pivotal Tracker é uma ótima ferramenta para rastrear histórias de usuários. Mas não é uma ferramenta de scrum, como tal, e a maneira como o scrum ensina a dividir histórias em tarefas não é facilmente manipulada pelo rastreador essencial. Você pode ativar a capacidade de adicionar tarefas às histórias do usuário. Mas se você estiver executando um projeto usando o scrum, sugiro usar um quadro branco e notas adesivas para acompanhar o andamento das tarefas durante um sprint.

Ter um objetivo de projeto de implementar um sistema de marcação polimórfica é bom, mas você ainda deve se concentrar na implementação dos recursos que o cliente deseja. Isso pode significar que, história do usuário refinada por história do usuário refinada, seu sistema evolui para um sistema de marcação polimórfica ao longo do tempo. Em qualquer ponto dessa jornada, no entanto, você deve ter um sistema composto por muitos recursos pequenos e testáveis, descritos por uma coleção de Histórias de Usuário que você implementou.

Nesse caso, parece que "etiquetar produtos" em seu sistema pode ser uma epopeia, ou seja, algo muito maior que uma única história de usuário e pode ser dividido em várias histórias menores com um pouco de esforço. Tomando uma quantidade razoável de licença artística, posso pensar nas seguintes Histórias de Usuário que podem ser aproximadamente aplicáveis ​​aos seus requisitos:

• Como administrador do sistema, quero propagar o sistema com algumas tags válidas para que os usuários tenham alguns valores para escolher quando usarem o recurso de marcação pela primeira vez.
• Como usuário do sistema, desejo procurar um produto pelo nome, para que eu possa etiquetá-lo mais tarde.
• Como usuário do sistema, quero poder ler a descrição de um produto para poder decidir quais tags ele deve ter.
• Como usuário do sistema, quero poder ver uma imagem do produto para poder decidir quais tags ele deve ter.
• Como usuário do sistema, desejo poder anexar uma única tag a um único produto.
• Como usuário do sistema, desejo remover uma única tag de um único produto.
• Como usuário do sistema, desejo poder anexar uma única tag a vários produtos.
• Como usuário do sistema, desejo poder anexar várias tags a um único produto.
• Como administrador do sistema, desejo ver uma lista distinta de tags em uso no sistema, para que eu possa decidir se alguma delas é duplicada.
• Como administrador do sistema, quero consolidar tags duplicadas.

... e eu poderia continuar.

Duvido que qualquer uma dessas opções seja tão realista que você as utilize, mas espero que elas ilustrem o tipo de detalhe que você pode obter com suas Histórias de Usuário.

Se uma história do usuário realmente não puder ser subdividida em histórias menores e você ainda considerar grande demais para tentar implementar de uma só vez, poderá dividi-la em fatias verticais. Esta é uma técnica que significa fornecer apenas parte do recurso em cada História do usuário, mas cada parte sendo uma fatia testável em todas as camadas relevantes da tecnologia, por exemplo, para um site, isso pode significar alterar as camadas de banco de dados, aplicativo e interface do usuário. Evite ter uma história do usuário para o banco de dados funcionando, outra para o aplicativo e outra para a interface do usuário, pois elas não serão testáveis ​​individualmente.

Tomando ainda mais licença artística, eu poderia dividir "Como usuário do sistema, desejo poder anexar uma única tag a um único produto". nas seguintes fatias verticais:

• Como usuário do sistema, olhando para um único produto, desejo procurar uma lista de tags para poder decidir qual aplicar.
• Como usuário do sistema que olha para um único produto, depois de ter decidido por uma tag para aplicar a esse produto, eu quero poder aplicá-lo.
• Como usuário do sistema que olha para um único produto, depois de aplicar uma tag a esse produto, desejo uma mensagem de confirmação na tela informando que ele foi salvo com sucesso.

Cada um deles é testável - se não for particularmente valioso por si só.

Existem livros escritos com o único objetivo de descobrir a maneira correta de descrever e detalhar seus requisitos. Portanto, não é uma tarefa fácil.

Muitas vezes, encontro equipes de desenvolvimento buscando soluções complexas em vez das mais simples. Isso pode ser devido à própria história ou porque a equipe quer buscar uma solução excessivamente complexa que não apenas a resolva, mas que também crie as bases para as histórias x, ye z. Essa é uma boa intenção, mas incha o escopo em que o mesmo trabalho pode ser feito com menos trabalho. É sempre difícil julgar o quanto o design deve entrar em uma história para não arruinar as histórias futuras, atrapalhando o design. Esta decisão é para a equipe tomar.

Como proprietário de um produto, você só pode influenciar isso dividindo as histórias em pedaços menores. Você deve se perguntar: a história é a menor solução em que podemos pensar agora? Podemos decompô-lo em conjuntos de recursos reduzidos que um dia se tornarão o "grande sistema de marcação flexível que eu sempre quis". Você pode começar com um sistema de tags para apenas uma única tag, estendê-lo para incluir uma lista de tags pré-selecionadas e permitir que o usuário defina tags etc.

Para a equipe de desenvolvimento, tudo se resume a: Podemos encontrar uma abordagem mais simples para realizar a história, mas ainda temos uma arquitetura sólida que realiza o trabalho hoje, sem comprometer os recursos futuros.

Se você está aberto a aceitar soluções intermediárias e a equipe de desenvolvimento também tenta oferecer a solução mais simples, mas boa, provavelmente encontrará o ponto ideal onde o tamanho das histórias que você deseja fazer é certo (quanto menor, melhor) . Isso não quer dizer que você tenha apenas pequenas histórias. Alguns são maiores que outros, isso é apenas um fato que você precisa aceitar ou, se eles são grandes demais, então divida as histórias em pedaços menores.