Nas últimas semanas tenho participado de várias discussões internas e em listas de discussão sobre composição de times de desenvolvimento. Este é um assunto especialmente interessante, pois a qualidade ou o custo do software que construímos é ultimamente o resultado da qualidade e do custo do time que o construiu.

A característica de rapidez da evolução da plataforma tecnológica de desenvolvimento faz com que se manter atualizado exija uma super especialização. Isto é muito difícil de ser feito e as pessoas com mais experiência e que conseguem se manter atualizadas acabam sendo conhecidas como “arquitetos” (categoria na qual eu me incluo). Elas dominam as múltiplas áreas de conhecimento de desenvolvimento e conseguem definir e ensinar como aplicar padrões e tecnologias de maneira adequada. No entanto, na minha visão, um dos maiores riscos deste grupo é que adotemos a busca da atualização tecnológica como o nosso principal e único objetivo e esqueçamos que na verdade o nosso objetivo é fazer software bom a um custo viável. Afinal, usualmente, o cliente não está interessado se o sistema dele é .NET, Java, usa DDD ou não, é feito via TDD ou não; o que ele quer é algo que ele perceba valor (ou seja, bom!) e que ele pague um custo que ele ache justo pra construir e manter o sistema.

Acho que no fundo, todos nós sabemos disto, já que provavelmente iniciamos nossa carreira fazendo algum sistema para alguém. Ocorre que quando as empresas vão crescendo, surge uma dificuldade de escala, já que temos que fazer um volume cada vez maior de horas de desenvolvimento. E, ao contratar mais pessoas, começam a existir os problemas usuais do desenvolvimento em equipe: aumento de custo e queda de qualidade. Várias alternativas têm sido propostas para lidar com isto, ligadas à própria origem da “Engenharia de Software” como disciplina, há décadas atrás. É muito interessante reler o livro “The Mythical Man-Month”, do Brooks. Os problemas que ele descreve na década de 60 sobre desenvolvimento baseado em Mainframe (!!) são praticamente os mesmos de hoje!

A abordagem mais em voga atualmente para lidar com o problema de escala é montar uma equipe hierárquica, normalmente sob coordenação de um gerente de projeto (nas maiores empresas, um PMP) e composta por pelo menos um arquiteto e um conjunto de desenvolvedores com mais e menos experiência (seniores e juniores). E usar um processo definido para garantir que os mínimos padrões de qualidade sejam atingidos e o custo controlado. Neste modelo, tenta-se diminuir o custo usando-se mais juniores e tentando evoluí-los com treinamento durante o desenvolvimento. Eu mesmo fui adepto deste modelo por muito tempo, mas confesso que, após muitos anos de tentativas, estou muito desapontado com os resultados. A cada vez os custos de produção aumentam, a qualidade continua ligada a somente a quem está construindo (e não ao processo) e manter um grau de satisfação na equipe é complicado. A tal ponto de que passei a não mais acreditar neste modelo e partir para a adoção de uma metodologia ágil.

Em desenvolvimento ágil as equipes são sempre pequenas e não há uma hierarquia rígida (há um líder técnico somente). O ciclo de entregas é curto e a preocupação com valor sendo entregue é o mais importante. Embora isto resolva vários problemas do desenvolvimento em equipe, ele tem um problema crítico de escala também, já que para grandes projetos seriam necessárias várias equipes e a orquestração disto não é trivial.

Neste cenário, estamos tentando ver como compor estas equipes ágeis. Tivemos várias experiências mal sucedidas com desenvolvedores menos experientes. O desenvolvimento ágil pressupõe muita autonomia e é difícil garantir qualidade e custo com juniores, já que o processo é bem leve e não há a preocupação com o treinamento em si. Alguns propõem o pair-programming como solução, porém algumas tentativas que fizemos nesta linha não foram também bem sucedidas. Isto tem nos feito buscar equipes somente com desenvolvedores super experientes. Ainda que sejam mais caros, os resultados têm sido melhores com um custo geral mais baixo. O desafio tem sido encontrar pessoas experientes que estejam dispostas a trabalhar em todos os aspectos da aplicação – que incluem CRUDs, relatórios etc. – e não somente na parte “legal” de infra ou interfaces avançadas.

Desta forma, perde-se um pouco o sentido de se ter pessoas só com o papel de arquiteto na equipe. Na verdade, cada um deve estar preocupado todo o tempo com as soluções dadas e participar de novas decisões, contribuindo com o resultado final do projeto. Acredito que este seja um modelo mais interessante, pois a ausência de um arquiteto formal faz com que os desenvolvedores se sintam mais livres para contribuir e assumam melhor esta responsabilidade. Claro que isto só é possível se cada desenvolver for capaz de contribuir desta forma e para isto, cada um deve de fato ser também um arquiteto!

Com isto, voltamos mais à maneira de como começamos, quando desenvolvíamos sozinhos. Se o sucesso que tínhamos lá puder ser refletido também nesta forma de trabalho em equipe, vamos estar no caminho certo!