Esta deve ser uma lista de todas as estruturas e metodologias ágeis existentes conhecidas. Cada estrutura contém uma visão geral e links para encontrar informações adicionais.
Nem todas as estruturas ou metodologias ágeis estão isoladas em projetos de desenvolvimento de software.
Deve-se notar que o Agile não é um framework ou uma metodologia por si só, é mais uma abordagem filosófica de como as coisas devem ser feitas.
Se eu perdi algum framework, deixe uma mensagem nos comentários ou me envie um e-mail para que eu possa atualizar de acordo. Se você tiver fontes melhores para um framework Agile, por favor, encaminhe-as. Esta lista é atualizada quando novas informações são aprendidas.
- 4DX - Four Disciplines of Execution
- Agile Manufacturing
- Agile-Agile Hybrid
- Agile-Waterfall Hybrid
- AgileBA
- AgilePM
- AgilePgM
- AgilePfM
- AgileSHIFT
- Agnostic Agile
- AUP - Agile Unified Process
- AIF - Application Integration Framework
- APM
- ASD - Adaptive Software Development
- BusDevOps
- BDD - Behavior-driven development
- ATDD - Acceptance test–driven development
- CAS - Complex Adaptive Systems
- Crystal Methods
- CVSAgile
- DA - Disciplined Agile Framework
- DDD - Domain-Driven Design
- DSDM - Dynamic Systems Development Methodology
- FAST Agile
- EDD - Example Driven Development
- FDD - Feature Driven Development
- Kanban
- Holacracy (Holacracia)
- LESS - Large Scale Scrum
- LSD - Lean Software Development
- Modern Agile
- MSP® (Managing Successful Programmes)
- MoP®(Management of Portfolios)
- Nexus
- OSAM - Optum Scaled Agile Methodology
- P4 / P4-Dev / P4-Ops
- Praxis Framework
- PRINCE2 Agile
- UP/USDP - Unified Process
- Project Half Double
- RAD - Rapid Application Development
- RUP - IBM Rational Unified Process
- SAFE - Scaled Agile Framework
- SAM - Successive Approximation Model
- SCARE - Sustainable Cultural Agile Release in the Enterprise
- Scrum
- Scrum de Scrums
- ScrumBan
- Scrum@Scale
- Spotfy Model
- Standard for Portfolio Management
- TDD - Test-driven development
- The Mercurial Perspective
- XP - Extreme Programming
Criador: | ? |
Ano do primeiro uso conhecido: | ? |
Percentual de relatórios de equipes ágeis usando: | N/D |
Maiores informações: |
Livro As Quatro Disciplinas da Execução |
Papéis / Roles: | Toda a organização |
Artefatos / Artifacts: | |
Cerimônias / Ceremonies: | |
Princípios / Principles: | |
Fases / Phases: | |
Estágios / Stages: |
Visão geral
4 Disciplinas:
- Concentre-se no extremamente importante
- Agir sobre as medidas de chumbo
- Mantenha um placar atraente
- Crie uma cadência de responsabilidade
4 Desafios:
- Gerentes e equipes de trabalho não conhecem o objetivo
- Gerentes e equipes não sabem o que fazer para atingir a meta
- Eles não mantêm a pontuação ou rastreiam as principais medidas de sucesso
- Eles não são responsabilizados
Concentra-se na criação de uma “Cultura de Execução” que incorpora as disciplinas em uma organização. Uma abordagem comum é trazida em todos os níveis da organização. Esta não é uma abordagem de projeto, mas toda uma abordagem organizacional.
Criador: | ? |
Ano do primeiro uso conhecido: | ? |
Percentual de relatórios de equipes ágeis usando: | N/A |
Maiores informações: | Agile Manufacturing |
Papéis / Roles: | |
Artefatos / Artifacts: | |
Cerimônias / Ceremonies: | |
Princípios / Principles: | |
Fases / Phases: | |
Estágios / Stages: |
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:
- Design de Produto Modular: projetando produtos de forma modular que permite que eles sirvam como plataformas para variação rápida e fácil
- 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
- 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
- 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
Criador: | ? |
Ano do primeiro uso conhecido: | ? |
Percentual de relatórios de equipes ágeis usando: | 20% |
Maiores informações: |
Effective Project Management: Traditional, Agile, Extreme, Hybrid |
Papéis / Roles: | Depende dos quadros |
Artefatos / Artifacts: | |
Cerimônias / Ceremonies: | |
Princípios / Principles: | |
Fases / Phases: | |
Estágios / Stages: |
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.
Criador: | ? |
Ano do primeiro uso conhecido: | ? |
Percentual de relatórios de equipes ágeis usando: | 20% |
Maiores informações: | |
Papéis / Roles: | Geralmente um gerente de projeto e equipe de suporte típica em cascata/preditiva |
Artefatos / Artifacts: | Vários do Scrum, muitos do PMBOK |
Cerimônias / Ceremonies: | Todo tipo que puder ser utilizado de acordo com a empresa |
Princípios / Principles: | |
Fases / Phases: | |
Estágios / Stages: |
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.
Criador: | Sam Zawadi |
Ano do primeiro uso conhecido: | 2017 |
Percentual de relatórios de equipes ágeis usando: | 1% |
Maiores informações: | |
Papéis / Roles: | n/a |
Artefatos / Artifacts: | |
Cerimônias / Ceremonies: | |
Princípios / Principles: | |
Fases / Phases: | |
Estágios / Stages: |
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:
- 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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 - 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 - 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. - 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. - 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. - 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
Criador: | ? |
Ano do primeiro uso conhecido: | 2000 |
Percentual de relatórios de equipes ágeis usando: | N/D |
Maiores informações: |
Desenvolvimento de software adaptativo: uma abordagem colaborativa para gerenciar sistemas complexos |
Papéis / Roles: | N/D |
Artefatos / Artifacts: | |
Cerimônias / Ceremonies: | |
Princípios / Principles: | |
Fases / Phases: | |
Estágios / Stages: |
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 da Complexidade: A Parte Mais Importante do Agile
Ano de Criação / Primeiro Uso
2001
Uso no mundo
n/aÂ
PrincÃpios
- Visão Boa o Suficiente
- Especificações MÃnimas
- Auto-organização
- Perguntas perversas
- Shadow Systems
- 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
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)
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
Criador: | DSDM Consortium, (atual Agile Consortium4). |
Ano do primeiro uso conhecido: | 1994 |
Percentual de relatórios de equipes ágeis usando: | N/D |
Maiores informações: |
|
Papéis / Roles: | 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 |
Artefatos / Artifacts: | |
Cerimônias / Ceremonies: | |
Princípios / Principles: | |
Fases / Phases: | |
Estágios / Stages: |
Visão geral
8 Princípios Fundamentais:
- Foco na necessidade do negócio
- Entregar no prazo
- Colaborar
- Nunca comprometa a qualidade
- Construa incrementalmente a partir de fundações firmes
- Desenvolver iterativamente
- Comunique-se de forma contínua e clara
- Controle de demonstração
O que é DSDM?
Inicialmente o acrônimo DSDM vem de Dynamic Systems Development Method surge como uma extensão do RAD3, 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
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
Kanban (Agile Kanban, Just In Time Delivery)
Visão Geral
A primeira coisa que você precisa saber sobre o Kanban é que ele não requer o uso de um quadro kanban e é mais do que apenas o quadro kanban. Você deve ter apenas um método visual para exibir o andamento do trabalho, o quadro kanban é um desses métodos.
É um processo Agile não iterativo que também pode ser incremental. Ele modela uma forma mais natural de trabalhar com um fluxo contÃnuo. É flexÃvel o suficiente para ser usado fora dos projetos ou como uma abordagem ágil organizacional inteira.
Kanban do mundo real: faça menos, realize mais com o pensamento enxuto
Coach Certificado de Kanban;Â O material oficial de treinamento
Ano de Criação / Primeiro Uso
1940 em Lean como JIT Manufacturing
Uso no mundo
5%
PrincÃpios
Cinco Práticas Básicas
- Definir e visualizar o fluxo de trabalho
- Limite de trabalho em andamento (WIP)
- Medir e gerenciar o fluxo
- Tornar as polÃticas de processo explÃcitas
- Use modelos para sugerir melhorias
Papéis
Em toda a organização ou em todo o projeto
Criador: | Craig Larman e Bas Vodde |
Ano do primeiro uso conhecido: | 2002 / 2005 |
Percentual de relatórios de equipes ágeis usando: | 1% |
Maiores informações: |
Scrum em grande escala: mais com LeSS (Addison-Wesley Signature Series (Cohn)) |
Papéis / Roles: |
Equipe de recursos, Proprietário do produto, Proprietário do produto da área, Scrum Master |
Artefatos / Artifacts: | |
Cerimônias / Ceremonies: | |
Princípios / Principles: |
|
Fases / Phases: | |
Estágios / Stages: |
As equipes ágeis são compostas por proprietários de produtos, scrum masters, desenvolvedores de software e outros que trabalham de forma colaborativa para resolver problemas complexos por meio da entrega criativa de produtos valiosos. Scrum é uma das metodologias ágeis mais populares que as equipes usam para desenvolver, entregar e sustentar produtos complexos. No entanto, apenas recentemente abordamos efetivamente o scrum de dimensionamento na empresa com estruturas de processos ágeis dimensionados, como o Large-Scale Scrum (LeSS).
O que é o framework LeSS?

LeSS é uma estrutura para escalar o scrum para várias equipes que trabalham juntas em um único produto. Ele começa com uma base de uma equipe scrum, conforme definido por Ken Schwaber e Jeff Sutherland no Guia do Scrum , e se aplica a várias equipes que trabalham juntas em um produto.
Isso é ainda mais refinado no livro Large-Scale Scrum: More with LeSS , de Craig Larman e Bas Vodde. Os autores condensaram seus anos de experiência para definir o LeSS como uma estrutura para agregar valor ao mesmo tempo em que reduz a complexidade e o desperdício.
A estrutura LeSS procura aplicar os princípios e ideais do Scrum em um contexto corporativo de grande escala da forma mais simples possível por meio de regras e guias definidos. Sua simplicidade rendeu ao LeSS o rótulo de ser uma estrutura “pouco suficiente”, mas isso não significa lançar uma luz negativa.
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 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
- Eliminar desperdÃcio
- Continue aprendendo
- Adiar decisões
- Entregue rápido
- Capacite a equipe
- Construir integridade em
- Veja o todo
Visão Geral
Uma expansão ou interpretação mais ampla do Manifesto Ãgil para Desenvolvimento de Software.
Ano de Criação / Primeiro Uso
?
Uso no mundo
n/aÂ
PrincÃpios
Quatro princÃpios orientadores:
- Torne as pessoas incrÃveis
- Experimente e aprenda rapidamente
- Agregar valor continuamente
- 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.
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.
Criador: | N/A |
Ano do primeiro uso conhecido: | ? |
Percentual de relatórios de equipes ágeis usando: | N/A |
Maiores informações: | P4-Dev |
Papéis / Roles: | Product Owner do Time Engenheiro de Sistemas do Time Scrum Master do Time |
Artefatos / Artifacts: | Backlog da equipe Resultados inspecionáveis Equipe DoD Backlog de melhoria da equipeBacklog do cluster Conhecimento Utilizável e Incremento do Sistema Cluster DoD Backlog de melhoria de clusterBacklog do portfólio Sistemas e aplicativos Plataformas e variantes do sistema Organização DoD Backlog de melhoria da organização |
Cerimônias / Ceremonies: | Planejamento de equipe Sincronização de equipe Refinamento da lista de pendências da equipe Revisão da equipe Retrospectiva da equipePlanejamento de cluster Sincronização de cluster Refinamento do backlog do cluster Revisão do cluster Retrospectiva do ClusterPlanejamento de portfólio Sincronização da organização Refinamento do portfólio Revisão de portfólio Retrospectiva da Organização |
Princípios / Principles: | P4 Values, Paradigms, Principles & Practices |
Fases / Phases: | Equipe de trabalho Comunidade de práticaGrupo de Proprietário do Produto da Equipe Grupo de Engenheiros de Sistemas de Equipe Equipe Scrum Master Group Círculo de Gerenciamento de ClusterGrupo de proprietários de produtos de cluster Grupo de Engenheiros de Sistemas de Cluster Grupo Scrum Master de Cluster Círculo de Gestão da Organização |
Estágios / Stages: | 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)
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
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)
Criado Por
IBM
Ano de Criação / Primeiro Uso
Década de 1980
Uso no mundo
n/a
PrincÃpios
6 melhores práticas
- Desenvolva software iterativamente
- Gerenciar requisitos
- Use arquiteturas baseadas em componentes
- Software de modelo visual
- Verifique a qualidade do software
- 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®Â
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:
- Lean-Agile Leadership,
- Team e Technical Agility,
- DevOps e Release on Demand,
- Business Solutions e
- 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.
- Fase de preparação:
- Coleta de informações
- SAVVY Start
- Fase de design iterativo:
- Planejamento de Projeto
- Design Adicional
- Processo de desenvolvimento iterativo:
- Prova de Design
- Alfa
- Beta
- 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.
Desenvolvimento iterativo de eLearning com SAM
Ano de Criação / Primeiro Uso
2012
Uso no mundo
n/a
Criador: | ? |
Ano do primeiro uso conhecido: | 2014 |
Percentual de relatórios de equipes ágeis usando: | 0% |
Maiores informações: | Apresentando o Método SCARE |
Papéis / Roles: | N/D |
Artefatos / Artifacts: | |
Cerimônias / Ceremonies: | |
Princípios / Principles: | |
Fases / Phases: | |
Estágios / Stages: |
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.

Criador: | xxxxxxxxxxxxxxxx |
Ano do primeiro uso conhecido: | *1986 – 1993 |
Percentual de relatórios de equipes ágeis usando: | 56% |
Maiores informações: | O Guia do Scrum |
Papéis / Roles: | Scrum Master, Product Owner, Developers |
Artefatos / Artifacts: | |
Cerimônias / Ceremonies: | |
Princípios / Principles: | |
Fases / Phases: | |
Estágios / Stages: |
O Scrum pretende ser uma estrutura para desenvolver, entregar e sustentar produtos complexos com um forte foco na liberação 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 de Harvard Business em 1986 para fazer referência a uma equipe multifuncional de alto desempenho ( The New New Product Development Game de Hirotaka Takeuchi e Ikujiro Nonaka)
Em 1990, o Scrum foi 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.
A Wikipedia se contradiz (o que não surpreende, pois é editada pelo cidadão) aqui ao dizer primeiro: “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 na OOPSLA’95.” E depois dizendo mais tarde que “O processo scrum foi desenvolvido por Sutherland, John Scumniotales e Jeff McKenna enquanto estava na Easel Corporation e influenciado pelo desenvolvimento ágil de software”.
Em um artigo diferente sobre Scrum ( aqui ), 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 na Universidade de Delaware. ” Esta entrada mais tarde se torna mais clara e se assemelha a uma história que pode fazer sentido afirmando: “No início da década de 1990, Ken Schwaber usou o que se tornaria Scrum em sua empresa, Advanced Development Methods; enquanto Jeff Sutherland , John Scumniotales e Jeff McKenna desenvolveram uma abordagem semelhante na Easel Corporation, referindo-se a ela usando a palavra scrum.Ken e Jeff trabalharam juntos para integrar suas ideias em um único framework, Scrum. Eles testaram o Scrum e o melhoraram continuamente, levando ao seu artigo de 1995, contribuições para o Manifesto Ágil em 2001 e a disseminação e uso mundial do Scrum desde 2002.”
Minha teoria sobre o curso dos eventos:
1. Um artigo em 1986 usou a palavra Scrum para descrever um processo.
2. Um livro de 1990 fez referência a esse artigo e construiu um processo baseado no processo descrito no artigo de 1986.
3. Duas equipes experimentaram métodos de desenvolvimento de software em algum momento entre 1986 e 1993.
4. Uma pessoa de cada uma dessas equipes (Jeff e Ken) se reuniu e refinou ainda mais os processos que usaram juntos e rotulou esse processo como Scrum por causa do artigo de 1986.
Parece provável que o Scrum fosse mais genérico e geral antes de 1993, comparado ao que hoje conhecemos como Scrum, com seu conjunto muito específico de regras e processos. Também parece provável que vários processos com características semelhantes tenham sido criados ao mesmo tempo e depois refinados por Jeff Sutherland e Ken Schwaber juntos. Em que ponto o Scrum se tornou Scrum é a verdadeira disputa.
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
- Transparência
- Inspeção
- Adaptação
Cinco valores
- Compromisso
- Coragem
- Foco
- Abertura
- 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
- Transparência
- Inspeção
- Adaptação
Cinco valores
- Compromisso
- Coragem
- Foco
- Abertura
- 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
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Â
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.
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:
- Trate os humanos como seres humanos
- Envolva-se na aprendizagem constante e compartilhada
- Trabalhe continuamente para melhorar com base nos resultados anteriores
- Esforce-se para ser transparente em seus pensamentos, ações e status
- Una a organização sob as motivações compartilhadas
- Abrace a ideia de que da qualidade vem a satisfação do cliente
- Limite a burocracia simplificando e agilizando seus processos
- Não limite as opções em prol da agilidade
- Espere mudanças e adapte-se do método mais eficiente e orientado para o conhecimento
Papéis
Toda a organização
Criador: | 1996 |
Ano do primeiro uso conhecido: | Kent Beck |
Percentual de relatórios de equipes ágeis usando: | 1% |
Maiores informações: |
Extreme Programming Explained: Embrace Change, 2ª Edição (Série XP)http://www.extremeprogramming.org/ |
Papéis / Roles: | Coach, clientes, desenvolvedores e testadores |
Artefatos / Artifacts: | |
Cerimônias / Ceremonies: | |
Princípios / Principles: | |
Fases / Phases: | |
Estágios / Stages: |
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
- Programação em pares
- Jogo de planejamento
- Desenvolvimento Orientado a Testes (TDD)
- Equipe inteira
- Integração contínua
- Reestruturação
- Pequenos lançamentos
- Ritmo Sustentável
- Propriedade de código coletivo
- Padrão de Codificação
- Design simples
- Metáfora do Sistema