Date Version Update Author
02/04/2019 0.1 Criação do documento Gabriel Ziegler
02/04/2019 0.2 Adição definição para Release 1 Gabriel Ziegler
02/04/2019 0.3 Adição definição para Release 2 Gabriel Ziegler

Release I

A definição de done de issues abertas na primeira releaseé:

  • Critérios de aceitação completos;
  • Tasks, se houverem, concluídas;

O ZenHub foi a ferramenta escolhida para auxiliar a equipe na condução do scrum, que utilizará sua funcionalidade de pipelines para fins rastreabilidade e transparência do trabalho a ser realizado na sprint.

As pipelines utilizadas serão:

  • Backlog - Todo o Backlog atualizado do produto.
  • Sprint Backlog - Issues/histórias que foram alocadas para a Sprint.
  • Ice Box - Issues/histórias que foram retiradas da coluna In Progress numa Sprint.por algum motivo de força maior.
  • In Progress - Issues/Histórias sendo trabalhadas no momento.
  • Review - Necessário revisão de EPS.
  • Done - Issue/história concluída.

Assim que uma história técnica ou de usuário respeitar a definição de pronto acordada, e, caso possua testes unitários, e a build esteja passando, o responsável por ela abrirá um Pull Request, e assim que for revisado por um membro de EPS, que, caso aceite a história, ela poderá ser movida para done. A cobertura de testes deverá estar em 30%.

Release II

Para a Release II, a definição de pronto sofrerá mudanças. Os critérios de pronto corresponderão a:

  • Critérios de aceitação completos;
  • Tasks concluídas;
  • Testes unitários completos.
As pipelines utilizadas no ZenHub corresponderão a:
  • Backlog - Todo o Backlog atualizado do produto.
  • Sprint Backlog - Issues/histórias que foram alocadas para a Sprint.
  • Ice Box - Issues/histórias que foram retiradas da coluna In Progress numa Sprint.por algum motivo de força maior.
  • In Progress - Histórias sendo trabalhadas no momento.
  • Testing - Com critérios de aceitação completos e tasks concluídas, a história agora deverá ser testada.
  • Review - Necessário revisão de EPS.
  • Done - Issue/história concluída.

Assim que uma história técnica ou de usuário respeitar a definição de pronto, e a build esteja passando, o responsável por ela abrirá um Pull Request, e assim que for revisado por um membro de EPS, que, caso aceite a história, ela finalmente poderá ser dada como concluída. A cobertura de testes deverá estar em 90%.