- Definition of Ready

- Definition of Done
- Coding Conventions
- Dailies – when on call / when status report
- Ceremonies

Definition of Ready:

- User History: deve ser bem escrita e de facil entendimento, para que por exemplo alguem de
fora possa minimanete entender o processo.
- Deve conter os critérios de aceite e testes.
- Listar priorização do item.
- Ser escrita levando em conta o esquema INVEST:

O INVEST diz que uma boa user story possui seis características:

Independent: histórias são mais facilmente trabalhadas quando são independentes, ou seja,
quando podemos implementá-las em qualquer ordem, já que não são intimamente ligadas,
gerando uma cascata (que pode virar gargalo) de implementação. Talvez essa seja a
característica mais difícil de alcançar totalmente.

Negociable: histórias não são contratos para implementar features; boas histórias captam a
essências e não os detalhes de uma feature. Definida a essência, os detalhes são negociados
com o Product Owner. E não definidos por ele.

Valuable: a premissa básica de uma história é que ela agregue valor ao produto, para o cliente.
Muitas vezes as histórias começam a ser quebradas. Quando começamos a quebrar demais as
histórias, temos que ter o cuidado de não transformá-la em algo que entregue apenas uma
parte da feature.

Estimable: não precisa ser algo exato; o time não precisa acertar sempre; mas o time precisa
ser capaz de estimar uma user story. Da mesma forma que uma história estimável pode ser
negociada, ninguém consegue estimar uma história que não entende. Entendo que esta seja a
característica chave de uma boa user story, por que está intimamente ligada a outras.

Small: boas histórias são pequenas. Elas entram no acordo entre Time e Product Owner sobre o
tamanho máximo de uma história dentro da Sprint. Além disso, quando as histórias são
menores, há chances maiores de ter uma estimativa mais precisa. É o típico caso de quando o
Time joga para o alto a estimativa de uma história “por não entender o que implicaria sua
implementação”. Se o time usar essa frase na planning, significa que a história deve ser revista.
 Testable: é preciso testar! Sempre! Testabilidade sempre foi uma característica de bons
requisitos; o mesmo é plenamente aplicável à user stories. Se o cliente não sabe como testar
algo, significa que ou a user story não está clara o bastante ou que ela não contém algo que
acrescente valor aos olhos do cliente.

Definition of Done:

- Desenvolvimento completo, incluindo classes de testes.

- Code Review.

- testes unitários devem ter o coverage towards 100%.

- Testes automatizados executados com sucesso.

- Codigo integrado ao master branch (git).

- Testes de quality*

Coding Conventions:

- Sugestão usar como uma referência inicial:

https://github.wdf.sap.corp/GSLIEBR/Foreign-Trade-Main-Page/blob/master/FT%20Code%20Patterns/
%5BCleanCode%5D%20FT%20Patterns.md

https://wiki.wdf.sap.corp/wiki/display/SCERRR/Code+Conventions+-+BE

Dailies:

- Sugestão inicial dailies diarias por video (via zoom) para integração e interação entre os
participamentes neste momento onde o time não se conhece.
- Manter o tempo maximo da daily em 15 minutos, possiveis temas que extrapolem o tempo
serão tratadas em meetings pois daily.
- Flexibilização status reports executados via chat em determinados dias da semana conforme a
maturidade do time (misto dias apenas em chat ou voz).
Ceremonies:

- Sprints de 2 semanas

- Sprint Planning Meeting:

-P.O. descreve as funcionalidades.

-A equipe questiona.

-A equipe decide se já irá criar tasks de desenvolvimento abaixo de cada user history
apresentada ou uma meeting posterior (Task Breakdown) para discutir pontos técnicos.

-No final é gerado o Sprint Backlog.

- Scrum Team e o P.O. definirão o objetivo.

- Sugestão de tempo 2 horas.

- Quando: segunda-feira ao inicio de um novo sprint.

- Sprint Review Meeting:

-É mostrado o que foi alcançado no Sprint.

-Nesta reunião estará o P.O., Scrum Team e Scrum Master.

- O mais importante é que o objetivo esteja realizado.

- Sugestão de tempo 1:30 h.

- Quando segunda-feira sequente a data final do backlog.

-Sprint Retrospective

-O que funcionou bem;

-O que poderia ser melhorado;

-Quais ações serão tomadas para melhoria;

- Sugestão de tempo 1:00 h.

- Quando segunda-feira ao final da review meeting.