O swarming é uma técnica pela qual os integrantes de uma equipe aproveitam suas diferentes habilidades trabalhando juntos ao mesmo tempo para entregar uma história de usuário. É reconhecida como uma abordagem poderosa para a entrega de histórias com rapidez e alta qualidade. Neste artigo, conheça técnicas para atingir os mesmos resultados para equipes geograficamente distribuídas.
Não é difícil fazer swarming em torno de uma funcionalidade com uma equipe no mesmo local (swarm = "enxame"); mas como fazer quando se é parte de uma equipe ágil geograficamente distribuída? Deve-se levar em conta, na avaliação da melhor abordagem para fazer o swarming, a distribuição geográfica da equipe e a variação dos fusos horários de seus integrantes.
Distribuição da equipe e direcionamento
Um problema é que muitas equipes distribuídas são separadas por função, com os desenvolvedores em uma localidade, os analistas de testes em outra e o product owner ou o cliente em um terceiro lugar. Em geral, quaisquer funções diferentes estão em localidades distintas.
É mais fácil ilustrar esse problema com um caso real. Conheci um gerente de programas que trabalhava na Alemanha e estava preocupado com um dos projetos, pois nele trabalhavam dois desenvolvedores localizados no Reino Unido, um na França, dois na Alemanha e dois analistas de testes na Índia. O product owner estava na Alemanha e ainda gerenciava o backlog do produto para duas outras equipes.
Há muitos problemas neste caso, e infelizmente situações como essa são comuns para equipes distribuídas geograficamente. Em geral estas equipes não fazem o swarming para atacar suas funcionalidades e, portanto, levam mais tempo para entregar cada uma delas; e o product owner acredita ter tempo para trabalhar em várias tarefas e atender a várias equipes ao mesmo tempo.
A primeira sugestão para o caso acima foi a de limitar o trabalho em progresso (WIP) dos desenvolvedores e pedir que trabalhassem todos em uma única história. Até então, cada um deles iniciava uma história diferente; agora tinham que trabalhar juntos e passarem a discutir como fazer isso em cima de uma única história.
Começando com uma dupla
A equipe não começou toda ao mesmo tempo. Primeiro foram os dois desenvolvedores localizados no Reino Unido, pois estavam no mesmo fuso horário. No entanto, não estavam no mesmo local; portanto tinham problemas de equipes distribuídas geograficamente. Tentaram uma combinação de Google Docs, compartilhamento de telas, pareamento e trabalho conjunto sobre a arquitetura. Tiveram que usar várias histórias para praticar e perceberam que as histórias estavam grandes demais. Ao tornar as histórias menores, ficou mais fácil realizar o swarming.
Adicionando um desenvolvedor
Depois de terem praticado com algumas histórias, os desenvolvedores no Reino Unido estavam prontos para trazer mais um desenvolvedor para o experimento, já na próxima história. Incluíram um dos desenvolvedores da Alemanha e agora precisavam lidar com uma hora de diferença no fuso, além da diferença em horários de entrada e saída do trabalho e nos horários de almoço. O grupo trabalhou, entregou a história e decidiu que já era hora de adicionar um analista de testes.
Adicionando um analista de testes
Com profissionais em Manchester e Londres na Inglaterra, Munique na Alemanha e Bangalore na Índia, a equipe inteira estava distribuída por quatro horas e meia de fuso horário e tinha no máximo cinco horas para trabalhar juntos durante o dia; isso considerando que o analista de testes ficasse até mais tarde e os desenvolvedores adiassem o almoço. Não era sustentável.
A equipe então decidiu separar o tempo de todos em timeboxes (períodos fixos de tempo) em vez de tentar trabalhar juntamente durante todas as cinco horas.
Trabalhando em timeboxes
Sabemos as vantagens de se trabalhar em timeboxes, uma das principais práticas do Agile, mas o fato é que não há necessidade de durarem uma ou duas semanas. Pode-se trabalhar em timeboxes menores. A equipe decidiu fazer uso do poder dos timeboxes para focar seus esforços no swarming e aproveitar ao máximo o trabalho conjunto.
Pelos primeiros noventa minutos do trabalho conjunto, faziam o swarming. Os desenvolvedores e analistas de testes trabalhavam juntos, compartilhavam suas telas, pareavam à distância, funcionando quase como uma equipe no mesmo local. Fora do horário do timebox, o swarming ainda poderia acontecer, mas dependeria do que cada um estivesse fazendo.
A equipe precisa resolver todas as questões que dificultem a realização do swarming; por isso foram tentadas várias abordagens.
Testes manuais eram o gargalo
Logo que começaram a fazer o swarming com o analista de testes, este só conseguia realizar testes manuais. Isto significava que a equipe contraía dívidas técnicas a cada iteração, e que o analista de testes acabava não entendendo completamente tudo o que estava em andamento. Quando o analista de testes começou a trabalhar com os desenvolvedores, passou a entender o que cada funcionalidade deveria realmente fazer; mesmo assim não conseguia desenvolver testes automatizados.
Continuando o swarming, os desenvolvedores construíram "ganchos" (hooks) no código, permitindo que o analista de testes automatizasse alguns dos testes. Não era a solução perfeita ainda, mas era melhor que nada. Com um pouco mais de ajuda, o analista de testes perdeu seu medo em relação à automação e começou a contribuir de forma mais produtiva.
Usando um quadro Kanban para visualizar o progresso
Como a equipe tinha integrantes em diversos fusos horários e os horários de trabalho quase não coincidiam, a equipe usava um quadro kanban para visualizar o progresso nas histórias. Com base nas informações do quadro, um integrante da equipe podia decidir chegar mais cedo ou ficar até mais tarde no dia seguinte.
Em equipes distribuídas geograficamente, é comum que alguns integrantes flexibilizem seus horários uma ou duas horas, se isso ajudar a equipe. O Kanban pode ser útil para a equipe ver se isso vale ou não a pena. A equipe logo percebeu que ao fazer mais swarming precisava realmente flexibilizar mais seus horários.
"Precisamos de mais histórias!"
Um dos efeitos do swarming foi o da equipe concluir seu trabalho mais rapidamente. Por haver menos trabalho em progresso, os integrantes da equipe terminavam mais histórias em menos tempo e agora haviam colocado pressão sobre o product owner para gerar histórias bem escritas e menores, de forma que pudessem trabalhar em equipe.
O product owner foi surpreendido; não estava pronto para a demanda de mais trabalho pela equipe.
No começo, o PO tentou gerenciar a demanda de todas as histórias ele mesmo. Mas logo percebeu que estava fazendo atividades demais ao mesmo tempo, divindo-se entre vários projetos; pediu ajuda e delegou o trabalho das outras duas equipes para outro product owner, passando com isso a se concentrar somente na equipe distribuída.
Existem outras alternativas
Existem outras alternativas para o swarming, além das escolhidas por essa equipe. Pode-se escolher outro caminho. Recapitulando, a equipe escolheu:
- Começar com quem estava mais próximo;
- Adicionar a próxima pessoa;
- Utilizar timeboxes para acomodar os desafios do fuso horário.
Uma alternativa diferente poderia ter sido:
- Começar com alguém em cada camada arquitetural e um analista de testes;
- Utilizar timeboxes para acomodar os desafios do fuso horário.
Ainda outra alternativa poderia ser:
- Utilizar um quadro kanban para visualizar o trabalho;
- Não tentar fazer swarming em tempo real, mas manter-se disponível caso alguém tenha dúvidas.
(Não me agrada esta terceira alternativa, porque acaba estimulando o trabalho em muitas coisas ao mesmo tempo.)
Quando o excesso de distribuição inviabiliza o swarming
Às vezes, a distribuição geográfica é tamanha que se torna inviável fazer o swarming de uma equipe multidisciplinar. Vejo isto acontecer nos projetos de um colega, que tem desenvolvedores em áreas que vão do Leste a Oeste dos EUA, além de uma equipe de testes em Pune, na Índia. Devido à diferença nos fusos horários, não há disponibilidade de tempo para fazerem sequer uma reunião, menos ainda trabalhar juntos por longos períodos.
Nesse projeto, os desenvolvedores faziam o swarming no seu próprio horário, completando os testes unitários e de integração e passando o código desenvolvido para a equipe de testes na Índia. Usavam também um quadro kanban para rastrear o progresso das histórias e dos impedimentos. Assim, quando a equipe de testes na Índia encontrava problemas, adicionava cartões no quadro kanban para que os desenvolvedores pudessem ver e responder.
Visualização ajuda
É difícil realizar o swarming quando não há sincronia nem de tempo nem de lugar. São úteis ferramentas que permitam visualizar as áreas de trabalho um do outro; mas o que realmente ajuda é visualizar o trabalho em andamento (WIP).
O swarming contribui para reduzir o WIP, o que auxilia a equipe a completar suas tarefas de forma mais rápida e melhor. Isso permite enxergar mais facilmente a direção para onde se está indo, além de favorecer a construção do relacionamento entre os integrantes da equipe.
Nem sempre é possível fazer o swarming, mas se tiver oportunidade, experimente e veja o que acontece!