A equipe de um projeto de software

No clássico livro de Frederick Brooks, The Mythical Man-Month, um dos capítulos fala sobre a montagem de uma equipe de desenvolvimento. Ele apelida isso de equipe cirúrgica, na qual traça um paralelo entre uma equipe médica e uma célula de desenvolvimento de software.

A equipe cirúrgica de Brooks

O projeto descrito no livro é enorme e exigia uma quantidade grande de pessoas para terminá-lo. Para evitar os problemas de comunicação, adotaram o princípio de uma equipe cirúrgica, na qual temos 2 cirurgiões e 1 anestesista, sendo apoiados por várias outras pessoas. Lembre-se que o cirurgião deve ter foco total no trabalho e problema diante de sí e não pode nem deve ser distraído com coisas como buscar soro aquecido ou procurar luvas esterelizadas. Essa analogia serve para projetos de software, o dividir para conquistar. Um projeto é dividido em vários outros menores, com seu prazo e escopo definidos.

Inspirado no livro, fiz o diagrama abaixo, baseado nas minhas próprias experiências e literatura corrente como o SWEBOK. Aproveitei para usar outra analogia também. Espero que gostem e entendam.

Essencialmente, temos uma equipe de pelo menos 3 pessoas. Um analista/programador principal, que toma as decisões de arquitetura, tecnologia e projeta o software e um outro analista/programador de apoio. Um coordenador ou gerente de projetos é necessário para tomar conta de toda a burocracia que afeta o projeto diretamente, mas não faz parte da construção do mesmo.

O diagrama acima é apenas uma sugestão do que seria uma célula de desenvolvimento e cabe a você adaptar e decidir o que é melhor para o seu projeto. Preste atenção na quantidade de pessoas, pois aumenta a dificuldade de comunicação e difusão de conhecimento entre seus membros. Uma equipe de desenvolvimento deve ser coesa na forma de trabalhar e se expressar no código-fonte gerado.

Lembrete: de nada adianta criar regras e padrões se ninguém irá aderir a eles. Determine o que é mais confortável e que irá ser seguido, mesmo debaixo de pressão. Algum planejamento é essencial, por menor que seja.

Outros analistas/programadores podem fazer parte do projeto, mas devem seguir as normas, arquitetura e estilo definidos pela dupla principal. Se isso não for seguido, o que você terá no final é código-lixo, com estilos de programação diferentes e que apenas uma ou outra pessoa será capaz de efetuar manutenções, alterações e correções. Nem sempre o programador concorda com uma abordagem. Ele pode e deve sugerir mudanças, mas cabe ao líder pesar se essa melhoria vale a pena ser propagada para todo o restante do código. Boas idéias e soluções sempre surgirão durante um projeto, mas coesão é mais importante que inovação depois de 10 meses.

Mas… e se a empresa for muito pequena? Euquipe?

A primeira coisa a se fazer, é planejar seu tempo. Considere tudo, até os minutinhos gastos em reunião, telefonemas com o cliente, etc. Precisou passar no banco, contabilize. Justifique seu tempo com ajuda a colegas e avise o seu gerente o tempo todo e liste o que foi feito com o seu tempo durante o dia ou semana. São os 15 minutos mais bem gastos do seu dia, nem que precise ficar depois do horário ou chegar uns minutos antes.

Um bom gerente irá criar um escudo contra as burocracias e atividades da empresa que atrapalham o trabalho de análise e programação. A melhor saída é usar um velho conhecido, o TimeBox.

Ele consiste em definir o que pode ser feito dentro de um prazo de 2 semanas. E o que estiver pronto em duas semanas é entregue. O prazo nunca muda e sim os requisitos. Se um requisito é grande demais para ser feito e entregue em duas semanas, o CLIENTE deve ser informado e a decisão é tomada de forma conjunta. Lembre-se também que o tempo gasto em planejamento deve ser contado e justificado. É muito comum o capataz gerente considerar o seguinte no cronograma, se houver um: 2 semanas = 10 dias = 8-10 horas/dia => 80-100 horas-homem de programação. É mais seguro considerar 5-6 horas por dia no começo e ajustar semanalmente.

Não é possível 9 mulheres gerar um bebê em 1 mês. (Frederick Brooks)

Fontes: Bicalho’s Memory About Fraked Up Projects
BROOKS, Frederick P., Jr. 1995. The Mythical Man-Month, Anniversary Edition. Reading, Mass.: Addison-Wesley.
(referência não está no formato ABNT)