CDD IT - Outsourcing de TI - Topologias de Time

Introdução às topologias de times

Saiba mais sobre os benefícios das equipes alinhadas ao fluxo e como elas trabalham com equipes de plataforma, equipes de subsistema e permitem que as equipes entreguem valor aos clientes. 

As equipes de engenharia precisam se mover mais rápido do que nunca para agregar valor aos clientes. O aumento da nuvem, SaaS e serviços sempre ativos significa que os clientes esperam novos recursos, menos bugs e 99,99% (ou mais) de tempo ativo. 

Para acompanhar essas demandas, as empresas adotaram práticas ágeis e, nos últimos tempos, práticas de DevOps, que prometem tempo de comercialização/tempo de espera mais rápido, frequência de implementação de melhorias, melhor cultura de equipe e maior colaboração entre equipes/departamentos. 

Embora seja mais fácil falar do que adotar práticas de DevOps, o livro Team Topologies oferece maneiras perspicazes pelas quais as empresas podem criar DevOps em suas empresas, incluindo que tipos de equipes podem ser mais eficazes. Este livro oferece um ponto de partida de como a Atlassian pensa sobre as equipes. Em vez de reiterar suas descobertas, queremos compartilhar nossa própria perspectiva sobre os tipos de equipes. 

O primeiro passo para uma transformação de DevOps é identificar a estrutura organizacional em vigor. No entanto, em qualquer empresa hoje, existem muitos tipos de equipe diferentes e, em alguns casos, equipes individuais assumindo várias funções e responsabilidades. Essa expansão torna difícil para a liderança visualizar todo o cenário organizacional e responder a perguntas como: 

Os líderes de desenvolvimento e operações podem entender melhor se as equipes certas estão disponíveis, observando a empresa através das lentes das topologias de equipe. Recomendamos reduzir o número de variações da equipe para quatro topologias de equipe fundamentais, que são digeríveis com facilidade tanto para a gerência superior quanto para os próprios membros da equipe: 

Lembre-se de que esses tipos de equipe assumem formas diferentes, dependendo do tamanho e da maturidade da empresa. Na realidade, uma combinação de mais de um tipo de equipe, ou uma equipe se transformando em outra, costuma ser a melhor abordagem.

Equipe alinhada ao fluxo

As equipes alinhadas ao fluxo se concentram em um fluxo de trabalho único e impactante. Pode ser um único produto ou serviço, um único conjunto de recursos, uma única jornada de usuário ou uma única persona de usuário. A equipe tem o poder de criar e entregar valor ao cliente ou ao usuário da forma mais rápida, segura e independente possível, sem exigir entregas para realizar partes do trabalho a outras equipes. 

Como as equipes alinhadas ao fluxo trabalham em todo o espectro de entrega, elas estão, por necessidade, mais próximas do cliente e, em geral, já são ágeis. Essa equipe incorpora o feedback do cliente nos ciclos de desenvolvimento, mantendo o software em produção. 

Embora as equipes alinhadas ao fluxo sejam comuns em muitas empresas de software, outras empresas podem estar mais familiarizadas com as estruturas de equipe organizadas por função (ex. equipes separadas para engenharia, design, controle de qualidade), em vez do fluxo de entrega. 

Como a equipe alinhada ao fluxo é o tipo de equipe mais comum nas empresas, a função de outras equipes é definida em relação a ela. As equipes alinhadas ao fluxo devem entrar em contato a todo o tempo com as seguintes equipes de suporte (subsistema complicado, capacitadora e de plataforma) para melhorar a velocidade de entrega e a qualidade de seus produtos e serviços sempre. 

Equipe de plataforma

As equipes de plataforma permitem que equipes alinhadas ao fluxo entreguem trabalho com autonomia substancial. Embora a equipe alinhada ao fluxo mantenha a propriedade total da criação, execução e correção de um aplicativo em produção, a equipe de plataforma oferece serviços internos que a equipe alinhada ao fluxo pode usar. 

As equipes de plataforma criam recursos que podem ser usados por várias equipes alinhadas ao fluxo, com pouca sobrecarga. Ao otimizar um produto, as equipes de plataforma minimizam os recursos e as cargas cognitivas da equipe alinhada ao fluxo. Essa atitude também beneficia os usuários finais, já que as equipes de plataforma podem criar uma experiência coesa que abrange diferentes experiências de usuário ou produtos. 

As equipes de plataforma criam serviços usados por todos os nossos produtos (como gerenciamento de identidade) e esperamos que eles forneçam documentação, suporte e consultoria para equipes alinhadas ao fluxo. 

Equipe de subsistema complicado

Uma equipe de subsistema complicado é responsável por construir e manter uma parte do sistema que depende de habilidades e conhecimentos específicos. A maioria dos membros da equipe deve ser especialista em uma área específica do conhecimento para entender e fazer alterações no subsistema. 

O objetivo dessa equipe é reduzir a carga de equipes alinhadas ao fluxo que trabalham em sistemas que incluem ou usam o subsistema. Com a experiência e os recursos da equipe de subsistemas complicados, as equipes alinhadas ao fluxo não precisam criar recursos em áreas muito complicadas para o trabalho diário. Os membros dessa equipe podem ter conhecimento especializado em certos microsserviços (por exemplo, um serviço de faturamento), algoritmos ou até mesmo inteligência artificial. 

Uma armadilha comum é incorporar especialistas em cada equipe alinhada ao fluxo que usa o subsistema. Embora essa atitude possa parecer eficiente, em última análise, não é econômica e está fora do escopo de uma equipe alinhada ao fluxo. 

Equipe capacitadora

As equipes alinhadas ao fluxo estão sob constante pressão para entregar e responder às mudanças com rapidez, tornando difícil encontrar tempo para pesquisar, aprender e praticar novas habilidades. 

Uma equipe capacitadora composta por especialistas em um determinado domínio técnico (ou produto) ajuda a preencher essa lacuna de capacidade. Essas equipes se concentram em pesquisa e experimentação para fazer sugestões informadas sobre ferramentas, estruturas e escolhas de ecossistemas que afetam a pilha de ferramentas. 

Assim, as equipes alinhadas ao fluxo têm mais tempo para adquirir e desenvolver recursos sem ter que deixar seus objetivos principais em segundo plano. A equipe capacitadora busca, em primeiro lugar, aumentar a autonomia das equipes alinhadas ao fluxo, aumentando suas capacidades com foco nos problemas, em vez de soluções. 

Se uma equipe capacitadora fizer seu trabalho bem, a equipe que ela assiste não precisará mais de ajuda após algumas semanas ou mais. A equipe capacitadora nunca deve trabalhar em uma dependência permanente.

Modos de comunicação

Como comentado antes, nem toda comunicação é positiva, pois aumenta a carga cognitiva dos times. Por isso é necessário mapear e compreender como topologias tão diferentes podem interagir na estrutura. De acordo com o livro, há três tipos diferentes de modos de comunicação:

Colaboração

Nesse modelo, os times A e time B trabalham juntos, exigindo adaptabilidade e alinhamento; 

X-as-a-Service

Aqui, o time A provê alguma coisa para o time B, com o mínimo de colaboração. Alguns dos casos mais comuns são os times que desenvolvem bibliotecas de código, de componentes ou APIs, por exemplo, que depois serão utilizadas por outras equipes;

Facilitadores

Nesse modo de comunicação, o time A ajuda ou pede ajuda para outro time, eliminando impedimentos, principalmente quando é necessário um trabalho ativo para a evolução do trabalho ou para a execução de melhorias.

Com base nestes três panoramas, é possível montar todo um esquema de colaboração entre os times dentro e fora de suas estruturas, buscando facilitar o trabalho.

Vocês são uma equipe alinhada ao fluxo?

As perguntas a seguir devem ser feitas para determinar se você tem uma equipe alinhada ao fluxo:

Sua equipe tem como objetivo produzir um fluxo constante de recursos?

Equipes maduras fazem lançamentos várias vezes por semana e, em alguns casos, várias vezes por dia. Em busca desse objetivo, as equipes maduras devem usar a integração contínua e a entrega contínua (CI/CD) para enviar recursos com frequência.

Sua equipe muda de direção com rapidez baseado no feedback (do cliente ou interno) das últimas mudanças?

Em geral, é melhor usar uma abordagem experimental para a evolução do produto. Os processos de DevOps maduros incluem testes automatizados para garantir envios de código de qualidade. No entanto, a experimentação vai além de simples testes de unidade ou aceitação. Você pode garantir que seus produtos ofereçam o maior valor aos clientes usando sinalizadores de funcionalidade para automatizar implementações para um subconjunto de usuários, versões alfa e beta para solicitar e medir o feedback e o comportamento do usuário e feedback contínuo qualitativo por meio de comentários, tickets de suporte, e fóruns comunitários.

Sua equipe tem entregas mínimas de trabalho para outras equipes?

Essa situação deve ser verdade de duas maneiras. Sua equipe deve ser autônoma e o trabalho deve acontecer com colegas de equipe imediatos para garantir uma entrega rápida. Além do escopo do trabalho, as entregas mínimas também podem assumir a forma de processos automatizados. Automatizar seu ciclo de desenvolvimento garante que mover as coisas seja um processo contínuo, não obstante se a próxima etapa for uma ação como um teste automatizado, uma mescla com o principal ou um ser humano real. 

Sua equipe tem tempo para lidar com mudanças de qualidade de código (também conhecidas como “dívida técnica”) para garantir que as alterações sejam fáceis e seguras?

As equipes maduras confiam no desenvolvimento baseado em troncos e nas práticas de IC/CD para manter sua base de código. O planejamento de capacidade deve incluir tempo dedicado para lidar com dívidas técnicas. Além disso, projetos de grande escala que abordam problemas subjacentes de infraestrutura ou plataforma devem receber tanta atenção quanto o desenvolvimento de recursos.

Sua equipe é avaliada pelas métricas corretas?

Além da rapidez com que ela faz lançamentos, a saúde também deve ser considerada, assim como as métricas de qualidade técnica nessas medidas bem-sucedidas.

Em relação à última pergunta sobre medição, as equipes de DevOps quase sempre consideram as quatro principais métricas de DevOps Research and Assessment (DORA) em sua definição de “sucesso”:

Com que frequência uma empresa lança com êxito para a produção.
A quantidade de tempo que uma confirmação leva para entrar em produção.
A porcentagem de implementações que causam uma falha na produção.
Quanto tempo leva para uma empresa se recuperar de uma falha na produção.

Além dessas métricas especificadas pela DORA, a Atlassian descobriu que equipes de alto desempenho e alinhadas ao fluxo também monitoram esses atributos:

A equipe tem um conjunto diversificado de habilidades e perspectivas.
Um proprietário em tempo integral garante que a equipe central e os participantes multifuncionais saibam a quem fazer perguntas e como tomar decisões relacionadas aos projetos pertencentes à equipe.
Há uma compreensão compartilhada dos requisitos, em conjunto com a definição de valores e métricas para o sucesso.
A equipe tem diretrizes claras que orientam quais tarefas realizar para mover os projetos para lançamento.
Ter um artefato real para discutir e testar suposições ajuda uma equipe a fazer iterações e melhorias constantes.
Compreender as dependências gerenciadas mantém os bloqueadores longe e ajuda a equipe a manter a velocidade.

Fonte: Atlassian / Team Topologies