Que tipo de histórias de usuários devem ser escritas nos estágios iniciais de um projeto?

Ao iniciar um projeto, você não tem nada --- nenhuma interface do usuário, nenhuma camada de dados, nada no meio. Assim, uma única história como "os usuários devem poder ver seus amigos" exigirá muito trabalho. Depois de ter essa história, alguém como "os usuários devem poder editar seus foos" é mais realista, mas essa primeira história envolverá a configuração de uma camada de interface do usuário, uma camada de lógica de apresentação, uma camada de lógica de domínio e uma camada de acesso a dados.

Isso não se encaixa no meu conceito de "tarefas": para mim, prefiro algo como as seguintes "tarefas":

• Mostrar dados fictícios para os foos de um usuário em HTML, derivados de objetos JavaScript.
• Configurar uma camada lógica de apresentação, e ligue o JavaScript objetos a ele.
• Configure uma camada lógica de domínio e conecte a camada lógica de apresentação a ela.
• Configure uma camada de acesso a dados e conecte a camada lógica do domínio a ela.

Tudo isso se enquadra na única "história" acima? Nesse caso, sinto que as histórias não são uma estrutura muito útil nos estágios iniciais de um projeto. Se assim for, tudo bem - só quero ter certeza de que não estou perdendo algo, pois estou realmente tentando aprender essa metodologia ágil da melhor maneira possível.

Essa é uma boa pergunta e provavelmente há várias boas respostas para ela. Minha opinião é esta:

Uma história é uma história do usuário, portanto deve ser definida em termos que descrevam como ela beneficia o usuário.

Se o Agile e as histórias vão funcionar para você, eles devem funcionar mesmo nos estágios iniciais. O primeiro ponto é uma história de usuário único (embora um pouco tecnológica), mas os outros três são descrições de tarefas técnicas.

Nos estágios iniciais de um projeto, quando você não tem os níveis adequados no local para fazer CRUD ( C reate, R ead, U pdate, D elete) rápida desenvolvimento e fácil, suas histórias precisam ser de muito menor e incremental peças.

Em vez de "O usuário deve poder visualizar o seu foo" , algo como isto:

1. O usuário deve poder ver uma página com dados de amostra
2. O usuário deve poder ver uma página com dados de amostra interativos
3. O usuário deve poder ver uma página com dados de amostra interativos ao vivo

Lembre-se de que a maioria das histórias de usuários que parecem grandes demais para se desenvolver em um único sprint (eu descobri que qualquer coisa maior que cerca de 8 pontos da história, ou dias de desenvolvimento, era muito grande) provavelmente pode ser dividida em partes que ainda são significativas para o usuário.

A matéria / recurso não precisa ser comercializável, apenas tem significado para o proprietário do produto. No caso acima, você pode colocar algumas peças de demonstração rápidas para mostrar o que mudou e como essa história está concluída - por exemplo, para o # 3, você pode mostrar a página para dois usuários diferentes com dados pré-preenchidos no banco de dados . No estágio 2, todos os usuários verão os mesmos dados.

O que você está perguntando é essencial "como você pensa sobre o espaço do problema", a fim de dividi-lo em partes sensíveis, das quais você pode fazer um design.

Se você chama isso de história do usuário, análise, decomposição, especificação ou coleta de requisitos ... no final, tudo se resume a várias coisas que normalmente terão alguma iteração.

Você precisa obter das cabeças dos usuários o que elas querem. (Eles provavelmente sabem um pouco do que querem e desejam coisas inconsistentes, mas ainda não conseguem ver isso.)

Você precisa capturar isso de alguma forma - você realmente só tem duas opções: palavras ou imagens. Ambos têm poder, use os dois, se puder. Em última análise, as palavras são mais poderosas do ponto de vista de uma disputa contratual.

Você precisa apresentar isso de volta e buscar um acordo.

Algumas pessoas fazem protótipos visuais precoces sem nenhum negócio ou outra lógica por trás. Essa pode ser uma técnica poderosa - até certo ponto, porque ainda envolve uma certa quantidade de movimento da mão.

Alguns irão fazer um storyboard - e então apresentar e explicar.

Alguns escreverão documentos rigorosos e cuidadosamente analisados.

Cada técnica tem suas vantagens e desvantagens.

Sobre o único conselho que eu daria é: Saltar para codificar uma solução muito cedo geralmente é uma má decisão. Entender o que fazer, para a OMS e por que, antes de você, geralmente leva a menos retrabalho e um desenvolvimento mais rápido.

Quando você fala sobre "tarefas", isso me parece algum tipo de detalhamento do trabalho, depois de descobrir o que, quem e por quê. Você não pode descobrir bem as tarefas até que a história do usuário seja entendida, em um documento, aprovada pelo cliente como o escopo do trabalho que você fará. Saber o que você precisa alcançar (a saída) permite que você descubra as tarefas (as etapas envolvidas na chegada).

Não economize na análise e documentação do front-end.

Acho que o que está faltando é que as histórias de usuários descrevem como o usuário espera usar o sistema. Essa é uma maneira de determinar os requisitos de negócios . Eles não foram projetados para dizer diretamente o que fazer tecnicamente, que é o que você parece querer.

Esta é sem dúvida uma das partes mais importantes de um projeto. Se você não acertar os requisitos de negócios, o sistema não será útil para os usuários.