Alisson Vale

Esta semana duas publicações interessantes sobre Integração Contínua me chamaram a atenção a ponto de eu estar sugerindo aqui no meu blog.

A primeira é um screen cast no DnrTV com Scott Hanselman e Jay Flowers sobre o CI Factory. O CI Factory realmente me impressionou. Ele ajuda a preparar e gerenciar "workspaces" que isolam, padronizam e permitem fácil extensão e manutenção de sistemas de integração contínua. Em poucos minutos de contato com a idéia da ferramenta já dá pra perceber o quanto seus projetos vão poder se beneficiar de seus recursos. Acho que o ponto alto do CI Factory é trazer consigo um grande conjunto de boas práticas na construção e no gerenciamento de sistemas de Integração Contínua e Build Servers. Algumas das boas práticas que detectei apenas vendo o vídeo (ainda não parei para me aprofundar no uso da ferramenta, mas certamente o farei assim que puder):

• Todos os arquivos necessários para execução da build estão no mesmo contexto de controle de versão do próprio aplicativo;
• Toda a lógica de build é portável de forma que pode ser rodada não só no servidor, mas também nas workstations dos desenvolvedores;
• As referências a componentes de terceiros são organizadas e gerenciadas em um espaço próprio;
• Adicionar ou Remover passos é simples e rápido;
• Incorporar novos recursos à sua build também é muito fácil e rápido. Já vem com os pacotes para vários controladores de repositório, Versionamento de assemblies, Frameworks para execução de Unit Tests, Code Coverage, Métricas, Análises de Código, Deployment e Pacotes para Instalação.

Um outro post interessante foi do Martin Fowler a respeito dos gargalos que às vezes podem ser gerados com builds quebradas em processos de integração contínua. Quando uma build é quebrada, o resto do time é afetado até que a build seja corrigida. A solução pode ser o uso de “branches privados” onde o desenvolvedor faz uma integração prévia antes de integrar com a mainline. Eu particularmente acho que alguma disciplina pode ajudar bastante em diminuir este problema. Práticas como, por exemplo, não integrar no fim do expediente e na iminência do horário de almoço, não realizar integrações simultâneas, deixar bem visível para o restante da equipe que há alguém integrando e evitar que desenvolvedores que estão integrando sejam interrompidos por qualquer motivo.

Uma das coisas que estou trabalhando neste momento é em uma maneira de registrar o que aconteceu em cada Sprint de projeto. Acho que vale a pena ter um instrumento simples pra fazer isso, e em termos de simplicidade ninguém consegue bater um “wiki”.

Assim, estou trabalhando agora em modelo de registro histórico dos sprints em nosso wiki (mediawiki), conforme mostrado no screenshot a seguir:

É importante para nós saber o que aconteceu em cada Sprint. O Product Owner assumiu então esse compromisso de manter um registro histórico dos principais acontecimentos de uma sprint. Isso envolve registrar:

·          a agenda que foi acordada;

·          a meta definida;

·         O backlog do sprint;

·         Que intervenções não planejadas precisaram ser realizadas;

·         Que bugs foram corrigidos?

·         Atendimentos  realizados ao cliente

·         Quais foram os resultados da retrospectiva.

o   O que funcionou bem?

o   O que pode melhorar?

Minha impressão me diz que esse tipo de registro vai ser simples de fazer e deixará uma sensação concreta do progresso do projeto. Será sempre interessante rever sprints de meses ou anos passados e analisar como o projeto evoluiu até seu estado atual.

O ambiente informativo é uma das características mais marcantes de um projeto ágil. Saber o que está acontecendo em um dado momento do projeto apenas olhando as paredes da sua "War Room" é um dos grandes atrativos oferecidos pelos métodos ágeis.

Além disso, há o fator psicológico. Ter todas as ações relacionadas com o escopo da iteração fora da sua cabeça alivia a pressão e o stress de ter que gerenciar uma enorme lista de coisas a fazer na sua memória de curto prazo. O desenvolvedor faz um planejamento das tarefas necessárias para o desenvolvimento de uma funcionalidade, escreve em post-its e cola no quadro. Cada tarefa deve durar no máximo um dia. Ao começar uma nova tarefa, o desenvolvedor remove seu post-it associado da área "To do" e o coloca na área "In Progress". Ao terminar, o post-it é movido para a área "Done". Como uma funcionalidade é criada por meio da execução de n tarefas (representadas em post-its), quando todos os post-its forem movidos para a área "Done" o seu desenvolvimento termina.

O que o SCRUM traz de interessante em suas práticas é que cada funcionalidade (ou item de backlog) é "atacada" por todo o time de uma só vez. Em outras palavras todos os membros do time de projeto trabalham na mesma funcionalidade até que ela seja completamente finalizada. Só aí passa-se para o próximo item de backlog da iteração. Dessa maneira, os post-its com as tarefas são distribuídos e resolvidos em paralelo e não mais de maneira sequencial. O principal benefício desse método é o trabalho em equipe. Cinco ou seis mentes com um objetivo comum produzem realmente um trabalho melhor. O lado negativo fica por conta da perda de produtividade. Não tenho elementos para comprovar que essa perda ocorra de fato, mas para nós esse fato se tornou evidente.

Pensando no processo transcorrendo dessa maneira projetamos um quadro informativo conforme a figura abaixo:

No mundo real o quadro ficou assim:

Os cartões brancos representam itens do backlog. Os post-its são as tarefas. A foto foi tirada no meio de uma iteração experimental de uma semana, por isso poucos cartões brancos. Mas repare na quantidade de post-its. O que tem de ser feito não está na cabeça de alguém, está no quadro e pode ser feito por qualquer membro da equipe.

Na teoria o quadro parece se encaixar bem no dia-a-dia de uma equipe Scrum. Na prática tivemos dificuldade em fazer algumas áreas funcionarem, principalmente a parte de impedimentos. A expectativa é que isso mude na medida em que o processo se torne mais aderente às nossas rotinas diárias.