Squads, tribos, chapters e guilds: como organizar times ágeis de frontend? #446
Replies: 18 comments
-
Fala @danvitoriano, o @filipedeschamps mencionou em #411 que a empresa dele agora tá se organizando em squads. Acho que ele seria uma boa pesssoa pra responder essa pergunta. Também mencionei uns vídeos (em inglês) de como o Spotify usa esse esquema: Spotify Engineering Culture - part 1
Quais ferramentas de apoio à comunicação vocês usam? Slack? GitHub? Claro que nada substitui uma conversa presencial, mas tem ferramentas que ajudam bastante. Eu ainda não experimentei essa organização, mas tô curioso pra saber das experiências de vocês. Abs |
Beta Was this translation helpful? Give feedback.
-
Fala @fabiorocha, obrigado pela sua resposta! Então, nós aqui usamos todas as ferramentas de comunicação disponíveis para ajudar o desenvolvimento: Slack, GitHub, Confluence, mas não é a mesma coisa. Na proposta do Spotify, as guilds são times que tem a mesma skill ou interesse, como os frontends, porém, como montar um guild e um squad ao mesmo tempo. Eis a minha dúvida! kkkk Aliás, vou ver os vídeos que você passou, muito obrigado! E grande @filipedeschamps! Vi uma talk dele semana passada na Vizir apresentando a lib cep-promise dele. Sensacional! |
Beta Was this translation helpful? Give feedback.
-
@danvitoriano aqui nós começamos a nos organizar no modelo Spotify e estamos enfrentando o mesmo problema que vocês. Acho que a cultura de comunicação e troca de conhecimento é o que precisa ser fomentado entre os fronts, usando Wiki, Tech Talks rápidas... além de certa proatividade dos profissionais de estudar, ler, buscar conhecimento pra poder transmitir. |
Beta Was this translation helpful? Give feedback.
-
@danvitoriano temos o mesmo problema aqui. Esse modelo do spotify já deixo claro que não dá certo em todas as empresas. Mas se foi tomada a decisão de ser assim, aqui vai algumas coisas que fizemos aqui onde trabalho que resolveram bastante problemas. Fizemos as seguintes adaptações: As guilds passaram a conversar mais, discutir mais coisas. Adicionamos dailys rápidas pra cada um falar o que estamos fazendo, se estamos usando novas tecnologias, se tá tendo algum problema e etc. Além disso adicionamos na nossa organização de guilds reuniões semanais que podem ser feitas tech talks, pode ser discutido sobre ferramentas para melhorar algum fluxo. O interessante aqui é que tenha sempre uma pauta pra reunião fluir melhor. E tem várias outras que estamos aos poucos testando e vem melhorando. Como falei o modelo do spotify não dá em todas as empresas, porém sempre podemos adaptar alguma coisa e tal. |
Beta Was this translation helpful? Give feedback.
-
O modelo no Pagar.me ainda está na versão 1.0, mas de largada já se demonstrou muito interessante para principalmente destacar como faltam pessoas para preencher papéis nas squads. Basicamente notamos que (numa analogia) jogamos War e tentamos conquistar vários países ao mesmo tempo e ficamos fracos em todos. Agora estamos tentando nos recuperar disto. O jeito que estamos montando os squads é um pouco diferente, pouco importa os papéis que estão dentro do squad desde que tenha no mínimo 3 papéis:
A estratégia serve para deixar o squad alinhado com a estratégia global da empresa. É o papel responsável pelo norte do squad. A tática é o papel técnico, por exemplo programadores de qualquer natureza ou qualquer especialidade técnica e o seu objetivo é materializar o norte vislumbrado pela estratégia. E por último o monitoramento que serve para duas coisas: ou evitar o autoengano (mensurando a performance, seja como for feito, tanto faz) ou para monitorar sinais vitais, caso seja um squad de operação, como temos um aqui chamado de Heartbeat, que mensura os sinais vitais dos nossos serviços. Todos os squads tem um propósito e um logo e isto faz muita diferença para definir o escopo. Estamos agora fazendo camisas com o logo dos squads, ta ficando muito massa. Um exemplo prático do squad Heartbeat: PropósitoGarantir a saúde dos nossos serviços e monitorar os seus sinais vitais. Papéis
O monitoramento do desenvolvimento é bem simples, não utilizamos sprint para este squad e é feito com o Trello, dinâmica de Kanban. Cada squad se organiza como fizer sentido desde que atenda aos 3 papéis mínimos: estratégia, tática e monitoramento. |
Beta Was this translation helpful? Give feedback.
-
@edmolima e @filipedeschamps muito boa as explicações de vcs! |
Beta Was this translation helpful? Give feedback.
-
@paulinhapenedo estou vendo que juntar o time e promover sempre essa troca de conhecimento, seja em tech talks, dojos, ou em estratégias mais elaboradas como a citada pelo @filipedeschamps na Pagar.me é o caminho para resolver essa lacuna entre time hiper focados mas que correm o risco de ficarem isolados! |
Beta Was this translation helpful? Give feedback.
-
@danvitoriano legal esse assunto! Aqui no GetNinjas estamos também nesse modelo, e pra manter todas as roles integradas e sincronizadas no que fazemos, sempre temos reuniões dos Chapters. No modelo do Spotify, o Chapter é uma "organização" de pessoas com os mesmos papéis, que sempre se encontram pra discutir o que tem rolado nos squads. Além disso, os Chapters servem pra decidirmos padrões de código, novas ferramentas pra usar e contar um pouco do que estamos fazendo no dia-a-dia. Mais uma coisa que decidimos é sempre ter um review, nos pull requests, de outra pessoa do outro squad. Isso mantém nosso code-base íntegro e a visibilidade do que fazemos. |
Beta Was this translation helpful? Give feedback.
-
Fala @eduardojmatos ! Bacana esse approach! Acho que aqui, o Fórum Técnico reúne devs backs e fronts. Tá fazendo falta um fórum do Chapter só de Fronts mesmo. Essa questão do review das PRs tb é interessante. Nossa regra é ter code review de ao menos duas outras pessoas do mesmo Chapter, mas não é obrigado ter alguém do mesmo squad. É de se pensar... só me resta a dúvida se um backend ia conseguir fazer code review de uma PR de front rsrsrs. ( Galera, tá muito legal esse feedback aqui, sensacional ❤️ ) |
Beta Was this translation helpful? Give feedback.
-
@danvitoriano pode crer! Lá definimos que, pelo menos uma pessoa que é especialista no assunto, precisa dar o |
Beta Was this translation helpful? Give feedback.
-
Caí aqui de paraquedas, e queria perguntar coisas objetivas que fiquei curioso em cima do que voces contaram... @danvitoriano @filipedeschamps @eduardojmatos @edmolima e @paulinhapenedo
Por fim, gostaria de parabenizar vocês, se mais empresas tivessem programadores discutindo/debatendo processos e melhorias, tenho certeza que elas entregariam ainda mais valor. |
Beta Was this translation helpful? Give feedback.
-
Opa @bernarddeluna bacana cara eu tenho esse mesmo pensamento, as coisas seriam mais fáceis talvez para o negocio se todos tivéssemos a consciência que o código será o menor dos seus problemas rsrs. Mas colocando aqui os pontos de como funciona atualmente onde trabalho. 1. De quanto em quanto tempo acontece a definição do objetivo do Squad? 2. A entrega de um squad é sempre um release no ar? Não é envolvido no squad experimentações, testes AB? research ou camadas de Design (com overlap ou dual track)? 3. Como o kanban trabalha em demandas, como fica essa geração de demandas? Como vocês consideram o uphill ou discovery nesse fluxo contínuo? A cada 15 dias há um processo de descoberta, na verdade acontece a todo momento a janela é mais um momento pra pararmos criarmos hípoteses, validar, trazer novos insumos e etc. Eu não tem bem claro o quanto isso é efetivo, espero que nos próximos anos possa experimentar novos times com praticas diferentes pra saber ao certo o que funciona ou não. A única coisa que sei é que dado todos esses processos, cerimônias e etc nos traz muita velocidade ainda mais vendo a maturidade atual do time. |
Beta Was this translation helpful? Give feedback.
-
Aqui onde trabalho os squads não são definitivos e inclusives tem pessoas, redator, que são comuns em mais squads. Mas por aqui, o que rola geralmente é Dev (pelo menos 2, podendo aumentar de acordo com a demanda), UX (mesma lógica de Dev), Redator e Scrum master (sim o termo é de outra p'ratica, mas é isso mesmo) |
Beta Was this translation helpful? Give feedback.
-
Fala @bernarddeluna , blz? Então, voltando aqui, nós fazemos reuniões trimestrais pra definir nossos OKRs (Objective Key Results). Esses OKRs são baseados em OKRs globais da empresa, mas com temas específicos pra cada squad (Experiência do Cliente, Exp. do Profissional, Pagamento, Data Science, SRE). A entrega é por sprint e o acompanhamento é feito via metabase em TVs próximas aos squads e notificações diárias nos canais de cada squad. A parte de A/B é feita pelo time mesmo. Estamos testando agora uma nova forma de fazer o research - estamos chamando de Triple Track Agile, algo que em breve vamos divulgar por aí. Não é nada revolucionário, mas usa as bases do dual track só adicionando uma nova track de "problem space". Dentro desse space temos várias técnicas pra testar, validar, discutir novas ideias. É algo experimental ainda, mas logo vamos lançar esse textão sobre nossas experiências com isso. Estamos usando scrum por hora, dentro do Delivery, mas logo mais vamos testar kanban, justamente porque o triple track acaba exigindo uma flexibilidade de definição de prioridades, de acordo com os resultados das experimentações de cada squad. Basicamente é isso que estamos testando agora, principalmente pra envolver mais desenvolvimento em algumas decisões de produto e não trazer muita experimentação pra dentro do Delivery - não tivemos bons resultados com isso, no fim das contas, mas é algo que vamos compartilhar nessa futura série de posts no nosso blog de tech (labs.getninjas.com.br). |
Beta Was this translation helpful? Give feedback.
-
@eduardojmatos esse post sobre o que não foi muito legal ao usar essa estrutura para experimentação vai rolar? |
Beta Was this translation helpful? Give feedback.
-
@danjesus pretendo soltar pelo menos um esse mês. A galera de produto e design também quer fazer algo sobre essa experiência que tivemos. Posto aqui quando soltarmos! :) |
Beta Was this translation helpful? Give feedback.
-
Olá pessoal, que discussão bacana! Parabéns e obrigada a todos os envolvidos por compartilhar suas dúvidas e seus conhecimentos, esta troca é muito rica! Como disse o @bernarddeluna, caí aqui de paraquedas também... rs... Eu estava pesquisando cases de como os Chapters (que aqui onde trabalho chamamos de "Staff's de especialistas") se organizam para darem visibilidade de suas interações e acabei caindo aqui =) Na VAGAS.com também trabalhamos com squads e, para tentar minimizar a "distância" e aumentar a troca entre os membros da staff, como front-ends por exemplo, utilizamos algumas das propostas aqui relatadas pelos colegas: techtalks, weekly's, PR's etc... Mas o meu ponto tem relação especificamente com os PR's! Hoje temos pelo menos 5 squads por aqui, e convencionamos que deveríamos ter ao menos 3 (três) revisores para cada PR, sendo 1 (um) integrante da squad que deu origem a demanda. Neste cenário, sempre temos alguém olhando para algum PR da própria squad, mas também temos alguém olhando para os PR's de outras squads, especialmente quando estes podem gerar algum impacto sobre outros desenvolvimentos (existem frentes que utilizam API's e bases comuns). Enfim, o que acontece é que nas daily's é bem comum que os devs digam que estão olhando para algum PR, sejam eles PR's originados através da própria squad, ou não. E, neste último caso, o restante do time não têm visibilidade do quanto de esforço o dev está investindo para validar PR's das outras squads, já que no quadro kanban da squad (que geralmente fica no JIRA/ Trello) só é possível ter visibilidade das demandas que foram desenvolvidas pelo próprio squad, e não das que foram desenvolvidas e que estão em PR de outras squads. Algumas vantagens desta forma de trabalho:
Alguns problemas desta forma de trabalho:
Enfim, isto me parece ter relação com gerenciamento em escala... Mas de qualquer forma, gostaria de saber se vocês já passaram (ou passam) por algo parecido, e como conseguiram resolver esta questão da visibilidade dos PR's em andamento? Valeu pessoal! |
Beta Was this translation helpful? Give feedback.
-
Bom assunto, temos um cenário muito parecido com o descrito pela @Luamm aqui no Conta Azul. Visibilidade dos PRs em andamentoAqui cada squad controla o seu board, normalmente tem uma coluna onde ficam as tarefas que estão em code review. E para saber quais pull requests precisam ser revisados ?Como trabalhamos com Github, tem a lista de pull requests abertos nos repositórios. O github permite que liste todos os PRs abertos para a organização também. Não sei se existe esse conceito de organização em outras ferramentas. Quantos reviews são necessários?Cada repositório tem isso especificado no README.md ou no CONTRIBUITING.md Como nos organizamos no Github?Cada time time/squad tem seu repositório, gerenciado pelo PO e pelos devs, onde as tarefas são criadas e priorizadas. Esses repositórios não tem código, servem para gerenciamento do time. E temos os repositórios onde a codebase fica e é onde são abertos os pull requests. Aqui existem vários assuntos pra ir mais afundo: Esses times/squads são multidisciplinares, back-ends, front-ends, PO, UX Designers. Como garantimos que os front-ends estão alinhados?Temos uma reunião semanal de 1hr entre todos os front-ends da empresa. Essa reunião tem como objetivo manter os fronts alinhados sobre os projetos que estão acontecendo e também se conhecerem já que hoje somos em 17 aqui. Para produtividade e engajamento desse encontro foi sugerido pelo @rafaelcamargo e tem funcionado o seguinte formato:
Isso tudo é produto de uma evolução na cultura de engenharia descrita nesse post do blog do Engenharia da ContaAzul |
Beta Was this translation helpful? Give feedback.
-
Olá galera, como vão?!
Resolvi aproveitar este espaço para fazer uma pergunta sobre a organização de times ágeis.
Aqui na empresa que trabalho, passamos a organizar os times em pequenos squads, como aplicado inicialmente pelo Spotify: um backend, um frontend, um arquiteto, um QA, um UX, e por aí vai.
Porém, como não somos muitos frontends, sentimos que ao ficarmos completamente separados uns dos outros, nosso desenvolvimento e entrosamento em relação a assuntos de front ficou prejudicado. Isolados em squads, nossa relação com o projeto ou o produto ficou mais interessante, porém, perdemos o contato e o desenvolvimento das threads que só interessam aos fronts, como frameworks, scripts, e tudo mais. Alguns tem sentido falta de sentarem mais próximos para um pair programming, tirar uma dúvida ou que a conversa que poderia rolar mais no nível do front nos ajudasse a solucionar os problemas mais específicos da área.
O que vocês acham? Quem já está trabalhando nesse esquema, tem sentido coisa parecida? O esquema de squad é melhor? Como solucionar esta distância entre assuntos de fronts?
Dêem suas opiniões, vai acrescentar muito no desenvolvimento dos nossos times ágeis.
Valeu!!!
Beta Was this translation helpful? Give feedback.
All reactions