dev_process_guidelines.md

Sugestão de guidelines de processo

DoR (definition of ready) - quando uma história pode ser considerada "pronta pra ser desenvolvida"?

• Priorização atende a um valor de negócios específico.
  • Como …, devo …, para que...
• Deve haver um roteiro de testes de aceitação (user acceptance journey), com pelo menos 1 cenário descrito no formato given-when-then.
• Deve estar estimada pelos desenvolvedores (well-sliced) - 3~5 dias (com baixo risco de complexidade e incerteza):
  • Histórias maiores que 8 story points podem ser quebradas em histórias menores.
  • Podem ser feitas PoCs pra diminuir incerteza e haver proposta de solução.
• Deve estar quebrada em tarefas técnicas pelos desenvolvedores (task breakdown).
  • Se tem poucas tasks, altas chances de haver incerteza.
    • Sugestão: criar história de investigação ou poc.
  • Se tem muitas tasks, altas chances de haver complexidade.
    • Sugestão: quebrar tarefas em mais de uma user story.
• Caso haja fluxo de UI, é desejável incluir referências visuais (wireframe ou layout final).

DoD (definition of done) - quando uma história é considerada como feita?

• Deve estar revisada e aprovada por 1 ou dois desenvolvedores.
• Cobertura de testes automatizados deve seguir a seguinte premissa:
  • Caso o item de trabalho seja uma feature de evolução (ou seja, não é refactoring ou tech chore), o código deve adicionar ou estender no mínimo um cenário de teste de aceitação (ou integração).
• Build da suite de testes deve estar passando.
• Deve estar disponível e testada em ambiente de validação/homologação.
  • deploy QA via heroku?

Sugestão de colunas do Scrum board:

• Backlog de histórias não refinadas (PO e scrum master)
• Histórias prontas para desenvolver (ready to dev) (PO, devs e scrum master)
• Histórias em desenvolvimento (Devs)
• Histórias em homologação/validação (PO)
• Histórias prontas