1. Introdução
O que é DoR
Por que você precisa de um DoR?
Onde usar o DoR
Quando usar o DoR
Modelo INVEST
Conclusão
Referências
1. Introdução
Certamente você já ouviu mais de uma vez, provavelmente até usou o artefato Scrum - Definição de Concluído com a equipe, daqui em diante - DoD. Talvez use sem nem perceber. Muitos artigos em russo foram escritos sobre o Departamento de Defesa. Eles falam sobre ele em conferências e treinamentos. Entender por que esse artefato é necessário e encontrar exemplos não é difícil. O Departamento de Defesa define os critérios pelos quais cada membro da equipe entende que a tarefa está encerrada. O objetivo mais profundo é sincronizar o conceito de Concluído entre cada membro da equipe. Acima desses critérios, muitas vezes, a equipe trabalha durante uma retrospectiva. Existe um artefato semelhante sobre o qual, por algum motivo, não há menção ao Scrum nos recursos de língua russa, e onde esse artefato é mencionado, nenhuma explicação é dada sobre o que é, por que é necessário e como usá-lo.
Provavelmente, frases como a sua soaram em sua equipe: “Falhamos no objetivo porque avaliamos incorretamente a tarefa” ou “Nosso PO retornou com a tarefa sem uma descrição adequada”. Na minha equipe, esses "sinais" apareceram mais de uma vez e, durante muito tempo, eu estava procurando uma maneira de resolver esse problema.
Definição de Pronto, a seguir denominado DoR, me deparei por acaso em um bate-papo de perfil dedicado ao Agile. Tentando encontrar informações, não encontrei uma única menção no RuNet sobre esse tópico. Portanto, fui ler e traduzir artigos em inglês. Agora, estou compartilhando o resultado com você, espero que isso ajude a tornar sua equipe ainda mais legal e produtiva.
O que é DoR
Então, o que é DoR? O tradutor do Google dirá que essa é uma "definição de prontidão". Se o DoD incluir critérios para concluir uma tarefa, então DoR - critérios para a prontidão de uma tarefa a ser levada ao trabalho. Ou seja, se uma tarefa atender aos critérios do DoR, a equipe poderá levá-la ao planejamento do trabalho. Parece ser simples, você provavelmente já começou a pensar em como, finalmente, juntamente com a equipe, compõe uma lista completa de requisitos para o seu OP, para que ele comece a escrever uma tonelada de documentação, e o restante dos membros da equipe possa sentar-se calmamente no computador e escrever código silenciosamente. Este é apenas o começo, e DoR não é o que parece à primeira vista.
Por que você precisa de um DoR?
Primeiro, respondemos à pergunta: por que esse artefato é necessário? Que benefício ele trará para a equipe? O DoR ajudará a equipe:
- Evite iniciar o trabalho em recursos que não possuem uma definição clara de critérios de conclusão. A equipe entenderá quando a história do usuário for considerada completa e o que precisa ser feito para fazer isso.
- Não perca muito tempo em vão em longas discussões, tarefas mal pensadas. Uma tarefa pré-processada economizará o tempo de toda a equipe. Calcule quanto tempo leva para discutir uma tarefa "ruim" para uma pessoa. Agora multiplique pelo número de pessoas na equipe. E agora para o número de tais tarefas.
- Concentre tempo e energia em coisas o mais "seguras" possível. Um dos desmotivadores mais poderosos é a funcionalidade lançada na lixeira.
- Envolva cada participante na discussão de tarefas. Em primeiro lugar, motiva a equipe. Em segundo lugar, ajuda a revelar cada membro da equipe como especialista. Em terceiro lugar, os desenvolvedores oferecerão sua própria visão do problema. Durante a discussão, podem surgir outras soluções que diferem radicalmente da idéia original.
Vamos dar uma olhada na lista de problemas que direta ou indiretamente resultam da falta de DoR:
- Discrepâncias na compreensão do problema aparecem regularmente entre os membros da equipe. Ao final do sprint, a discrepância se intensifica, o que leva a incidentes quando ocorrem mudanças no processo de desenvolvimento, o que é natural. Mas, tendo em vista que esses momentos não foram registrados, apenas quem encontrou isso diretamente sabe sobre eles.
- Os requisitos funcionais mudam mais rapidamente do que a equipe consegue compreendê-los. Desde que a tarefa entrou no sprint, com alta incerteza, no momento em que a peça está pronta e a "fundação" é lançada, novas informações são exibidas que exigirão um retorno ao início. Quanto pior a tarefa for executada, mais frequentemente essa situação surgirá no sprint. No final, isso levará a um fakap.
- Muitas vezes, há problemas em avaliar o resultado obtido do funcional, a equipe não sabe como coletar métricas, ou pior ainda, se esqueceu delas. O Scrum é principalmente sobre os benefícios para o cliente, usuário ou comprador. Se a equipe não avaliar os benefícios da tarefa, ela não recebe feedback e a capacidade de ajustar o curso do desenvolvimento do produto. Isso pode levar à falha completa.
- Além disso, a falta de DoR tem um grande impacto nos testes e, em vez das expectativas de QA na história do usuário, ele também testará as expectativas dos desenvolvedores. O código pode funcionar perfeitamente, os autotestes funcionam como um relógio, mas a funcionalidade não funciona na Produção.
No final, isso leva ao lançamento de um produto que não está funcionando, inútil, não resolve o problema principal. E isso é uma perda de tempo que todo mundo quer gastar em coisas importantes. Em um dos artigos, me deparei com um excelente ditado: "O lixo entrou, o lixo saiu".
Onde usar o DoR
Os DoRs são usados no Refinamento do Backlog do Produto, a seguir denominado PBR ou o nome mais conhecido do artefato: Higiene. Durante esta atividade, as Histórias de Usuário ficam Prontas - Prontas. Isso significa que o resultado do evento, na lista de pendências do produto, está pronto nos EUA. O DoR é necessário para descrever o estado em que os EUA podem ser discutidos sobre o planejamento. Isso é chamado de Takin - aceito pelos EUA.
Para ir além, estou prestando atenção em como Jeff Sutherland, um dos fundadores do manifesto Scrum e Agile, fala sobre o DoR e o DoD em seus vídeos. Sutherland apresenta os conceitos de Done-Done e Ready-Ready. Quando um membro da equipe diz que uma tarefa está pronta ou concluída, entende-se que atende aos critérios que a equipe definiu no DoD e DoR, respectivamente. Este é um aspecto importante, todo membro da equipe deve entender e não esquecer. Caso contrário, surgem situações engraçadas quando Petya dirá no Diário que a tarefa já foi concluída e, então, os testes precisam ser adicionados lá, e seria bom refatorar o código, e a Revisão de Código ainda não passou.
Assim, até que os EUA atinjam o estado Pronto-Pronto, ele não existe e não é discutido no planejamento. A parte superior da lista de pendências deve ser apenas nos EUA, com um estado Pronto-Pronto. A melhor maneira de conseguir isso é trabalhar nos EUA com a equipe. Isso nos permitirá analisar o problema de diferentes ângulos, envolver cada membro da equipe no processo e, posteriormente, desenvolver responsabilidade coletiva pela funcionalidade liberada. Os desenvolvedores serão responsáveis pelo resultado e pela qualidade se perceberem que isso é fruto do trabalho "conjunto" deles.
Quando usar o DoR
Quando a equipe entende durante a RBR que a tarefa não corresponde ao DoR e carrega muita incerteza, faça uma lista de perguntas, escolha um pesquisador e adie a tarefa para a próxima RBR. Na minha equipe, ele se chamava Pesquisa, mas depois mudamos para o Spike do XP, porque pensamos que ele traz mais resultados e clareza no resultado do estudo. Certifique-se de limitar o estudo por tempo e designe o resultado que deseja obter até o final. Durante o Spike, o pesquisador pode atrair qualquer ajuda de fora, por exemplo, membros de outras equipes, metodologistas, OPs, arquitetos ... em geral, quem quiser. Resultado - respostas a perguntas, novos dados, protótipo. Se houver muitas Histórias de Usuário, você poderá usar 1-2 Spike em cada sprint para a próxima iteração, garantindo assim um fluxo constante de tarefas Prontas.
Como mencionado acima, o DoR é um conjunto de critérios. A equipe pode tentar compor esses critérios eles mesmos. Trabalhe com esses “sinais” rastreados nas iterações. Discuta em retrospecto esses pontos, encontre a causa raiz. Se você não deseja gastar a próxima retrospectiva nisso, use soluções prontas.
Muitos artigos descrevem o modelo INVEST, que é semelhante ao SMART, mas mais adequado para a História do usuário. Além de artigos, este modelo também é recomendado na literatura Agile. Por exemplo, Roman Pichler no livro “Product Management in Scrum” ou Mike Cohn - “User Stories. Desenvolvimento de software flexível. ”
Modelo INVEST
- Independência Independente - Tente evitar a criação de USs que dependem um do outro, pois causam problemas na priorização e no planejamento. O cliente pode escolher EUA com alta prioridade, que depende da tarefa com menor prioridade. Os EUA dependentes devem ser mesclados, divididos de forma diferente ou aumentados.
- Negociabilidade negociável - os EUA não são uma obrigação ou requisito contratual formal. EUA não é uma tarefa técnica. Durante o sprint, eles podem e devem ser discutidos e alterados. Um cartão com histórico, independentemente da forma que exista, é uma breve descrição da funcionalidade, cujos detalhes devem ser esclarecidos durante o trabalho. Deixe anotações nos cartões para gerar discussão quando a tarefa for concluída. É importante encontrar um meio termo aqui, porque, com o excesso de anotações, a equipe perceberá como informações exaustivas e não haverá discussão. Minha equipe se deparou com isso muito rapidamente. Os detalhes discutidos tornam-se testes que podem ser escritos no verso do artigo ou no comentário no cartão eletrônico. Os testes de aceitação são simples e claros para todos.
- Valor valioso para o usuário ou cliente - “Cada história deve ter um certo valor para o usuário” - uma declaração incorreta. A maioria esquece constantemente do comprador. Foco, dependendo da sua empresa: B2C, B2B, B2G. O principal é evitar histórias valiosas apenas para os desenvolvedores. Tais histórias devem ser reformuladas para que os benefícios se tornem aparentes e o cliente possa definir prioridades. Não há necessidade de jogar tarefas de arquitetura no lixo, explicar ao cliente quais os benefícios que uma tarefa trará e reformulá-la.
- Avaliação estimada - os desenvolvedores devem poder estimar o tamanho dos EUA, ou seja, o tempo aproximado que levará para implementar. Existem três razões principais pelas quais a intensidade do trabalho de parto pode não ser mensurável:
- A equipe não tem conhecimento do assunto
- A equipe não possui experiência técnica
- A história é muito grande
No primeiro e no segundo caso, o spike o ajudará. No terceiro, os EUA precisam ser decompostos em outros menores. - Compacidade pequena - depende muito do tamanho dos EUA, é muito difícil avaliar os EUA grandes e pequenos demais. É difícil trabalhar com épicos, pois consistem em vários EUA. Épicas podem ser divididas em dois tipos:
- Composto. Tudo é simples aqui - nós nos decompomos. Considere o restante dos pontos, a primeira coisa que a equipe provavelmente sugerirá: divida os EUA por tipo de camada arquitetural: por EUA em um banco de dados, back-end, front-end e assim por diante.
- Complicado. O tamanho grande dos EUA se deve à sua própria essência, eles não são decompostos ou são muito difíceis. Neste caso, usamos spike.
- Testabilidade testável - a confirmação de que os EUA foram desenvolvidos com sucesso serve como um teste bem-sucedido. Se os EUA não puderem ser testados, a equipe não saberá quando a criação está concluída ou apresentará os próprios critérios. Além disso, cada membro da equipe será diferente.
Conclusão
Em conclusão: usando o DoR, você não se livrará das lacunas que aparecerão no sprint. Isso também não significa que, durante o sprint, não haja necessidade de contato constante entre a OP e os desenvolvedores. Registre constantemente os resultados das discussões na forma de testes de aceitação, para que nenhuma equipe perca o entendimento do status da tarefa. Analise e discuta com a equipe os problemas atuais, talvez eles estejam relacionados à falta de DoR.
O DoR é um artefato que permitirá que a equipe pense melhor nos EUA, o que reduzirá os riscos e permitirá que cada membro da equipe discuta constantemente as tarefas. Você encontrará muitas informações detalhadas sobre o INVEST e a História do usuário no livro “Histórias do usuário”. Recomendo que cada membro da equipe leia este livro ou, pelo menos, leia você mesmo e compartilhe informações com eles.
Escreva nos comentários que o DoD e o DoR são usados em sua equipe.
Referências
1) Roman Pichler “Gerenciamento de produtos no Scrum”
2) Mike Cohn “Histórias personalizadas. Desenvolvimento de software flexível ”
3) agilealliance.org
4) linkedin.com
5) boost.co.nz
6) scruminc.com