Agile - Usuário História Definições [fechado]

Question

Eu estou escrevendo um pequeno aplicativo para o negócio do meu amigo, e pensei em aproveitar a oportunidade para retocar em algum treinamento Agile Project Management eu fiz no início do ano.

I (! E eu acho, minha organização atual) têm sempre lutou com levantamento de requisitos na forma de User Stories, que tomam a forma:

Como [Tipo de Usuário] Eu quero [recurso], para que [algum benefício]

Eu sou sempre tentados a perder o início eo fim, e apenas deixar o recurso - mas isso, então só se torna coleta de requisitos da maneira antiga

Mas eu não quero apenas torná-lo apto, para que eu possa dizer 'eu estou fazendo Agile' .... por exemplo, se eu sei que o usuário deve ser apresentado com uma lista de itens, então a razão é auto-evidente, não é?

por exemplo.

Como [Store Manager] Eu quero [para ver uma lista de itens de estoque] para que ...?

É prática normal para deixar de fora a cláusula [para que]?

Answer 1

Nós usamos a perder para fora também. E, deixando-o para fora perdemos muito. Para entender o recurso corretamente e não apenas fazer a coisa certa, mas fazer o bem coisa que é a chave para saber por que o recurso, e para que a próxima tecla é OMS (o papel) Em termos DDD, das partes interessadas. As partes interessadas podem ser diferentes, todos que se importa. De programadores e administradores de banco de dados para todos os tipos de usuários.

Assim, entender primeiro, que é a parte interessada, então você sabe que 50% do por que ele se importa, então o benefício, e então ele já está quase obviamente, o que de implementar.

Tente não apenas escrever "como um usuário". Especificamos. "Como gerente da loja", ou mesmo "como o chumbo do turno responsável por fechar o dia", eu preciso .... para que ....

Talvez você possa implementar diferente algo que lhe dará o mesmo das partes interessadas ainda melhor benefício !!!

Answer 2

Tente, para alcançar [Business Value] Como [usuário] Eu preciso [recurso].

O objetivo é concentrar-se sobre o valor do recurso oferece. Ele ajuda você a pensar em fatias verticais, o que reduz puros "tarefas técnicas" que não são visíveis. Não é uma transição fácil, mas quando você começar a pensar na vertical você começa realmente ser capaz de reduzir os resíduos em seu processo.

Outra maneira é pensar nos testes de aceitação que seu cliente poderia escrever para garantir o recurso iria funcionar. É um salto curto para, em seguida, usando algo como FitNesse para automatizados desses testes.

Answer 3

Não, na verdade não é óbvio - há uma série de razões para querer ver uma lista, um monte de coisas que você pode querer com ele - digitalizá-lo para algumas informações, obter uma visão geral, imprimi-lo, copie e cole -lo em uma palavra documento etc. E o que exatamente é lhe dará dicas valiosas em detalhes razoáveis ??de implementação - a formatação da lista, o conteúdo exacto; ou mesmo um indício de que uma característica diferente pode ser uma idéia melhor para satisfazer essa necessidade. Não ser surpreendido ao descobrir que a razão realmente é "para que eu possa contar o número de entradas" ...

É claro, isso pode na verdade não se aplicar a você. Meu ponto real de fato é que existem razões que as pessoas vieram com esse modelo - e há também razões que muitas pessoas experientes na verdade, não usá-lo. E quando você é novo para a prática, você não está em uma boa posição para avaliar todos os prós e contras de seguir uma prática, por isso eu recomendo que simplesmente tentar segui-lo de perto por algum tempo. Você pode se surpreender com a utilidade dela - ou não, caso em que você ainda aprendeu algo e pode soltá-lo com uma clara e concisa ...:)

Answer 4

User Stories é outra maneira de dizer que você precisa para entrevistar seus usuários para descobrir o que eles querem e quais os problemas que estão tentando resolver. Que o coração de ter isso em desenvolvimento ágil. Se o formulário não está trabalhando para o seu em seguida, tomar um passo para trás e tentar uma abordagem diferente que se sente mais natural para você ou melhor adaptados às suas capacidades como escritor.

Em suma, não se sentir como você tem que estar em uma camisa de força. O importante é que você siga o espírito da metodologia.

Neste caso específico que você deseja obter uma lista dos problemas que o usuário tem, por que eles são problemas, eo que eles acham que vai ajudá-los.

Answer 5

Eu acho que você realmente deve tentar obter uma razão definida, mesmo que isso possa parecer óbvio. Se você não pode vir até com uma razão, então por que construir o recurso, em primeiro lugar? Também a razão pode apontar outras deficiências no projeto que poderia provocar melhorias em outras áreas.

Answer 6

Muitas vezes categorizar as minhas histórias pelo usuário / persona que se relaciona principalmente para, assim, eu não colocar a identidade do usuário no título história. Minhas histórias também são maiores do que algumas metodologias ágeis sugerir. Normalmente, eu começo com um título. Eu usá-lo para fins de planejamento. Uma vez que eu chegar perto de realmente trabalhando nisso história, eu completá-lo com alguns detalhes - idéia básica, restrições, suposições, histórias relacionadas - para que eu capturar mais da informação que eu sei sobre isso. Eu também manter minhas histórias em um wiki, e não em cartões de nota. Eu entendo o trade-off - ou seja, eu posso passar muito tempo em detalhes antes de eu precisar deles, mas eu sou capaz de capturar e compartilhar com ele, normalmente, os clientes fora do local facilmente

.

A linha inferior para mim é que Agile é uma filosofia, ao invés de uma especificação. Existem implementações específicas que podem (fortemente) sugerir que você fazer as coisas de uma certa maneira e pode ser inegociável em alguns itens. Por exemplo, é difícil dizer que está fazendo XP, se você não programa par. Em geral, porém, eu diria que a maioria agilistas diria que você deve fazer essas coisas que o trabalho para você, da maneira que eles trabalham para você - contanto que eles sejam consistentes com os princípios gerais, você pode ainda chamada -se ágil. Os princípios gerais que incluem coisas como libertação antecipada / liberar muitas vezes, testes unitários, iterações curtas, reconhecer que a mudança vai acontecer, planejamento atraso detalhado até que esteja pronto para implementar, ...

A linha inferior para mim: se as histórias trabalhar para você sem que o usuário e lógica - contanto que você compreender quem é o usuário e por que eles querem algo - fazê-lo como quiser. Só não exigem uma especificação completa antes de iniciar a execução.