Imagine uma situação - o testador encontra um erro, começa a discuti-lo com o desenvolvedor - e ele insiste que isso não é um erro, porque a especificação não falou sobre essa funcionalidade. Isso é familiar?
Ou porque os requisitos eram ambíguos, e ele os entendeu mal. Ou talvez, pelo contrário, eles tivessem tanta informação que o foco foi perdido e parte da informação foi perdida de vista durante o desenvolvimento.
E nessa situação, o desenvolvedor não é uma praga que deliberadamente cometeu um erro. Na prática, se você fornecer requisitos simples, compreensíveis e, o mais importante, breves, o número de erros que os testadores encontrarão será zero.
Você provavelmente também está familiarizado com disputas sobre o assunto "um bug ou um recurso". Os clientes descobriram falhas e o proprietário do produto vem à equipe com comentários. E o testador e o desenvolvedor se defendem, explicando isso pelo fato de que, na configuração original, não houve conversa sobre a implementação desse recurso. E esses momentos são iniciados no backlog.
Acredito que todas essas tarefas instituídas após o lançamento e que são o resultado de uma especificação mal desenvolvida também são bugs. Erros que caracterizam a qualidade do seu produto.
Acontece que os analistas de negócios determinam quais recursos precisam ser criados. Os desenvolvedores os criam. Os testadores encontram defeitos no trabalho de ambos. É assim que a abordagem tradicional de desenvolvimento funciona. Mas você pode ensinar esses três a trabalharem juntos para fazerem seu trabalho melhor e imediatamente, sem alterações adicionais. E esse meio de comunicação é chamado 3 Amigo. Também chamado de Story Kick Off Huddles ou Triad.
3 Amigo é ...
3 Amigo é uma prática que fornece um entendimento universal do que será entregue ao cliente. Ajuda a transmitir a voz da equipe, não o entrelaçamento de opiniões dispersas.
Esse método de comunicação dentro da equipe ajuda a:
- chegar a um acordo comum sobre as expectativas antes do desenvolvimento
- formar um acordo sobre como fazer a coisa certa imediatamente
Também ajuda a entender:
- que problema resolvemos
- quais são as soluções
- o que precisamos fazer para que a tarefa esteja pronta
A reunião dos três amigos é uma maneira de pensar em conjunto que preenche a lacuna no entendimento das especificações comerciais. Ela ajuda no desenvolvimento de histórias interessantes de usuários.
O objetivo é fazer o trabalho no prazo, mas ao mesmo tempo não planejar com antecedência, para que os detalhes tenham tempo para se tornar obsoletos.
Por que 3? Quem está inscrevendo-se?
O nome da prática não nos limita a três contextos, mas apenas cria uma estrutura mínima. Para garantir que, no desenvolvimento dos requisitos, todas as nuances técnicas sejam levadas em consideração, casos explícitos e implícitos, que a especificação reflita a necessidade real do cliente - são necessários três diferentes contextos / pensamento: negócios, desenvolvedor, testador. Além disso, a reunião não se limita apenas a essas pessoas. Envolve todos os envolvidos na implementação do requisito. Por exemplo, se sua tarefa não tem apenas a web, mas também é móvel, você precisa de um contexto adicional. Ou seja, a pessoa que fará a implementação no aplicativo móvel. Em nossas equipes, na maioria das vezes 4 desenvolvedores (1 iOS, 1 Android, 1 traseiro, 1 frontal), um testador e um analista de negócios participam da reunião.
Analista de negócios ou PO
Um representante de negócios sabe (quase sempre) o que ele quer obter no final e que valor o cliente e a empresa receberão disso. É importante falar sobre esse time.
Participando da reunião do Amigo 3, o analista de negócios compartilha informações com os participantes para que todos na equipe tenham o mesmo entendimento e expectativa da história do usuário. Além disso, somente ele pode limitar o escopo dos critérios de aceitação pelos quais a aceitação ocorrerá.
Desenvolvedores
O desenvolvedor sabe como implementar o requisito do negócio, quais são as oportunidades para isso. Como regra, ele pensa nos detalhes que precisa conhecer para iniciar a implementação. Ao fazer perguntas com base em sua experiência e conhecimento do sistema, o desenvolvedor ajuda a revelar várias nuances, mesmo na fase de discussão dos requisitos.
Testador
O testador, como outros membros da equipe, ajuda a enriquecer os requisitos com vários casos de teste. Com base em sua experiência, ele cada vez mais lança dúvidas sobre quaisquer declarações feitas pela equipe. Portanto, é melhor encontrar casos extremos, cenários implícitos, imaginar o que pode dar errado, o que deve ter cuidado.
Quando a prática é aplicada?
Eu raramente via um processo de desenvolvimento em que os requisitos eram apresentados explicitamente. Na maioria dos casos, os requisitos começaram a ser estudados no estágio de desenvolvimento ou teste e, somente então, algumas inconsistências foram reveladas.
É provável que uma especificação não testada tenha requisitos ambíguos, contraditórios, incompletos, duplicados e às vezes até desatualizados, porque todo mundo entende o que leu e ouviu à sua maneira. Portanto, surgem diferenças de interpretação.
E se a documentação for grande e detalhada, a leitura poderá levar mais tempo que o próprio processo de teste ou desenvolvimento.
Em nossa linha de negócios, decidimos aplicar essa prática quando as tarefas começaram a demorar nos testes. Identificamos três problemas principais:
- No estágio de teste, muitos retornos ocorreram devido ao esclarecimento dos requisitos. Essas foram pausas tangíveis nos testes e desenvolvimento, quando um analista de negócios determinou como deveria funcionar.
- O teste da tarefa foi atrasado devido a uma especificação muito detalhada. Os casos eram frequentes, quando o testador podia passar de 3 a 6 horas apenas estudando os requisitos e desenvolvendo os casos de teste, e o próprio teste demorava cerca de 30 minutos, e o mais notório era o caso em que o teste era iniciado após duas semanas de estudo da especificação, era muito complicado. e detalhado.
- Bem, o problema mais comum era que durante os testes de aceitação havia muitos bugs. Esses bugs que poderiam ter sido evitados se tivessem sido pensados antes do desenvolvimento.
Portanto, apesar do desenvolvimento ágil, ainda há um estágio de trabalho com a especificação técnica. E se você não levou em consideração alguns casos, porque o cliente não falou sobre eles ou não fez o que ele realmente tinha em mente, depois de ir ao produto, várias tarefas para revisão ou até mesmo alteração estão no backlog.
E, finalmente, vale a pena expressar o problema com a avaliação.
É difícil avaliar uma tarefa quando você realmente não entende toda a quantidade de trabalho que ainda precisa ser realizado. Quantos testes escrever, quantos retornos serão causados por erros ou alterações devido a imprecisões na especificação? Mesmo que o desenvolvedor faça uma avaliação precisa do próprio tempo de desenvolvimento, você quase nunca adivinhar quanto tempo levará o estágio imprevisível do teste.
Passos para praticar AC
1. Formulamos requisitos como User Story
Eu recomendo aplicar para desenvolver requisitos com base em histórias de usuário. E como base para pegar uma história e, em uma reunião de 3 amigos, estudar apenas ela.
Aqui, um ponto muito importante é que o requisito do negócio é realmente formulado como uma história do usuário. Ou seja, continha em si três partes, a saber:
Eu como <função>, quero <ação>, para que <motivação>
Na verdade, esse é o modelo de narrativa personalizado mais popular chamado Connextra. Existem também outros modelos, mas eu recomendo usar este. E porque, agora eu vou explicar.
Tradicionalmente, existem 2 problemas ao formar uma história de usuário:
- Ao gravar, ou não indicam o papel, deixando ação e motivação
- Ou eles indicam o papel e a ação e jogam fora a motivação.
Isso realmente causa problemas, e tentarei explicar quais exemplos com exemplos simples.
- Conhecendo o "papel", você, como membros da equipe, entenderá melhor os limites dos critérios de aceitação que precisa formular. Se você não estiver totalmente ciente da pessoa envolvida nessa história de usuário, poderá fazê-lo além do necessário ou vice-versa, algum tipo de funcionalidade.
- Exemplo : a equipe não entendeu o papel na história do usuário e, ao trabalhar no problema, decidiu executar três métodos para a API: adicionar, editar e excluir. E na frente, eles adicionarão botões que chamarão esses métodos. Quando eles apresentaram sua decisão à empresa, receberam um feedback de que seu cliente é realmente um analista de negócios específico que precisa de um método de adição. E ele não irá excluir e editar. Sim, e ele pode chamar esse método através do carteiro.
- A equipe não entende a motivação do "papel" para quem eles criam uma história de usuário. Devido a mal-entendidos, os limites da própria história do usuário são mal delineados. Além disso, os critérios de aceitação no final podem não resolver o problema do cliente final, embora correspondam à ação que foi dita na história do usuário.
- Exemplo : uma equipe contratou uma história de usuário em que um analista de negócios não conseguiu articular claramente a motivação. Por um lado, ela deveria deixar o cliente fiel e fazer uma melhoria para ele. Por outro lado, redução de custos para o banco. Nesse caso, os métodos de implementação e os critérios de aceitação eram radicalmente diferentes. Porque no primeiro caso, a equipe se concentrou nos critérios de aceitação do usuário. No segundo - a equipe prestou atenção em como tornar a implementação mais simples e rápida possível.
Mas a formulação no formato acima não é um pré-requisito. Conheço equipes que realizam reuniões no formato Amigo 3 e sem uma história de usuário. E como base, use o TK. Nesse caso, existem armadilhas, mas foi uma escolha consciente da equipe.
O encontro 3 Amigo começa com a preparação. Em preparação para isso, os requisitos são formulados para que sejam compreensíveis para toda a equipe. Esses requisitos são validados para prontidão para o trabalho.
A validação inclui a avaliação do histórico em relação aos critérios do INVEST. Bem como a qualidade da redação da história em si. Aqui, qualquer ambiguidade, verbosidade é excluída e, quando avaliada pelo INVEST, é dada atenção especial ao tamanho da história. Se a equipe entender que o requisito é épico, ocorre a decomposição.
Depois que o requisito passou do estágio de transformação em uma história de usuário e validação pela equipe (3 amigos), podemos prosseguir com a elaboração dos critérios de aceitação.
2. Complementamos os critérios de aceitação na História do Usuário na reunião de 3 Amigo
Primeiro, você precisa decidir quais são os critérios de aceitação.
Portanto, critérios de aceitação são requisitos do cliente; especificação pela qual o sistema / user story pode ser verificado.
Eles têm um nome alternativo, condições de satisfação - condições para satisfação de expectativas (autor Mike Cohn).
Em uma reunião de 3 equipes Amigo já vêm preparadas. Eles já têm uma história de usuário validada, que talvez já tenha algum conjunto de critérios de aceitação que o representante comercial formulou de forma independente.
Durante a reunião, as tarefas dos participantes são complementar / enriquecer a história com um número suficiente de critérios de aceitação para sua subsequente implementação.
Os critérios de aceitação não devem incluir detalhes de implementação. De fato, critérios de aceitação são regras de negócios que governam uma história de usuário em desenvolvimento. Os detalhes da implementação são registrados nos testes de aceitação, mas após todos os critérios de aceitação terem sido formulados.
Não vale a pena confundir detalhes da implementação com critérios de aceitação, mesmo que com prazos limitados, você, como equipe, possa sempre "descartar" algum escopo de critérios que não sejam tão importantes para os negócios no futuro próximo. Se houver detalhes com a implementação técnica nos critérios, você corre o risco de perder informações e tempo importantes que já foram gastos na discussão dos detalhes da implementação. Os detalhes da sua implementação dependem diretamente do escopo dos critérios que você precisa fazer.
Além disso, evite uma descrição seqüencial do cenário com um conjunto de etapas (sistema de gerenciamento de caso de teste clássico). Qualquer uma de suas declarações deve ser atômica. É melhor usar um estilo descritivo do comportamento esperado da função criada.
Por exemplo:
* , .*>
3. Mantemos o tempo
Um EUA bem decomposto geralmente não contém mais de 10 critérios de aceitação. Se, no processo de discussão, um grande número de critérios de aceitação for encontrado e todos estiverem sujeitos à implementação, essa história precisará ser decomposta em várias histórias com um conjunto diferente de critérios de aceitação.
Se isso não for feito, a reunião de 3 Amigo será bastante atrasada.
O momento ideal para realizar uma reunião de 3 Amigo é de 30 minutos a 1 hora.
Aumento aceitável no início do caminho - quando a equipe está apenas aprendendo a se comunicar e aplicar essa prática.
Se uma equipe tem uma grande história para trabalhar, é improvável que em uma sessão eles sejam capazes de elaborar todos os critérios e testes de aceitação. Porque o foco e a atenção estão perdidos. Nesse caso, você precisa dividir a sessão em várias reuniões. Mas, neste caso, existe o risco de perda de contexto e imersão adicional pode ser necessária em uma segunda reunião.
4. Para concluir o estudo dos critérios, usamos a heurística USR
Ao ensinar essa prática às equipes, recomendo o uso de heurísticas no início de seu caminho para amenizar a falta de experiência. Com a experiência, a equipe tem suas próprias heurísticas e listas de verificação sobre o que procurar ao desenvolver critérios.
A heurística do USR permite considerar os critérios em todos os níveis necessários para obter o máximo de informações sobre o que o cliente deseja.
Então
- USUÁRIO - O que o usuário deseja fazer com o sistema?
- SISTEMA - O que o sistema deve fazer?
- RISCOS - Que problemas podem surgir?
É importante primeiro elaborar todos os critérios do grupo USUÁRIO e depois passar para o nível do sistema. Aqui, os desenvolvedores front-end e back-end estão incluídos e, no nível de seus sistemas, podem formular critérios de aceitação para o que deve acontecer, a fim de implementar os critérios do grupo USUÁRIO.
E, finalmente, a banda RISK. Na maioria das vezes, esquece-se da elaboração de requisitos, embora não seja menos importante. Ele abrange vários casos complexos que talvez você não consiga implementar. Mas é necessário se manifestar e aceitar os riscos em equipe.
Maneiras de aplicar a prática para desenvolver casos de teste antes do desenvolvimento
A maneira recomendada de formalizar os requisitos é nos casos de uso. Na TI russa, chamamos isso de casos de teste.
Existe uma ferramenta conveniente para o desenvolvimento de casos de teste em uma reunião do 3 Amigo, chamada mapeamento de exemplo. Neste artigo, eu toquei brevemente nele. No próximo artigo, publicaremos informações detalhadas sobre essa ferramenta e como ela é usada na estrutura da reunião da tríade.
Os casos de teste podem ser implementados como testes de aceitação automatizados para o histórico. Além disso, quando você estiver trabalhando em casos de teste, certifique-se de agrupá-los. Dividir casos de teste em grupos é uma maneira de dividir a história em vários casos menores.
Nos casos de teste, a decomposição de uma regra de negócios ocorre exatamente no nível do sistema no qual elas serão implementadas, e não pelo usuário.
Todos os detalhes da implementação devem estar nos seus casos de teste, para que eles se concentrem nos desenvolvedores no processo de implementação.
Como pode parecer no processo geral (quando você precisa realizar esta reunião)
É recomendável que você elabore requisitos para apenas uma história de usuário em uma única reunião. É permitido mais, desde que sejam histórias muito pequenas ou tenham significado interligado.
Como no sprint você pega histórias prontas para o trabalho, uma reunião de 3 histórias de Amigo deve ser realizada antes do planejamento. Caso contrário, você corre o risco de cometer um grande erro com a estimativa preliminar. Na prática, a avaliação da história após a reunião de 3 Amigo é muito diferente da original.
Além disso, faz sentido adicionar um novo item ao DOD como um indicador de prontidão, para que a história esteja pronta para trabalhar nela no sprint.
Por exemplo, algumas equipes que começaram a aplicar essa prática concordaram que não farão o sprint durante o planejamento se não houver critérios de aceitação e testes de aceitação para a tarefa.
E na revisão do sprint, a aceitação da história é apresentada de acordo com os critérios de aceitação.
Mas, ao mesmo tempo, a reunião do 3 Amigo também se encaixa no processo, se a equipe está trabalhando e não no scrum, mas por exemplo usa o kanban. Nesse caso, a tarefa entra em desenvolvimento somente depois de passar por uma reunião de 3 Amigo.
Qual é o resultado da reunião 3 Amigo?
- scripts / exemplos (respostas óbvias)
- regras / critérios de aceitação especificados
- histórias novas / decompostas
- entendimento comum da área do problema
- empatia (empatia, participação)
O principal resultado dos três amigos são os testes de aceitação escritos no formato " Dado / Quando / Então" . De fato, escrevê-los pode levar mais tempo do que gostaríamos, portanto, não é recomendável formalizar todos os requisitos em uma reunião quando todos estão juntos. Normalmente, um desenvolvedor ou testador trabalhará nisso imediatamente. E assim que eles têm todos os critérios e casos de teste registrados, 3 Amigos analisam brevemente o que aconteceu para garantir que todos concordem com o que foi gravado.
Lucro do uso da prática de 3 Amigo
A estratégia do Amigos 3 pode ter um enorme impacto na eficácia de toda a equipe, bem como na qualidade e sustentabilidade de seus projetos, aumentando a capacidade de manobra e a flexibilidade para mudar.
Aqui estão mais alguns bônus:
- Ao planejar, não passamos muito tempo imergindo no significado da história.
- Detecta confusão e mal-entendidos em um estágio inicial, o que permite uma entrega mais rápida
- Garante que a equipe discuta a quantidade necessária de trabalho
- Ajuda a encontrar todos os critérios de aceitação e outros atributos de qualidade.
- O desenvolvimento de casos de teste é muito mais fácil.
- Provocamos os desenvolvedores a cobrir o código com testes
- Chegamos rapidamente à conclusão de que esse recurso não é necessário
Nossas equipes, usando a prática, conseguiram reduzir o retorno de tarefas devido a especificações imprecisas. As tarefas de back-end que os caras aprenderam a desenvolver "pela primeira vez". Ou seja, sem bugs e imediatamente no prod.
Armadilhas
- Não se limite a apenas três pessoas. Se você precisar de mais - ligue.
- Não conheça toda a equipe. Nesta reunião, deve haver um número mínimo de pessoas para implementar o recurso.
- Não considere isso uma reunião regular - um ritual. Caso contrário, a equipe terá um negativo ao aumentar o número de reuniões.
Master class na conferência QualityConf
De 27 a 28 de maio, como parte do festival RIT ++, na conferência QualityConf, darei uma master class sobre o desenvolvimento de requisitos usando a prática do 3 Amigo.
Se você estiver interessado na abordagem e tiver dúvidas, também pode entrar em contato comigo pelo telegrama @Travieso_nastya.
Histórico de abordagem
O autor da abordagem: George Dinwiddy, 2009.
Ele descreveu essa abordagem em sua entrevista e mencionou em vários artigos, os links aos quais anexei. Além disso, como material adicional, anexei todas as referências aos recursos em inglês, segundo as quais estudei e aprendi a aplicar essa prática.
https://www.agilealliance.org/glossary/three-amigos/
https://www.infoq.com/interviews/george-dinwiddie-three-amigos
https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories
https://www.stickyminds.com/better-software-magazine/three-amigos