Reunir requisitos em uma metodologia ágil

5

No excelente livro Histórias de usuário aplicadas , o autor especificou o seguinte processo para requisitos de arrasto na forma de usuário histórias:

Crie funções de usuário (personas) - > crie metas de usuário para cada função - > Escreva histórias de usuário - >
estimar todas as histórias de usuário - > prioriza as histórias - > seleciona algumas histórias de usuário para a primeira versão - >
escreva critérios de aceitação para cada história - > divida cada história em tarefas - > estimar tarefas

No entanto, não entendo por que as ALL histórias devem ser estimadas primeiro e se elas precisam ser estimadas por que deixar os critérios de aceitação fora da história até a hora de trabalhar nela?

A próxima coisa é sobre os critérios de aceitação em si, nos critérios de aceitação do livro, onde afirmações simples como:

  • teste com Master Card para pagamento.
  • teste com Visa para pagamento.

O formato Given ... When ... Then ... é melhor para escrever testes de aceitação?

A última coisa é sobre a quebra de histórias de usuários para tarefas, por que se preocupar em re-estimar as tarefas quando a tarefa em si foi estimada no ponto da história?

    
por Songo 23.04.2013 / 18:22
fonte

3 respostas

1

Acho que o objetivo da estimativa inicial é fazer com que todos concordem (em alto nível) sobre a ordem de complexidade envolvida na implementação da História. Isso deve ajudar na priorização da história.

Quando nossa equipe mudou para o Agile, houve muito debate sobre como escrever AC.

O que acabamos concluindo é que os formatos "teste com cartão mestre para pagamento" e "Dado ... Quando ... Então ..." tiveram seus méritos. O primeiro é obviamente mais fácil de escrever porque está em uma linguagem natural. O último é mais preciso porque define explicitamente pré-requisitos, ações e expectativas.

Descobrimos que, por uma questão de velocidade, o CA foi inicialmente escrito em uma linguagem natural. Se depois disso ainda houver um elemento de ambiguidade, eles serão traduzidos para o formato formal. Além disso, se um AC for destinado a ser codificado como um teste automatizado, ele deverá estar no formato formal.

Em relação à divisão de histórias em tarefas: também seguimos esse conselho um pouco, mas descobrimos que é desnecessário sobrecarga.

    
por 23.04.2013 / 18:46
fonte
1

Estimar com precisão uma história é trabalho (não muito, mas acrescenta). Uma estimativa precisa não tem valor direto para o cliente. Então, estime apenas o quanto for necessário (e com precisão) para o planejamento.

A longo prazo, você pode se safar com 'pequeno / médio / grande'. Faça isso. Ter tempo para passar por critérios de aceitação, testes, tarefas ou aumento de estimativas precisas é uma perda de tempo se você não for trabalhar na história por dois meses - no momento em que você revisitar a história, as chances são de que o conteúdo, contexto ou o conhecimento mudou.

Em uma sprint / iteração, você precisa de estimativas razoavelmente precisas. Tarefas e detalhes AC (em qualquer formato que a equipe goste mais) valem o esforço adicional.

Acho que a ideia de estimar a história (estimativa bruta) e depois a tarefa separadamente (estimativa detalhada) orienta você no processo de refinamento das estimativas conforme necessário.

Além disso, 'Dado ... Quando ... Então' tem méritos, assim como 'As foo, eu quero ...' e 'apenas faça funcionar, todos nós sabemos do que estamos falando' . Para mim, não existe um formato - depende da história e do contexto.

    
por 23.04.2013 / 20:35
fonte
0

Concordo com você sobre a estimativa. Na minha empresa, temos um processo de requisitos muito formalizado (ditado pelo nosso cliente) e muitas histórias de usuários sendo geradas. Analistas de negócios como eu escrevem essas histórias e, em muitos casos, não temos o conhecimento técnico para estimar de maneira realista. Para nós, a etapa de estimativa ocorre depois que uma equipe de scrum decidiu retirar uma história do backlog. Nesse ponto, realizamos uma rápida sessão de planejamento / preparação, onde nossos líderes de tecnologia e nós, BAs, podem falar sobre as histórias que vamos trabalhar nessa corrida, e os desenvolvedores usarão "planejamento de pôquer" ou qualquer método que faça sentido para um dado scrum equipe para dar uma história uma estimativa de tamanho. Eu faço questão (como bacharel) de NÃO votar no poker de planejamento, mesmo que eu esteja inserido em um time de scrum.

Também concordo que os ACs devam fazer parte da história antes de que é estimada. É totalmente possível para um desenvolvedor olhar apenas a declaração de valor e não enxergar completamente todas as necessidades lógicas que surgem imediatamente, e estimar imprecisamente uma história. Para mim, uma história não é "feita" a menos que tenha critérios de aceitação explicados. Por razões óbvias, também sou extremamente cuidadoso se algum dia eu tiver que tocar nos ACs por uma história "em vôo" (já aceita por um time), porque isso é como mexer com os postes da baliza durante um jogo de futebol. Se eu tiver que mudar um AC, é com o acordo do desenvolvedor que possui a história e depois de considerar cuidadosamente se deve ou não apenas criar uma nova história no backlog (idealmente, devemos sempre fazer isso, mas não fazemos isso). t viver em um mundo ideal de livro-ágil).

Tanto quanto o melhor formato de escrita para fins de teste, você pode ir de qualquer maneira. Acho que o clássico "Como um X, eu preciso de Y, para que eu possa Z" funciona melhor porque é instantaneamente compreensível para qualquer membro da equipe ou parte interessada que se deparar com ele. Se você escrever corretamente, deve ser sempre fácil derivar os casos de teste. Muitas vezes, enquanto escrevo uma história de usuário, me pego pensando "como eu testaria isso?". Eu também acho muito informativo como um cara de requisitos para encontrar nossos testadores e escolher seus cérebros sempre que eu puder. Acontece que muitas vezes eles têm uma visão diferente da nossa aplicação do que a BA, e "pensar como um testador" nos ajuda a fechar o ciclo da lógica ao escrever uma boa história de usuário.

Temos revisões de histórias de usuários entre os BAs no meu projeto, o que eu acho que é uma boa prática, e acabamos tendo uma maneira padronizada de escrevê-las. Isso é bom para um projeto tão grande quanto o nosso, porque nosso cliente (ou quem quer que seja) pode passar pelas histórias do usuário e não precisa lidar com vários tipos de formatos de história do usuário.

No que diz respeito às tarefas, essa é realmente uma questão específica da organização. Para nós, as tarefas são mais úteis quando vários desenvolvedores acabam trabalhando em uma única história de usuário. As tarefas nos ajudam a acompanhar o que cada desenvolvedor está fazendo. Nossos Scrum Masters, como desenvolvedores, dividem histórias em tarefas, porque isso lhes dá uma visão mais granular do que está acontecendo e os ajuda a estimar a velocidade. Em nosso projeto, também rastreamos tarefas por hora, mas histórias por ponto. Eu acho que não é 100% ágil-scrum "kosher", mas ajuda a equipe de gerenciamento de projetos. Realmente, o que você faz ou o que não faz com as tarefas depende muito do que você está tentando acompanhar, como você quer fazer isso e como você está organizado.

    
por 16.12.2016 / 20:49
fonte