Um desafio muito presente nas empresas é como criar uma estrutura que diminua os gargalos de comunicação, ou seja, como todas as pessoas (e times) devem se comunicar uns com os outros para preencher seus objetivos e metas....
Diariamente estamos evoluíndo nossos sistemas (mudanças incrementais) e projetos, seja em termos de arquitetura, design de código, funcionalidades, refatorações, reestruturações, resoluções de bugs, etc… Mas, o que tudo isso tem em comum?...
Imagine que você venda coisas para seus clientes onlines, frequentemente você será questionado por:
Onde estão minhas coisas?
Ou seja, clientes irão nos contatar para saber mais e investigar uma ordem de compra específica....
Muitas vezes vão haver situações onde a melhor decisão é jogar toda arquitetura e base de código fora para começar reescrever uma nova do zero, porém, em situações e cenários assim é muito comum pessoas se sentirem mal do ponto de vista onde o código que elas escreveram será “condenado” e para várias pessoas jogar código fora é sinal de falha....
Em posts anteriores vimos como organizar e dividir times orientados à contextos: https://blog.matheuscastiglioni.com.br/inverse-conway-maneuver/ e uma pergunta ou problemas que podem surgir com essa aboragem: “Que pessoa ou time pode mexer nos contextos de outro time?...
É comum em desenvolvimento de sistemas nos depararmos com problemas que aparecem e fazer parte do nosso dia-a-dia, por exemplo:
Quando uma pessoa ou time precisa subir um ambiente de QA, é necessário pedir para alguém ou realizar operações e processos manuais (configurações e mais configurações) para ter tal ambiente....
Em um post anterior vimos a famosa Lei de Conway, nele entendemos os problemas que existem quando nos deparamos com tal lei.
Como exemplo do post havíamos visualizado um sistema onde sua arquitetura era dividida em camadas, ou seja, uma camada para o front, outra para o back, uma para o banco de dados e a última de infraestrutura....
Durante o ciclo de desenvolvimento dos nossos softwares podemos e vamos em algum momento nos deparar com desafios, às vezes menos complexos e varias vezes muito complexos....
Construir softwares é algo que já fazemos há muito tempo e é algo ainda dificil e complexo de ser feito. Isso porque variaveis e contextos sempre mudam, assim como uma solução para o desenvolvimento de um aplicativo pode não dar certo para o desenvolvimento de um site ou a arquitetura para uma empresa de vinte anos pode não dar certo para uma empresa de seis meses....