Agile Methods

Visão Geral

Concentra-se fortemente em responder rapidamente aos clientes com prazos de produção curtos e prazos de entrega de design. Possui forte relacionamento com o Lean Manufacturing, porém com desenvolvimento e processos mais flexíveis. Pode ser usado com Lean ou um aprimoramento do Lean. Parece estar relacionado ao aumento da capacidade de prototipagem rápida de impressoras 3D. Meu lado cínico me diz que é apenas Lean com impressoras 3D, que recebeu um nome Agile para soar sofisticado e moderno.

Agile Manufacturing

Ano de Criação / Primeiro Uso

?

Uso no mundo

n/a

Princípios

4 elementos-chave:

1. Design de produto modular
2. Tecnologia da Informação / Automação
3. Parceiros Corporativos
4. Cultura do Conhecimento

Visão Geral

Uma mistura de duas ou mais estruturas Agile.  Scrum e XP são amplamente usados ​​juntos (o que parece que só faria XP). O objetivo é experimentar e obter as melhores práticas de cada estrutura.  Também chamado de Agile Blended
*Tecnicamente, Scrumban é um híbrido Agile-Agile.

Gerenciamento de projeto eficaz: tradicional, ágil, extremo, híbrido
O que é Hybrid Agile, afinal?

Ano de Criação / Primeiro Uso

?

Uso no mundo

20%

Papéis

Depende dos frameworks

Visão Geral

“Uma mistura de práticas de gerenciamento de projetos Agile e Predictive. Às vezes referido apenas como “Agile” ou “Scrum”.

*Tem sido minha experiência que a maioria das pessoas que afirmam fazer Scrum, na verdade, fazem uma abordagem Híbrida Agile-Waterfall.
Scrum é o maior framework em uso relatado.
É minha convicção que este é o maior em uso. Eu estive em mais do que algumas equipes “Scrum” com um Gerente de Projeto e sem Sprints.”

Combinando Agile e Waterfall

Waterfall Hybrid

Abordagem híbrida Agile/Waterfall

Ano de Criação / Primeiro Uso

?

Uso no mundo

20%

Papéis

Normalmente, um gerente de projeto e uma equipe de apoio preditiva / cascata típica

Visão Geral

Uma abordagem não dogmática. Não é uma estrutura, mas um conjunto de princípios que se opõem ao Manifesto Ágil. A filosofia por trás disso afirma que a escolha de uma estrutura pode realmente prejudicar a agilidade, mas pode não ser a melhor coisa a se fazer.

Agnóstico Ágil

Pensando Além do Manifesto Ágil – Agilidade Agnóstica

Ano de Criação / Primeiro Uso

2017

Uso no mundo

0,1% 

Princípios

12 Princípios da Agilidade Agnóstica:

1. Colocar meu cliente em primeiro lugar, tornando-o independente.
2. Para fazer o meu melhor, complementando a teoria com a experiência prática.
3. Para adaptar a agilidade ao contexto.
4. Para entender as restrições que impedem e trabalhar para removê-las.
5. Para compartilhar, aprender e melhorar.
6. Respeitar os frameworks e seus praticantes.
7. Para reconhecer desconhecidos e buscar ajuda.
8. Para nunca enganar e nunca deturpar.
9. Lembrar que agilidade não é o objetivo final.
10. Reconhecer que o dogmatismo não é ágil.
11. Para reconhecer que agile é mais do que ágil.
12. Para dar à comunidade como ela me deu.

Visão Geral

Um ciclo de vida adaptável de especular, colaborar e aprender. É baseado no Rapid Application Development (RAD). Ele se esforça para focar nos usuários finais do produto e incentiva o aumento da transparência entre os desenvolvedores e os clientes.

Um ciclo de vida adaptável de especular, colaborar e aprender. É baseado no Rapid Application Development (RAD). Ele se esforça para focar nos usuários finais do produto e incentiva o aumento da transparência entre os desenvolvedores e os clientes.

Código adaptativo: codificação ágil com padrões de design e princípios SOLID (práticas recomendadas para desenvolvedores)

Evolução de ASD

Ano de Criação / Primeiro Uso

2000

Uso no mundo

n/a

Eu sou um bloco de texto. Clique no botão Editar (Lápis) para alterar o conteúdo deste elemento.

CAS – Complexity Leadership / Complex Adaptive Systems

Visão Geral

Baseado na Teoria da Complexidade e Teoria do Caos – que por sua vez vem da Teoria dos Sistemas. O objetivo é construir a organização com a capacidade de se adaptar às mudanças rapidamente, reconhecendo que é um sistema complexo que deve ser equilibrado entre o organizado e o caótico.

Teoria de Liderança de Sistemas Complexos: Novas Perspectivas da Ciência da Complexidade na Eficácia Social e Organizacional (Explorando a Complexidade Organizacional)

Liderança de Complexidade

Teoria da Complexidade: A Parte Mais Importante do Agile

Complexity Leadership

Ano de Criação / Primeiro Uso

2001

Uso no mundo

n/a 

Princípios

1. Visão Boa o Suficiente
2. Especificações Mínimas
3. Auto-organização
4. Perguntas perversas
5. Shadow Systems
6. Emergência

Papéis

Nível Organizacional

Visão Geral

Uma família de metodologias de desenvolvimento de software movidas a humanos, adaptáveis, ultraleves, ‘esticar para caber’. Destina-se a abordar a questão das características múltiplas e do tamanho da equipe entre projetos.
1. Visão Boa o Suficiente
2. Especificações Mínimas
3. Auto-organização
4. Perguntas perversas
5. Shadow Systems
6. Emergência

Crystal Clear: uma metodologia impulsionada por humanos para pequenas equipes (Agile Software Development Series): 1ª (primeira) edição

Agile Framework Crystal

Artigo da Projetos e TI – Agile Methods: Crystal

Criado Por

Alistair Cockbur

Ano de Criação / Primeiro Uso

1980/2001

Uso no mundo

n/a 

Princípios

Trabalho em equipe
Comunicação
Simplicidade
Reflexão
Ajustes frequentes
Melhorar processos

Papéis

Patrocinador
Usuário Embaixador
Designer Principal
Programador

Papéis virtuais
Coordenador
Especialista em negócios
Redator técnico
Testador

Visão Geral

Não Agile – Waterfall com um nome Agile onde requisitos são chamados de histórias de usuário.  O foco está em tentar remover a burocracia.

Ano de Criação / Primeiro Uso

?

Uso no mundo

n/a

DA – Disciplined Agile Framework / DAD – Disciplined Agile Delivery

Visão Geral

Esta é uma abordagem híbrida destinada a colocar as pessoas em primeiro lugar e fazer do aprendizado um forte foco do processo.  É construído mais para grandes organizações distribuídas.
O corpo diretivo desta abordagem e os materiais educacionais associados são agora propriedade do Project Management Institute (PMI)

Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise (IBM Press)

Ano de Criação / Primeiro Uso

2009

Uso no mundo

0,5%

Princípios

Seis Ciclos de Vida – Agile, Entrega Contínua: Agile, Exploratório, Lean, Entrega Contínua: Lean, Programa.

Papéis

Líder da equipe, proprietário do produto, membro da equipe, proprietário da arquitetura, parte interessada

Visão Geral

Baseia-se na análise e design orientados a objetos. O objetivo é tornar a criação de aplicativos complexos mais fácil conectando peças ou módulos relacionados em um modelo em constante evolução. Ele incentiva o desenvolvimento iterativo.

Implementando Design Orientado a Domínio

Design Orientado a Domínio: Combatendo a Complexidade no Coração do Software

Domain Driven Design

Ano de Criação / Primeiro Uso

2004

Uso no mundo

n/a

Princípios

Três princípios fundamentais:
Concentre-se no domínio central e na lógica do domínio
Baseie o projeto complexo em modelos do domínio
Colabore constantemente com especialistas de domínio para melhorar o modelo de aplicativo e resolver quaisquer problemas emergentes relacionados ao domínio

Visão Geral

O DSDM foi criado em parte devido a problemas com o Rapid Application Development (RAD). Seu foco está no ciclo de vida completo do projeto, do início ao fim. Originalmente criado para o desenvolvimento de software, ele está indo além desse reino.  Usa muito além de projetos de engenharia de software, com expansões em gerenciamento de programas, entrega de serviços e muito mais.
*Eles apenas chamam de DSDM agora

Manuais DSDM

DSDM: Método de Desenvolvimento de Sistemas Dinâmicos: O Método na Prática

AGILE: Agile Project Management, Kanban, Scrum, Kaizen (DSDM Atern, Agile Project Scope, Agile Software, Full Value Chain, Forecasting with Kanban, Scrum Roles, Scrum Artifacts, Sprint Cycle)

Uma abordagem ágil de ciclo de vida completo: Metodologia de desenvolvimento de sistemas dinâmicos (DSDM)

Criado Por

DSDM Consortium

Ano de Criação / Primeiro Uso

1994

Uso no mundo

n/a 

Princípios

8 Princípios Fundamentais:

1. Foco na necessidade do negócio
2. Entregar no prazo
3. Colaborar
4. Nunca comprometa a qualidade
5. Construir gradativamente a partir de fundações firmes
6. Desenvolva iterativamente
7. Comunique-se continuamente e claramente
8. Demonstrar controle

Papéis

Patrocinador de Negócios
Visionário de Negócios
Gerente de Projetos
Coordenador Técnico
Analista de Negócios
Líder de Equipe
Desenvolvedor de Soluções
Embaixador de Negócios
Testador de Soluções

Visão Geral

O FAST Agile tem um forte foco em confiar nos desenvolvedores e nas equipes auto-organizadas. Sua criação foi inspirada na Tecnologia Open Space; um método para organizar e conduzir reuniões que enfatiza a importância de se concentrar em uma tarefa específica e importante.
Origens do Spotify Squad

Regras FAST:
Faça a coisa Certa
Seja um jogador de equipe
Seja um jogador em forma de T
Esforce-se pela excelência em seu ofício

FAST Agile Scaled Technology

Criado Por

Cron Technologies LLC

Ano de Criação / Primeiro Uso

?

Uso no mundo

n/a

Princípios

Visão Geral

Destina-se a otimizar o valor do cliente, concentrando-se nos recursos entregues.

1. Desenvolva um modelo geral
Resultado: Modelo de Objeto de Alto Nível e Notas
2. Crie uma lista de recursos
Resultado: Lista de recursos agrupados em conjuntos e áreas temáticas
3. Plano por recurso
Produto: Plano de Desenvolvimento; Proprietários de conjuntos de classes e recursos
4. Design por recurso
Resultado: Pacote de Design
5. Construa o recurso
Resultado: Programação, Teste, Empacotamento

Ano de Criação / Primeiro Uso

1997

Uso no mundo

n/a 

Princípios

Guia prático para FDD

FDD e Modelagem Ágil

Um guia prático para desenvolvimento orientado a recursos

Kanban (Agile Kanban, Just In Time Delivery)

Visão Geral

Scrum em larga escala: mais com LeSS (Addison-Wesley Signature Series (Cohn)) 

Princípios LeSS

Visão geral do LeSS

Ano de Criação / Primeiro Uso

2002 / 2005

Uso no mundo

1%

Princípios

Teoria da Fila
Scrum em larga escala é Scrum
Transparência
Mais com menos
Foco no produto inteiro
Centrado no Cliente
Melhoria contínua em direção à perfeição
Pensamento Enxuto
Sistemas a pensar
Controle de Processo Empírico

Papéis

Equipe de recursos,

Proprietário do produto,

Proprietário do produto da área,

Scrum Master

Visão Geral

Isso não é tanto uma estrutura ou metodologia, mas um conjunto de princípios orientadores.

Arquitetura Enxuta: para Desenvolvimento Ágil de Software 

Implementando o Desenvolvimento de Software Lean

7 conceitos básicos de Lean

7 Princípios Orientadores do Desenvolvimento Enxuto

Ano de Criação / Primeiro Uso

1980 / 1990

Uso no mundo

n/a

Princípios

7 princípios orientadores

1. Eliminar desperdício
2. Continue aprendendo
3. Adiar decisões
4. Entregue rápido
5. Capacite a equipe
6. Construir integridade em
7. Veja o todo

Visão Geral

Uma expansão ou interpretação mais ampla do Manifesto Ágil para Desenvolvimento de Software.

Modern Agile

Ano de Criação / Primeiro Uso

?

Uso no mundo

n/a 

Princípios

Quatro princípios orientadores:

1. Torne as pessoas incríveis
2. Experimente e aprenda rapidamente
3. Agregar valor continuamente
4. Faça da segurança um pré-requisito

Visão Geral

O gerenciamento de programas de sucesso (MSP®) representa uma boa prática comprovada na entrega bem-sucedida de mudanças transformacionais por meio da aplicação de gerenciamento de programas.

Criado Por

AXELOS

Ano de Criação / Primeiro Uso

?

Uso no mundo

n/a

Visão Geral

O gerenciamento de portfólio ajuda as organizações a tomarem decisões sobre a implementação das mudanças certas em suas atividades normais de negócios (BAU) por meio de projetos e programas.

A orientação de Gestão de Portfólios (MoP ® ) fornece aos executivos seniores e profissionais responsáveis ​​pelo planejamento e implementação de mudanças, um conjunto de princípios, técnicas e práticas para introduzir ou reenergizar o gerenciamento de portfólio. O MoP ajuda as organizações a responder à pergunta fundamental: Temos certeza de que esse investimento é certo para nós e como ele contribuirá para nossos objetivos estratégicos?

Criado Por

AXELOS

Ano de Criação / Primeiro Uso

?

Uso no mundo

n/a

Visão Geral

Uma maneira de escalar o Scrum usando várias equipes Scrum. É baseado no Guia Scrum com uma equipe Nexus adicional composta por um Dono do Produto, Scrum Master e Membros da Equipe de Integração.

Estrutura do Nexus para escalonamento de Scrum, o: Fornecimento contínuo de um produto integrado com várias equipes Scrum

Guia Nexus

Escalando Scrum com Nexus

Criado Por

Scrum.Org

Ano de Criação / Primeiro Uso

2015

Uso no mundo

n/a

Papéis

O Dono do Produto,

Scrum Masters,

Membros da Equipe de Integração do Nexus,

Equipe de Desenvolvimento

Visão Geral

Variação proprietária do Agile que é semelhante ao SAFe – Scaled Agile Framework. Implementado na Optum e United Health Group.

Lições aprendidas em Scaled Agile

Criado Por

United Healthgroup / Optum

Ano de Criação / Primeiro Uso

2015 / 2016

Uso no mundo

Só a United Healthgroup / Optum

Visão Geral

P4 consiste em P4 Operations e P4-Development Framework e se destina ao desenvolvimento físico do produto. É um método para dimensionar a agilidade além de apenas equipes de projeto e estendê-la a um nível de programa. P4 significa Pragmático, Paradigmas, Princípios e Práticas

Camadas de grupo:

1. 1. Nível de equipe
2. Nível de Cluster
3. Nível Organizacional

P4 traz o conceito de uma retrospectiva para o nível organizacional, estabelece as bases para um programa Agile em escala.

P4-dev

Visão geral de P4

Ano de Criação / Primeiro Uso

?

Uso no mundo

n/a

Visão Geral

Praxis é um framework gratuito para a gestão de projetos, programas e portfólios. Inclui um corpo de conhecimento, metodologia, estrutura de competência e modelo de maturidade de capacidade. A estrutura é apoiada por uma base de conhecimento de recursos e uma enciclopédia.

Ver as origens do Praxis e como ele se relaciona com outros guias, incluindo PRINCE2® e ISO21500.

Criado Por

Adrian Dooley – APM

Ano de Criação / Primeiro Uso

2014

Uso no mundo

n/a

Unified Process (UP) / Unified Software Development Process (USDP)

Visão Geral

Processo Unificado (UP) / Processo Unificado de Desenvolvimento de Software (USDP) As origens do Rational Unified Process. É orientado por casos de uso com um ciclo de desenvolvimento iterativo e incremental. É mais amplo do que o RUP no tamanho do projeto e menos orientado nos detalhes de como desenvolver o software.

UML 2 e o Processo Unificado: Análise Prática Orientada a Objetos e Design (2ª Edição)

Entenda o Processo Unificado

USDP

Ano de Criação / Primeiro Uso

Década de 1980

Uso no mundo

n/a

Visão Geral

Metodologia de desenvolvimento de software que se concentra na prototipagem ao longo de um planejamento abrangente. A maioria das variações iterativas do Agile descendem do RAD.

Desenvolvimento rápido: Taming Wild Software Schedules

RAD Model

Ano de Criação / Primeiro Uso

Década de 1980

Uso no mundo

n/a

Princípios

Modelo RAD:

• Modelagem de Negócios
• Modelagem de dados
• Modelagem de Processo
• Geração de aplicativos
• Teste e Rotatividade

Visão Geral

Um processo de desenvolvimento de software que divide o desenvolvimento em quatro fases

O Rational Unified Process: Uma introdução (3ª edição)

IBM RUP

Criado Por

IBM

Ano de Criação / Primeiro Uso

Década de 1980

Uso no mundo

n/a

Princípios

6 melhores práticas

1. Desenvolva software iterativamente
2. Gerenciar requisitos
3. Use arquiteturas baseadas em componentes
4. Software de modelo visual
5. Verifique a qualidade do software
6. Controle as mudanças no software

Visão Geral

Uma estrutura destinada a equipes Agile maiores, desenvolvimento de software corporativo. Ele usa princípios e práticas integrados de Lean, Agile e DevOps. SAFe utiliza práticas de Scrum, Kanban e XP.

Guia de referência do SAFe 4.5: Scaled Agile Framework para Lean Enterprises (2ª edição) 

The Rollout: Um romance sobre liderança e construção de uma empresa Lean-Agile com SAFe® 

SAFE

SAFe Flow

Criado Por

Dean Leffingwell © Scaled Agile, Inc.

Ano de Criação / Primeiro Uso

2011

Uso no mundo

1%

Princípios

Cinco competências essenciais da empresa Lean:

1. Lean-Agile Leadership,
2. Team e Technical Agility,
3. DevOps e Release on Demand,
4. Business Solutions e
5. Lean Systems Engineering, Lean Portfolio Management

Papéis

Proprietários épicos,
Arquiteto corporativo,
Engenheiro de sistema,
Gerente de produto,
Engenheiro de release train,
Proprietários de negócios,
Equipe de desenvolvimento,
Proprietário do produto

Visão Geral

SAM é um modelo iterativo usado para design instrucional. Pretende ser uma atualização ou um complemento da abordagem ADDIE.

1. Fase de preparação:
   1. Coleta de informações
   2. SAVVY Start
2. Fase de design iterativo:
   1. Planejamento de Projeto
   2. Design Adicional
3. Processo de desenvolvimento iterativo:
   1. Prova de Design
   2. Alfa
   3. Beta
   4. Ouro

Na fase de Projeto Iterativo, o processo itera por meio de três fases – Projeto, Protótipo e Revisão. Na fase de Desenvolvimento Iterativo, há três processos adicionais de – Desenvolver, Implementar e Avaliar. A fase de desenvolvimento segue o caminho de processos da Fase de design iterativo.

Saindo de ADDIE para SAM

Desenvolvimento iterativo de eLearning com SAM

Ano de Criação / Primeiro Uso

2012

Uso no mundo

n/a

Visão Geral

Concentre-se no grupo / equipe que restringe o fluxo e trabalhe para aumentar a coordenação entre os outros grupos e aquele grupo.

https://itknowledgeexchange.techtarget.com/uncharted-waters/introducing-the-scare-method/

Ano de Criação / Primeiro Uso

2014

Uso no mundo

n/a

Visão Geral

O Scrum se destina a ser uma estrutura para desenvolver, entregar e sustentar produtos complexos com um forte foco no lançamento de uma parte ou incremento do produto “Pronto” no final de cada iteração (Sprint).

*Quem criou a ideia do Scrum é contestado. É comumente creditado a Ken Schwaber e Jeff Sutherland, fazendo o primeiro uso conhecido em 1993.

No entanto, o termo “Scrum” foi usado pela primeira vez na revisão da Harvard Business em 1986 para fazer referência a uma equipe multifuncional e de alto desempenho ( The New Product Development Game por Hirotaka Takeuchi e Ikujiro Nonaka)

Em 1990, Scrum foi supostamente discutido em um livro (eu não li o livro e não posso confirmar) por Peter DeGrace e Leslie Stahl chamado “ Wicked Problems, Righteous Solutions: A Catologue of Modern Engineering Paradigms. ”

Este artigo discute o Scrum como sendo criado por Jeff Sutherland, John Scumniotales e Jeff McKenna em 1993. 

Contradizer a Wikipédia (não é surpreendente, pois são edições de qualquer pessoa)-se aqui pela primeira ditado, “Jeff Sutherland é um dos criadores do processo de desenvolvimento de software Scrum. Junto com Ken Schwaber, ele criou o Scrum como um conjunto de processos no OOPSLA’95. ” E depois dizendo que “O processo scrum foi desenvolvido por Sutherland, John Scumniotales e Jeff McKenna enquanto estava na Easel Corporation e foi influenciado pelo desenvolvimento ágil de software.”

Em um artigo diferente sobre Scrum, a Wikipedia faz referência ao artigo de 1986, “The New New Product Development Game”, mas acrescenta: “O framework Scrum foi baseado na pesquisa de Schwaber com Tunde Babatunde na DuPont Research Station e University of Delaware. ”Essa entrada mais tarde se torna mais clara e se assemelha a uma história que pode fazer sentido ao declarar:“ No início dos anos 1990,  Ken Schwaber  usou o que viria a ser o Scrum em sua empresa, Métodos de Desenvolvimento Avançado; enquanto  Jeff Sutherland , John Scumniotales e Jeff McKenna desenvolveram uma abordagem semelhante na Easel Corporation, referindo-se a ela usando o scrum de palavra única.Ken e Jeff trabalharam juntos para integrar suas ideias em um único framework, Scrum. Eles testaram o Scrum e o melhoraram continuamente, resultando em seu artigo de 1995, contribuições para o Manifesto Ágil em 2001 e a difusão e uso mundial do Scrum desde 2002 ”.

Minha teoria sobre o curso dos eventos:
1. Um artigo de 1986 usou a palavra Scrum para descrever um processo.
2. Um livro em 1990 fez referência a esse artigo e construiu um processo com base no processo descrito no artigo de 1986.
3. Duas equipes experimentaram métodos de desenvolvimento de software em algum lugar entre 1986 e 1993.
4. Uma pessoa de cada uma dessas equipes (Jeff e Ken) se reuniu e refinou ainda mais os processos que eles usaram juntos e rotularam esse processo de Scrum por causa do artigo de 1986.
Parece provável que o Scrum era mais genérico e geral antes de 1993, em comparação com o que agora conhecemos como Scrum com seu conjunto muito específico de regras e processos. Também parece provável que vários processos com recursos semelhantes foram criados ao mesmo tempo e, em seguida, refinados por Jeff Sutherland e Ken Schwaber juntos. Em que ponto o Scrum se tornou Scrum é a verdadeira disputa.

Criado Por

Ken Schwaber e Jeff Sutterland

Ano de Criação / Primeiro uso

*1986 – 1993

Uso no mundo

56%

Princípios

1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Papéis

Scrum Master (s)
Dono do Produto
Equipe (s) de Desenvolvimento

Cerimônias

• Sprint Planning
• Daily Meeting
• Sprint Review
• Sprint Retrospect

Visão Geral

Ele consiste em várias equipes, cada uma utilizando Scrum, colaborando em um produto ou projeto. O objetivo é escalar o Scrum para servir a projetos de desenvolvimento maiores. Cada equipe tem um Scrum Master, mas cada uma trabalha a partir do mesmo Product Backlog.

Criado Por 

Agile Alliance

Ano de Criação / Primeiro Uso

2001

Uso no mundo

15%

Princípios

Três pilares

1. Transparência
2. Inspeção
3. Adaptação

Cinco valores

1. Compromisso
2. Coragem
3. Foco
4. Abertura
5. Respeito

Papéis

Scrum Master (s)
Dono do Produto
Equipe (s) de Desenvolvimento
Scrum de Scrums
IT Journal

Visão Geral

Usa a melhoria contínua do processo, trabalho em andamento limitado (WIP) e monitoramento dos fluxos de processo do Kanban dentro da estrutura Scrum.
A evolução do Scrumban [R]: Obtendo o máximo do Agile, Scrum e Lean Kanban (Agile Software Development Series) 
O que é Scrumban?
Scrum-ban

Ano de Criação / Primeiro Uso

2008 (ou antes)

Uso no mundo

8%

Princípios

Três pilares

1. Transparência
2. Inspeção
3. Adaptação

Cinco valores

1. Compromisso
2. Coragem
3. Foco
4. Abertura
5. Respeito

Papéis

Scrum Master (s)
Dono do Produto
Equipe (s) de Desenvolvimento

Spotify Agile / Spotify Squad / Spotfy Model

Visão Geral

O Agile é mais importante do que o Scrum. O Spotify Agile foi projetado para focar na cultura Agile ao invés de uma estrutura específica. Tem um grande foco no compartilhamento de conhecimento. 

No Spotify Agile, existem três tipos de Squads – Recurso, Aplicativo Cliente, Infraestrutura. Não se preocupe em lançar recursos que não estão prontos, ele libera e oculta os recursos para ajudar a encontrar problemas com integração mais cedo.
Uma modificação do FAST Agile

Criado Por

Spotify

Ano de Criação / Primeiro Uso

2006

Uso no mundo

1%

Princípios

Cultura de Engenharia Spotify

Papéis

Líder

Membro do Squad

TDD – Test-driven development – Desenvolvimento Orientado a Testes

Visão Geral

Tem uma relação com a Extreme Programming , na qual uma prática possível na Extreme Programming era escrever o teste primeiro e depois codificar para o teste. Não recebeu um nome próprio até cerca de 2002.
Desenvolvimento orientado a testes: por exemplo 

TDD

TDD por exemplo

Criado Por

Agille Alliance

Ano de Criação / Primeiro Uso

1998

Uso no mundo

1%

Visão Geral

Um aprimoramento do Kanban que está sendo criado. O fluxo de trabalho contínuo do Agile Kanban / Just in Time Delivery com um conjunto de princípios e práticas para se tornar uma organização mais centrada no ser humano e simplificada. Um Agile mais ágil.
Isso não é para projetos de desenvolvimento de software, é toda uma abordagem de agilidade organizacional.

A perspectiva Mercurial

Princípios da Perspectiva Mercurial

Kanban: A Perspectiva Mercurial

Criado Por

Mercurial

Ano de Criação / Primeiro uso

2017 / 2019

Uso no mundo

0,5%

Princípios da Perspectiva Mercurial:

1. Trate os humanos como seres humanos
2. Envolva-se na aprendizagem constante e compartilhada
3. Trabalhe continuamente para melhorar com base nos resultados anteriores
4. Esforce-se para ser transparente em seus pensamentos, ações e status
5. Una a organização sob as motivações compartilhadas
6. Abrace a ideia de que da qualidade vem a satisfação do cliente
7. Limite a burocracia simplificando e agilizando seus processos
8. Não limite as opções em prol da agilidade
9. Espere mudanças e adapte-se do método mais eficiente e orientado para o conhecimento

Papéis

Toda a organização

Visão Geral

A Extreme Programming se concentra em trazer as melhores práticas para a engenharia de software. Ele enfatiza a refatoração de código e a programação emparelhada. Valoriza muito o trabalho em equipe, a colaboração e os espaços de trabalho compartilhados.

Programação Extrema Explicada: Adote a Mudança, 2ª Edição (Série XP)

http://www.extremeprogramming.org/

Programação Extrema (XP)

Criado por

Kent Beck

Ano de Criação / Primeiro uso

1996

Uso no mundo

1%

5 regras principais

1. Planejamento
2. Gerenciamento
3. Projeto
4. Codificação
5. Teste

5 Valores Fundamentais

1. Simplicidade
2. Comunicação
3. Feedback
4. Respeito
5. Coragem

Papéis

Coach
Clientes
Desenvolvedores
Testadores

12 práticas de XP

1. Programação em par
2. Jogo de Planejamento
3. Desenvolvimento Orientado a Testes (TDD)
4. Equipe inteira
5. Integração contínua
6. Reestruturação
7. Pequenos lançamentos
8. Ritmo Sustentável
9. Propriedade do código coletivo
10. Padrão de Codificação
11. Design simples
12. Metáfora do Sistema