ScrumSociety - 2ª REUNIÃO: + definição do processo e cronograma

2ª REUNIÃO: Mais definições em relação ao processo e definição do Cronograma.

Como escolhemos o processo SCRUM, vamos trabalhar em fluxo de SPRINTS. As sprints durarão 15 dias cada e serão delimitadas por uma reunião no começo, a reunião de planejamento, em que planejaremos o que vamos fazer naquela SPRINT, e uma reunião de retrospectiva no final, em que o time se reúne para discutir o que foi feito, quais dificuldades foram encontradas, quais requisitos/histórias do backlog foram concluídas e quais não foram, etc.

O objetivo neste fluxo de processo é entregar um MPV - Mínimo Produto Viável, ou seja, no final da PRIMEIRA Sprint já entregaremos um pedaço de código que realiza uma funcionalidade mínima do produto.

A sprint começa na reunião de Planejamento. O time se reúne e escreve histórias para os requisitos apresentados pelo Product Owner. Essas histórias vão todas para o backlog do produto. O Backlog do Produto reúne todas as histórias já escritas para o produto - ou seja, todos os requisitos traduzidos em tarefas a serem realizadas. Essas histórias são então estimadas (em tempo de implementação, ou tempo para concluí-las). O Product Owner, em constante contato com o Cliente, ordena as histórias por ordem de PRIORIDADE. O Time Então decide quais histórias vão entrar na Sprint, levando em consideração as histórias na ordem de prioridade estabelecida pelo Product Owner, e também o tempo estimado para cada história. O time deve ponderar a respeito do tempo da Sprint e quantas histórias podem ser realizadas neste tempo. Faz parte do processo fazer uma boa estimativa e conhecer profundamente o ritmo e os limites do time. É importante que o time faça uma estimativa precisa. Se muitas histórias entram na Sprint e, ao final da mesma, as histórias não foram concluídas (homologadas), então a Sprint é quebrada. Isso significa que o time fez uma estimativa fraca para a Sprint, pois puxou muitas históris do backlog para uma mesma sprint, causando overload. O extremo contrário também é problemático: caso o time puxe poucas histórias para a Sprint, e conclua todas as histórias antes do término da Sprint, então o time deverá puxar mais histórias do backlog para aquela sprint. É ideal que o time se conheça e saiba estimar bem quantas tarefas consegue realizar em um determinado período de tempo.

Como o time é auto-organizável, uma vez que tenha-se decidido quais histórias serão executadas na sprint, o próprio time se divide (em comum acordo) em relação às histórias. Há históras de testes caixa preta, testes de interface, implementação, usabilidade, etc. O Time se auto organiza para realizar as histórias, considerando algumas premissas:

• O modelo de programação é XP - Extreme Programming, então o time trabalha em duplas. Uma dupla realiza uma mesma história. Enquanto um da dupla implementa, o outro fiscaliza. Os integrantes da dupla invertem os papéis a cada hora.
• As duplas devem variar entre o Time;
• Os tipos de história também devem variar entre as duplas (uma mesma dupla não deve realizar sempre o mesmo tipo de história). O ideal é que cada dupla realize, numa mesma sprint, os papéis de desenvolvedor, tester, etc.

Quando uma história é concluída, é o papel do SCRUM Master homologar a história com o Dono do Produto. O SCRUM Master mostra a história concluída para o PO, que diz se é aquilo mesmo que ele queria para aquele requisito ou não. A história só pode ter seu status trocado para CONCLUÍDA após ser homologada.

Definido o processo de desenvolvimento de nosso Produto, nós nos reunimos também para definir o CRONOGRAMA do desenvolvimento.

DEFINIÇÃO DO CRONOGRAMA:

• 05/10 a 09/10: Reuniões iniciais: Planejamento do Processo
• 12/10  a 16/10: Reuniões iniciais: Definição do Produto
• 20/10 a 30/10: Sprint 1
• 30/10: Primeira Entrega
• 02/11 a 13/11: Sprint 2
• 13/11: Segunda entrega
• 16/11 a 27/11: Sprint 3
• 27/11: Terceira Entrega
• 01/12: Apresentação e Entrega final

Para a próxima reunião, vamos começar a definir o que o Produto é, qual o nome, qual sua descrição de elevador, o que ele faz e o que ele não faz. Então criaremos personas para o nosso produto, e então, após isso, vamos começar a análise de requisitos e criação de histórias.