DevCafé: Time ágil x Time de futebol

Uma analogia com a paixão do brasileiro afim de explicar cada papel em um time ágil e como isso pode fazer toda a diferença no resultados

Photo by Sandro Schuh on Unsplash

Você pode não ser fã de futebol, não ter um time ou seleção pela qual torça e acompanhe os jogos, não saber quem é Messi, Neymar ou Cristiano Ronaldo, até mesmo nunca ter assistido uma partida, mas com certeza, ao escutar a palavra FUTEBOL, o seu cérebro materializa algo, mesmo que não seja de forma precisa e aprofundada, mas com certeza a essência do que significa a palavra você terá. Por isso, escolhi o futebol para nos auxiliar a entender como funciona (ou deveria funcionar) um time ágil.

Alguns acordos de nomes para ficarmos todo na mesma página:

• PO: Product Owner, Product Manager
• TL: Techlead, Tech Manager, Scrum Master (eu sei que são papéis diferentes, mas abstraia, prometo que vai fazer sentido)
• DEV: Time de desenvolvimento
• PBI: Product Backlog Item, Estória de Usuário

Anatomia de uma equipe

Exemplo de formação de um time de futebol

Quanto mais conseguirmos fazer com que a bola chegue redonda no ataque, maior será a quantidade de gols no final da partida

Um time de futebol de campo possui 10 jogadores de linha mais o goleiro. Na imagem acima, mostramos um esquema tático de como esses 11 jogadores se comportam em campo. Durante o jogo, cada um tem uma área específica do campo que ele deve ocupar e executar seus papéis.

Em um time ágil, conseguimos fazer um paralelo a isso, onde podemos seguir a seguinte "escalação":

• DEFESA: TL
• CRIAÇÃO: PO
• ATAQUE: DEV

Mais a frente, vou explicar melhor porque "escalei o time" dessa forma.

Regras

Segundo pesquisa rápida na wikipedia, as regras do futebol existem desde o ano 1863. Apenas para contextualizar quem não conhece o esporte mais a fundo, seguem algumas regras mais comuns:

• Uma partida possui 2 tempos de 45min.
• Com a bola em jogo, apenas o goleiro pode colocar as mãos na bola, e mesmo assim dentro da sua área
• Cada time inicia o jogo com 11 jogadores
• As faltas cometidas são passíveis de penalização com cartões amarelo e vermelho, respectivamente. Quando um jogador recebe um cartão vermelho ele se retira de campo

Galvão: Pode isso Arnaldo? Começar a sprint sem os critérios do DOR fechados?
Arnaldo: Não Galvão, errou o árbitro! Nesse caso o certo seria pegar o próximo item da priorização com o DOR ok.
Galvão: É Arnaldo, e pior que o VAR nem pode interferir nesse caso…

No dia a dia de um time ágil não temos uma cartilha de regras pré estabelecidas e que devemos seguir sob possibilidade de penalização. As regras na verdade são pré estabelecidas pelo time, porém, no geral são referentes aos seguintes pontos:

• Tamanho do ciclo de desenvolvimento (sprint): existem times que atuam com intervalos de duas semanas, já outros preferem três semanas.
• DOR (definition of ready): um combinado de itens cujo time entende que é o mínimo de informações necessárias para dar início ao seu trabalho. Geralmente mais usado pelo time de desenvolvimento, mas pode ser aplicado a todos os times.
• DOD (definition of done): outro combinado, mas dessa vez para que fique claro os requisitos mínimos para considerar uma entrega concluída.
• Agendas de cerimônias: o time possui uma recorrência de reuniões diárias de alinhamento (daily), além de uma reunião de review para apresentar as entregas e outra de retrospectiva, onde são discutidas os problemas encontrados no ciclo e exaltadas as conquistas alcançadas.

Papéis e responsabilidades

Em um time de futebol de campo, os papéis e responsabilidade são muito claros:

• Goleiro + Defesa: defender o gol para evitar que o adversário conclua suas jogadas com sucesso
• Meio Campo (criação): conectar a defesa com o ataque e atuar na criação das jogadas
• Ataque: finalizar e marcar gols

Mais um ponto onde não existe uma cartilha para ser seguida a risca no ágil. Vale muito o combinado que o time está seguindo.

Porém, vou compartilhar com vocês uma visão extremamente pessoal, e que não precisa ser seguida a risca, mas segue um racional e que já vi funcionando.

• TL: atua na defesa, servindo de suporte para o time o blindando de interferências, dando direcionamentos e resolvendo problemas que envolvem outros times
• PO: com auxílio técnico da defesa, o PM/PO atua no setor de criação do time. É ele quem pensa no funcional e dita como será o produto que será entregue na mão do cliente.
• Design: atua na criação juntamente com o time de produtos. O time de design é que materializa visualmente as ideias de produto do time de negócios, e é responsável por fazer o primeiro filtro de possíveis ideias que não podem ser executadas.
• DEV: compõe o ataque, seu trabalho é colocar em prática as ideias de negócio, materializadas por design.

Exposta minha visão de papéis e responsabilidades, bolei uma pesquisa sobre um ponto que geralmente acaba criando um pouco de polêmica, que seria o material entregue para a equipe de desenvolvimento. Veja na imagem a seguir:

Resultado de enquete do linkedin

Aqui vale ressaltar que a ideia não era dizer o que é o certo e o que é o errado, mas sim mostrar que existem pessoas que preferem sim algo muito mais direto, do que ter um material mega extenso para a leitura. Como sabemos, o brasileiro não é muito conhecido por ler as bulas dos remédios que consome… rs

Galvão: Que golaaaaaaaaaaaaaaaço!!!
Caio Ribeiro: Também Galvão, com um passe desses até o Casa Grande marcava!

Já trabalhei com os 3 tipos de abordagem, e em todas elas vi ganhos e prejuízos. No geral, assim como a maioria da pesquisa, prefiro uma abordagem onde se entregue ao time de desenvolvimento um material mais elaborado, mas também defendo que isso não se torne mera burocracia que ninguém usa, precisa ser algo tão completo quanto é direto.

Aproveito para deixar minha opinião sobre cada abordagem de PBI:

• Apenas um título de marcação: em times mais maduros, que trabalham a muito tempo juntos e já possuem maior entrosamento um PBI de marcação ou com apenas um texto bem sucinto é mais que o suficiente. O time tem tanta iteração que, muitas vezes, demandar muito tempo passando coisas para o PBI seria praticamente o tempo de desenvolvimento. Nesse caso, um PBI mega elaborado se torna uma burocracia.
• Um título com breve descrição: também acho que o time precisa estar maduro e muito conectado nesta abordagem. Sem isto, você se verá muitas vezes explicando para o PO como determinada funcionalidade se comporta. Eu defendo muito que um código bem escrito é um documento, mas defendo também que o PO deve ser auto-suficiente para dizer como cada parte da aplicação funciona
• Quanto mais informações melhor: a abordagem mais "safe", pois entrega tudo o que desenvolvedor precisa para atuar, mas vale o alerta de estar sempre validando se as informações não estão sendo passadas em demasia. Um exercício legal é sempre repassar os PBIs na retrospectiva, vendo o que foi útil, e o que não foi utilizado.

Objetivos

Numa partida de futebol o objetivo é muito claro: marcar mais gols do que o adversário. Ao entrar em campo eles sabem que, se no soar do apito final o placar estiver a seu favor, o objetivo foi alcançado.

Porém, existem momentos que outros resultados também são satisfatórios para a equipe, e nesses casos a vitória é muito bem vinda, mas não era necessária. Exemplo: último jogo da rodada, o time precisa de 1 ponto para subir uma posição na tabela e com isso se classificar para outro campeonato.

Caio Ribeiro: Galvão, o time jogou muito mal, mas esse empate foi mais que suficiente para garantir a classificação.

No dia a dia do time ágil temos um cenário muito parecido… O time de desenvolvimento possui um ritmo de entregas, e com isso sabemos a quantidade de itens que conseguimos priorizar na sprint. Porém, por vezes, nem sempre todos os itens estão relacionados aos mesmos entregáveis, e não entrega de um item menos prioritário, não necessariamente significa um insucesso.

Mudança de planos

Para facilitar a analogia ainda não havíamos falado sobre o técnico do time, porém aqui ele entra em cena. Durante os 90 minutos de jogo, muitos imprevistos podem acontecer:

• jogador se machucar
• expulsão
• time armado defensivamente perdendo de 3 gols de diferença
• entre outras tantas…

Em qualquer um destes cenários, se faz necessário algum tipo de mudança, seja substituindo um jogador por outro que estava na reserva, ou até mesmo chamando algum jogador em campo e pedindo para o time mudar de estratégia.

Galvão: Ô Caiô, você não acha que está na hora do Tite mudar não?
Caio Ribeiro: Acho sim Galvão, tá na hora de colocar mais velocidade no ataque, o Gabriel não ta jogando nada hoje!

Em uma sprint, imprevistos também podem acontecer, e o time precisa estar preparado para aceitar isso. Existem momentos que uma entrega deixa de fazer sentido devido a uma mudança brusca de mercado e, com isso, não faz mais sentido demandar esforço em seu desenvolvimento.

Aqui vale a análise de caso a caso, já passei por momentos que a cada daily estávamos falando de itens que não tinham conexão com a daily passada… Isto não é uma mudança de planos, caracteriza mais uma falta deles.

Acho que é isso galera! Espero que gostem do conteúdo e que de alguma forma possa ajudar vocês a se organizarem e marcar mais gols do que sofrer.

Lembrem: pintou dúvida? Discorda de algo? Falei alguma bobabem? Comenta aí! ;-)