A Visão de DoR - Qualidade de Entrada de Requisitos | Ame Digital

Palestra realizada na B2W | Ame Digital em parceria com a comunidade QA Ladies.

Transcript

1. QUALIDADE DE ENTRADA DE REQUISITOS A Visão de DoR
2. Rodrigo Vieira • QA Ágil; • Se aventurando em DevOps; • Apaixonado por compartilhar conhecimento e pela família. *Casado com a Jess :) Jéssica Vasques • Scrum Master; • Curtindo a transformação Ágil; • Apaixonada por livros, Harry Potter e Futebol. *Casada com o Ro :) in/docarmovieira in/jessvasques
3. Definition of Ready Definição de Pronto Ou como gostamos: Qualidade na Entrada da Sprint
4. ▸ Adição ao Scrum; ▸ DoR e DoD; ▸ Interação do Product Owner com DevTeam.
5. SEM DoR: ▸ Requisitos com baixa qualidade na Sprint; ▸ Planejamento de baixa qualidade; ▸ Time desmotivado; ▸ PO insatisfeito.
6. PRODUCT BACKLOG READY > Escrito como estórias de usuário - INVEST > Possui teste de aceitação automatizável > Análise da tarefa realizada com a área de negócios > DevTeam e PO na mesma página das estórias > Dimensionamento das estórias de usuário feito em pontos > Não restam perguntas pendentes que impeçam a equipe de atuar
7. Definition of Ready NA VEIA
8. - Evolução dos requisitos; - Exemplos de layout; - BDD’s ou critérios de aceite; - Detalhes de acesso; - Cenários testáveis; - Fácil compreensão sem a presença do Product Owner; - Sem dependência de histórias na mesma sprint; - Compreensão da história em menos de 5 minutos; - Uma história não deve ter especificações; - Medir o estado de “pronto” de um backlog; - Somente o suficiente dos itens do product backlog; - Identificar a sobrecarga do time, auxiliando e ajudando na responsabilidade de um pelo outro; - Reduzir a pressão para as equipes se comprometerem com estimativas antes das histórias ficarem “prontas”; - Reduzir a quantidade de requisitos colocados durante o desenvolvimento.
9. “▸ Trabalhar com o conceito de histórias prontas facilita tanto o trabalho do PO como do DevTeam; ▸ Comunicação “Cara a Cara”, mantendo o Ágil na sua rotina; ▸ Sem impor muitas regras, seja prático e fácil.
10. Pontos Positivos X Pontos Negativos
11. Pontos Negativos ➢ Quantidade excessiva de requisitos. Quanto mais requisitos de DoR, mais cotovelos você tem, lembrando que o PO tem que especificar cada ponto levantado; ➢ Pode ser usado como âncora de um processo regulatório, impedindo assim a colaboração do DevTeam.
12. Pontos Positivos • Quanto menos melhor • Melhora a facilitação de lidar com histórias incompletas • Deve encolher de acordo com o tempo e não crescendo • Indivíduos e interações sobre processos e ferramentas • Empresários e desenvolvedores devem trabalhar juntos durante todo o projeto • O método mais eficiente e eficaz de transmitir informações para e dentro do DevTeam é a conversa face a face • As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas
13. Dicas de Boas Práticas ➢ Planejar a sua própria definição de Pronto; ➢ Somente o DevTeam pode chamar uma história de Pronta; ➢ Use rótulos, cores, semáforos e etc., para identificar as histórias prontas no backlog; ➢ Use rótulos, cores, semáforos e etc.,para identificar o que está faltando na história para poder subir de backlog a sprint; ➢ Importante sempre compreender a definição de Pronto e os benefícios que ele traz para o backlog.
14. Dúvidas???
15. Obrigado!