Modelo de Trabalho para Equipes Distribuídas em Projetos de Websites com Scrum

Resumo
Este post mostra uma proposta de trabalho para projetos web com equipes distribuídas que possuem foco em trabalhamos com criação de websites, comércio eletrônico, desenvolvimento de sistemas para web e publicidade online (SEO & SEM). Vamos pegar o exemplo do site da ScrumAlliance (http://www.scrumalliance.org).

Visão do Produto
Apresentação do produto a equipe de desenvolvimento. Pode ser utilizado vídeos, fotos, desenhos, storyboards, etc.

Ilustração 1: Visão do Produto


Backlog
Podemos utilizar os produtos da Google Docs para organizarmos nosso backlog.

Ilustração 2: Itens de Backlog


Sprint
O Item de Backlog deve ser quebrado em tarefas. Para facilitar o processo de análise, podemos levar para a equipe de desenvolvimento uma solução em wireframe, para que facilite o entendimento do requisito. Importante, a equipe pode ajudar no processo de melhoria do wireframe, ele não entra como uma verdade absoluta, entra apenas como um facilitador no processo de análise de sistemas a ser realizado pela equipe.
Uma boa pratica é deixarmos sempre disponível os wireframes e um mapa de navegação do sistema, para que os desenvolvedores tenham uma visão mais completa do projeto.

Ilustração 3: Wireframe de um Item de Backlog


Ilustração 4: Mapa de Navegação


Ilustração 5: Planejamento da Sprint - Item de Backlog X Tarefas


Quadro de Kanban
Ilustração 6: Quadro de Kanban (tarefas)


As tarefas devem ser colocadas em um quadro de Kanban, para que possamos acompanhar a execução dos itens de backlog. Podemos utilizar as ferramentas do Google Docs para está finalidade. Basta recortar e colar a tarefa, para ter a representação do post-it movimentado.

Reuniões Diárias
Ilustração 7: Reuniões Diárias


Todos os dias devemos realizar a nossa reunião de alinhamento de tarefas. No nosso exemplo temos que utilizar uma ferramenta que permita falar e todos escutarem, um exemplo é o skype sendo executado em grupo.

Mantendo a Qualidade
Podemos durante a execução da Sprint reduzir o risco das coisas estarem saindo do planejado, tanto a nível de qualidade como a nível de expectativa do item de backlog. Para podemos sempre estar alinhados a cada liberação do item de backlog pela equipe de desenvolvimento, nós podemos iniciar os testes durante a execução da Sprint, realizando desta maneira um trabalho de prevenção de erros.
Uma boa pratica é ter um servidor que possa receber o código a ser testado / validado pelo Product Owner.

Ilustração 8: A Sprint tem que realizar o processo inteiro


Review
Temos que realizar a entrega dos itens de backlog para o Product Owner, podemos utilizar o mesmo servidor de testes (comentado no item “Mantendo a Qualidade”).
Este item tem que ter o apoio de uma ferramenta de comunicação, como o skype em grupo, para que a apresentação do item de backlog sejá realizado ao Product Owner e o Product Owner possa fazer o aceite total, parcial ou rejeitar o item de backlog.

Ilustração 9: Review


Podemos gerenciar as nossas Review utilizando as ferramentas do Google Docs. Onde registramos os problemas / melhorias identificadas e se um item de backlog foi aceito 100%.
Os problemas / melhorias voltam a ser implementados quando o Product Owner desejar, pois ele é o responsável pela priorização dos itens de backlog.

Ilustração 10: Registro da Review


Retrospectiva
Podemos utilizar as ferramentas do Google Docs para realizar a retrospectiva, pois ela permite com que todos os integrantes do projeto possam escrever os itens da retrospectiva ao mesmo tempo.

Ilustração 11: Retrospectiva


A utilização do Skype em Grupo permite a explicação de cada item adicionado ao quadro de retrospectiva para toda a equipe.

Visão dos Documentos no Google Doc
A próxima figura mostra o jogo de planilhas criadas por Sprint.

Ilustração 12: Planilhas por Sprint


Conclusão
Este post apresentou uma proposta de trabalho, utilizando Google Docs e Skype. Mas podemos também utilizar o Google Talk, que também permite um bate papo em groupo. Podemos também utilizar softwares. Mas a questão não é a ferramenta e sim a sua utilização focada a resultados. A grande questão é como podemos realmente utilizar as ferramentas para repor a perda da comunicação face a face que estamos perdendo com a utilização de equipes distribuídas.

Abraço a todos,

Abu