A liberdade na agilidade

Vamos mergulhar no mundo do Disciplined Agile (DA), uma abordagem híbrida e agnóstica que combina centenas de estratégias e práticas do Agile, Lean e tradicionais para orientar você a encontrar o seu WoW (Way of Working) a melhor maneira para seu time ou organização trabalhar. Esse post está recheado de links que direcionam para assuntos específicos no site do Disciplined Agile. Tem muito conteúdo bacana e útil lá. Aproveite!

DA é sobre ser pragmático e reconhecer que existem ótimas ideias tanto na comunidade Agile quanto na comunidade tradicional. Devemos mostrar um pouco de humildade e respeitar pelo fato de que a comunidade tradicional construiu muita coisa boa e tinha algumas ideias ótimas.

A verdadeira agilidade vem da liberdade, não de um único framework

O DA é um Toolkit e não um framework! É uma caixa de ferramentas que permite a você escolher e evoluir uma forma de trabalhar adequada ao seu propósito, que seja a melhor para você, dada a situação que está enfrentando. Em vez de prescrever um conjunto de “melhores práticas”, o DA ensina como escolher e evoluir um WoW baseado em praticamente todos os frameworks mais populares, incluindo XP, Scrum, Kanban e SAFe.

Scott Ambler, um dos criadores do DA, enfatiza que é preciso permitir que os times evoluam seu ciclo de vida ao longo do tempo. Por exemplo, um time que começa com o ciclo de vida ágil (Agile Lifecycle) baseado em Scrum pode começar a adotar maneiras mais enxutas (Lean Lifecycle) de trabalhar, com práticas do Kanban e práticas de integração contínua e implantação contínua (Disciplined DevOps), e eventualmente evoluir para um ciclo de vida de entrega contínua ágil ou lean (Continuous Delivery Agile Lifecycle / Continuous Delivery Lean Lifecycle).

Ele reforça que, DA é sobre fazer escolhas inteligentes e experimentar práticas para ver o que funciona melhor para o time e que eles experimentem uma prática por algum tempo para ver se ela realmente funciona bem para eles.

Por que ágil disciplinado?

Sobre isso, Scott Ambler, destaca que o ágil disciplinado é necessário porque cada time é único e enfrenta uma situação única, portanto, precisa ter sua própria maneira de trabalhar e as organizações precisam permitir e habilitar os times, para obter a verdadeira agilidade.

O DA começa onde você está. Sua organização fez um grande investimento em sua maneira atual de trabalhar (WoW), e com o DA você pode evoluir sobre esse investimento.
O DA permite que você melhore cada vez mais. O DA está focado em ajudá-lo a aprender e transformar sua organização em uma organização que aprende, através da melhoria contínua guiada. Ao invés de simplesmente fornecer uma coleção de “melhores práticas” que podem não ser aplicáveis ao contexto da sua organização.
O DA fornece uma base sólida para a agilidade organizacional. Pessoas e times em toda a sua organização, independentemente da função de negócios, podem se beneficiar de orientações diretas para otimizar seus processos. O DA aborda toda a empresa, não apenas o desenvolvimento de software.
A maneira de pensar ágil disciplinada do DA, é capturada na forma de princípios, promessas e diretrizes. Os agilistas disciplinados acreditam nesses princípios, por isso adotam esses comportamentos e seguem essas diretrizes de maneira sensível ao contexto.

Verdadeira agilidade em escala

Os frameworks ágeis em escala tendem a ter uma visão bastante estreita do que significa agilidade em escala, escolhendo focar na agilidade de um programa para o desenvolvimento de um produto baseado em software ou na aplicação da agilidade em todos (ou pelo menos na maioria) dos times de software de sua organização. Embora esse seja um bom ponto de partida, ele claramente não é suficiente. O que dizer dos times que não estão focados no desenvolvimento de software? E os times que estão em situações mais simples?

O contexto importa

O Disciplined Agile (DA) fornece orientações diretas para ajudar as organizações a otimizar seus processos de maneira sensível ao contexto, fornecendo uma base sólida para a agilidade dos negócios, fornecendo maneiras de avaliar os fatores que impactam a escalada da agilidade no contexto da sua organização.

Fonte: A Solid Foundation for Business Agility with Disciplined Agile https://www.pmi.org/disciplined-agile/

Para saber mais: Faça os cursos oficiais de Disciplined Agile com a JUMP http://jump.bhz.br

Architecture Owner

Outro dia eu estava conversando com um desenvolvedor super bom de serviço. Ele me disse que acha “waste” essa diversidade de práticas e processos de desenvolvimento ágil. Ele tem muita dificuldade em reunir e visualizar todas as práticas e métodos funcionando juntos porque veio de um contexto muito técnico onde o que tinha de ser feito era apenas escrever código e entregar o software. Ele me disse que gostaria de saber, por exemplo, o que o arquiteto de software faz. 🙂 Eu achei sensacional a duvida dele e expliquei rapidamente o papel do arquiteto, mas isso ficou na minha cabeça e resolvi fazer esse post.

O papel de arquiteto de software ágil hoje está bem mais consolidado. O Disciplined Agile Delivery define o papel do Architecture Owner e as principais responsabilidades desse papel são:

Guiar a criação e evolução da arquitetura da solução.
Mentor e o Coach dos membros do time nas práticas e questões de arquitetura.
Entender a direção arquitetural, os padrões da organização e garantir que o time esteja aderente à eles.
Garantir que o sistema será suportado de maneira fácil encorajando um design adequado e tocando as refatorações necessárias para garantir um bom design.
Garantir que o sistema seja testado e integrado frequentemente.
Tem a palavra final sobre as decisões técnicas, mas deve engajar o time nas decisões e não dita-las.
Lidera o esforço de visualização inicial da arquitetura.
Trabalhar junto ao time de arquitetura corporativa (se ele existir).

No ciclo de vida básico do DAD existe um marco específico para provar a arquitetura o mais cedo possível na fase de construção. É uma forma do arquiteto mitigar os riscos técnicos e um checkpoint de governança para sinalizar a gerência sênior e outros stakeholders as decisões e questões técnicas.

Por que você deveria considerar Microservices em um próximo projeto?

Para responder essa pergunta vou assumir que você desenvolve aplicações monolíticas. Os “monolitos” são o padrão “de fato” para a construção de aplicações de negócio hoje em dia. Você vai argumentar que as aplicações que você cria tem um alto-nível de modularização com alta-coesão e baixo acoplamento e que você desenvolve serviços e tal. Tudo bem, mas você tem de concordar que não é comum quebrar a aplicação em diversos serviços, implantáveis separadamente e manter essa prática em produção. Isso é novidade. Concorda?

Bom, se você já passou pelo desenvolvimento de uma aplicação grande em Java EE ou .NET, em algum momento já passou pelos seguintes problemas:

A produtividade caiu ao longo do projeto. Sua aplicação se tornou difícil de manter a medida que a aplicação cresceu. Isso resultou em ciclos longos de build para implantar novas funcionalidades ou mesmo novos serviços, e você não conseguiu fazer muito mais rápido.
O deploy era “tudo ou nada”. Os pacotes grandes forçaram a construção, testes e deploy, mesmo em uma pequena mudança. Os CRUDs, as transações mais críticas e os relatórios ficaram todos no mesmo implantável e na mesma infraestrutura;
A escalabilidade também foi “tudo ou nada”. Não dava para escalar apenas parte da aplicação. Até dava mas nem foi cogitado isso;
O Onboarding de novos desenvolvedores foi difícil. Os novos integrantes do time tiveram de baixar todo o código e aprender a lidar com a aplicação inteira.
O gerenciamento de dependências de código ficou complexo.
O projeto ficou preso a uma única opção de tecnologia.

Para atacar estes problemas os caras pensaram em modularização e particionamento da aplicação em pequenas partes que chamaram de micro-serviços. Cada micro-serviço funciona como uma aplicação independente, implantável separadamente, com interface de serviço baseada em REST agnóstica em relação à tecnologia. Isso possibilita uma liberdade de escolha de tecnologia de implementação. Com essa liberdade você pode implantar serviços em plataformas diferentes e escalar de forma independente também.

Mas não existe almoço grátis… atenção ao desempenho. Você vai ter de monitorar o tempo de resposta e o uso de recursos e é importante ficar atento desde o início. Serviços distribuídos tendem a ter problemas em função da latência, por exemplo. Atenção ao design dos serviços. Evite as dependências entre serviços e a necessidade de orquestração para conseguir que o deploy fique realmente independente, senão vai acabar tendo deploy “tudo-ou-nada” do mesmo jeito. 🙂

Mas voltando aos benefícios… outra liberdade que você tem com esse modelo é “rampar” times diferentes para cada serviço. Isso te dá a possibilidade de paralelizar ou adiar a entrada de um novo time de acordo com o melhor momento para investimento. Lembrando que a métrica do time de “2 pizzas” vale aqui e também a abordagem DevOps onde o time que desenvolve também é responsável por manter e acompanhar o serviço em produção.

As vantagens dessa abordagem estão sendo experimentadas ainda, mas resultados positivos tem sido apresentados em conferências. Acho que você deveria considerar para tornar os times mais capazes de responder rapidamente às novas necessidades de negócio. A abordagem de desenvolvimento de aplicações monolíticas gera respostas mais lentas. Microservices promete entregas mais freqüentes e mais rápidas. Isso permite feedback mais rápido dos usuários e ajustes nos investimentos por parte do time de negócios.

Enterprise Agile

Como ponto de partida o Scrum é um excelente método ágil. No Brasil ele abre as portas das empresas para a agilidade. Isso se dá pela sua grande difusão entre os profissionais de gerenciamento de projetos nas áreas de TI. Agora, quando as empresas começam a levar o agile para um patamar corporativo o Scrum sozinho se mostra insuficiente.

Na prática, para uma abordagem corporativa é necessário recorrer a outros métodos para preencher os gaps de processo que o Scrum não trata. É aí que surgem as dificuldades. Quando as empresas começam a olhar para outros métodos surge o conflito de terminologias e a sobreposição de conceitos. Isso gera uma certa confusão na hora de definir e instalar esse novo processo. Faltam elementos para integrar o agile com as estratégias de governança das empresas.

Nesse contexto surgiu o Disciplined Agile Delivery (DAD). O DAD é uma abordagem híbrida que faz a “costura” de diversos métodos no formato de um framework de decisão. Esse framework te ajuda a definir o processo mais adequado de acordo com o contexto e a cultura organizacional da sua empresa. Diferente do Scrum, o DAD considera que existe um ecossistema corporativo e ele não pode ser ignorado.

O DAD estende o Scrum com estratégias do Extreme Programming (XP), Agile Modeling (AM), Unified Process (UP), Kanban, Lean Software Development, SAFe entre outros. Ele aborda práticas técnicas como Continuous Delivery, TDD, arquitetura, modelagem e também documentação e governança, fornecendo alternativas que aumentam a chance de você adotar estratégias que funcionem no seu contexto. Se você tem interesse em DAD entre em contato comigo. Vamos bater um papo.

Para mais informações acompanhe o blog Disciplined Agile Delivery. Para saber mais sobre treinamentos e certificações acesse o site do Disciplined Agile Consortium.

2 Pizzas = 1 Team

Regra de ouro para dimensionar times ágeis.

Regra das duas pizzas: O Time deve ter o número de pessoas que possa ser alimentado com duas pizzas.

Assim, o time deve ter 7 mais ou menos duas pessoas, ou seja, de 5 a 9 pessoas. A razão para essa regra é que times pequenos facilitam a comunicação entre os seus membros. Agora, se o time for incluir o João Vitor, então pode pedir uma pizza só pra ele. 🙂

Essa regra é atribuída a Jeff Bezos, fundador da Amazon.

Novo livro sobre DAD: Introduction to Disciplined Agile Delivery

Você está procurando um livro enxuto, de poucas páginas, de fácil leitura, que mostra como aplicar o DAD em situações típicas do dia-a-dia? Achou! 🙂

Acaba de ser lançado o livro Introduction to Disciplined Agile Delivery

Esse livro de 102 páginas é para aqueles que querem conhecer a essência do DAD, o que ele é e o que não é e quais os seus benefícios.

Sobre o DAD, ele é gratuito para uso e apesar de ter sido desenvolvido originalmente na IBM agora é mantido pelo Disciplined Agile Consortion. No DAC você encontra todas as informações sobre o programa de certificação em DAD.

Boa leitura!

A Small Agile Team´s Journey from Scrum to Continous Delivery.
by Mark Lines and Scott Ambler

Compartilhe isso:

Compartilhe isso:

Compartilhe isso:

Compartilhe isso:

Compartilhe isso:

Compartilhe isso: