Arquitetura Ágil = Design Emergente + Arquitetura Intencional

Metodologias de desenvolvimento tradicionais costumam usar Big-Design-Up-Front (BUFD) para criar uma infra-estrutura de roadmap arquitetônico destinado a atender plenamente as necessidades do futuro sistema. A crença é que um esforço único no início poderia capturar requisitos e planos arquitetônicos suficientes para suportar o sistema para os próximos anos.

No entanto, esta abordagem vem com muitos desafios. Um deles é o delay no início da execução. Um outro desafio surge quando a arquitetura planejada, que possui um conjunto grande de especulações, se encontra com o mundo real. Pouco tempo é suficiente, para que os desenhos se tornem frágeis e difíceis de mudar e eventualmente surge um Big-branch-and-merge para que um novo conjunto de suposições especulativas seja colocado em ação. Para endereçar esses desafios combinamos o design emergente e a arquitetura intencional, impulsionados pela colaboração.

Design Emergente

O princípio 11 do Agile Manifesto é o principal motor por trás do conceito de design emergente: “As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.” As implicações disso são:

  • O design é cultivado de forma incremental por aqueles que estão mais próximos a ele.
  • O projeto evolui de mãos dadas com a feature de negócios. Ele é constantemente testado e ativado por refatoração, TDD e integração contínua.
  • Equipes evoluem rapidamente o projeto de acordo com os requisitos atualmente conhecidos; o projeto é estendido somente conforme necessário para implementar e validar o próximo incremento de feature.

Esta nova prática de design emergente é eficaz no nível de equipe. No entanto, o design emergente por si só é insuficiente para o desenvolvimento de grandes sistemas.

  • Ele pode causar redesenho excessivo para coisas que poderiam ter sido antecipadas.
  • Equipes nem sempre são capazes de sincronizar com as outras, criando assim uma entropia de suposições e divergência de arquitetura.
  • As equipes podem mesmo não estar cientes de algumas das necessidades futuras de negócios maiores; fatores fora de seu alcance que direcionam a necessidade da arquitetura futura.
  • Bases comuns de arquitetura melhoram a usabilidade, extensibilidade, desempenho e manutenção de um sistema de sistemas maior.
  • Novos, padrões do usuário transversais afetam o propósito futuro da arquitetura.
  • Fusões e aquisições direcionam integrações e a necessidade de padronização da infra-estrutura.

Arquitetura Intencional

Portanto, chega um ponto em que o design emergente é uma resposta insuficiente à complexidade do desenvolvimento de sistemas em larga escala. Simplesmente, não é possível para as equipes se antecipar às mudanças que podem muito bem ocorrer fora do seu ambiente. Também não é possível para as equipes individuais entenderem completamente todo o sistema e, assim, evitar a produção de código e design redundante e ou conflitantes. Para isso alguma arquitetura intencional é necessária – um conjunto de iniciativas de arquitectura intencional, planejado para aumentar o design da solução, desempenho e usabilidade e fornecer orientação para o projeto entre as equipes e sincronização da implementação.

Arquitetura é uma colaboração

Claramente, é melhor ter ambos: rápido, controle local do design emergente e uma visão global da arquitetura intencional. A combinação, proporciona a orientação necessária para assegurar que o sistema como um todo tenha integridade conceitual e eficácia. Alcançar o equilíbrio certo de design emergente e arquitetura intencional impulsiona a evolução eficaz do sistema, como mostrado no diagrama desse post. 

O diagrama mostra que eles não são construções independentes. Arquitetura intencional restringe o design emergente, mas a um nível suficientemente elevado de abstração para permitir que as equipes possam se adaptar eficazmente a parte “intencional” para seu contexto específico. Ao mesmo tempo, influências e design emergente corrigem a arquitetura intencional e também alimentam novas ideias para o futuro, centralizando o esforço intencional.

Tal reciprocidade profunda entre design emergente e arquitetura intencional só pode ocorrer como resultado da colaboração entre as equipes ágeis, arquitetos de sistemas e gestores de produto.

Fonte: SAFe

 

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.

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

2 pizzas

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!

IntroDADCoverMedium

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