A criação e revisão de código são partes essenciais do ciclo de vida de desenvolvimento de software. Com muitas maneiras de revisar o código, pode ser difícil para as equipes escolher qual método implementar.
Programação em par, um tipo de criação mútua contínua, é um método em programação extrema (XP) onde equipes de dois trabalham lado a lado para criar e revisar código simultaneamente. Programadores suficientes estão apreensivos com a ideia de uma pessoa por cima do ombro que a programação em pares tem lutado, ao contrário integração contínua e outras práticas de XP.
A programação Mob leva a programação em par ainda mais longe, onde toda a equipe trabalha em um pedaço de código juntos. Embora a programação em par tenha sofrido, a programação mob feita corretamente pode beneficiar toda a equipe. Quando feito em sessões estruturadas de uma hora, com os membros da equipe participando ativamente, o mobbing pode produzir código de qualidade enquanto aprimora as habilidades e a compreensão dos membros da equipe.
O que é programação mob?
Woody Zuill, que contribuiu para a ideia e a popularizou, descreve a programação mob como “uma prática de desenvolvimento onde toda a equipe trabalha na mesma coisa, ao mesmo tempo, no mesmo espaço e no mesmo computador.” Zuill observou que essa abordagem envolve toda a equipe em todos os aspectos do desenvolvimento de software, incluindo design; codificação; teste; e trabalhar com clientes, usuários e outras partes interessadas.
Em um cenário de programação mob presencial, a equipe está em uma sala, com o código projetado em uma tela ou visível para todos. Como desenvolvimento remoto de software tem crescido em popularidade, as ferramentas de compartilhamento de tela tornam possível a programação mob remota. Todos contribuem ativamente para o trabalho.
A abordagem mais comum do mobbing tem dois papéis específicos: o motorista e o navegador. O papel do motorista é um seguidor não crítico de instruções. O navegador informa ao motorista o que digitar. O mob, uma terceira função que abrange todos os outros membros da equipe, fornece conselhos ao navegador, detecta bugs e pensa nos níveis mais alto e mais baixo sobre a construção do código. Os membros da equipe alternam as funções a cada 15 minutos ou mais, e todo o processo geralmente é agendado como uma sessão de uma hora.
A rotação evita certos problemas, como uma pessoa dominando a sessão programando enquanto todos os outros assistem. Equipes menores – por exemplo, grupos de três ou quatro – podem achar essas regras excessivamente rígidas e se adaptar de acordo.
Benefícios da programação mob
As equipes são compilações de diversos conjuntos de habilidades. A distribuição de habilidades em uma equipe de desenvolvimento nem sempre se alinha com uma hierarquia de papéis. Por exemplo, um programador júnior pode não ter experiência, mas conhecer atalhos de teclado que um colega sênior não conhece. Com capacidades variadas de uma pessoa para outra, o trabalho em equipe pode levar a um programador produzindo código limpo apenas para tê-lo arruinado por outra pessoa quando ela faz manutenção nesse código. O mesmo é verdade para testes unitários.
A programação em pares não resolve esse problema em potencial, pois os membros da equipe em pares podem ter os mesmos pontos fracos. As duplas não aprendem novas técnicas tão rápido quanto quando toda a equipe está envolvida e ainda há lacunas de habilidades. Além disso, passar de trabalhar sozinho para trabalhar com um parceiro durante a maior parte da semana é uma experiência chocante que pode levar à resistência.
Em vez disso, a programação mob permite que a equipe construa a melhor experiência na sala, sem exigir um trabalho de equipe constante durante a semana. O melhor programador SQL, por exemplo, dá conselhos sobre como construir SQL. Todos na equipe se beneficiam ao aprender novas técnicas e práticas com seus colegas. De certa forma, a programação mob é semelhante a um exercício de aprendizado, mas que resulta em código de produção de qualidade.
A programação mob também pode produzir um benefício sutil para supervisores e trabalhadores. Os supervisores que estão frustrados com o fato de os trabalhadores não estarem seguindo uma nova prática exigida podem reforçar o requisito durante a sessão de uma hora. Ao mesmo tempo, os trabalhadores frustrados com uma prática podem demonstrar ao seu supervisor de primeira linha qual é o problema com a abordagem.
Se toda a equipe se envolver durante as reuniões, a programação mob produz um software funcional de ótima qualidade e estrutura, ao mesmo tempo em que constrói conhecimento compartilhado entre a equipe. É também uma maneira produtiva de interromper as rotinas dos programadores, dividindo o dia de trabalho como uma atividade de meio período enquanto fornece código de trabalho.
Como implementar a programação mob
Qualquer equipe pode iniciar a programação mob colocando um novo recurso em desenvolvimento e trabalhando em conjunto nele.
Primeiro, escolha a história mais importante no quadro. No e-commerce, por exemplo, escolha um story que toque no checkout. Para um software de produtividade tradicional, escolha a parte do sistema com maior probabilidade de ser alterada. Ter toda a equipe trabalhando nesse recurso alivia as preocupações com o autor tirando férias ou saindo da empresa porque toda a equipe ganha conhecimento sobre o recurso.
Em seguida, agende uma única reunião de uma hora para toda a equipe – idealmente, três a nove pessoas. Uma equipe colocada deve reservar uma sala com um projetor ou outra tela compartilhada e configuração de sala de aula ou sala de conferência; uma equipe remota precisa de um software de reunião e de um fluxo de trabalho multiusuário.
Uma técnica comum para colaboração é usar controle de versão para a entrega. Ao final de um período de 15 minutos, a pessoa que é o motorista submete o trabalho ao controle de versão e passa a função de organizador da reunião para o próximo motorista. Dadas as rotações de 15 minutos e um pouco de tempo para a troca, pode fazer sentido agendar 75 minutos para cada reunião de “uma hora”.
Para ser bem-sucedido, o processo geralmente requer pelo menos um campeão dentro da empresa: alguém com comunicação em equipe e habilidades de observação para perceber exatamente quem está – e quem não está – participando plenamente. Isso é especialmente verdadeiro para mobs remotos.
A programação do Mob pode se tornar um evento diário nas condições certas. Embora as reuniões diárias possam ser desafiadoras, a maioria das pessoas consegue lidar com uma hora de um novo fluxo de trabalho. Esse arranjo exige muito menos das pessoas do que a programação contínua em pares, que pode ocorrer durante a maior parte do dia de trabalho. A equipe pode trabalhar junta como um mob por uma hora e depois voltar para suas outras tarefas. Diante da resistência, explique que é apenas uma hora de cada vez.
Inclua todos na equipe que podem escrever código. Designers gráficos, escritores técnicos e Scrum Masters podem não ter interesse. A questão principal é se a equipe está disposta a desacelerar e explicar. Caso contrário, esses grupos podem achar melhor gastar seu tempo em outro lugar. Mas forçar a equipe a explicar seus processos de pensamento revela lacunas e cria ideias melhores. É melhor desacelerar e explicar do que deixar algumas pessoas para trás.
Fazendo o mobbing funcionar
Como o mobbing é apenas programação, ele se encaixa no fluxo de trabalho do desenvolvimento de software. Os programadores escrevem o código e o enviam para o controle de versão. Dito isso, as equipes provavelmente terão mais trabalho a fazer ao final de uma sessão de 75 minutos. O recurso no qual a equipe está trabalhando pode não estar completo. Eles poderiam colocá-lo em um galho e pegá-lo amanhã ou entregá-lo a um programador para terminar hoje. Pode ser melhor para o último navegador assumir a história e terminá-la.
Para adotar a programação mob, o que é mais necessário é uma vontade genuína de experimentá-la, além da disciplina dos membros da equipe para participar ativamente quando não estiverem nas funções de motorista ou navegador. Isso provavelmente é mais adequado para equipes verdadeiramente colaborativas, onde as linhas de responsabilidade são intencionalmente confusas e as contribuições individuais são bem-vindas. Isso significa que os membros da equipe não são excessivamente possessivos com partes específicas da base de código.
Então, novamente, as equipes que possuem forte propriedade de código podem se beneficiar muito do mobbing, já que todos os recursos definidos pelo mob têm propriedade conjunta. O requisito básico é a vontade de aprender e experimentar coisas novas.
A programação Mob não é a resposta para todos os projetos. Quando ágil equipes incorporam programação mob, eles renunciam a outras técnicas de programação. Se a equipe não oferecer suporte total a esse novo método, haverá uma grande probabilidade de uma diminuição na quantidade total de código escrito. A equipe também tem mais chances de perder o interesse no projeto se não estiver totalmente a par da programação mob.
É um processo intenso que exige que todos estejam na mesma página, mas quando implementada corretamente, a programação mob pode servir como uma prática benéfica para um projeto Agile.