Você já deve ter ouvido falar no termo squads autônomas, certo? Essa é uma nomenclatura que vem ganhando cada vez mais espaço e adeptos entre as equipes de TI das empresas, especialmente entre as startups. Consiste em equipes pequenas e multidisciplinares, em geral com menos de 8 pessoas, responsáveis de ponta a ponta pela construção de um projeto. Do design ao deploy, passando pela manutenção e operação de um produto, serviço ou mesmo funcionalidade, um squad (esquadrão) tem total autonomia para decidir o que construir, como construir, e principalmente como trabalhar em colaboração conjunta ao longo do projeto.
Um pouco de história: a cultura de engenharia do Spotify
O termo squad nasceu de uma cultura de transformação ágil criada pelo Spotify em 2008. Naquela época, a empresa apostava no Scrum como metodologia ágil de processos baseada em times de desenvolvimento. Com o passar dos anos, porém, acabaram se dando conta que os princípios ágeis estavam se perdendo em práticas específicas que não agregavam os resultados esperados: mais que mestres em processos, eles precisavam de líderes mais servidores. Foi então que resolveram renomear o papel do Scrum Master para “Treinador Ágil”, e passaram a adotar o termo Squads, ao invés de Time Scrum, tendo como força motriz a autonomia entre as equipes.
E como as squads funcionam, na prática?
Cada squad possui uma missão de longo prazo – que pode ser algo como, no caso específico do Spotify, “tornar o player o melhor lugar para se descobrir música” – com objetivos de curto prazo, que são renegociados a cada 3 meses. Os membros do esquadrão trabalham próximos uns aos outros, em um ambiente que favorece a colaboração, com mesas ajustáveis e fácil acesso às telas de cada membro da equipe. A aposta na autonomia veio não só pelo fator motivacional, uma vez que, como sabemos, pessoas motivadas trabalham melhor, como também pela velocidade na entrega de projetos, ao permitir que todas as decisões aconteçam localmente em cada squad, ao invés de passar pela aprovação de todo o corpo diretor da empresa.
Claro que, apesar de cada esquadrão ter a sua própria missão, todas as squads autônomas precisam estar alinhadas com a estratégia de Produto da empresa, suas prioridades e também com o que fazem os outros esquadrões. A ideia geral é: esquadrões desacoplados, porém bem alinhados. É mais ou menos como em uma banda de jazz: apesar de cada músico ser autônomo, e tocar seu próprio instrumento, eles ouvem uns aos outros, e focam na música como um todo.
Autonomia alinhada
A cultura de engenharia do Spotify acabou evoluindo para um modelo de “autonomia alinhada”, onde o alinhamento possibilita a autonomia, de tal forma que quanto maior o alinhamento entre as equipes, mais autonomia elas terão para trabalhar. O trabalho do líder é comunicar qual problema precisa ser resolvido, enquanto as squads autônomas colaboram umas com as outras para encontrar a melhor solução. Dentro desse contexto, uma consequência direta da autonomia é a pouca padronização.
O que, a princípio, pode parecer ruim. Mas, no fim do dia, a abordagem informal acaba levando a um equilíbrio saudável entre as equipes. É a chamada “cultura de polinização”. Por exemplo: ao invés da imposição de padrões formais, quando uma quantidade crítica de squads usa uma determinada prática ou ferramenta – como o GIT – este acaba se tornando o caminho de menor resistência e outras squads tendem a escolher as mesmas ferramentas.
Tecnicamente, cada esquadrão é dono de um ou mais sistemas. Existe muita interação, mas cada sistema é focado em uma necessidade específica, que deve se manter pequena e desacoplada, com interfaces e protocolos claros. Como estamos falando de uma cultura de colaboração, é fundamentada sobretudo no compartilhamento de conhecimento entre os pares. Por exemplo, vamos supor que a squad 1 precisa que algo seja feito ao sistema B, sendo que a squad 2 conhece o código melhor para realizar a tarefa.
Tipicamente, a squad 1 faria essa solicitação para a squad 2. Mas se a squad 2 tiver outras prioridades, a squad 1 não precisa esperar: ao invés disso, ela será bem vinda para prosseguir na tarefa e editar o código sozinha, e então pedir para que a squad 2 revise as alterações. Em resumo, qualquer um pode editar qualquer código, mas, diante de uma cultura de colaboração, cada esquadrão pode revisar o código de seus pares. O resultado é que, além de melhorar a qualidade das entregas, é uma cultura que ajuda a disseminar o conhecimento.
Chapters, Tribes e Guilds
Squads autônomas são agrupadas em tribos (Tribes). Uma tribo é como uma matriz/tabela (ver desenho); cada pessoa é um membro de um squad e também de uma seção (Chapter). O squad é a primeira dimensão, com foco em entregar o produto com qualidade, enquanto a seção representa uma área de competência, como Qualidade, Produção e Operações. Como um membro da squad, o líder da seção está focado em treinar e ser o mentor como engenheiro. Apesar de ser uma imagem bonita, ela não reflete exatamente a realidade das coisas. Pois, em um ambiente em constante transformação, como o da TI, a comunicação mais valiosa acontece de maneiras informais e imprevisíveis.
Para dar suporte a tudo isso, existem as Guildas (Guilds). Uma Guilda é uma comunidade orgânica de interesse, onde pessoas de toda a empresa se unem para compartilhar o conhecimento de uma área específica. Por exemplo: liderança, desenvolvimento web, ou entrega contínua. Qualquer um pode entrar ou sair de uma Guilda a qualquer momento. As Guildas geralmente se organizam através de listas de email e outros meios informais de comunicação. O foco é sempre no ganho em comunidade, ao invés de estruturas hierárquicas mais rígidas.
O objetivo final, comum a todos, é a facilidade com que os projetos são colocados em produção. Se o lançamento (release) se mostrar difícil, poucos lançamentos serão feitos para evitar a dor; isso significa que cada lançamento será maior e portanto cada vez mais difícil, o que leva a um ciclo vicioso. Mas se o lançamento for fácil, será possível lançar com maior frequência, e cada lançamento será menor e mais fácil que o outro. Por essa razão, o foco é uma infraestrutura de entrega contínua com testes automatizados.
Mas, e quanto aos Indicadores de Confiabilidade?
Não seria interessante se cada squad pudesse contar com uma Matriz de Resiliência com indicadores baseados nos princípios de Engenharia de Confiabilidade do Site (SRE)? A One Platform faz exatamente isso: monitora os principais indicadores e emite alertas que possibilitam uma melhor gestão por parte dos times de desenvolvimento. A segmentação é feita por Produto, sendo que as dependências são apresentadas de uma forma muito simples e intuitiva, com status de uptime e downtime na mesma interface.
A One Platform é organizada visando a Observabilidade de múltiplos times x múltiplos produtos, independente da quantidade de produtos ou squads atreladas a esses produtos (por exemplo, time comercial e customer success). Conta também com diversos canais de notificação para alertas, tais como Slack, Telegram, WhatsApp, Google chat e e-mail.
A plataforma está em constante desenvolvimento, e atualmente conta com alguns dos principais indicadores de Confiabilidade, tais como:
- Deployment Frequency (gerando uma timeline com todo o ciclo de vida da aplicação)
- Change Failure Rate
- Lead time for changes
- Mean Time To Recover (MTTR)
- Uptime
- Mean Time Between Failure (MTBF)
- Mean Time To Acknowledge (MTTA)
- Budget de SLA
Conheça a nossa plataforma que contempla todas essas métricas.