Hoje em dia quando estamos entregando software podem surgir varias questões, por exemplo:
Onde o sistema vai viver? (em termos de nuvem e hospedagem) Como o sistema será distribuído?...
Um problema que em alguns momentos podemos nos deparar é com algo chamado acoplamento, mais especificamente como podemos diminuir os pontos de impactos em nossos serviços?...
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....
As vezes vamos nos deparar com momentos onde precisamos tomar algumas decisões e muitas vezes esses momentos é são complexos, pois:
O que eu devo fazer?...
Um problema comum que vira e mexe aparece é sobre divisão de pessoas e times, mais especificamente falando sobre números, no caso: “Quantas pessoas deve compor um time”?...
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....