User Stories - Problemas que não podem ser feitas histórias de usuários [fechado]

Question

Eu sou de um fundo XP. Eu sei que o processo muito bem e têm experiência de trabalho sólida com ele. Eu encontrei-o para ser a melhor maneira de desenvolver software.

eu me encontrar na posição de um médico processo de tipos e isso cria muita auto-exame e reavaliação dos meus próprios entendimentos.

Um muito comum coisa que ouço é que algum trabalho não pode ser feito em histórias. Eu, pessoalmente, não acredito nisso. As desculpas incluem

1. A sua grande demais (O desenvolvedor não terá nada para mostrar até o final de 5 semanas).
2. é um algoritmo complicado ou conceito abstrato (terá 5 semanas para escrever e nada para show).

Esta questão é obter sugestões, dicas ou sugestões.

Eu estou procurando sugestões, dicas e sugestões sobre a forma de abordar estas e outras problemas percebidos (e mais, se você pode pensar neles).

eu vou marcar a resposta que tem mais informações sobre como contornar os usuários / desenvolvedores que histórias não vai escrever e endereço de suas muitas desculpas a respeito de porque não (eu só listei alguns e há muitos mais) .

Answer 1

Então, basicamente, a sua pergunta é "O que posso fazer se as pessoas reivindicam uma tarefa é grande demais para uma história de usuário, e não pode ser dividido.

Na minha experiência, quase qualquer problema pode ser dividido. Pergunte a eles se podem implementar uma versão simplificada, deixar de fora os recursos avançados, talvez até mesmo usar os valores padrão em alguns lugares; basicamente qualquer coisa para produzir algo que dá sentido (ou seja testáveis) resultados dentro de uma iteração.

Lembre-se:. O ponto de uma iteração não é para oferecer funcionalidade completa, mas a funcionalidade apenas útil e testável

Esta divisão pode ser difícil, mas obriga a considerar o que você realmente precisa em primeiro lugar, que é muito valioso. Os desenvolvedores podem cadela sobre ele (eu muitas vezes fazem-me :-)), mas é realmente necessário. Quebrar grandes tarefas em histórias de usuários gerenciáveis ??está no coração de todos os métodos ágeis.

Dito isto, se a tarefa realmente, realmente, realmente não pode ser discriminado (pense algoritmo matemático complexo em um ambiente de pesquisa, que leva semanas para sequer entender os conceitos básicos de), então a sua iteração é curto demais. A iteração precisa ser longa o suficiente para produzir resultados significativos. E se a maioria dos seus problemas são tão difícil que eles tomam 2-3 meses para fazer qualquer coisa, então esse é o seu comprimento iteração. Mas eu nunca vi um projeto onde isso era realmente o caso ...

Answer 2

Aqui estão alguns recursos que eu coletei ao longo do tempo e que ajuda poder:

• Padrões para Stories Splitting Usuários
• história de Redução de Peso Toolkit
• Vinte Maneiras de Histórias Dividir
• maneiras de histórias de usuários divididos

grande demais ou muito complicado, há sempre uma maneira de colocar uma história sobre dieta (talvez você não vai obter o resultado final em uma iteração, mas isso não significa que você não pode e, assim, haverá mais do que uma iteração).

Answer 3

Normalmente, quando você começa "é muito grande", o que eles realmente estão dizendo é "Eu só tenho uma vaga idéia de como isso deve funcionar". Você precisa trabalhar com eles para melhor defini-lo até que se torne possível dividi-lo em partes lógicas que podem ser mais facilmente gerenciados.

Answer 4

usuários / desenvolvedores que histórias não vai escrita

Os usuários não devem histórias de usuários de gravação. Eles não devem dizer-lhe histórias de usuários. Você pode esperar que eles falam sobre como eles funcionam, os problemas que os incomodam e que eles gostariam de ter para facilitar o seu trabalho diário.

Você, por sua vez, é suposto para ouvi-los e tomar notas. Se eles permitem, use um gravador ou uma câmera. Então você trazer as informações de volta coletadas quando você reproduzi-la e identificar o que você chama de histórias de usuários. Você discuti-los com a equipe e quando você tem acordo que você tem casos de uso de meta em seu desenvolvimento.

O que os desenvolvedores papel desempenhado, é até você. Se eles só codificadores, eles não tomam parte no processo. Se eles, em parte, atuam como consultores, então eles ajudam a definir as histórias de usuário.

Answer 5

O problema "especificação algorítmica" é comum.

Muitas pessoas preferem escrever código e realmente não me importo quem é o usuário ou o que eles fazem.

Eu tento levá-los a concentrar-se por fazer estas perguntas.

1. Que medidas pode a pessoa take? O que eles poderiam possivelmente do com as informações? Se eles têm alguma responsabilidade, eles podem tomar medidas para negar, aprovar, espera, rejeitar, reprocess, parar, iniciar alguma coisa. Se o usuário não pode tomar qualquer acção, você precisa perguntar se eles são realmente stake-holders.
2. Que decisão que eles têm que fazer? Como a decidir qual a acção (se houver) para tomar? Não podemos automatizar essa decisão - é por isso que pessoas estão no loop
.
3. Que informação faz esta necessidade pessoa a tomar a decisão de agir.

Informações-decisão-ação.

Nós só software de gravação para preparar informações para as pessoas a tomar decisões para que eles possam tomar medidas.

Se isso não é o foco, então as histórias ficar fora de controle.

Answer 6

É basicamente o dever ea responsabilidade do proprietário do produto. E não pode haver qualquer requisitos / tarefa que não pode ser dividido em User Stories. Eu encontrei muitas dessas discussões sobre Scrum Master Fóruns

Answer 7

Se as reivindicações da equipe de desenvolvimento que a história é muito grande e não pode caber dentro da Sprint .. tomar o seu feedback e tentar dividir a história com deve ter e bom ter tarefas e tentar dividi-lo com base nisso.

verificar este fluxograma .. pode ser uma ajuda: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf