Fernando Costa

o 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:
Meiobit
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)

Houve um feedback muito positivo sobre os posts relacionados a engenharia de software e projetos. É impressionate como as empresas e obviamente, as pessoas que fazem parte delas, continuam cometendo os mesmos erros. E mais, são erros tão comuns que não importa a tecnologia. Prazos muito curtos, estimativas completamente erradas, requisitos mutantes, gambiarra e fracassos, muitos fracassos.

O The Standish Group publica um relatório chamado The Chaos Report e mostra o cenário da indústria de software:

- Aproximadamente 18% do projetos são cancelados por atrasos e orçamento estourados.
- Aproximadamente 52% dos projetos estouram o orçamento e/ou o prazo.
- Aproximadamente 30% de todos os projetos de TI atingem seus objetivos dentro de prazo e custo estimados.

Se apenas 3 de cada 10 projetos dão certo, o que raios está havendo com os outros 7? A taxa de falhas é enorme e não há comparação com outros tipos de indústria e os motivos já foram descritos em inúmeros livros e um deles é: software é abstrato.

Quando alguém pede para colocar rodas de liga leve no carro, espera pagar por isso. O objeto “roda de liga leve” pode ter sua qualidade analisada imediatamente: menor peso, mais bonito, etc. A mesma lógica não funciona para software, já que ele não existe no mundo físico, é texto que magicamente faz alguma coisa acontecer dentro do computador.

“…colocar uns botões dinâmicos aqui, sem refresh… poderia ser em Flash ou quem sabe Silverlight. Hum… será que Flex seria vantajoso? Vamos fazer em Flex. Se ficar ruim, tentamos Flash e/ou Silverlight. Mas não pode atrasar!”

O que assusta muita gente é que não há linguagem, framework, ferramenta ou plataforma que resolvam problemas que estão além da tecnologia. As metodologias de desenvolvimento ágil como o Iconix, Scrum e XP tem o mantra “embrace change”, ou seja, não lute contra mudanças, mas integre-as ao seu dia a dia. Apesar disso parecer uma novidade, não é. Esse tipo de busca já havia sido objeto de pesquisa e análise nos anos 60 e 70 do século passado.

E o que é mais interessante. A lista que vou apresentar abaixo é antiga e muita gente lê e diz: nossa, verdade.

Agora, dos listagem acima, quantos deles o PHP, Ruby on Rails, Java ou .Net possuem influência?

Nenhum. São atividades que precedem a escrita do código e a escolha da tecnologia. Todas circulam em torno de Planejamento. Há um enorme vício em começar a trabalhar sem planejamento algum. É impressionante como o importante é sempre o mantra “começar o desenvolvimento o mais rápido possível”. É o velho pensamento de que se não há código, não há progresso.

Se traçarmos um paralelo com o mundo real, é como começar a construir um prédio, sem saber quantos andares ele vai ter.

Fonte:

Meiobit

Bicalho’s Memory About Fraked Up Projects