No projeto em que venho trabalhando desde
o final de 2003 projeto este que resultou na construção de um
software de gestão acadêmica - nosso grande desafio foi tentar levar informações gerenciais e de acompanhamento do projeto para fora do "war room". Nossa realidade contava com a participação de alguns gerentes e patrocinadores que não frequentavam nossa sala de projeto e, portanto, acabavam tendo que se atualizar por meio de reuniões periódicas que, na maioria das vezes, eram difíceis de se agendar. Por outro lado, a comodidade de se poder acompanhar o andamento do projeto mesmo remotamente foi vista como um grande diferencial tanto pelo cliente quanto pela própria equipe de desenvolvimento. O portal do projeto era consultado várias vezes por semana por gerentes e patrocinadores e muitas vezes por dia pelos próprios membros da equipe.
Quando se fala em agilidade para projetos de desenvolvimento de software uma coisa sempre me vem a cabeça: gargalos. O grande diferencial em processos construídos à partir de métodos ágeis está, no meu ponto de vista, em se minimizar ao extremo todo e qualquer gargalo que possa interferir no trabalho da equipe quando esta tenta transformar as idéias do cliente em software funcional. Assim, tínhamos muito receio que o portal criasse algum tipo de gargalo burocrático para a equipe, afetando diretamente sua velocidade. Assim procuramos diluir as tarefas de atualização das informações no portal entre a equipe de modo a não sobrecarregar um ou outro de seus membros.
O Portal O portal foi construído com base em um instrumento de gestão de conteúdo para portais corporativos que eu desenvolvi no ano de 2002. No entanto, acho possível que outras ferramentas - como o Plone ou o SharePoint - também possibilitem a um projeto alcançar resultados semelhantes. Algumas customizações foram feitas na ferramenta de modo a formatar a informação da maneira que precisávamos e o resultado pode ser observado na figura 1.
Figura 1 Área principal do portal de acompanhamento do projeto.
A figura 1 mostra o portal do projeto exibindo a situação do projeto em meados da iteração de número 09, ocorrida entre 17/06/2004 e 05/07/2004. Nesse momento, havia a meta de se atingir aproximadamente 446 pontos em 10 iterações, o que equivalia a se atingir o primeiro marco do projeto, definido pela equipe em conjunto com gerentes e patrocinadores. Ao acessar o portal, estes stakeholders tinham uma visão clara do andamento não só do projeto como um todo, mas também da iteração que se seguia. Era possível saber o nível de velocidade da equipe por meio de um gráfico de análise simples e também conferir visualmente como andava o progresso das iterações. Várias informações disponibilizadas pelo portal foram utilizadas pelos gerentes para, por exemplo, aumentar ou diminuir a equipe de desenvolvimento de acordo com nossas demandas de prazo. Repare (pelo gráfico de velocidade) que houve uma queda de rendimento entre as iterações 03 e 04 um desenvolvedor deixou a equipe nesse período - e depois um salto entre as iterações 04 e 05 três novos desenvolvedores foram contratados.
Tivemos a preocupação também de publicar alguma documentação de suporte metodológico, já que os métodos utilizados não eram de todo conhecido pelos patrocinadores. O Plano de Projeto, release planning e a própria descrição do processo interno de desenvolvimento também foram importantes principalmente para os novos membros da equipe que chegavam ao longo do tempo.
O portal também se tornou um ótimo instrumento para centralização do acesso às várias ferramentas de apoio ao processo que utilizávamos (integração contínua, bug tracking, etc). O cliente o utilizava para ter acesso às releases liberadas confrontando-as com as informações de finalização do desenvolvimento de uma user-story.
Outra visão gerencial que sentimos a necessidade de apresentar foi um gráfico para acompanhamento dos testes de aceitação realizados pelo(s) cliente(s). Veja figura 2.
Figura 2: Gráfico para acompanhamento da execução dos testes de aceitação ao longo do tempo.
Essa implementação foi inspirada na sugestão dada por Ron Jeffries, Ann Anderson e Chet Hendrickson no livro Extreme Programming Installed (veja figura 3). Ao realizar os testes de aceitação o cliente fazia a marcação nesse gráfico de forma que tínhamos uma idéia dos nossos níveis de regressão ao longo do tempo.
Figura 3: Gráfico sugerido por Ron Jeffries et al,
em Extreme Programming Installed.Desafios Nosso maior desafio foi absorver as atividades de alimentação do portal sem burocratizar o processo e sem criar documentações de pouco valor para o usuário. Começamos, então, definindo as seguintes regras:
1 A equipe de desenvolvimento continuaria a trabalhar com informações físicas dispostas na parede da War Room. Adesivos vermelhos, amarelos e verdes seriam afixados nos cartões para indicar seu andamento. Os cartões estariam dispostos em um quadro de cortiça na parede da War Room (veja figura 4).
2 Os cartões físicos continuariam sendo escritos na reunião de início de iteração, porém, os testes de aceitação seriam descritos diretamente no portal pelo cliente.
3 Ao iniciar ou concluir uma tarefa, os desenvolvedores tinham a responsabilidade de acessar o portal e marcar o status da user story para Iniciado ou Concluído.
4 O cliente também tinha a responsabilidade de lançar no portal o resultado de cada teste de aceitação realizado.
5 Os desenvolvedores deveriam manter uma cópia impressa do cartão de forma a orientar seu trabalho para atender os testes de aceitação. Alterações no cartão eram atualizadas à lápis na cópia impressa e depois discutidas com o cliente para que ele as atualizasse no portal.
 Figura 4 Os cartões de iteração foram mantidos em seu modelo tradicional
Segundo esse modelo, a equipe de desenvolvimento sofreu pouco impacto no seu dia-a-dia. O desenvolvedor, apenas precisava fazer duas coisas: abrir a história no portal e redefinir seu status e colocar o adesivo no cartão localizado no quadro de cortiça na War Room. O maior impacto ficou definitivamente por conta da sobrecarga de trabalho para o cliente. Para resolver isso, eventualmente foi preciso alocar um ou dois analistas de negócio para o ajudarem na execução e na documentação dos testes de aceitação. O formulário apresentado a seguir (Figura 5) era utilizado pelo cliente ou analista para documentar a user-history.
Figura 5: Formulário para lançamento de conteúdo no portal. Nesse caso o conteúdo é uma user-story, mas poderia ser uma release, ou um outro documento qualquer.
Um qualificador chamado Story Point e outro chamado Situação permitiam que o portal calculasse as métricas apresentadas na página principal.
À medida que as iterações se sucediam, um repositório de conteúdo ia se formando permitindo a formação de uma base de conhecimento sobre o projeto que foi muito útil principalmente quando havia troca de membros na equipe (Veja figura 6).
Figura 6: Repositório de user stories classificados por iteração.
O acompanhamento de releases também podia ser feito pelo portal graças a uma integração com os resultados gerados pelo Cruise Control.Net. As informações formatadas no portal indicavam o que efetivamente tinha sido modificado em cada release publicada.
Figura 7: Repositório de releases geradas pela integração contínua.
Conclusão Esse case me permitiu exercitar algumas idéias para a disponibilização de informações de acompanhamento em projetos ágeis. Mesmo sendo tal idéia, de certa forma, um pouco contraditória com os próprios princípios ágeis, na medida em que podem burocratizar o processo. O que eu pude aprender nesse case é que é possível sim, integrar um projeto de software ágil com outros métodos ou instrumentos de gerenciamento, desde que os princípios do manifesto ágil sejam mantidos e que o código do software continue sendo visto como o artefato mais importante de todo o processo de desenvolvimento. De fato, é preciso muita atenção e muito cuidado para com a definição dos papéis e muita disciplina da equipe para manter a rotina de atualização funcionando. O que pude observar, é que depois que essas rotinas são incorporadas ao dia-a-dia da equipe, o processo flui de maneira muito mais controlada e organizada, deixando gerentes e patrocinadores mais tranquilos com relação a evolução do projeto.
|