Cada vez mais o desenvolvimento de software está a ser feito através de equipas distribuídas, por elementos geograficamente dispersos que raramente se encontram no mundo real. Penso que este caminho é inevitável – por um lado as pessoas querem melhorar a sua qualidade de vida, não perdendo tanto tempo em transportes ou files, não gastando tanto dinheiro na habitação tradicionalmente cara das grandes cidades, não sofrendo tanto com a poluição e o stress. Por outro lado, se as empresas portuguesas querem desenvolver soluções globais, as suas equipas devem ser igualmente globais, incorporando elementos de diferentes países, culturas e formação. Por último, a inovação passa claramente por não nos limitarmos ao brainpower disponível numa certa area geográfica.
Em contrapartida, vários estudos indicam que a proximidade dos elementos da equipa é um factor fundamental no desenvolvimento de software. Por exemplo, neste artigo (pdf) pode-se ler: “the gains from being at hand drop off significantly when people are first out of sight, and then most severely when they are more than 30 meters apart”. As metodologias ágeis insistem no contacto constante com a equipa e o cliente. Por um lado a comunicação explícita é muito mais fácil quando estamos a trabalhar todos na mesma sala, mas existe um outro tipo de comunicação tão ou mais importante que a comunicação explícita – a observação. Podemos aprender muito só por estar no sítio onde as coisas acontecem, ouvindo pedaços de conversas aqui, exclamações ou outras manifestações emocionais acolá. Chama-se a isto o contexto do grupo: saber quem realmente são os seus elementos, quais as suas características, como devemos falar com eles, aquilo em que são bons e aquilo em que não são bons, etc. Como trazer este contexto para equipas distribuídas?
Uma equipa da universidade de Saskatchewan fez em 2005 um estudo (pdf) que tentava responder ao seguinte: como é que se consegue manter o contexto do grupo em projectos open-source de alguma dimensão? Em particular, como é que o NetBSD, o Apache httpd e o Subversion, projectos de reconhecido sucesso, fazem para evitar, por exemplo, duplicação de esforço?
Após entrevistarem diversos programadores destes projectos, chegaram a uma supreendente conclusão. A solução parece residir em duas ferramentas nada sofisticadas: mailing lists e text chat (IRC). De facto, apesar destes projectos terem em média mais de 20 programadores activos e haver pouco particionamento do código (os commit logs mostraram que a maioria dos ficheiros foram sendo editados por múltiplos programadores), os entrevistados referiram serem raras as colisões e a duplicação de esforços.
De facto, as mailings lists e o text chat funcionam não só para comunicação explícita, mas também para comunicação por observação. Basta acompanhar a mailing list de um destes projectos durante alguns dias para ficarmos a saber quem pertence à equipa, quem trabalha no quê e quem irá trabalhar no quê assim como aferir um pouco a personalidade dos seus intervenientes. Obviamente, isto só funciona porque todos têm o cuidado de partilhar as suas intenções e o seu estado actual através destas ferramentas. Apesar da perda de eficiência que advém do facto de registarmos por escrito tudo o que fazemos (perde-se tempo a escrever um mail para cada coisa que fazemos ou planeamos fazer), toda a gente o faz, nestes projectos. Porquê?
Bem, provavelmente tem a ver com a motivação que está por trás de quem trabalha em projectos open-source: a reputação social. Uma das formas de construir essa reputação é precisamente participando activamente nas discussões do projecto, escrevendo mails com boas ideias, bem escritos e tecnicamente bem apoiados que mereçam elogios da comunidade. O desejo de criar esta reputação também explica a escalabilidade deste sistema tão simples. Muita gente coloca questões na mailing list na esperança que alguém responda, nomeadamente algum expert nessa área. Ora esse expert pode não estar disponível, ou pode não ter tempo para responder a essas solicitações. É comum alguém menos expert (ou pelo menos reconhecido como menos expert) aproveitar para mostrar as suas qualidades e responder à questão. Como a resposta também vai para a mailing list em geral, será devidamente avaliada por outros experts que eventualmente a corrigirão (embora não seja normalmente necessário). Se compararmos este mecanismo tão simples com o formalismo dos “module maintainers” (pessoas que assumem a responsabilidade de certos módulos), percebemos que este último não é escalável – muitas questões não serão respondidas em tempo útil já para não falar da duplicação de perguntas.
Aquilo que mais me interessou no estudo foi tentar perceber até que ponto este sistema de partilha de contexto funcionaria num projecto comercial, no âmbito de uma empresa. Há duas pistas no artigo que me levam a pensar que não funcionará:
- Alguns entrevistados referiram que em situações de grande pressão temporal (por exemplo a correcção de uma vulnerabilidade de segurança) surgiam por vezes problemas de coordenação, havendo duplicação de esforços. Os projectos closed source comerciais estão tipicamente mais sujeitos a pressões de tempo e deadlines apertadas que os projectos open-source, pelo que a perda de eficiência associada à actualização explícita constante do nosso estado poderia não ser compatível com os prazos do projecto.
- A motivação para adquirir reputação social por esta forma quase não existe nas empresas. Infelizmente, essa reputação está muito mais associada a cargos e hierarquias (e em alguns casos, antiguidade). Ninguém é promovido por discutir activamente numa mailing list mas sim por apresentar resultados – nesse sentido, as pessoas concentram-se em desenvolver o máximo de código e não a falar sobre ele. As colisões são raras porque o código é altamente particionado. Ao contrário dos projectos open source, é comum encontrarem-se ficheiros que são mexidos apenas por quem os criou. É claro que isso levanta outros problemas relacionados com a manutenção dos mesmos que fogem um pouco ao tema.
Acima de tudo, actualmente nada bate a eficiência de comunicação directa de uma equipa que trabalha no mesmo local. Mas será este modelo sustentável? Como referi na introdução deste artigo, a dispersão das equipas parece-me uma tendência inevitável. Claramente o desafio será encontrar mecanismos eficientes de partilha de contexto que as pessoas realmente utilizem e os projectos open source serão uma referência incontornável neste caminho, pois são indubitavelmente o expoente máximo da colaboração em equipas distribuídas.