Agile Methods

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.

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 

Como 4 Disciplinas da Execução

Execução é a chave! A abordagem do 4DX

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:

  1. Concentre-se no extremamente importante
  2. Agir sobre as medidas de chumbo
  3. Mantenha um placar atraente
  4. Crie uma cadência de responsabilidade

4 Desafios:

  1. Gerentes e equipes de trabalho não conhecem o objetivo
  2. Gerentes e equipes não sabem o que fazer para atingir a meta
  3. Eles não mantêm a pontuação ou rastreiam as principais medidas de sucesso
  4. 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:

  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

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

What is Hybrid Agile, Anyway?

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:

Blending Agile and Waterfall

Hybrid Waterfall

Agile/Waterfall Hybrid Approach

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:

Agnostic Agile

Thinking Beyond the Agile Manifesto – Agnostic Agility

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:

  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
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

Código adaptável: codificação ágil com padrões de design e princípios SOLID (melhores práticas do desenvolvedor)

Evolução dos ADS

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 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

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:

  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 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

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

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

Sistema Toyota de Produção

O que é Kanban?

Ano de Criação / Primeiro Uso

1940 em Lean como JIT Manufacturing

Uso no mundo

5%

Princípios

Cinco Práticas Básicas

  1. Definir e visualizar o fluxo de trabalho
  2. Limite de trabalho em andamento (WIP)
  3. Medir e gerenciar o fluxo
  4. Tornar as políticas de processo explícitas
  5. 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)) 

Princípios do LeSS

Visão geral do LeSS

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:
  • Teoria das filas
  • Scrum em grande escala é Scrum
  • Transparência
  • Mais com menos
  • Foco em todo o produto
  • Centrado no cliente
  • Melhoria Contínua em Direção à Perfeição
  • Pensamento enxuto
  • Sistemas a pensar
  • Controle de Processo Empírico
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 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.

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)

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

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

  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 Journ
al

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

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/

Programação Extrema (XP)

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

  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