Olá Pessoal,
No post desta semana vamos ver o que colocar no conceito de Done do seu projeto Scrum. Claro que não há uma regra universal para o que deve ser colocado, pois isso vai variar de projeto para projeto. Vou abordar uns que considero mais tradicionais.
O que colocar no conceito Done no projeto Scrum?
É algo que parece ser fácil de definir, mas não é como parece. Alguns projetos levam em consideração apenas o foi acordado entre o Product Owner e o ScrumMaster para adotar o conceito de Done, outros buscam um concenso com o team; qual a melhor? Não há melhor ou pior e sim aquele que se adapta ao projeto (eu particularmente preferia discutir com o meu team o que vamos considerar como Done). Claro que a contribuição do Product Owner é importante também, porém evitaria de deixar a discussão apenas entre PO & SM. Mas seria algo como:
- Todas as tarefas devem estar cumpridas: parece ser óbvio, mas nem é. Algo bem comum é: terminei todo o desenvolvimento, mas o build não está ok, então você precisa arrumar o build para poder concluir seu ítem. Não importa quem quebrou, mas precisa estar fixed, é esperado que quem provocou a situação que arrume, caso esta pessoa esteja disponível.
- Código refatorado (refactoring): sabemos que a primeira vez que vimos o código, apenas fizemos ele para que as coisas pudessem funcionar, então ter um código bem refatorado é required (se você usa TDD terá menos trabalho);
- Pair Review: o código deve ter sido revisado por dois outros membros da equipe; (usar uma ferramenta com o review board)
- Build passando;
- Unit Tests passando e cobertura > 80% ;
- Design atualizado;
- Qualificado pelo Tester: Ou seja, teste funcional feito de preferência por um tester, pois eles são bons em encontrar bugs no menor tempo possível.
Uma experiência que quero compartilhar com vocês é sobre o ponto de refactoring acima. É muito importante colocar ele no conceito de Done. O motivo? Quantos desenvolvedores você conhece que faz refactoring (de verdade e não apenas o rename)? Acredito você não consegue fechar uma “mão” com o resultado, mas não só por isso. O cliente não está disposto a pagar pelo refactoring, não se esqueça disso, pois para o cliente, algo dado como Done já possui certos padrões de qualidade e refactoring na visão do cliente não agrega valor ao produto, caso for feito à parte, consumindo mais horas. E eu tenho que concordar com ele, realmente já deveríamos entregar isso quando concluímos o item do backlog, afinal de contas nós que estimamos o tempo que levaria para entregar o item e nesse momento eu deveria colocar quanto tempo levaria no refactoring. Para o cliente, não importa o como você vai fazer, desde que tenha qualidade e atenda ao que ele pediu. Então, o melhor lugar para colocar o refactoring seria no conceito de Done, assim todo desenvolvedor terá que garantir que isso foi feito, enviar o peer review, etc. Outro item que gostaria de citar da lista é o “qualificado pelo tester”, parece estranho, pois em projetos ágeis cada membro é responsável por testar e garantir que está funcionando. Bem, não podemos seguir tudo ao pé da letra ou interpretar com uma única linha de raciocínio. Em um projeto meu, seria bom e interessante eu ter um tester para ir qualificando os itens que fossem ficando prontos e no final do Sprint todos os itens deveriam passar por ele. Mas por que isso? Para garantir que de fato está funcionado. Apesar do desenvolvedor já ter testado, eu considero que não é uma tarefa fácil nós pegarmos os nossos próprios bugs, sempre vamos testar pelo “caminho da felicidade”. Os testes de fato são bons, vão testar cobrindo vários cenários com base no escopo, testar em ambiente e formas diferentes e ver o resultado esperado. Então, ter isso no conceito de Done ajuda a encontrar possíveis bugs mais cedo e ajuda aumentar a qualidade do produto.
Vou ficando por aqui. No próximo post falarei mais sobre o papel do Tester. Agora eu fiquei curioso. E você, o que coloca no seu “conceito de done” ?
Compartilhe…
Abracos, see ya!