MSF na prática - Controlando um projeto com bandeiras

Este artigo é baseado em um projeto real que participei. Conceitos fundamentais de MSF – Microsoft Solutions Framework, SDLC – Software Development Life Cycle, Item Tracking e gestão de pessoas estão inseridos na narrativa como uma estória.

por Fabio Camara

Este artigo é baseado em um projeto real que participei. Conceitos fundamentais de MSF - Microsoft Solutions Framework, SDLC - Software Development Life Cycle, Item Tracking e gestão de pessoas estão inseridos na narrativa como uma estória.

Este artigo é um pequeno pedaço de um livro novo sobre MSF que em breve será lançado. Espero dos meus amigos leitores, críticas e sugestões sobre o estilo que estamos adotando para o conteúdo do livro.

Controlando um projeto com bandeiras

Era um projeto único para história das instituições financeiras do Brasil. Algo muito mais assustador que o bug do milênio e com possibilidade de efeito real, pois se não ficasse pronto na data contratada - pense em mudar de profissão - foi a frase dita pelo meu contratante.

A matriz de balanceamento estava assim configurada:

• Tempo: Fixo;
• Funcionalidade: Aceitável;
• Recursos: Gerenciamento livre.

A plataforma tecnológica era baseada em Windows DNA. Eram centenas de componentes e páginas em ASP. Eram dezenas de programadores, muitos entravam e saiam durante todo o projeto. O sistema deveria ter três grandes módulos: Segurança, gerenciador de troca de mensagens e mecanismo de controle de reserva bancária. Para acrescentar mais um desafio ao projeto, como se não bastasse os existentes, exigiram a utilização de uma ferramenta de troca de mensagens do principal concorrente da Microsoft, por motivos puramente políticos.

Minha sensação no meio do projeto era terrível. Tínhamos 60 desenvolvedores, 3 coordenadores, 4 analistas de negócios que também testavam e um arquiteto com comportamento complexo. Certa vez tive o seguinte sonho: _ Estava na central de trens no horário mais lotado do dia, praticamente não se enxergava dois metros à frente. Segurava uma criança de pouco mais de três anos em minha mão direita. Uma pessoa esbarrou em mim e minha carteira caiu no chão. Soltei levemente a mão para abaixar-me e pegar meus documentos e dinheiro. Senti uma sensação horrível. Fechei os olhos para não ver o que eu mais temia. Acordei assustado no meio da noite. Fiquei feliz em perceber que era um pesadelo, mas me preocupei muito ao decifrar o sonho e entender que assim estava o projeto.

No dia seguinte comecei a estudar quais seriam os ciclos de vida mais adequados para o projeto. Todos estavam praticamente andando com vontade própria, conforme as experiências anteriores do profissional alocado. Depois de alguns estudos, assim definimos os ciclos:

• Segurança: todas as especificações eram imutáveis e o sistema exigia um planejamento prévio muito bem elaborado. Decidimos por ciclo em cascata e apostamos no profissionalismo do coordenador responsável.

• Gerenciador de trocas de mensagens: este módulo tinha requisitos "semi-congelados" e com um grau de importância ao projeto significativo, pois criava dependência com os demais módulos. Nosso primeiro pensamento era colocar a regra de compilação diária como ciclo, mas as funcionalidades não conseguiam ser compiladas com alguma funcionalidade razoável em 8 horas. Decidimos por utilizar um ciclo iterativo incremental com marcos miniaturas. Os marcos tinham entre um dia e três dias. Depois deste prazo, uma compilação automática era feita e o resultado submetido para testes funcionais.

• Mecanismo de controle da reserva bancária: provavelmente este módulo era o "coração" do projeto. Precisávamos confiar em analistas de negócios que nunca havíamos trabalhado antes. Estes analistas eram profissionais de negócios e não estavam acostumados a trabalhar em projetos de tecnologia de informação. Para uma melhor visualização do desafio, estes analistas não sabiam testar a própria funcionalidade que especificaram. Nossa decisão foi unânime - utilizamos compilação diária com testes superficiais dentro de um ciclo iterativo incremental. Os testes eram realizados por profissionais cruzados, ou seja, o testador não podia ter especificado a funcionalidade.

Parecia que os problemas estariam sob controle, mas minha sensação ruim continuava. Depois de uma semana funcionando desta forma, a motivação dos times estava melhor. Todos estavam otimistas, contudo alguma peça ainda estava ausente e eu não sabia qual era. No domingo tive outro sonho: Estava num grande cruzamento, em cima de uma pequena plataforma, e eu funcionava como um guarda de trânsito substituindo os sinais. Eu percebia carros passando, mas não conseguia identificá-los. Acordei com a compreensão que faltava controle no projeto.

Todos os coordenadores eram competentes, porém eram otimistas demais. Contratei uma pessoa, que chamei de "controller", para ficar controlando todos os resultados combinados nos ciclos dos módulos. Era algo como um escritório de gerência de projetos (PMO - Project Management Office). O controller me trazia com antecipação as tendências de desvios do planejado contra o realizado e um relatório de gerenciamento de risco. Nossos cronogramas trabalhavam praticamente com o universo de duas semanas, uma imediatamente anterior e a semana seguinte. Usamos o conceito de "timeboxing", ou seja, cada iteração tinha um número fixo de funcionalidades e demoravam uma semana. Caso alguma funcionalidade não ficasse pronta na semana, nós fechamos a iteração assim mesmo e colocamos as funcionalidades que sobraram nas próximas iterações ou em alguma iteração especial que chamamos de "task force".

Nota do Autor: task force era uma iteração especial, muito curta, implementada como uma espécie de jogo, que tinha como objetivo finalizar todas as funcionalidades "retalho" das outras iterações. Na iteração task force, os desenvolvedores tinham horário de entrada mas não tinham horário fixo de saída. Algumas vezes, usamos task force para acelerar a redução de bugs e atingir o índice de "zero bug bounce".

A sinalização literal

Após quatro semanas de implementadas as novas técnicas de ciclo e controle, descobrimos que ainda tínhamos um sério desafio. A questão era: Nós sabíamos com antecedência sobre determinados desvios e avisamos os coordenadores e desenvolvedores que estavam diretamente responsáveis pelo módulo, entretanto nem todos da equipe se comprometiam em ter atitudes diferentes para reverter o quadro.

Lembrei do romance que ensina a teoria das restrições intitulado "a meta" de Elyahu Goldratt e Jeff Cox e estava prestes a me conformar com esta situação. No romance, o autor ensina que os gargalos não são eliminados, eles são distribuídos em novos gargalos que geralmente são menores. Comecei a conversar com um consultor da Microsoft sobre esta situação e ele me falou que utilizava um relatório de status do projeto no qual havia umas sinalizações chamadas bandeiras. Estas bandeiras existiam para visualmente tornar o relatório mais fácil de compreender.

• Banderia azul: funcionalidades completadas, após ciclo de testes funcionais e teste de aceitação com o cliente;

• Bandeira verde: funcionalidades sendo implementadas dentro do prazo planejado;

• Bandeira amarela: funcionalidades com pequenos atrasos que não ultrapassam o prazo de uma iteração. Em outras palavras, conseguiríamos colocar o projeto com bandeira verde na próxima task force;

• Bandeira vermelha: funcionalidades com atrasos superiores a uma iteração. Em outras palavras, não conseguiríamos recuperar o projeto com uma task force.

Ao ouvir isso compreendi meu sonho. Os sinais!!! Era a técnica que faltava para sensibilizar todos da mesma forma no projeto. Primeiro, compramos as bandeiras e colocamos junto com a equipe do módulo, de preferência na entrada e em local bem visível. Depois criamos uma reunião semanal, toda segunda-feira pela manhã, onde avaliávamos com a equipe o status do projeto e definíamos a bandeira daquela semana. Estipulamos as seguintes regras para as bandeiras:

• Bandeira verde: uma reunião semanal na segunda-feira pela manhã;

• Bandeira amarela: três reuniões na semana, na segunda-feira pela manhã, na quarta-feira no final do dia e na sexta-feira no final do dia para incentivar possíveis trabalhos no final de semana;

• Bandeira vermelha: reuniões todos os dias, duas vezes ao dia (as vezes três). Pela manhã para assegurar que todos sabem quais são as metas do dia e ao final do expediente para verificar se as metas foram alcançadas. Dependendo da situação, excepcionalmente encorajávamos algumas horas extras.

Minha proposta na bandeira vermelha era que o ciclo fosse insuportável. Eu pessoalmente exercia uma pressão muito grande em todos do time do referido módulo. No meu pensamento, eu estava passando um comprometimento especial para que ao entrar em bandeira amarela, todos evitassem a qualquer custo entrar em bandeira vermelha.

A sinalização foi um sucesso. Até o comportamento pessoal entre os desenvolvedores era diferente. Quando estavam em bandeira verde, saiam para almoçar por duas horas, conversavam sobre futebol e shows de rock. Na bandeira amarela, o silêncio reinava. Na bandeira vermelha, os amigos dos outros módulos não chegavam perto para não atrapalhar o empenho do time em recuperação.

Outros benefícios foram:

• Redução da entrada e saída dos desenvolvedores no projeto: apesar da pressão que era exercida nas "task forces" ou nos momentos de bandeiras diferente da verde, os programadores gostavam do ambiente de profissionalismo e diziam que o projeto era uma escola;

• Maior previsibilidade: sabíamos com antecedência saudável os desvios. Apesar de não alterarmos em hipótese alguma uma iteração em andamento, podíamos já incluir na iteração seguinte ou planejar uma task force especial.

Com a comunicação clara, verificação freqüente através de marcos e reuniões otimizadas, tornamos o projeto "dominável" e principalmente previsível. Em vários momentos tivemos que tomar decisões para trazer o projeto de volta à linha da previsibilidade, entretanto julgamos que isto fazia parte de nosso papel no projeto.

Chamamos de reuniões otimizadas por que fazíamos em uma sala especial. A sala não tinha mesa nem cadeiras, somente quadros brancos espalhados por todas as paredes disponíveis. Todas as reuniões nesta sala eram em pé, obviamente, pois como afirmamos a pouco, a sala não tinha mesa nem cadeiras. Fazíamos dois tipos de reuniões nesta sala: reunião de distribuição de tarefas de uma iteração e reunião de especificação de idéias iniciais.

No primeiro tipo de reunião, escrevemos no quadro todas as funcionalidades que deveriam constar na iteração nos quadros disponíveis. Explicamos as funcionalidades e delegamos para os técnicos que seriam responsáveis. Verificamos todas as dependências entre as funcionalidades e analisamos os riscos. No final de trinta minutos, no máximo, todos estes importantes assuntos estavam acordados entre todos. Nossa ATA da reunião eram fotos digitais passadas por e-mail para todos os presentes na reunião.

No segundo tipo de reunião, convocamos especialistas em um determinado assunto. Quebramos o assunto em pedaços menores e determinamos um especialista presente na reunião para cada pedaço. Os especialistas escolhiam um quadro disponível e escreviam idéias macro sobre funcionalidades necessárias ao pedaço. Depois que todos terminassem - cerca de vinte minutos, todos trocavam de papel: de autores, passavam a revisores dos outros textos escritos. Cada especialista revisava pelo menos dois quadros. No final de uma hora, tínhamos um interessante conjunto de idéias sobre funcionalidades com um ótimo nível de factibilidade.

De todas as técnicas que usamos, as mais complexas de implementar foram:

1. Manter as funcionalidades de uma iteração imutáveis durante a própria iteração, visto que tínhamos mudanças com mais freqüência do que havíamos planejado inicialmente: o problema é que todo mini-time adorava uma possibilidade admissível de desculpa para não cumprir com a implementação de todas as funcionalidades dentro do prazo fixo da iteração;

2. Evitar utilizar os recursos alocados em uma iteração durante a própria iteração, pois em determinados momentos do projeto foram necessárias várias reuniões emergenciais: idem acima, é patrocinar justificativas aceitáveis para atrasos;

3. Acostumar os patrocinadores do projeto a só terem informações detalhadas de cronograma no prazo de duas semanas: como só abríamos em detalhes até duas iterações para frente, muitos dos investidores reclamavam da falta de uma projeção de médio e longo prazo que fosse mais confiável que nossos "chutes estimados";

4. Considerar índices de erros estáveis para alocação de recursos, pois de tempos em tempos sofríamos a surpresa negativa de descobrir acentuados índices de erros: trabalhávamos com a margem de 10% de re-trabalho, ou seja, a cada 120 horas, planejávamos 12 horas para correção de bugs. Na maioria das vezes dava certo, contudo nas vezes que falhou tivemos sérios problemas para recuperar atrasos.

Por fim, em um belo dia após o final de semana mais tenso de minha história nesta existência humana, o projeto entrou em produção e uma equipe de manutenção formada por muitos dos participantes do projeto assumiram o produto. Na minha reflexão, o ciclo iterativo incremental com "timeboxing" foi chave para o sucesso, entretanto sem as bandeiras teríamos sofrido muito, muito, muito e muito mais. Um brinde a quem idealizou as bandeiras!!!