Agile Methods

Visão geral

Coloca um forte foco em responder rapidamente aos clientes com prazos de produção curtos e tempo de projeto. Tem uma forte relação com o Lean Manufacturing, mas com desenvolvimento e processos mais flexíveis. Ele pode ser usado com o Lean ou um aprimoramento do Lean.

Parece estar relacionado ao aumento da capacidade de prototipagem rápida das impressoras 3D. Meu lado cínico me diz que é apenas Lean com impressoras 3D, dado um nome Agile para soar chique e moderno.

O que é Agile Manufacturing?

O Agile Manufactoring é uma metodologia de manufatura que coloca um foco extremamente forte na resposta rápida ao cliente – transformando velocidade e agilidade em uma importante vantagem competitiva.

Ele representa uma abordagem muito interessante para desenvolver uma vantagem competitiva no mercado em rápida evolução de hoje.

Uma empresa ágil está em uma posição muito melhor para aproveitar pequenas janelas de oportunidade e mudanças rápidas na demanda do cliente.

Por que o Agile Manufactoring é eficaz?

O Agile Manufactoring é eficaz porque reconhece as realidades do mercado moderno e as transforma em uma vantagem competitiva.

Ele aborda diretamente os seguintes problemas:

• Os consumidores adoram gratificação instantânea. Eles estão cada vez mais se acostumando com isso e muitas vezes estão dispostos a pagar por isso. Por exemplo, você já encomendou um produto com envio noturno… esperando ansiosamente?
• Os consumidores adoram a escolha. Eles preferem obter um produto exatamente como querem… sem concessões.
• Os consumidores são inconstantes. Seus interesses mudam e se movem de maneiras imprevisíveis.

Agile é de particular valor para fabricantes em países com mercados locais grandes e bem desenvolvidos e altos custos de mão de obra (por exemplo, Estados Unidos). Ele aproveita a proximidade com o mercado, oferecendo produtos com um nível de velocidade e personalização sem precedentes, que simplesmente não pode ser igualado por concorrentes offshore. Transforma a fabricação local em uma vantagem competitiva.

4 Elementos Chave:

Existem quatro elementos chave para  o Agile Manufactoring:

1. Design de Produto Modular: projetando produtos de forma modular que permite que eles sirvam como plataformas para variação rápida e fácil
2. Tecnologia da Informação/Automação: automatizando a disseminação rápida de informações em toda a empresa para permitir uma resposta rápida aos pedidos
3. Parceiros Corporativos: criando alianças virtuais de curto prazo com outras empresas que permitem um melhor tempo de colocação no mercado para segmentos de produtos selecionados
4. Cultura do Conhecimento: investir em treinamento de funcionários para alcançar uma cultura que apoie mudanças rápidas e adaptação contínua

Visão geral

Uma mistura de duas ou mais estruturas ágeis. Scrum e XP são amplamente usados ​​juntos (o que parece apenas fazer o XP). O objetivo é tentar tirar as melhores práticas de cada framework.

Também chamado de Agile Blended

*Tecnicamente, Scrumban é um híbrido ágil-ágil.

Visão geral

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

*Em minha experiência que a maioria das pessoas que afirmam fazer Scrum, na verdade fazem uma abordagem híbrida Agile-Waterfall.

Nestes casos o Scrum é relatado como maior framework em uso, no meu ver essa metodologia híbrida de Agile-Waterfall é uma das mais utilizadas no mundo, visto que eu estive em mais do que algumas equipes “Scrum” com um Gerente de Projeto e sem Sprints.

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 dele afirma que a escolha de um framework pode realmente atrapalhar a agilidade, pode não ser a melhor coisa a fazer.

PORQUE?

O Agile tornou-se uma mercadoria a ponto de o espírito do que o Manifesto Agile representa está murchando. Vender frameworks, métodos e outras formas de trabalho caros é a ordem do dia do Complexo Industrial Ágil, um Complexo que tem seus interesses não na agilidade, mas na própria proliferação, independentemente do benefício ou não de seus destinatários.

A abordagem de tamanho único é uma antítese frustrante do que significa ser ágil e buscar agilidade, mas é promovida e popularizada em detrimento não apenas do destinatário, mas do movimento ágil como um todo.

Este é o meio em que o Agnostic Agile nasceu, servindo como uma lembrança do que significa operar a serviço da agilidade, unindo-se como uma comunidade global para trabalhar pelo bem maior e lutar pelo bom combate!

ORIGENS

Fundado em Londres em 2016 e publicado em 2017, Agnostic Agile é um movimento da comunidade global para melhorar a prática profissional Agile em todo o mundo. Temos uma comunidade crescente de milhares de membros, que agora é administrada como um corpo profissional com um conselho cujos membros cobrem quase todos os continentes do mundo.

PRINCÍPIOS

Procuro defender os seguintes princípios, com o melhor de minha capacidade e julgamento:

1. Colocar o cliente em primeiro lugar, tornando-o independente.
   Colocarei os interesses do meu cliente em primeiro lugar, pois é o que fui contratado para fazer. Eu o ajudarei a entender, em profundidade, a mentalidade do agile, com seus princípios e valores, ao invés de apenas as especificidades de framework. Dessa forma, eu o “ensino a pescar” e o empodero, levando-o a um lugar de independência, que elimina a criação de laços de dependência.
2. Fazer o meu melhor, complementando teoria à experiência prática.
   Aplicarei todo conhecimento e aprendizado a respeito de práticas de lean e agile disponíveis, conforme minhas habilidades atuais permitam. Tais podem vir de minhas próprias experiências ou de qualquer framework que melhor atenda às necessidades e o contexto de meu cliente. Eu procurarei sempre aconselhá-lo com base no equilíbrio saudável entre teoria e experiência prática.
3. Adaptar agilidade ao contexto.
   Reconheço que existe arte em nossa prática de lean e agile, sendo motivada por evidências empíricas, e que inteligência emocional, compreensão do contexto do cliente, e os níveis de maturidade do mesmo, podem superar a adoção de qualquer (aspecto de um) método ou framework, mesmo quando tal (aspecto de um) método ou framework seja o mais ágil. Eu sugiro o ideal para este cliente, ao invés de forçar algo que ele não precise.
4. Compreender as restrições inconvenientes e trabalhar para removê-las.
   Respeitarei o contexto específico do meu cliente, e me empenharei, da melhor forma que conheço, em remover qualquer restrição que impeçam a agilidade.
5. Compartilhar, aprender e melhorar.
   Compartilharei, com prazer e honestidade, o meu conhecimento e minhas experiências com meus colegas praticantes e também com guardiões de framework, ajudando, continuamente, a melhorar as práticas de lean e agile. Isso inclui fornecer feedbacks construtivos, de modo respeitoso, para que todos possam se beneficiar de aprendizado e aprimoramento contínuos.
6. Respeitar os frameworks e seus praticantes.
   Respeitarei os frameworks e o valor que eles oferecem. Respeitarei também aqueles que os praticam, e aqueles que ajudaram a criá-los e aprimorá-los.
7. Reconhecer o desconhecido e procurar ajudar.
   Admitirei, corajosamente, não saber, caso sinta que um problema ou desafio podem estar além dos meus conhecimentos e das minhas habilidades, não importando se pequenos ou grandes, e me comprometerei em pedir ajuda a um colega praticante se para o benefício do meu cliente.
8. Nunca enganar ou deturpar.
   Nunca enganarei ao afirmar saber algo que não sei, e nunca deturparei nem esconderei qualquer opção ou escolha que possa beneficiar o meu cliente
9. Lembrar que agilidade não é o objetivo final.
   Lembrarei que obter agilidade não garante o melhor resultado para o meu cliente e que, em alguns casos, estratégias mais tradicionais podem ser mais efetivas para o atual clima e contexto
10. Reconhecer que dogmatismo vai de encontro à agilidade.
    Não serei dogmático a respeito de frameworks e métodos de lean ou agile, pois o dogmatismo vai de encontro à agilidade, não beneficiando o meu cliente, nem a minha comunidade, ou mesmo a minha própria prática. Portanto, procurarei ativamente evitá-lo.
11. Reconhecer haver mais do que agilidade na prática do agile.
    Reconhecerei que o caminho para a agilidade, às vezes, precisa ser construído para que possamos começar ou continuar a jornada. Construir tal caminho pode incluir práticas como o treinamento de pessoas ou organizações, a aplicação do pensamento lean, e o gerenciamento de mudanças organizacionais. Assim, procurarei aprender e dominar o que for necessário para compor um caminho seguro para a agilidade.
12. Devolver à comunidade
    Lembrarei que sou um membro da comunidade de praticantes de lean e agile. Procurarei ajudar a minha comunidade a melhorar e aprender com ela tanto quanto ela aprende comigo. Com isso, beneficiarei os praticantes do agile, assim como os clientes, em qualquer lugar.
13. Abrir a diversidade, sem compromisso
    Promoverei a diversidade e a inclusão no meu local de trabalho e ao me envolver com os clientes e suas atribuições. Vou me esforçar para educar líderes e gerentes de contratação, celebrar as diferenças dos funcionários e procurar constantemente desafiar meus preconceitos conscientes e inconscientes

Visão geral

Um ciclo de vida adaptativo de Especular, Colaborar e Aprender. Ele é baseado no Desenvolvimento Rápido de Aplicativos (RAD). Ele incentiva os clientes para se concentrar nos clientes finais do cliente uma transparência entre os desenvolvedores e desenvolvedores.

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

8 Princípios Fundamentais:

1. Foco na necessidade do negócio
2. Entregar no prazo
3. Colaborar
4. Nunca comprometa a qualidade
5. Construa incrementalmente a partir de fundações firmes
6. Desenvolver iterativamente
7. Comunique-se de forma contínua e clara
8. Controle de demonstração

O que é DSDM?

Inicialmente o acrônimo DSDM vem de Dynamic Systems Development Method surge como uma extensão do RAD³, o DSDM é aplicado em projetos de Sistemas caracterizados pelos cronogramas e custos limitados.

Sobretudo o DSDM aponta falhas de informação mais comuns destes projetos, incluindo custos excedentes, perda de prazos, falta de envolvimento de usuários e acompanhamento da alta gerência.

Embora através do uso do RAD, contudo, sem os devidos cuidados o DSDM pode aumentar ainda mais o risco em outros quesitos, o DSM consiste em:

• 3 fases: pré-projeto, ciclo de vida, e pós-projeto.
• A fase ciclo de vida é subdividida em 5 estágios: análise de viabilidade, análise de negócio, Iteração do Modelo Funcional, iteração de elaboração e construção e, por fim, implantação.

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 vem se expandindo ainda mais para fora desse reino.

Usa muito além dos projetos de engenharia de software, com expansões no gerenciamento de programas, entrega de serviços e muito mais.

* Eles apenas chamam de DSDM agora

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 destina-se ao desenvolvimento de produtos físicos. É um método para escalar 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

Níveis de Grupo

• Nível da equipe
• Nível de cluster
• Nível organizacional

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

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 esse grupo.

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

5 Regras Principais – Planejar, Gerenciar, Projetar, Codificar, Testar

5 Valores Fundamentais – Simplicidade, Comunicação, Feedback, Respeito, Coragem

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 programação pareada.

Valoriza muito o trabalho em equipe, a colaboração e os espaços de trabalho compartilhados.

12 Práticas de XP

1. Programação em pares
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 de código coletivo
10. Padrão de Codificação
11. Design simples
12. Metáfora do Sistema