: :
os agilistas

É por isso que a topologia de times melhora a qualidade dos produtos

É por isso que a topologia de times melhora a qualidade dos produtos

os agilistas
: :

Marcelo Szuster: Quais são as motivações para que a gente tenha que pensar na topologia do time? Por que não é uma mera questão de colocando times e quantos? Por que que interessa e o que exatamente o autor quer dizer quando ele fala da topologia de times?

Gabriel Naves: Show de bola, qual que é a motivação principal? Tão dos conceitos nessa área de tecnologia e informação, desenvolvimento de software mais difundidos é a lei de …. Ela traz para a gente que as formas de comunicação, os caminhos de comunicação que já existem entre os times e nas áreas das empresas, elas vão refletir diretamente na arquitetura e no desenvolvimento de software. Dado isso, dado que se você tem uma área, tanto área A  quanto área B e que o sistema vai comunicar com o sistema B ou o time de infraestrutura A que existe, isso vai impactar na arquitetura, vai impactar no software, vai impactar no seu produto, você deve pensar na topologia do seu time. Então, o que seria a topologia? Quais times vão existir? Como vai ser as formas de comunicação entre elas e eles? E tudo que está ao redor de eles, estão entrando no mundo que ele é …, os domínios e os produtos são …, as coisas vão entrando, mudando o tempo todo. As pessoas também, como fazer isso de uma forma mais huma, onde o time não tenha tanta carga cognitiva, onde as coisas vão ter fluir de uma forma realista.  

 

Marcelo Szuster: Está falando assim, porque é engessado, até anunciar essa lei, ela não é tão clara, acho que para uma forma para as pessoas. Está dizendo o seguinte, a empresa pode ter até a intenção de ter uma determinada arquitetura. Quando a gente fala arquitetura, ela quer que a arquitetura seja toda descentralizada para poder evoluir várias partes do sistema rapidamente, mas dependendo da forma que ela organize os times, ela não vai ter essa arquitetura descentralizada, porque os times, na verdade, vão ter uma preponderância, eles é que vão acabar pelo jeito pelo fluxo, não sei se é intuitivo ou não, pelo fluxo de informações, esse time vai influenciar e a arquitetura vai acabar refletindo. O próprio time é isso, a lei de Cone. Se você tem só um time que cuida de um banco de dados, vamos pensar assim, não tem jeito, não é cara? Você não pode falar que vai ter um banco de dados descentralizado, nada, porque só tem um time, todo o fluxo de informações é convergido ali, e aí no fundo é como se você tivesse uma arquitetura descentralizada. É isso?

Gabriel Naves: Exatamente, cedo mais literal, a lei diz, organizações que projetam sistemas são limitados a produzir desenhos que são cópias das estruturas de comunicação dessas organizações, ou seja, as estruturas de organização que já existe lá é um fator limitante para o seu sistema, é uma barreira, então se você pensa em times que deveriam se comunicar e eles não se comunicam, produtos que têm um conceito em específico, deveriam ter um conceito específico e não atendem-se, vai fatalmente impactar no seu produto final. Então você tem que entender essas fronteiras, entender que isso impacta, isso é uma coisa de muitas décadas atrás, para pensar na topologia do seu time, e é isso que o livro traz para a gente, uma forma realista, com abordagem, ele numera quais times deveriam existir, como as formas de comunicação entre esses times, tudo isso é baseado nessa lei de Cone, nesse enunciado.

Marcelo Szuster: E é uma lei antiga né cara, é uma lei antiga, Angela, é um mental que vem que a gente está balançando a cabeça?

Angela Duarte: Não, estou balançando a cabeça, só me inquieta assim mesmo. Mas é interessante isso que o Naves falou, né, que eu acho que pelo menos aqui no nosso contexto, isso foi algo que realmente fez muito sentido, porque no ano passado a gente vinha tentando já assim, é que por feeling, né, adaptar a nossa estrutura, estava crescendo, a gente colocou mais times para trabalhar nesses produtos, mas a gente sentia a dificuldade de fazer esses times trabalharem bem, de reduzir a complexidade, porque a gente percebia que muitas vezes, assim, cada time eles tinham um espectro de atuação que era muito grande. Então, quando a gente começou a pesquisar mais, né, e está na literatura que a gente percebeu, talvez aqui tenha uma resposta que vai fazer esse sentido aqui para o nosso contexto, né, e aí foi exatamente essa visão aí, né, de fazer essa manobra reversa de …, que ajudou a gente a estruturar, a reorganizar os nossos times. Então, a gente revisou a arquitetura, detalhou bem ali todo o fluxo de valor, né, e como que fatiou, né, no nosso caso aqui a gente meio que fatiou isso em algumas etapas e aí cada time ficava focado numa determinada etapa, que continha alguns serviços, que estavam envolvidos ali naquela etapa, então isso reduziu bastante a complexidade que eles estavam atuando, né, isso foi para a gente uma grande virada, porque a gente conseguiu ver, os resultados a gente conseguiu ver melhoria na performance do time, né, que conseguia ter um produto de software, né, tem uma frase que é interessante que eu vi há poucos dias, né, software that fits in your head, então acho que foi isso que a gente conseguiu, né, conseguiu fatiar de uma forma que isso coubesse ali dentro da atuação do time, isso trouxe uma melhoria bem grande na performance. 

Marcelo Szuster: Quais são as motivações para que a gente tenha que pensar na topologia do time? Por que não é uma mera questão de colocando times e quantos? Por que que interessa e o que exatamente o autor quer dizer quando ele fala da topologia de times? Gabriel Naves: Show de bola, qual que é a motivação principal? Tão dos conceitos nessa área de tecnologia e informação, desenvolvimento de software mais difundidos é a lei de …. Ela traz para a gente que as formas de comunicação, os caminhos de comunicação que já existem entre os times e nas áreas das empresas, elas vão refletir diretamente na arquitetura e no desenvolvimento de software. Dado isso, dado que se você tem uma área, tanto área A  quanto área B e que o sistema vai comunicar com o sistema B ou o time de infraestrutura A que existe, isso vai impactar na arquitetura, vai impactar no software, vai impactar no seu produto, você deve pensar na topologia do seu time. Então, o que seria a topologia? Quais times vão existir? Como vai ser as formas de comunicação entre elas e eles? E tudo que está ao redor de eles, estão entrando no mundo que ele é …, os domínios e os produtos são …, as coisas vão entrando, mudando o tempo todo. As pessoas também, como fazer isso de uma forma mais huma, onde o time não tenha tanta carga cognitiva, onde as coisas vão ter fluir de uma forma realista.     Marcelo Szuster: Está falando assim, porque é engessado, até anunciar essa lei, ela não é tão clara, acho que para uma forma para as pessoas. Está dizendo o seguinte, a empresa pode ter até a intenção de ter uma determinada arquitetura. Quando a gente fala arquitetura, ela quer que a arquitetura seja toda descentralizada para poder evoluir várias partes do sistema rapidamente, mas dependendo da forma que ela organize os times, ela não vai ter essa arquitetura descentralizada, porque os times, na verdade, vão ter uma preponderância, eles é que vão acabar pelo jeito pelo fluxo, não sei se é intuitivo ou não, pelo fluxo de informações, esse time vai influenciar e a arquitetura vai acabar refletindo. O próprio time é isso, a lei de Cone. Se você tem só um time que cuida de um banco de dados, vamos pensar assim, não tem jeito, não é cara? Você não pode falar que vai ter um banco de dados descentralizado, nada, porque só tem um time, todo o fluxo de informações é convergido ali, e aí no fundo é como se você tivesse uma arquitetura descentralizada. É isso? Gabriel Naves: Exatamente, cedo mais literal, a lei diz, organizações que projetam sistemas são limitados a produzir desenhos que são cópias das estruturas de comunicação dessas organizações, ou seja, as estruturas de organização que já existe lá é um fator limitante para o seu sistema, é uma barreira, então se você pensa em times que deveriam se comunicar e eles não se comunicam, produtos que têm um conceito em específico, deveriam ter um conceito específico e não atendem-se, vai fatalmente impactar no seu produto final. Então você tem que entender essas fronteiras, entender que isso impacta, isso é uma coisa de muitas décadas atrás, para pensar na topologia do seu time, e é isso que o livro traz para a gente, uma forma realista, com abordagem, ele numera quais times deveriam existir, como as formas de comunicação entre esses times, tudo isso é baseado nessa lei de Cone, nesse enunciado. Marcelo Szuster: E é uma lei antiga né cara, é uma lei antiga, Angela, é um mental que vem que a gente está balançando a cabeça? Angela Duarte: Não, estou balançando a cabeça, só me inquieta assim mesmo. Mas é interessante isso que o Naves falou, né, que eu acho que pelo menos aqui no nosso contexto, isso foi algo que realmente fez muito sentido, porque no ano passado a gente vinha tentando já assim, é que por feeling, né, adaptar a nossa estrutura, estava crescendo, a gente colocou mais times para trabalhar nesses produtos, mas a gente sentia a dificuldade de fazer esses times trabalharem bem, de reduzir a complexidade, porque a gente percebia que muitas vezes, assim, cada time eles tinham um espectro de atuação que era muito grande. Então, quando a gente começou a pesquisar mais, né, e está na literatura que a gente percebeu, talvez aqui tenha uma resposta que vai fazer esse sentido aqui para o nosso contexto, né, e aí foi exatamente essa visão aí, né, de fazer essa manobra reversa de …, que ajudou a gente a estruturar, a reorganizar os nossos times. Então, a gente revisou a arquitetura, detalhou bem ali todo o fluxo de valor, né, e como que fatiou, né, no nosso caso aqui a gente meio que fatiou isso em algumas etapas e aí cada time ficava focado numa determinada etapa, que continha alguns serviços, que estavam envolvidos ali naquela etapa, então isso reduziu bastante a complexidade que eles estavam atuando, né, isso foi para a gente uma grande virada, porque a gente conseguiu ver, os resultados a gente conseguiu ver melhoria na performance do time, né, que conseguia ter um produto de software, né, tem uma frase que é interessante que eu vi há poucos dias, né, software that fits in your head, então acho que foi isso que a gente conseguiu, né, conseguiu fatiar de uma forma que isso coubesse ali dentro da atuação do time, isso trouxe uma melhoria bem grande na performance. 

Descrição

Este conteúdo é um corte do nosso episódio: “#200 - "Team Topologies": criando estruturas e times de alta confiança”.

Nele, os crafters da dti digital Gabriel Naves, Arquiteto de Software e Angela Duarte, Tech Manager, explicam o conceito de “Topologia de Times” apresentado no livro “Team Topologies”, de Matthew Skelton e Manuel Pais. Essa, inclusive, é uma técnica bem utilizada que pode virar a chave de um negócio que não está caminhando bem com seus resultados.

Ficou curioso? Então, dá o play!

Quer conversar com Os Agilistas? É só mandar sua dúvida/sugestão na nossa página do Linkedin ou pelo e-mail osagilistas@dtidigital.com.br que nós responderemos em um de nossos conteúdos!

Nos acompanhe pelas redes sociais e assine a nossa newsletter que chega todo mês com os assuntos quentes do agilismo através do site.

See omnystudio.com/listener for privacy information.