Uma pequena visão da selva ágil

Neste texto você terá uma pequena visão da selva ágil. Apesar de já termos feito uma vez aqui um Benchmark Ágil1, hoje vamos olhar um pouco mais à fundo.

Há alguns anos, você poderia dizer “Scrum é ágil” e perguntar “ágil é Scrum? Agora sabemos que há mais carne nos ossos. Neste momento, existem mais de cinquenta frameworks ágeis conhecidos e menos conhecidos disponíveis.

Para obter uma primeira impressão dos diferentes frameworks, tento trazer alguma estrutura na selva para métodos e frameworks. Na Figura 1, posiciono os frameworks ágeis mais conhecidos em uma estrutura. As estruturas estão posicionadas dentro das seções “Programas/projetos únicos” ou em “Business as usual” / por tempo indeterminado, ou ambos.

Fig. 1 Estrutura de visão geral ágil 2

Por outro lado, as estruturas estão agrupadas em nível de equipe, produto ou programa e portfólio. Nas caixas azuis escuras na Figura 1, vemos estruturas ágeis que são aplicáveis ​​apenas em organizações com foco em TI.

Todas as outras estruturas podem ser usadas em organizações de TI e não orientadas para TI (de cor azul claro).

Eu não mapeei todos os frameworks conhecidos nesta figura, e para ser honesto, eu acho que há muita duplicação e provavelmente os drivers comerciais também desempenham um papel para ‘desenvolver’ o próximo garoto no bloco sem valor agregado em comparação com os quadros existentes.

O nível de equipe, incluindo Scrum e Kanban, é aplicável tanto no desenvolvimento e nas operações de produtos e serviços orientados a TI e não-orientados a TI.

O nível de engenharia se concentra especificamente no desenvolvimento de produtos orientados a TI.

As estruturas temporais de projetos e programas são adequadas para TI e não TI. As estruturas permanentes (segmentadas por produto e por equipe) se concentram especificamente no desenvolvimento de produtos e TI, e as estruturas voltadas para os negócios ajudam as organizações a aumentar sua agilidade.

Nível de equipe

Se começarmos no nível de equipe da Figura 1, então, vemos, claro, o Scrum, conforme descrito por Ken Schwaber e Jeff Sutherland em seu Guia do Scrum.

Além disso, você verá estruturas como Kanban (conforme descrito no Guia Kanban para equipes Scrum3), Scrumban e DevOps ou BusDevOps4.

O nível de equipe pode ser usado tanto no ambiente de TI quanto no ambiente de não TI. Neste nível de equipe também podemos posicionar os seguintes frameworks de TI: Crystal family5 (desenvolvido por Alistair Cockburn com  Crystal Clear e Crystal Yellow, Orange, Orange Web, Red, Maroon, Diamond e Sapphire) Desenvolvimento Rápido de Aplicativos6 (RAD desenvolvido por James Martin), Desenvolvimento Adaptativo de Software7 (ASD por Jim Highsmith, Sam Bayer), Processo Unificado Ágil8 (AUP) como uma versão simplificada do RUP (Unified Process Rational9que foi substituído pelo Desenvolvimento Ágil Disciplinado10 (DAD) que foi substituído pelo Ágil Disciplinado11 (DA).

Se você deseja oferecer qualidade como uma equipe dentro do mundo de TI, apenas seguir essas estruturas não será suficiente. Para melhorar a qualidade e minimizar a dívida técnica (por exemplo, código ineficiente devido a muitos ajustes iterativos), você pode fazer uso da eXtreme Programming12 (XP, desenvolvida por Kent Beck, Ward Cunningham e Rom Jeffries) com Programação Pareada, Desenvolvimento Dirigido por Testes de Aceitação13 (ATDD), Desenvolvimento Orientado a Testes14 (TDD), Desenvolvimento Dirigido por Comportamento15 (BDD), Desenvolvimento Dirigido por Recursos16 (FDD), Desenvolvimento Orientado a Exemplo17 (EDD), Design de Experiência do Usuário18 (UX), Integração Contínua e Implantação Contínua. O AgileBA19 fornece as técnicas para realizar análises de negócios.

A modelagem ágil (AM) é uma metodologia para modelagem e documentação de sistemas de software baseados nas melhores práticas.

É uma coleção de valores e princípios que podem ser aplicados em um projeto de desenvolvimento de software (ágil).

Existem várias práticas principais: documentação, documentar continuamente, documento finalizado, especificações executáveis, informações de fonte única, participação ativa de partes interessadas, previsão de arquitetura, ferramentas inclusivas, modelagem de iteração, modelagem look-ahead, storming de modelo , modelos múltiplos, requisitos priorizados, previsão de requisitos.

Scrum ou Kanban?

Quando as equipes começam a trabalhar com o Agile, o Scrum é frequentemente escolhido. Uma escolha óbvia, mas a questão é se esta é sempre a escolha certa. Em um blog de Roman Pichler20o link foi feito com a fase de vida de um produto.

Durante a primeira fase do ciclo de vida de um produto comercial, em que o produto comercial é finalmente colocado no mercado pela primeira vez, a incerteza é alta, e o foco está na entrega pontual do primeiro produto pronto para o mercado.

Um prazo foi definido e essa data deve ser cumprida. Durante esta fase, o foco de toda a equipe está na entrega de um produto comercialmente viável. Esse desenvolvimento é perfeito para o Scrum com sua abordagem iterativa, sendo capaz de lidar com a incerteza e trabalhar em conjunto no resultado (o produto comercial).

Opcionalmente, um segundo lançamento pode ocorrer com um conjunto de funcionalidades importantes, para que, eventualmente, um produto maduro seja colocado no mercado.

Durante o curso mais longo do ciclo de vida do produto, vemos que a quantidade de incerteza e as alterações solicitadas diminuem. Neste momento você pode fazer bom uso do Kanban.

Em um fluxo contínuo, as Estórias de Usuário podem ser coletadas, desenvolvidas e implementadas uma a uma por membros individuais da equipe.

Se observarmos a transferência muitas vezes difícil para ambientes de produção, o tempo de colocação no mercado pode ser reduzido organizando adequadamente a transferência e reduzindo o número de erros de transferência quando as equipes de desenvolvimento e produção são mescladas e o teste e a implantação de integração são automatizados (Integração Contínua e Implantação Contínua CI/CD). Dessa maneira, uma equipe de DevOps é criada.

Scrumban é a combinação de Scrum e Kanban. No primeiro caso, foi planejado como um modelo de transição para mudar de Scrum para Kanban e deixar que a equipe experimentasse os conceitos de Lean e Kanban.

Hoje em dia é uma abordagem em que a equipe optou por trabalhar de acordo com o Scrum com Sprints, mas usar o sistema Kanban para continuamente visualizar e melhorar seu método de trabalho para otimizar o fluxo de unidades de trabalho (por exemplo, User Stories).

Escalar para o nível do produto ou do programa

Para poder usar uma maneira ágil de trabalhar em uma organização de algum tamanho, apenas ter equipes individuais ágeis não é suficiente. A maneira ágil de trabalhar precisa ser  escalada e, quando possível, o alinhamento geral precisa ser institucionalizado.

Para institucionalizar a coordenação, o gerenciamento de dependências e a integração entre as diferentes equipes ágeis permanentes dentro do lado “run-the-business” / “business-as-usual”, existem vários frameworks disponíveis, incluindo:

  • O Nexus, conforme descrito no The Nexus Guide21, é uma estrutura para o desenvolvimento de iniciativas de desenvolvimento de produto ou software com três a nove equipes do Scrum, em Sprints de até trinta dias. Nexus é a resposta de Ken Schwaber, um dos fundadores do Scrum, à escalabilidade do Scrum. Requer mais do que apenas a vontade e o comportamento ágil das diferentes equipes Scrum para trabalhar juntas para entregar um produto integrado. O Nexus é baseado e baseia-se no Scrum e nas regras e funções formuladas no The Scrum Guide. Podemos posicionar o Nexus na equipe e nos níveis de programa do SAFe, mas ele não oferece disposições sobre o nível de portfólio.
  • Scrum at Scale22 ( S@S , desenvolvido por Jeff Sutherland e Alex Brown) é uma estrutura modular. O ponto de partida em S@S é que uma estrutura abrangente de tamanho único não é possível, mas que toda vez que precisamos examinar a escala dos princípios básicos do Scrum. A estrutura pode ser adaptada para sua própria organização, adicionando os módulos S@S necessários. S@S baseia-se no conhecido framework Scrum. Por analogia com o Nexus, você poderia dizer que S@S é a resposta de Jeff Sutherland, ao lado de Ken Schwaber, o outro fundador do Scrum, sobre a escalabilidade do Scrum.
  • Large-Scale Scrum23 LeSS, desenvolvido por Craig Larman e Bas Vodde) é um framework ágil com regras, baseado em princípios e fazendo experimentos. A LeSS Company oferece uma base de conhecimento de acesso livre (less.works) contendo a abordagem integrada, princípios, descrições de processo, definições, funções, exemplos, etc., para desenvolvimento de produtos em larga escala, principalmente relacionados a TI. A transparência também é um conceito-chave no LeSS. A primeira versão data de 2005 e desde então, o trabalho está sendo feito constantemente sobre o uso e desenvolvimento do LeSS.
  • O Scaled Agile Framework24 (SAFe, desenvolvido por Dean Leaffingwell) é uma estrutura para permitir o escalonamento de equipes ágeis a fim de criar sistemas melhores, criar maior envolvimento dos funcionários e fazer uso de considerações de custo corretas. Esta é a missão da organização ágil escalonada e do fundador da SAFe, Dean Leffingwell. A organização ágil escalada oferece uma base de conhecimento que é acessível gratuitamente a todos com uma abordagem integrada na forma de descrições de processos, definições, funções, exemplos, etc. para o desenvolvimento de produtos Lean / Agile. O SAFe é baseado em cinco competências principais: Lean-Agile Leadership, Team e Technical Agility, DevOps e Release on Demands, Business Solutions e Lean Systems e gestão de Lean Portfolio.

A figura 1 (veja o bloco ‘Business as usual’ / indefinido), faz uso de uma divisão entre as metas de produto e equipe, ou seja, com base na cooperação, se necessário, das equipes ou não.

Ou, em outras palavras, as equipes individuais podem trabalhar de maneira autônoma (foco da equipe) ou precisam trabalhar juntas para entregar um produto novo ou modificado (foco no produto).

Todas as estruturas mencionadas referem-se a exemplos em que várias equipes trabalham em um único produto ou fluxo de valor complexo (estruturas de produtos específicos).

Não é visível na figura várias estruturas que fazem uma distinção entre produtos onde você está trabalhando em conjunto com um máximo de nove equipes (no total a “equipe de equipes” não deve exceder o número de Dunbar de 125-150 pessoas) e uma “equipe de equipes de equipes” (por exemplo, soluções grandes SAFe, Nexus +, LeSS Enorme).

O outro grupo diz respeito a estruturas para dar suporte a departamentos de TI que precisam manter dezenas ou centenas de aplicativos ou serviços, em que as dependências entre as equipes são mínimas (estruturas de múltiplas equipes direcionadas).

Aqui o modelo Spotify25 (desenvolvido por Henrik Kniberg, Anders Ivarsson e Joakim Sundén) pode ser posicionado, mas também o Scaled Agile Lean Development (ScALeD26, desenvolvido por Peter Beck, Markus Gartner, Christoph Mathis, Stefan Roock e Andreas Schliep).

Para ambos os grupos, existem interfaces essenciais entre as equipes em áreas como integridade de dados, segurança e arquitetura, que podem ou não exigir coordenação durante a implementação de mudanças.

Além disso, há muitos frameworks menos conhecidos que podem oferecer suporte em nível de produto, incluindo Agile Integration Framework (AIF)27, Agile Team Portfolio Management (AgileTPM), AgilePath, Continuous Agile, Disciplined Agile (DA), Enterprise Scrum, Enterprise Agility, FAST Agile, RAGE, Surge, XSCALE, Industrial XP, e AgileDS.

No lado esquerdo da figura 1, vemos os projetos e programas únicos como parte de “mudar o negócio”. Aqui é feita uma distinção entre projetos e programas.

Dentro do bloco do projeto, vemos três estruturas e / ou métodos, todos os três dos quais são um desenvolvimento adicional das estruturas de gerenciamento de projetos mais tradicionais:

  • Agile Project Management28 (AgilePM , que é derivado do DSDM29);
  • PRINCE2 Agile30  (derivado de PRINCE2 de AXELOS)
  • PMI-ACP31  (além do PMBOK Guide of PMI)
  • Project Half Double32  (Project Half Double é executado por uma comunidade de profissionais de gerenciamento de projetos dedicados que são apaixonados pelo que fazem)
  • O Agile Project Management33 (APM), não mencionado na figura, pode ser posicionado aqui também.

No lado do programa, vemos:

  • Managing Successful Programs 34 ( MSP da AXELOS) que é muito ágil em si mesmo com o crescimento passo-a-passo (via tranches) em direção ao objetivo pretendido (e se conecta ao PRINCE2 (Agile)) e
  • AgilePgM35  (Agile Program Management of Agile Business Consortium) que se conecta ao AgilePM por um lado e é comparável ao MSP por outro.

Praxis cobriu os níveis de portfólio, programa e equipe. Praxis36 é um framework gratuito para o gerenciamento de projetos, programas e portfólios (baseado no PRINCE2, MSP, MoP, AgilePM e outros frameworks). Inclui um corpo de conhecimento, metodologia, estrutura de competência e modelo de maturidade de capacidade. O framework é suportado por uma base de conhecimento de recursos e uma enciclopédia.

O Disciplined Agile (DA) abrange projetos e programas únicos, bem como o desenvolvimento de produtos como de costume. O kit de ferramentas DA é um kit de ferramentas de decisão de processo que descreve como as equipes ágeis de desenvolvimento de software, DevOps, TI e negócios trabalham em configurações de classe empresarial.

Nível de gerenciamento de portfólio

O gerenciamento de portfólio tradicional foca em ‘mudar o negócio’. Nos capítulos anteriores, ficou claro que mais e mais mudanças estão sendo tratadas pela organização, ou seja: pelas equipes ágeis permanentes.

Isso significa que o gerenciamento de portfólios deve agora fornecer uma visão geral do que ocorre em ‘executar negócios’ / ‘business as usual’ para que sejam implementadas iniciativas de mudança.

Estruturas de portfólio existentes, como Gerenciamento ou Portfólios ( MoP37  da AXELOS) e Standard for Portfolio Management38( SfPfM do PMI) cobrem apenas a parte de mudança de negócios.

O Agile Portfolio Management39 (AgilePfM da ABC) abrange ‘executar os negócios’ / ‘business as usual’ e ‘mudar o negócio’.

Além disso, há vários frameworks ágeis que também incluem um componente de gerenciamento de portfólio:

  • A SAFe oferece uma camada de gerenciamento de portfólio para controlar as equipes permanentes de equipes ‘run the business’ / ‘business as usual’.
  • O Disciplined Agile (DA) oferece um processo de portfólio no qual, além dos projetos, são levados em consideração vários aspectos de “execução de negócios” / “business-as-usual”, como as equipes permanentes e a gerência operacional de soluções de TI existentes.
  • Scrum @ Scale contém módulos visão estratégica e desenvolvimento organizacional para o qual o gerenciamento de portfólio pode ser relacionado.
  • O Spotify também fornece sua própria abordagem de gerenciamento de portfólio com seu planejamento estratégico.
  • O AgilePfM usa alguns conceitos básicos de um hub de inovação, um processo de portfólio ágil, a maturidade das iniciativas dentro do portfólio, bem como horizontes para um portfólio ágil.

No momento (jan ‘2019) não há estruturas de gestão de carteira maduras que incluem’ mudar o negócio ‘, bem como’ executar o negócio ‘/’ business as usual ‘.

O AgilePfM foi lançado pelo Agile Business Consortium (anteriormente DSDM Consortium) como parte de seu Agile Business Change Framework.

No entanto, está ficando cada vez mais claro que os princípios globais de gerenciamento de portfólio ágil são baseados em frameworks como SAFe, Agile PfM e Disciplined Agile.

Nível de negócio

O foco do negócio fornece estruturas para aumentar a agilidade dos negócios, alterando a mentalidade de todos os funcionários da organização.

O que significa trabalhar de forma ágil?

Como podemos ter certeza de que os valores e princípios do Manifesto Ágil são compreendidos e aplicados, e os valores do Scrum (coragem, foco, comprometimento, respeito e abertura) são parte do que estamos fazendo?

Se a mentalidade correta estiver em vigor, será muito mais fácil implementar uma estrutura ágil. Na figura 1, as seguintes estruturas são mencionadas:

  • O Open Space Agility (OSA) é uma técnica segura, pragmática e repetível para obter uma adoção Agile rápida e duradoura. Funciona com o framework que você está usando atualmente, e o OSA pode ser adicionado a qualquer momento. O OSA é usado para envolver ativamente o maior número de funcionários possível em seu programa Agile.
  • O AgileSHIFT (desenvolvido pela AXELOS) é um framework que prepara as pessoas para mudanças transformacionais, criando uma cultura de agilidade corporativa. A estrutura AgileSHIFT ajuda as organizações a passar por uma mudança de transformação, a adotar uma mentalidade de ‘sobreviver, competir e prosperar’. Isso ajudará a preencher a lacuna entre o estado atual e o destino (o Delta no AgileSHIFT), adotando uma variedade de abordagens ágeis, estruturadas e híbridas em toda a organização. A grave divisão existente entre “administrar o negócio” e “mudar o negócio” desaparecerá.
  • Agility scales (desenvolvidas por Jurgen Appelo) ajudam as organizações a alcançar a agilidade em escala de baixo para cima – com evidências mensuráveis ​​de transformação organizacional.
  • Lean Startup (desenvolvido por Eric Ries) é uma metodologia para o desenvolvimento de negócios e produtos, que visa encurtar os ciclos de desenvolvimento de produtos e descobrir rapidamente se um modelo de negócio proposto é viável; isso é conseguido adotando uma combinação de experimentação orientada por hipóteses de negócios, usando um produto viável mínimo (MVP), lançamentos de produtos iterativos e aprendizado validado.
  • Holacracy40 (desenvolvido pelo fundador da Ternary, Brian Robertson) é um método de gestão descentralizada e governança organizacional, no qual a autoridade e a tomada de decisões são distribuídas por uma holarquia de equipes auto-organizadas, em vez de serem investidas em uma hierarquia gerencial.

Não mencionado na figura:

  • Goal Driven Agile (GDA) baseia-se em três pilares principais: autonomia, alinhamento e melhoria estruturada. É uma estrutura muito simples e consiste em apenas uma estrutura de base, o diamante, cinco papéis e dez blocos de construção.

Conclusão

Já existem mais de 50 frameworks ágeis e conforme evoluímos esse número ainda está crescendo.

A figura pode ajudá-lo em seu processo de seleção de framework ágil, mas não pode ser visto com frequência suficiente, não atue dogmaticamente, veja uma estrutura não como uma panaceia que possa ser implementada imediatamente.

O senso comum também ajuda a obter mais agilidade e, provavelmente, o melhor caminho para se tornar mais ágil é dividir seus produtos e serviços em partes autônomas menores e tê-los suportados por uma equipe individual.

E você conhece mais algum framework não listado?

Referências

  1. Benchmark Ágil
  2. Esta imagem é baseada em uma versão mais simples no livro Scaling Agile in organizaties(Portman, 2017)
  3. Kanban Guide for Scrum teams
  4. BusDevOps
  5. Crystal Methods
  6. Rapid application development
  7. Adaptive Software Development
  8. Agile Unified Process
  9. IBM Rational Unified Process
  10. Disciplined Agile Development
  11. Disciplined Agile Development
  12. eXtreme Programming
  13. Acceptance test–driven development
  14. Test-driven development
  15. Behavior-driven development
  16. Feature-driven development
  17. Example Driven development
  18. User Experience
  19. AgileBA
  20. Pichler, Roman, ‘Is Scrum right for your product?’, 19 de setembro de 2016, veja: www.romanpichler.com
  21. The Nexus Guide
  22. Scrum@Scale
  23. LeSS
  24. SAFe
  25. Spotify Model
  26. ScALeD
  27. Application Integration Framework (AIF)
  28. AgilePM
  29. DSDM
  30. PRINCE2 Agile
  31. PMI-ACP
  32. Project Half Double
  33. APM
  34. MSP
  35. AgilePgM
  36. Praxis Framework
  37. MoP®(Management of Portfolios)
  38. Standard for Portfolio Management
  39. AgilePfM
  40. Holacracia(Holacracy)

Comentários

Deixe uma resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

%d blogueiros gostam disto: