Para ter sucesso, as equipes de software do Agile devem seguir as mesmas práticas principais que outras equipes ágeis: uma pequena equipe de membros dedicados, com todo o conjunto de habilidades necessárias para desenvolver seu produto, uma compreensão clara dos resultados a serem alcançados e interação frequente com base no feedback do cliente.

No entanto, o desenvolvimento eficaz do software Ágil requer muitas práticas adicionais, específicas do software. Os líderes digitais exibem essas práticas, e empresas de todos os setores podem se beneficiar delas.

Funções de suporte e controle transformadas

Funções de apoio e controle, como jurídico, compliance, finanças e recursos humanos, por vezes podem prejudicar o desempenho da equipe ágil. Normalmente, eles retardam a tomada de decisões e criam gargalos, forçando as equipes ágeis a estender seus prazos.

Os líderes aumentam sua agilidade inscrevendo essas funções no processo de mudança e fazendo com que eles adotem princípios ágeis.

Quatro diretrizes podem reduzir os impedimentos ao desempenho da equipe Ágil.

– Alinhar incentivos: Certifique-se de que a equipe de suporte e controle entenda que a velocidade e a produtividade das equipes ágeis são vitais para os resultados dos negócios e que eles devem acelerar o progresso da mesma enquanto realizam seu trabalho de suporte e controle.

As finanças podem desempenhar um papel importante, movendo-se para um modelo ágil de planejamento e orçamento, que permita a rápida realocação de recursos e o financiamento de equipes ágeis persistentes.

– Desenvolver treinadores em vez de árbitros: Empresas bem-sucedidas mudam a mentalidade e o comportamento das pessoas em funções de suporte e controle.

Em vez de agir como árbitros que julgam se uma ação quebra as regras (muitas vezes, no final do jogo), eles se tornam treinadores que apoiam, educam e orientam equipes ágeis para alcançar seus objetivos.

– Construir relacionamentos: Embora a maioria das equipes ágeis não precise, por exemplo, de um membro da equipe em tempo integral de recursos humanos, atribuir um funcionário de RH a um grupo de equipes pode ser benéfico.

Essa pessoa entenderá melhor o trabalho e os objetivos das equipes, construirá relacionamentos com os membros e ajudará a identificar proativamente necessidades e problemas antes que se tornem impedimentos.

– Coloque guard-rails nas estradas, não bloqueios: A articulação dos limites da função de controle para as equipes ágeis ajuda a aumentar sua autonomia e, ao mesmo tempo, esclarece quando a orientação é necessária.

Também incentiva as equipes a exercer funções de controle – como questões legais e de conformidade – quando antecipam que seu trabalho pode esbarrar nesses guard-rails.

Arquitetura Modular

Muitos sistemas de TI têm arquiteturas monolíticas bem acopladas, em vez de uma arquitetura modular mais moderna — e isso limita a velocidade da mudança.

Em arquiteturas monolíticas, a lógica de negócios pode estar espalhada por muitos componentes, de modo que mudar um componente significa que você terá que mudar outros também.

Isso pode ser aceitável em sistemas menores, especialmente se os desenvolvedores originais (que sabem como a lógica está espalhada) ainda estiverem por perto para ajudar a gerenciá-lo.

Mas à medida que os sistemas crescem e as equipes de desenvolvimento aumentam, isso se torna mais difícil de gerenciar. As equipes que implementam novos recursos têm que modificar vários componentes, e acabam esbarrando nos trabalhos uns dos outros.

Como os componentes são mutuamente dependentes, mudar uma parte do sistema muitas vezes requer testes de regressão total, diminuindo ainda mais a velocidade de entrega.

Algumas organizações abordam esse problema através de programas grandes e caros que buscam uma substituição por atacado de um grupo de sistemas legados.

Esses programas, que normalmente envolvem um corte total e abrupto para um novo sistema – após vários anos de projeto, construção e testes – têm uma taxa de falha de até 90%, de acordo com pesquisas recentes do Grupo Standish.

Uma abordagem melhor para modernizar uma arquitetura monolítica baseia-se em princípios ágeis de mudança passo a passo, guiada pelo valor do negócio.

Um método cada vez mais popular e bem-sucedido que incorpora esses princípios é mover-se incrementalmente para microsserviços, que são componentes independentes, vagamente acoplados e capazes de serem modificados, testados e implantados independentemente dos sistemas que os utilizam.

O primeiro passo para migrar do monolítico para o modular é identificar onde o valor do negócio pode ser desbloqueado, separando um componente do monólito. Estas são geralmente áreas em que as equipes colidem mais, ou áreas que mudam mais frequentemente, ou ainda áreas frágeis ou instáveis.

O próximo passo é descobrir quais componentes são mais fáceis de separar, com base no número de dependências de outros componentes e no grau de dificuldade em separar a lógica do negócio do monólito para colocá-lo no microsserviço.

Em seguida, o trabalho é realizado em pequenos incrementos, priorizados com base nessas duas etapas. As ferramentas de inteligência de software podem ajudar nessas decisões, fornecendo dados rígidos sobre dependências e conexões.

Os microsserviços geralmente são organizados pela experiência do cliente ou capacidade de negócios, em vez de por camada de pilha. Portanto, eles exigem habilidades multifuncionais, uma vez que uma capacidade de negócio pode cruzar vários silos.

Por exemplo, abrir uma conta pode envolver a interface do usuário, fluxos de trabalho, bancos de dados e lógica de negócios, exigindo suporte de uma ampla equipe multifuncional.

Uma vez que um microsserviço é acessado através de uma interface de programação de aplicativos, outras equipes não precisam entender seu funcionamento interno.

Com o tempo, as organizações migram progressivamente a funcionalidade do monólito para os microsserviços, com base no valor do negócio e na dificuldade técnica. Vários fatores determinam quanto de uma aplicação deve ser reestruturada como microsserviços.

Algumas partes de um aplicativo podem ser livres de problemas e requerem alterações apenas raramente, então migração pode não valer a pena para elas.

Em outras situações, o business case justificará o investimento na mudança para uma arquitetura totalmente baseada em microsserviços, possibilitando consistência na estrutura e habilidades da equipe; a facilidade de mudanças e manutenção; e a reutilização de recursos em outras aplicações.