Parece que em pequenas equipes de desenvolvimento (mais de 20 pessoas) não deve haver problemas com desunião, trabalhar em um código comum e tomar decisões técnicas. Mas todos sabemos que não é assim (para não mencionar equipes como a nossa, onde mais de 80 pessoas). Há três anos, para resolvê-los, começamos a realizar uma conferência interna semanal para desenvolvedores do DevForum. Abaixo do gato, você aprenderá sobre como isso nos ajuda, por que outros formatos (como reuniões semanais ou Revisão da Sprint) e instruções para criá-lo nem sempre funcionam.
Por três anos, acumulamos muito conteúdo bom. Portanto, haverá uma série de artigos escritos com base em discursos no DevForum :
1. Gato de Schrodinger sem caixa: o problema do consenso em sistemas distribuídos.
2. Infraestrutura como código: primeiro conhecido.
3. Infraestrutura como código: como superar problemas com o XP.
4. Como os servidores concordam: O algoritmo de consenso distribuído Raft.
5. O cavalo está morto - choro: transição de tslint para eslint.
6. Geração de contratos datilografados para modelos c #. (Em andamento ...)
...
O que é o DevForum e que problemas ele resolve?
O DevForum é o nosso evento interno semanal para desenvolvedores de Dodo IS. Ele funciona às quintas-feiras há três anos. Os desenvolvedores se reúnem e dedicam uma hora para se comunicar.
Nesta reunião, discutimos questões técnicas relevantes para toda a equipe. Uma hora, dois relatórios de meia hora, tempo para perguntas e respostas.
Que problemas a conferência interna resolve?
Para avançar em direção à consecução de um objetivo comum, é importante mantermos o foco em questões significativas da empresa. Para a sincronização geral de todo o Dodo, temos reuniões semanais às segundas-feiras. Todos os funcionários, parceiros / franqueados estão presentes, gravações de reuniões podem ser vistas
em domínio público . Para uma sincronização com negócios e parceiros, organizamos uma
Revisão Sprint quinzenal. Para um foco único e sincronização regular da equipe de TI, você precisa de mais imersão na "carne" técnica. É isso que estamos fazendo no DevForum.
Aqui está uma lista de problemas e suas soluções:
- Compartilhando conhecimento . Agora, temos mais de 80 desenvolvedores em nossa equipe. Cada um deles tem seu próprio histórico, suas próprias especificidades de trabalho, seu próprio nível de imersão. Nossas equipes são divididas por produto. E pode acontecer que duas equipes independentes precisem passar pela mesma situação. Quando eles têm a oportunidade de compartilhar suas melhores práticas, pensamentos, sucessos ou vice-versa, eles ficam melhores. Há uma pequena chance de não pisar no ancinho de alguém.
Além disso, nossa equipe está em constante expansão, novas pessoas vêm e recebem uma ferramenta pronta para atualização e compartilhamento regulares de conhecimento. - Treinamento . Aqui você pode aprender se não pode fazer sozinho e ensinar, se puder. O treinamento é um ponto que está intimamente ligado ao compartilhamento de conhecimentos. Quer gostemos ou não, precisamos melhorar constantemente nosso nível técnico.
- Sincronização técnica de comandos (não confunda com a sincronização diária de comandos) . É fácil acompanhar tudo quando você tem apenas três pessoas. Agora somos muito mais. Às vezes, encontramos esse problema: as equipes trabalhavam em paralelo em um produto, mas não sabiam o que cada uma faz. Como resultado, surgiram conflitos, reescrevendo o código de outra pessoa etc. Quando alguns o fazem, enquanto outros jogam, o processo de desenvolvimento pode escorregar. No DevForum, também nos concentramos na sincronização técnica de equipes e estamos lutando com desunião.
- Ferramenta para mudança . Você pode vir aqui e mudar o curso da história. Aqui você precisa contar pelo exemplo.
Um exemplo Digamos que temos Oleg. Ele senta na infraestrutura e faz o projeto Autonomy com os caras. Quando o projeto iniciar todo o seu potencial, a vida de desenvolvedores simples se tornará mais fácil. Eles vão parar de puxar a infraestrutura e farão tudo sozinhos. Você faz tudo sozinho, não depende de ninguém, tudo bem.
Oleg está pronto para fazer mudanças na empresa. Mas ele sabe que simplesmente escrever sobre as alterações feitas no Slack não é suficiente. É necessário contar em público, explicar, responder perguntas, escrever um artigo, realizar uma série de ações, caso contrário nada mudará. Oleg chega ao DevForum e o usa como uma ferramenta de mudança.
- Treinamento antes do desempenho . Aqui você pode praticar antes de um grande desempenho. Mais uma vez, tome Oleg como exemplo.
Um exemplo Oleg quer falar em grandes conferências. Ele precisa de honra, fama e milhares de visualizações no Youtube.
Ele vem até nós e fala honestamente sobre seus objetivos ambiciosos. Nós, por sua vez, fornecemos a ele uma plataforma para um treinamento (praticamente) indolor. Se necessário, ajudamos, solicitamos, orientamos.
O limite para entrar no DevForum (diferente de uma mitap ou conferência) é mínimo. Oleg precisa preparar um tópico, preparar slides por meia hora e chegar na hora certa. Este é um ótimo lugar para um ensaio experimental. Treinamento em gatos, ou seja, em nós. Vamos dar feedback e analisar os slides, e você pode conferir as piadas sobre nós.
Após o DevForuma, o relatório já pode ser lançado em uma mitap local. E provavelmente eles o levarão.
Um pouco retrô: como surgiu o DevForum
De onde veio esse formato? Korotenechko. Há três anos, nossa empresa fez sua primeira tentativa de introduzir a Sprint Review regularmente.
Parecia assim: todos se reuniram em uma sala, absolutamente tudo e se revezaram dizendo um ao outro quem havia feito o que nas últimas semanas. Naquela época, éramos apenas 20, mas imagine como é ouvir e ver o código para o representante de negócios e o desenvolvedor para ver o desenvolvimento de pizzarias. Rapidamente percebemos que as pessoas ouvem apenas tópicos que lhes interessam e, em outros, ficam dolorosamente presas ao telefone.
Somos confrontados com o fato de que é uma demonstração profundamente técnica para as pessoas que estão longe disso. Eles vieram para ver como o caixa começou e contamos a eles a experiência de usar a estrutura Polly para implementar retrays entre serviços. Logo percebemos que esse formato era de pouca utilidade para as pessoas, e a Sprint Review foi recusada dessa forma. Em algum momento, foi simplesmente cancelado e a reunião no calendário permaneceu.
Um grupo de pessoas da iniciativa pensou: é muito legal mostrar coisas técnicas para aqueles que estão no assunto. Há uma reunião, as pessoas são, há um desejo, há tópicos. Então começamos a nos reunir uma vez por semana e continuamos a fazê-lo até hoje.
Durante três anos, o formato passou por algumas mudanças.- Começamos a gravar nossas apresentações. O formato em si já dura três anos, temos registros em dois anos. Todos eles são armazenados em um local, se desejado, você pode revisar.
- Saímos do formato da demonstração porque chegamos à conclusão de que a preparação e a própria demo levam mais tempo que o formato da apresentação.
- Passamos para o formato de apresentação, que é fácil de preparar, oferecendo literalmente 40 minutos de tempo (embora aqui, é claro, dependa da complexidade do tópico e do palestrante).
- A princípio, todos os desenvolvedores falaram no DevForum. Em algum momento, assumimos que nem cada pessoa falava, mas um representante da equipe.
- Depois fomos mais longe e paramos de incomodar com uma proposta de falar com as equipes que agora têm "nada acontece".
- Inicialmente, ajustamos quatro tópicos por hora, mas chegamos à conclusão de que, por mais interessantes que fossem os relatórios, até o final da hora apenas restava mingau na minha cabeça. Agora, abordamos um ou dois tópicos no DevForum, 25 minutos de um relatório e 5 minutos para perguntas.
- Recentemente, decidimos expandir um pouco a gama de tópicos e, às vezes, convidar palestrantes externos.
Sabemos que nosso DevForum não é um formato super exclusivo, muitos de nossos colegas tentaram algo semelhante. Infelizmente, porém, muitas vezes essas reuniões regulares não se enraízam, tornam-se rapidamente obsoletas e murcham. Nosso DevForum vive por três anos - esse é um longo tempo para analisar, coletar conhecimentos e compartilhar com você a experiência de criar e manter esse formato.
Como organizar o DevForum na sua empresa
Você precisará de 6 coisas básicas:
1. Compreendendo as tarefas e os formatos do DevForum.
Mais detalhesPara entender se é necessário executar o DevForum em casa, você pode consultar as tarefas que esse formato resolve em nosso Dodo.
Essas são as tarefas de comunicação, treinamento e auto-realização dos programadores. O DevForum é um mecanismo flexível e pode, uma vez ou outra, trabalhar mais para alcançar objetivos diferentes.
Existem dois formatos de fala verificados que desenvolvemos ao longo de três anos. Você pode adotar:
Relatório : um desenvolvedor prepara e fala, enquanto outros fazem perguntas.
Um exemplo Houve um tópico chamado “Registro Estrutural”, que falou sobre o serilog, seu uso em nossos projetos e como ele ajuda a trabalhar melhor com logs no Kibana. Ele também abordou o tópico de log estrutural via NLog e o uso de interfaces comuns de ILogging para projetos .NET CORE.
Após a apresentação, houve uma sessão de perguntas, e todos os participantes entenderam como era fácil adicionar essa biblioteca a um novo projeto. Demoramos 30 minutos. Por mais meia hora, discutimos os níveis de registro naquele dia, como Depuração, Informações, Aviso, Erro etc., e, especificamente, quais níveis descrevem quais situações no sistema. Na sessão de perguntas, foi levantado o problema de erros de ruído nos logs, principalmente os relacionados a retrays. Desde o DevForum, todos os novos projetos de microsserviços usam exatamente o Serilog e também aparecem em nosso modelo de serviço.
Tomada de decisão : há um problema que de alguma forma afeta a todos. As pessoas vêm com possíveis soluções para se concentrar em uma coisa.
Um exemplo Reunimos o DevForum para discutir a definição de concluído e queríamos estabilizar a qualidade do código fornecido para a produção. Mas como fazer isso quando você tem vários comandos trabalhando em um código comum de uma só vez? A solução foi tornar comum todas as definições de histórias de usuários concluídas. O DOD proposto foi um ponto controverso. Nos reunimos e discutimos se precisávamos ou não. Uma decisão geral foi tomada. Para implementá-lo, adicionamos um item à lista de verificação em nosso rastreador de tarefas (Kaiten) e o tornamos um item obrigatório ao fechar tarefas. Algumas equipes reforçaram ainda mais o Departamento de Defesa, acrescentando seus próprios pontos importantes para eles.
2. Organizadores poderosos e carregados.
Mais detalhesO que mais deve ser levado em consideração é a presença de pessoas que estão constantemente envolvidas no evento - os organizadores. É importante que eles sejam de desenvolvedores ou pessoas que entendem a parte técnica. Eles terão que ajudar os participantes a formular tópicos, procurar novos palestrantes e, às vezes, manter uma discussão fazendo boas perguntas.
No nosso caso, temos 3 organizadores dos desenvolvedores e uma equipe de marca de TI que ajuda ativamente.
3. Consentir com o gerenciamento do seu departamento de TI.
Mais detalhesAlém dos objetivos e organizadores, um componente importante do sucesso do evento é a falta de oposição de cima. Este processo é uma iniciativa puramente popular, podemos dizer que os entusiastas fazem isso. A ajuda da gerência pode ser benéfica e a oposição será desastrosa. Ainda assim, as pessoas se reúnem durante o horário de trabalho, usam instalações e equipamentos do escritório. Isso, no mínimo, não deve ser proibido.
4. A disponibilidade de espaço e equipamento para reuniões.
Mais detalhesO espaço pode ser uma sala de reunião no escritório ou um local de reunião virtual, uma chamada geral no Skype ou no Google meet.
Sempre nos reunimos em uma sala de reuniões reservada "para sempre neste momento" no escritório, mas ao mesmo tempo transmitimos tudo no geral, o Google meet, que também é o mesmo e não muda entre as reuniões.
Nossa negociação é grande, acomodando 20 a 30 pessoas. Há um projetor e um sistema de saída de som para chamadas remotas. Todo mundo sabe que, às quintas-feiras, das 16:00 às 17:00, o DevForum é realizado nesta sala de reuniões.
Devido ao fato de termos um desenvolvimento parcialmente distribuído, temos a certeza de levar os trabalhadores remotos a uma chamada comum. Ele também permite que os alto-falantes exibam sua tela no computador, conectando-se a uma reunião geral. Os palestrantes podem estar na sala de reuniões gerais ou em qualquer outro local conveniente para eles. Todos nós os ouviremos e também veremos a tela deles.
O espaço permanente designado torna essa reunião mais confiável e previsível para os participantes.
5. A presença de uma audiência de ouvintes.
Mais detalhesPara reunir os participantes, temos um canal permanente na folga #devforum, onde todos os desenvolvedores se sentam com certeza. Inclusive incluímos esse canal na lista de canais obrigatórios na lista de verificação do novo desenvolvedor. Além disso, os mentores iniciantes garantem que caem no canal #devforum.
Há anúncios de reuniões, discussões posteriores, escolha de tópicos e discussão de tópicos.
Para que as pessoas participem da vida do fórum, organizamos pesquisas, pedimos aos palestrantes para dar feedback e também publicamos uma gravação da reunião no dia seguinte pela manhã.
Também é importante que o evento seja voluntário e opcional. Sim, ele é realizado durante o horário de trabalho, mas se alguém quiser trabalhar ou tiver coisas mais importantes a fazer no momento, ele poderá perder.
Exemplo de publicação pós-evento:
Um exemplo de discussão após uma reunião:
6. Presença de palestrantes e tópicos para discussão.
Mais detalhesEsta é a parte mais importante e mais difícil da organização. Aqui nos deparamos com problemas, tanto na busca de palestrantes quanto na disponibilidade de tópicos.
Aqui está apenas uma pequena lista de atividades que os organizadores realizam para envolver as pessoas:
- Procuramos tópicos com antecedência, elaboramos um plano de desempenho por mais de uma semana. No início, procuramos por tópicos no início da semana e, na quinta-feira, tivemos que conversar.
- Entramos nos canais de comando e perguntamos explicitamente: existem tópicos para o DevForum?
- Conduzimos conversas pessoais com programadores, incentivando-os a se apresentar. Fundamentamos o valor da participação do palestrante: uma compreensão mais profunda do tópico, experiência de falar, benefício público, material para um artigo futuro, conferência.
- Abordamos os tópicos do canal para discussão que as pessoas estariam interessadas em ouvir. Desenvolvedores experientes podem responder e atuar como palestrantes.
- Respondemos a eventos socialmente importantes, organizando independentemente discussões sobre tópicos problemáticos de desenvolvimento.
- Assistimos a conferências anteriores com nossos participantes. Depois de participar de conferências, sempre há algo a dizer.
- Após os resultados de conferências importantes para nós, com a participação de muitas pessoas, estamos organizando uma discussão no formato de "3 melhores relatórios da mais recente Highload ++".
- Convidamos oradores externos.
Algo mais importante
Pode parecer que tudo é simples (ou vice-versa, nada está claro); portanto, listarei mais alguns recursos da organização que devem ser levados em consideração e mantidos em mente.
Os organizadores precisam trabalhar com alto-falantes. Resolvemos o medo de falar através da ajuda na preparação do discurso. Preguiça ou desorganização são interrompidas por uma solicitação para formular o tópico com antecedência, mesmo na forma de rascunho, e com a data exata do discurso.
Às vezes não há. Há momentos em que muita coisa foi encontrada, outras em pouco. Nesse caso, você não pode cancelar categoricamente o evento. Devemos tentar encontrar tópicos ou falar por nós mesmos. Os organizadores também são desenvolvedores, por isso sempre temos algo a dizer. Você pode recorrer a truques, organizando mais discussões gratuitas.
Qualidade de vídeo e som. É um momento puramente técnico, mas é importante para as pessoas que o som seja bom (verifique a conexão e a Internet com antecedência) e a demonstração do código na tela é legível. Mesmo o tópico mais interessante, com falhas técnicas, pode alienar os espectadores.
Nós acumulamos material. As reuniões devem ser gravadas. Temos um arquivo de vídeos, com apresentações e materiais adicionais anexados. Existem listas de reprodução no YouTube. Colocamos todos os registros em nosso sistema de documentação, onde há uma pesquisa em texto completo e você pode encontrar o tópico de seu interesse depois e se familiarizar.
Dedicado às equipes de desenvolvimento nas quais não há gerentes nos quais você trabalha em um único código, no qual os desenvolvedores estão interessados em saber o que está acontecendo, para as pessoas que desejam desenvolver e ajudar os outros a crescer, aquelas equipes nas quais a confiança é importante por dentro.
Da Dodo Pizza Engineering com humanidade