domingo, 5 de janeiro de 2014

Equipes Dispersas de Desenvolvimento de Software

Especialização X Multidisciplinaridade

Sou partidário da especialização, mas sem radicalismos... é importante que o profissional desenvolvedor de software especialista em algum assunto, tenha também uma visão cuja amplitude lhe permita executar o seu trabalho sem dependência extrema dos colegas. Por exemplo, é essencial que o programador saiba testar... e para testar ele precisa conhecer um mínimo do ambiente operacional onde o programa vai ser executado.
Por outro lado... não me agrada a ideia de equipes multidisciplinares onde todo mundo faz tudo, ou faz de tudo. Menos ainda me agrada a ideia de um único desenvolvedor executar toda a linha de desenvolvimento de um caso de uso.

Salvo exceções muito específicas, duvido que a qualidade sobreviva a um único desenvolvedor levantando requisitos, documentando/especificando, programando scripts, serviços e telas e testando. Duvido também que ele documente adequadamente o que deve ser feito e o que foi feito para quando outro desenvolvedor for substitui-lo. Estou ciente que essa visão vai contra a proposta corrente dos métodos ditos 'ágeis', mas acho que é isso mesmo: para funcionar esse métodos dependem de programadores 'estrelas' e as equipes são sempre de custo alto e dependentes da capacidades de um ou outro.

O conceito comum de fábrica de software peca pelo alto custo de implementação e excesso de burocracia. Fábricas de software que não tenham um nível altíssimo de documentação (leia-se custo e burocracia) e recurso dedicado (leia-se custo), simplesmente não funcionam, ou funcionam transferindo o custo para algum cliente (geralmente governo) que esteja disposto a pagar sem questionar os excessos.

A alternativa é o modelo onde existe método e documentação plena e suficiente para o desenvolvimento (e manutenção !), sem excessos, onde a ausência de um desenvolvedor não implique que o substituto tenha que ler fontes de programa só para entender o que o caso de uso faz e quais as regras envolvidas. Óbvio não é ? é... mas como definir o que é documentação plena e suficiente sem excessos ?

A Documentação Avaliada Como Insumo

Se por um lado considero que é essencial documentar tecnicamente o sistema, por outro lado desprezo qualquer documentação que não seja insumo de alguma atividade. Esse negócio de documentar só porque é regra da empresa não funciona.

O que não faltam são templates de documentos para que se tenha uma boa referência de como documentar um sistema. Uma boa medida para saber se a documentação está em nível suficiente é avaliar se ela está cumprindo bem seu papel como insumo. O processo que delimita as atividades de cada desenvolvedor e define bem os artefatos e insumos de cada tarefa está criando, por consequência, uma boa medida de avaliação da documentação, pois basta verificar o nível de entendimento do desenvolvedor seguinte no fluxo do processo para avaliar se a documentação (insumo) que ele recebeu estava suficiente. Por exemplo: o programador entendeu bem as especificações do analista ou teve muitas dúvidas em relação ao que devia ser feito ? se o programador entendeu bem, esse é um bom indicativo de que a documentação recebida pelo programador está suficiente. Claro que existem ruídos e o coordenador da equipe deve avaliar quando o problema é na documentação e quando é no programador.

Equipes Dispersas

Tenho trabalhado com equipes dispersas há muito tempo de forma ocasional. De um ano e meio para cá tenho trabalhado de forma sistemática com 4 desenvolvedores distantes (em uma equipe 8), sendo estes com foco em programação e automatização de teste enquanto os internos tem foco em disciplinas relacionadas ao conhecimento do negócio e qualidade em geral (análise, modelagem, planos de teste, etc.). Tive a possibilidade de confirmar e evoluir várias ideias a respeito de um processo de desenvolvimento pragmático baseado na especialização de atividades, foco na documentação como insumo e delimitação de comunicação.

De forma geral cheguei à conclusão de que a correta adequação desses dois "problemas" (manutenção de documentação + equipe dispersa) pode se tornar uma vantagem competitiva na medida em que a equipe esteja devidamente alocada em suas áreas de competência (especializada).


Nenhum comentário: