No entanto, um ritual funcionou muito bem nas equipes das quais fiz parte. Eu quero falar sobre o dev huddle.
O que é um dev huddle?
Há muitos nomes para isso: Dev Huddle, Tech Huddle, Dev Meeting. Seja como for, é uma reunião recorrente para os desenvolvedores de uma equipe.
Então, o que isso faz? Bem, é um fórum para discutir tópicos técnicos e tomar decisões sobre arquitetura, convenções ou qualquer outro aspecto da pilha de tecnologia.
“Nossa, isso é tão inovador! “, você pode pensar. Sim, não é nada inovador. O diabo está nos detalhes.
Executar um huddle de desenvolvimento eficaz pode ser complicado. Nada frustrará mais um grupo de desenvolvedores do que ter mais uma reunião inútil. Se você está ocupando o tempo deles, é melhor fazer valer a pena.
Por que devo fazer isso?
Antes de focar no como, vamos dar uma olhada no porque primeiro. O que esperamos realizar?
Criar Alinhamento
Os desenvolvedores podem trabalhar juntos (às vezes também literalmente), mas constrói software como se nunca tivesse se conhecido antes. Eles concordam com as convenções de codificação? Qual é a biblioteca preferida para analisar JSON?
Existem toneladas de pequenas decisões a serem tomadas. Com o tempo, eles formam um entendimento coeso da construção de software que é crucial para qualquer equipe de alto desempenho.
Promover a inovação
Você não reescreverá seu aplicativo a cada seis meses com a tecnologia mais moderna, mas deseja incentivar os experimentos. Melhorias contínuas composto ao longo do tempo.
Já fiz parte de times que pareciam desesperados no começo. Após um ano de muitas pequenas melhorias, estamos fazendo implantação contínua. No entanto, isso raramente acontecerá em um grande empurrão.
Incentive o debate
Algumas equipes praticam o que eu chamo discussão por posse, onde as pessoas mais seniores da equipe tomam as decisões de tecnologia e o resto, bem, as segue. Se eles tiverem a sorte de descobrir essas decisões, claro.
Seu pessoal sênior tem experiência e instinto, mas todos os outros podem contribuir também.
Preparação
Gosto de estruturar grupos em torno de um acúmulo de ideias.
Algo tão simples como um post-it na parede ou uma lista de problemas no trabalho do Github. Cada um pode ser apenas um título simples – eles estão lá para iniciar uma conversa.
Alguns exemplos:
- Vamos experimentar atacar, uma nova biblioteca de asserções
- Refatore nossas chamadas de API para usar Ganchos de reação
- Documentação ausente para nosso microsserviço mais recente
Quem adiciona novos tópicos? Todo mundo!
Encontrar um candidato para refatoração durante o emparelhamento? Leia isso dev.to artigo sobre essa nova biblioteca?
Basta adicioná-lo à parede.
No começo, você será o único a postar ideias. Com o tempo, o resto da equipe se sentirá mais confortável e participará. Veremos como escolher o que falar em um minuto.
Encontrando um tempo
Alguns podem dizer: “Vamos nos reunir sempre que necessário. Somos ágeis!”
Na minha experiência, isso não funciona. Sempre há algo urgente ou alguém não tem tempo agora.
Meu conselho? Escolha um slot fixo: mesmo dia e hora, todas as semanas.
Idealmente, sempre que for menos perturbador. Após o dia, logo após o almoço – realmente não importa. As pessoas vão se acostumar com isso e levar isso em consideração na programação.
Meia hora deve ser suficiente para ter conversas significativas.
O fluxo da placa é um bom indicador. Se você está coletando mais e mais tópicos sobre os quais nunca fala, talvez seus grupos de desenvolvimento precisem ser um pouco mais longos. Se você está ficando sem coisas, talvez possa terminar mais cedo ou até mesmo mudar para conversas quinzenais.
Como executar um dev huddle
Executar um dev huddle consiste em examinar a lista de tópicos, discuti-los, chegar a uma conclusão e documentá-la. Parece fácil, certo?
Não tão rápido. Em primeiro lugar, há tem para ser um facilitador.
Um bom facilitador controla o tempo total, certificando-se de que nenhum tópico consuma todo o tempo. Eles também dão a todos a chance de falar.
Sem essa função, você pode acabar tendo uma discussão em um pub, apenas sem a cerveja.
Eu costumava correr todos os huddles em uma equipe anterior. Só percebi muito mais tarde o erro que foi.
As reuniões acabam sendo suas quando deveriam pertencer a toda a equipe. É difícil facilitar e ser um participante ativo ao mesmo tempo.
Em vez disso, gire a facilitação. Todos praticam a moderação e você também se diverte um pouco!
Se você tiver muitos tópicos, terá que escolher quais abordar. Você pode tomá-los em ordem de criação, ou ponto vote pouco antes de começar.
Algumas pessoas apresentarão mais pontos do que outras. Tente mantê-lo equilibrado. Uma grande mudança arquitetônica requer mais do que alguns minutos, então talvez uma reunião de acompanhamento seja necessária.
E então, a discussão segue.
Um amontoado não consertará uma cultura quebrada, mas é um bom teste decisivo. Você está expressando opiniões ou fatos? Você está lutando para conseguir uma palavra? Nesse caso, um amontoado é o menor dos seus problemas.
Aqui está um exemplo de lista de verificação para ajudar moderadores menos experientes:
- Are there open points from last time?- Choose the topics for today* For every topic The owner presents the issue so that everybody is on the same page Talk about it (Keep a timebox!) Resolution What did we decide? Assign an owner to take care of the follow-up - Have we made decisions that need to be reflected in ADRs?- Finish on time, unless there is something that absolutely can't waitO resultado
Fazer a equipe falar uma com a outra já é alguma coisa. Se não houver resultado, no entanto, não é realmente uma reunião, mas uma reunião social.
Portanto, anote suas descobertas. Normalmente, será sobre coisas que você deseja fazer ou coisas que fará a partir de então.
Histórias técnicas / itens de folga
Não dê ouvidos ao microgerenciadores de cabelos pontudos que desejam registrar todas as ações já realizadas, por mais inconseqüentes que sejam. Para pequenas coisas, mantenha a contabilidade ao mínimo e conte com tempo de folga.
Para coisas maiores, escreva histórias técnicas e certifique-se de integrá-las em seu backlog regular. Muito pode ser dito sobre isso.
TLDR: mantenha uma história técnica com os mesmos padrões das histórias de usuário.
Acompanhar as decisões
Imagine o seguinte: todos estão animados para o amontoado. Ele fica intenso, mas você chega a um acordo sobre se deve usar ponto-e-vírgula ou não. Coisas sendo feitas. Mas ninguém anota e você tem que começar tudo de novo na próxima semana.
Enfurecedor, não é?
Posso te interessar em algum Registros de decisão de arquitetura leve? Pode parecer formal e pouco ágil, mas realmente não é. Você apenas tem um lugar onde acompanha as decisões que toma.
Um arquivo Markdown com um título, o que você decide e uma explicação do contexto é tudo que você precisa. Já vi pessoas escreverem romances para tornarem-se poéticos sobre as virtudes de Kafka quando algo simples também funciona:
Title: Use Kotlin instead of Java for new servicesDate: 2018/10Decision: We'll be using Kotlin whenever we start a new service but leave the existing onesContext: We think Kotlin will help us create more lightweight services while improving quality thanks to null safetytem muitos modelos que você pode usar. O importante é ser disciplinado e refletir sobre o que você concorda.
Fique amontoado!
Olhando para trás, todas as equipes em que participei se beneficiaram significativamente por ter um lugar para os desenvolvedores se alinharem. É apenas um pequeno investimento de esforço e tempo.
Experimente e encontre a configuração que funciona melhor para você.
