Em 1975, Frederick P. Brooks escreveu o revolucionário The Mythical Man-Month. Quarenta anos depois, esta série de artigos pretende revisar as afirmações e os argumentos do autor. Quanto o ofício da Engenharia de Software evoluiu desde então?

Capítulo 3: The Surgical Team

Neste capítulo, Brooks analisa o problema da construção de grandes sistemas de software.

Logo de início, o autor cita um estudo realizado por Sackman, Grant e Erickson que encontrou uma diferença de produtividade de 10 para 1 entre programadores com o mesmo nível de experiência. O estudo não encontrou relação alguma entre experiência e produtividade.

Com base nessa informação, Brooks questiona se a ideia de usar uma equipe pequena de pessoas altamente capacitadas ao invés de uma massa maior de pessoas medianas não seria mais eficiente. Por exemplo, num projeto grande envolvendo 200 pessoas, a ideia seria demitir as 175 menos produtivas e montar um super time de 25 pessoas bastante capacitadas.

Note que o conceito de equipes de alto desempenho é frequentemente trazido à tona pelos proponentes do movimento ágil, mas vemos aqui a discussão desde pelo menos a década de 70.

Brooks reforça a ideia de um bom time com poucas mentes trabalhando num projeto, mas lembra que uma equipe pequena levaria muito tempo para construir um sistema realmente grande. A partir disso, ele defende que um projeto grande poderia ser dividido em pequenos subprojetos, cada um com uma equipe pequena e especializada no escopo daquele subprojeto. Desta maneira, não seria necessário 200 desenvolvedores que conhecessem todo o projeto, sendo mais fácil treinar pequenas equipes para cuidar de pequenas partes do projeto, aumentando a produtividade global.

Seria essa a forma correta de escalar um projeto, em contraposto à força-bruta, isto é, aumentar mais e mais o número de pessoas, todas trabalhando no sistema como um todo.

Após lançar os fundamentos, Brooks define alguns papéis necessários para montar uma super equipe, utilizando-se de uma analogia com uma equipe médica que realiza uma cirurgia. Por exemplo:

  • O cirurgião: seria o programador líder ou arquiteto, responsável pelas definições importantes do projeto.
  • O copiloto: o segundo pilar técnico da equipe, alguém responsável por revisar, pensar, discutir e avaliar, garantindo a sanidade das decisões do cirurgião.
  • O administrador: seria uma espécie de gerente para lidar com a parte burocrática e livrar os demais papéis de gastar tempo com o que não faz parte do projeto em si.
  • O instrumentador: responsável pelas ferramentas usadas no projeto.
  • O testador: o cirurgião precisa de alguém para criar os casos de teste e panejar como o sistema será testado.
  • Etc.

Segundo Brooks, equipes com uma formação deste tipo poderiam compor um grande projeto gerenciado por poucas mentes, os cirurgiões ou especialistas, mantendo assim uma integridade conceitual no sistema que não seria possível com uma grande equipe.

Considerações

A primeira lição é aprender que a maioria, se não todos, os conceitos agile já existiam muito antes deste movimento surgir. Se você é do tipo apaixonado por novidades, às vezes acha que ninguém sabia desenvolver software até o início deste século ou mais recentemente, talvez seja importante considerar um estudo da história da Engenharia de Software.

A diferença de produtividade citada pelo autor, que pode chegar a uma ordem de magnitude, é confirmada ainda hoje por qualquer pessoa que trabalha num ambiente de desenvolvimento de software. Meu orientador da pós-graduação já dizia que algumas pessoas trabalham 10 anos fazendo a mesma coisa e no total acumulam apenas um ano de experiência real. Além disso, existem inúmeros outros fatores que fazem desenvolvedores renderem mais ou menos, que vão desde a capacidade de entender lógica de programação, até pura preguiça e excesso de procrastinação.

A divisão de um grande projeto em pequenas equipes especializadas, defendida pelo autor, é exatamente o que utilizamos hoje em dia. Claro que a formação dessas equipes é algo que varia enormemente, mas o Scrum de Scrums é uma prática comum e largamente utilizada hoje. Nada mais atual do que um livro de 40 anos atrás, não é? 🙂

Somente a formatação da equipe, principalmente nos detalhes apresentados no livro, é algo que não seria mais viável hoje. Em 1975 não havia IDEs avançadas e ambientes de desenvolvimento tão produtivos quanto os de hoje. Além disso, muito trabalho burocrático em papel e tinta eram necessárias, os quais hoje são facilmente resolvidos utilizando-se editores de texto, planilhas e outros softwares especializados. Então muitos dos papéis descritos nos livros simplesmente são incompatíveis com o cenário atual da tecnologia e do desenvolvimento de software.

Porém, em minha opinião, os princípios gerais permanecem tão firmes quanto estavam quando o livro foi escrito. Por exemplo, precisamos de um líder/arquiteto para manter uma integridade conceitual no projeto. Isso vai um pouco de encontro com algumas filosofias ágeis, mas na prática o desenvolvedor mais experiente acaba assumindo este papel informalmente.

Enfim, não há uma prova cabal para determinar se os argumentos do autor apresentam a melhor solução para grandes projetos ou não. Entretanto, uma análise da evolução dos métodos utilizados para desenvolvimento de software atuais mostram que não estamos caminhando num sentido muito diferente.

Pragmaticamente, os argumentos de Brooks fazem muito sentido para a atualidade e nos dão a oportunidade de uma reflexão profunda sobre a forma como desenvolvemos software.

Concluído o terceiro capítulo, Brooks ainda não nos desapontou com argumentos que caíram pelo tempo. Não deixe de acompanhar o próximo capítulo! 😀