Atualmente, usamos o JIRA para rastrear nosso trabalho de desenvolvimento. Meu gerenciamento quer formatar e categorizar tudo como "Histórias de usuários", incluindo tarefas não relacionadas ao desenvolvimento de software. Por exemplo:

"Como gerente de teste, posso executar o teste do aplicativo usando apenas testes automatizados e nenhum teste manual para poder testar o aplicativo da maneira mais eficiente possível?

Critérios de aceitação: 1. Converta 50 testes manuais existentes em testes totalmente automatizados 2. Os testes devem ser executados em menos de 1 hora "

Quero entender a comunidade se faz sentido usar "histórias de usuários" para trabalhos que suportam o processo de desenvolvimento de software, não são realizados pelos programadores e não resultam diretamente em código de entrega. Ou isso deve ser tratado / classificado de maneira diferente (por exemplo, no JIRA)?

Atualizado em 7/7/2011 - Pergunta reformulada para se concentrar no termo "história do usuário".

sim

qualquer parte interessada, qualquer recurso que melhore o sistema

[que comecem os votos puristas!]

"Minha gerência quer usar o Agile para tudo, incluindo tarefas não relacionadas ao desenvolvimento de software".

Isso não significa escrever histórias de usuários para todos os recursos.

Se você deseja escrever histórias de usuários para todos os recursos, não está necessariamente sendo ágil. Você está apenas escrevendo histórias de usuários para todos os recursos.

Histórias de usuários! = Ágil.

Histórias de usuários é uma maneira de reunir e entender requisitos. Eles podem ser usados ​​perfeitamente em cascata, se você quiser. Algumas pessoas fazem isso.

Agile é uma maneira de gerenciar projetos. Você pode usar Histórias de Usuário, ou não, em um projeto Agile.

Histórias de usuários para gerenciar dívidas técnicas e tarefas internas - novamente - nada têm a ver com ser ágil.

Muitas pessoas estão perfeitamente felizes em adicionar recursos "técnicos" ou "de suporte" a um sprint sem perder tempo escrevendo uma "história de usuário" falsa para usuários não internos, com pouco valor agregado e que não interessam.

Se o controle de qualidade não obtiver a história, quanta perda real de negócios existe?

Se as partes interessadas reais não obtiverem suas histórias, a empresa realmente sofre.

Isso não faz sentido para mim. Uma 'História do usuário' em essência é apenas isso, uma história do usuário, não uma história do gerente de projetos, não uma história do desenvolvedor, nem uma história do engenheiro de garantia da qualidade.

Nessa nota, o software é:

1. Definível
2. Testável

As melhorias no processo são abertas e geralmente subjetivas.

Critérios de aceitação: 1. Melhoria no teste 1 (por x / a)

Como você mede a melhoria nos testes? Não há contrato definível para isso.

E em uma nota não relacionada, ESPERAMOS sinceramente que o seu exemplo dado acima,

Como gerente de teste, posso executar o teste do aplicativo usando apenas testes automatizados e nenhum teste manual para que eu possa testar o aplicativo da forma mais eficiente possível?

... é apenas um exemplo, porque há tanta coisa errada nisso que nem consigo começar a descrever.

Dívida técnica pode ser tratada de maneira semelhante a uma história de usuário, mas isso pode se tornar bastante feio às vezes. Por exemplo, ter uma história como "Como desenvolvedor, quero ter testes de unidade em funcionamento para ter confiança nos testes para validar se outras alterações quebram algo", não tem muito valor para o proprietário do produto mas pode ser uma boa idéia para a equipe fazer parte de sua própria refatoração que faz parte do trabalho em um sprint.

Gosto da ideia de ter tarefas separadas das histórias do usuário, pois as tarefas não serão algo que você mostraria ao usuário final de um sistema, mas podem ajudar a melhorar a manutenção e o tempo que leva para desenvolva algum novo recurso. Dependendo de quantas tarefas, em termos de totais totais de pontos, algumas tarefas podem durar 2 minutos e outras podem levar 2 semanas, foram criadas. Isso pode ser o que determina se a equipe faz um sprint e não coloca novos recursos, mas funciona em tarefas para limpar coisas que já vi algumas vezes em que trabalho.

Na minha humilde opinião, sim, você pode usar histórias de usuários para projetos de desenvolvimento que não são de software, não apenas tarefas de melhoria de processos. Por exemplo, há 3 anos, eu era o padrinho de casamento do meu amigo e usei a metodologia Agile e as histórias de usuários para planejar o casamento. Todas as tarefas que tivemos que concluir foram escritas como histórias de usuário com critérios de persona, intenção, justificativa e sucesso para cada história de usuário. Todas as partes envolvidas participaram do nosso scrum diário para discutir o que fizemos no dia anterior e o que faríamos naquele dia. Todos estavam geograficamente dispersos, por isso realizamos teleconferências para nossas reuniões diárias de scrum, planejamento de sprints, retrospectivas, sessões de redação e estimativa de histórias ... você escolhe, nós fizemos. Tivemos 6 corridas no total (3 meses) e o casamento foi um sucesso impressionante, sem deixar pedra sobre pedra.

Você tem um problema profundo quando coloca "histórias de usuários" internas na mistura com histórias de usuários reais.

Releia quantas definições de "parte interessada" puder encontrar.

http://en.wikipedia.org/wiki/Scrum_(development )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

Leia-os com muito, muito cuidado, para que você possa ver a diferença entre Galinhas e Porcos.

As "histórias de usuários" internas são escritas por galinhas.

Histórias de usuários reais são escritas por porcos.

Suas histórias de usuários "orientadas para galinhas" não são muito importantes. Não importa o quanto a gerência queira rastreá-los como se fossem histórias reais de usuários com valor real, elas não são histórias reais de usuários e não criam valor da mesma maneira.

No limite embaçado do argumento está a questão do controle de qualidade. O controle de qualidade é importante e, sem ele, nada funciona.

Isso não faz magicamente o controle de qualidade de repente um porco. Ainda os torna um não interessado. Eles fornecem suporte, infraestrutura e uma base essencial para o restante do trabalho. Mas elas são "histórias de usuários" são essencialmente diferentes das histórias de usuários reais do usuário real.

Se o controle de qualidade não mostrar um aprimoramento nos testes, ninguém sai do negócio. Dinheiro não está perdido.

Se o usuário não puder realizar negócios em primeiro lugar, você estará fora do negócio. Dinheiro está perdido. Toda a operação é uma falha total.

Não misture partes interessadas internas ("galinha") e reais ("porco").

O comentário "galinhas e porcos" erra o alvo. As partes interessadas internas são galinhas no que diz respeito ao produto que está sendo desenvolvido (a menos que esteja sendo desenvolvido para elas), mas são porcos no que diz respeito ao processo de desenvolvimento.

A pergunta que você está fazendo é se a fórmula da frase "Como um , Eu gostaria de poder _ , para que eu possa __ "seria útil para definir e melhorar os processos de negócios onde as melhorias não exigem a criação de um novo código de software. Encontrei esse segmento porque estou pensando em fazer a mesma coisa e procurando as melhores práticas, mas minha forte intuição é que a resposta à sua pergunta é "sim". O objetivo da estrutura da sentença é realmente forçar o escritor a abstrair soluções que ele já deve ter em mente e se concentrar no que o usuário - nesse caso, o usuário do processo - queira fazer isso.Não vejo razão para que a história do usuário não seja útil quando aplicada ao processo.

O ponto sobre os critérios de aceitação é bom, mas não precisa ser dogmático (o que é Agile de qualquer maneira). É um bom exercício ao projetar qualquer processo de negócios para perguntar: "Como saberei se a mudança no processo alcançou meu objetivo?" É verdade que nem sempre é possível executar um teste automatizado para responder a essa pergunta, mas esse não é um motivo para desqualificar a história do usuário como ferramenta.