User Stories - Problemas que não podem ser feitas histórias de usuários [fechado]
-
19-09-2019 - |
Pergunta
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
- A sua grande demais (O desenvolvedor não terá nada para mostrar até o final de 5 semanas).
- é 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) .
Solução
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 ...
Outras dicas
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).
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.
usuários / desenvolvedores que histórias não vai escrita ??p>
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.
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.
- 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.
- 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 .
- 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.
É 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
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