Planejamento da Release
A release terá uma duração de 62 dias. Sendo iniciada no dia 24/04/2017 e tendo seu termino no dia 24/06/2017 Cada sprint terá 1(uma) semana de duração, exceto a primeira sprint(#0) que terá uma duração de 2(duas) semanas, sempre começando e acabando nas segundas-feiras. A partir dessa definições, se tem o cronograma abaixo de sprints.
| Número da Sprint | Início | Término |
|---|---|---|
| #0 | 24/04/2017 | 08/05/2017 |
| #1 | 08/05/2017 | 15/05/2017 |
| #2 | 15/05/2017 | 22/05/2017 |
| #3 | 22/05/2017 | 29/05/2017 |
| #4 | 29/05/2017 | 05/06/2017 |
| #5 | 05/06/2017 | 12/06/2017 |
| #6 | 12/06/2017 | 19/06/2017 |
| #7 | 19/06/2017 | 24/06/2017 |
A primeira sprint foi projetada para durar duas semanas pelo fator conhecimento, isto é, nessa release será desenvolvido a parte visual do projeto Cadernos. Uma vez que será feito em uma nova tecnologia não conhecida por boa parte da equipe, foi necessário designar um tempo extra para o aperfeiçoamento da equipe na nova tecnologia.
Os critérios para afirma que uma user Stories, Sprints e Release estão pronto são apresentados na tabela a seguir.
| User Stories | Sprints | Release |
|---|---|---|
| Testes Unitários e de Aceitação | Aprovação do POM | 90% de cobertura em teste unitário |
| Atendendo aos critérios de aceitação | US do backlog da sprint implementadas | Aprovação do cliente |
| Está de acordo ao guia de estilo | Ritual de Retrospectiva realizado | Métricas de código dentro do padrão estabelecido no plano de qualidade |
| Integrado à branch homolog |
As história de usuário e técnicas estão disponíveis no Backlog do Produto. Sendo a sua categorização da seguinte forma:
| Tipo de História | Quantidade |
|---|---|
| História de Usuário | 22 |
| História Técnica | 6 |
| Total | 28 |
O roadmap da release pode ser encontrado no Board do projeto (é necessario ter o Zenhub instalado). Basta filtrar por milestone, selecionando a sprint desejada. A imagem abaixo mostra um overview do roadmap.
* todas as história da sprint 0 são histórias técnicas
Vale resaltar que o projeto está em contante alteração de escopo e portanto futuras US pode surgir e por isso optou-se por deixar a sprint 7 sem US. Assim a medida que novas história surgirem, teremos onde encaixar no roadmap.
Responsável por manter contato com o cliente de forma mais frequente. Esse papel é o encarregado de manter as expectativas do Product Owner(PO) sempre alinhadas com o time na Sprint Review, uma vez que no contexto é dificil reunir todos stakeholders, vê-se necessário esse papel.
Responsável por manter os valores ágeis dentro da equipe, propondo técnicas, enfatizando a importância das metodologias e motivando a equipe para seguir os objetivos da Sprint.
Responsável por manter a wiki atualizada em relação a todos artefatos gerados na Sprint, isso inclue planejamento e resultados da Sprint, relatório de qualidade das stories implementadas.
A partir dos resultados satisfatórios com uso do Slack na Release 01, decidiu-se continuar usando a ferramenta como principal canal de comunicação entre a equipe.
O Discord e o Hangouts serão utilizados de maneira secundária, como canais para reuniões com pautas mais imediatas.
A daily meeting serão realizadas todos os dias úteis da semana as 20:30 no canal de comunicação #status-update da ferramenta slack. Para recordar todos os integrantes do time, será utilizado uma configuração em um bot para avisar todos os integrantes do grupo que devem mantar seu status naquele momento, conforme a image a seguir.
Para a estimativa de pontos de uma história, será utilizado a técnica de Planning Poker. Técnica que consiste em avaliar uma certa história em pontos na escala de fibonacci. Todos os indivíduos deve, privadamente, selecionar o valor na escala que acham que correspondem ao volume de trabalho da história em questão. Em seguida, todos os membros do time irão discutir os valores selecionado e concordaram com um valor.