upGAME Group - Processos

Apesar de estarmos fazendo muitas postagens mais ao estilo ágil, é importante falarmos um pouco mais sobre os processos usados e como estão sendo aplicados.


Processo utilizado e sua aplicação

Como informamos na primeira apresentação, estamos trabalhando utilizando o Scrum, porém, com o passar do tempo, resolvemos adaptar um pouco o Scrum para se alinhar com as necessidades do grupo e com as limitações da ferramenta.

As diferenças.

Em um breve resumo, nossas principais diferenças são:

• Não temos Burndown;
• Não trabalhamos com um Backlog Global;
• A comunicação presencial é mais restrita;
• Nossas tarefas contam apenas com dois estados: To Do e Done;
• Temos um membro para cuidar exclusivamente das tarefas administrativas/gerenciais.

Em nosso processo, não temos um Burndown, isso porque o Issues Trackar não nos proporciona essa funcionalidade. Assim sendo, estamos monitorando o progresso dos pares pelos commits feitos no Github.

Podemos citar também as diferenças quanto ao Backlog. Como temos um prazo máximo de entrega a ser respeitado, um grupo grande e poucas Sprints para fazer as tarefas, resolvemos, em uma reunião, definir nossas tarefas e alocá-las nas 4 sprints necessárias para concluirmos nosso trabalho, assim sendo, não fizemos um backlog global, apenas fizemos os backlogs para cada sprint, distribuindo as Tasks previamente. Apesar disso, tarefas que ficam remanescentes das sprints anteriores, são colocadas nas próximas, assim como no Scrum padrão.

Backlog para a Sprint 3 (Atual).

Backlog da Sprint 4 (Próxima e última).

A maior parte da nossa comunicação está sendo feita por meio do github. Quando uma task é atualizada, o github envia um e-mail informando a todos os colaboradores do projeto que ela foi alterada e as informações que foram adicionadas e tudo mais, assim como quando uma tarefa é criada e excluída.

Outro problema que tivemos é que no Issues Tracker não temos como classificar as tasks como To Do, In Progress ou Done. Ele possibilita apenas To Do e Done. Para sabermos o que cada par de programação está fazendo, nos reunimos após as aulas. Neste momento todos dizem em que o seu par está trabalhando a previsão de conclusão daquela tarefa

Outro diferencial para o Scrum é que, além dos programadores, temos também um membro que cuida da parte administrativa e gerencial do projeto, ficando por conta da alocação de tarefas no Issues Tracker, documentação, atualização do blog, criação das apresentações e monitoria do andamento das tarefas. Pensamos que isso ajudaria pois os outros integrantes devem apenas se preocupar em programar e em estar atento as tarefas no Github e seus prazos. Com isso evitamos a sobrecarga de funções, o que pode atrapalhar o rendimento geral do grupo.

Modelo de Pares de programação

Com a utilização de um modelo de programação em pares estamos obtendo bons resultados. Neste modelo, os dois integrantes do grupo programam funcionalidades diferentes. 

Após terem concluído suas tarefas, o outro integrante fica responsável pela análise do código de seu parceiro.

Quanto o código passa pela análise, os dois integrantes devem fazer os testes nas aplicações criadas para garantir o funcionamento.

Assim, cada par é responsável pela qualidade e a funcionalidade dos seus códigos.

Esse modelo será desfeito na sprint final, a sprint de integração, onde todos os integrantes devem integrar as funcionalidades ao sistema final e fazer os testes (testes de caixa cinza), para certificar-se de que a integração não atrapalhou no funcionamento das aplicações.