Métodos Ágeis - Um Guia Definitivo com mais de 20 metodologias ágeis - Michel Deunizio - KINDLE

Prévia do material em texto

MICHEL DEUNIZIO
E S C R I T O P O R
UM GUIA DEFINITIVO COM MAIS DE
METODOLOGIAS ÁGEIS
UTILIZADAS POR GRANDES EMPRESAS PARA 
CRIAR O
MÉTODOS
ÁGEIS
PRODUTO CERTO
 1 º E D I Ç Ã O 2 0 2 0
20
Por que utilizar
Métodos Ágeis?
 
Essas empresas buscam agilidade para
aumentar sua produtividade, melhorar a
qualidade, encurtar os ciclos de entrega,
entre vários outros fatores.
 
Nesse modelo ágil, as empresas flutuam em
um ambiente de colaboração e cocriação, e
através de vários métodos que serão
abordados nesse e-book, consegue-se criar
um ambiente muito criativo e ágil.
 
Além disso, com os ciclos de iteração com
o cliente, consegue-se medir o progresso
do produto e tomar decisões rápidas, como
pivotar ou perseverar uma ideia.
M
uito se ouve falar sobre cultura ágil
e a busca por essa transformação
dentro das empresas.
SUMÁRIO
Manifesto Ágil
Scrum
Kanban
Lean Startup
Lean Inception
Design Thinking
Service Design
Design Sprint
Kaizen
Extreme Programming
Feature Driven Development
Adaptive Software Development
DSDM
Crystal Method
D.A.D
Agile Modeling
OpenUp
Management 3.0
LESS
Scrum@Scaled
SAFe
Nexus
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
MANIFESTO ÁGIL
MANIFESTO ÁGIL
MANIFESTO ÁGIL
MANIFESTO ÁGIL
MANIFESTO ÁGIL
MANIFESTO ÁGIL
MANIFESTO ÁGIL
MANIFESTO ÁGIL
MANIFESTO ÁGIL
MANIFESTO ÁGIL
O Manifesto Ágil foi criado por 17 profissionais
praticantes dos métodos ágeis, que se juntaram e
declararam valores e princípios para o
desenvolvimento de softwares. Pode-se dizer que o
manifesto ágil aborda os valores que todos esses
profissionais acordaram entre si para disseminar
no mundo.
VALORES
Indivíduos e interações mais que processos e
ferramentas
No desenvolvimento de softwares e produtos deve-se
dar muito valor para a colaboração e comunicação
entre as pessoas, e simplificar os processos e
ferramentas.
Software em funcionamento mais que documentação
abrangente
O software funcionando perfeitamente e entregue ao
cliente é um indicador muito importante para sua
equipe, e a documentação deve ser complementar para
agregar valor ao negócio.
Colaboração com o cliente mais que negociação de
contratos
Colaboração com o cliente é muito importante para a
construção de um   software de sucesso, onde o
resultado e felicidade do cliente é mais
importante do que negociações de contrato.
Responder as mudanças mais que seguir um plano
Na construção de softwares e produtos, muitas
vezes vivemos em ambientes de alta incerteza. Por
isso devemos ser adaptáveis e responder as
mundanças rapidamente.
2
Aceitar mudanças de requisitos, mesmo no fim do
desenvolvimento. Processos ágeis se adequam a
mudanças, para que o cliente possa tirar vantagens
competitivas.
6
O método mais eficiente e eficaz de transmitir
informações para, e por dentro de um time de
desenvolvimento, é através de uma conversa cara a
cara.
PRINCÍPIOS
1 Nossa maior prioridade é satisfazer o cliente, atravésda entrega adiantada e contínua de software de valor.
3
Entregar software funcionando com frequência, na escala
de semanas até meses, com preferência aos períodos mais
curtos.
4
Pessoas relacionadas à negócios e desenvolvedores devem
trabalhar em conjunto e diariamente, durante todo o
curso do projeto.
5
Construir projetos ao redor de indivíduos motivados,
dando a eles o ambiente e suporte necessário e
confiando que farão seu trabalho.
7
8
9
10
Software funcional é a medida primária de progresso.
Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser
capazes de manter indefinidamente passos constantes.
Contínua atenção à excelência técnica e bom design
aumenta a agilidade.
Simplicidade: a arte de maximizar a quantidade de
trabalho que não precisou ser feito.
11 As melhores arquiteturas, requisitos e designs emergemde times auto-organizáveis.
12
Em intervalos regulares, o time reflete em como ficar
mais efetivo, então, se ajustam e otimizam seu
comportamento de acordo.
SCRUM
SCRUM
SCRUM
SCRUM
SCRUM
SCRUM
O Scrum é um framework dentro da qual as pessoas
podem resolver problemas complexos, ao mesmo
tempo em que fornecem produtos viáveis de forma
produtiva e criativa do maior valor possível.
Desenvolvido e mantido por Ken Schwaber e Jeff
Sutherland, é utilizado para gerenciar o
desenvolvimento de produtos desde 1990.
PILARES
TRANSPARÊNCIA
Alinhamento entre os envolvidos no projeto, clareza
nos padrões utilizados, de modo que fique visível
e entendido por todos os membros do time.
INSPEÇÃO
Os artefatos e o trabalho devem ser inspecionados
frequentemente por todos os membros do time.
ADAPTAÇÃO
Somos transparentes, inspecionamos e por fim
adaptamos. Esse é o ciclo do Scrum e a adaptação é
a melhoria incremental dos processos.
O Scrum é fundamentado nas teorias empíricas de
controle de processo e emprega abordagem iterativa
e incremental para aperfeiçoar a previsibilidade e
o controle de riscos. Três pilares apoiam a
implementação de controle de processo empírico:
transparência, inspeção e adaptação.
VALORES
CORAGEM
Todos devem ter coragem de fazer as coisas
certas e trabalhar em problemas difíceis.
FOCO
Todos concentrados no trabalho e nos
objetivos da Sprint.
COMPROMETIMENTO
Todos se comprometem pessoalmente com os
objetivos da equipe.
RESPEITO
Todos se respeitam, são capazes e
independentes.
ABERTURA
Abertura e Transparência entre todas as
partes interessadas. Desde o time de
desenvolvimento até o cliente.
EVENTOS
SPRINT
Time-Boxed fixa onde o time Scrum se compromete a
desenvolver tudo que foi definido.
SPRINT PLANNING
Planejamento do que será desenvolvido na Sprint.
DAILY SCRUM
Reunião diária de alinhamento do time de
desenvolvimento.
SPRINT REVIEW
Reunião para apresentar para as partes interessadas
o que foi desenvolvido na Sprint.
SPRINT RETROSPECTIVE
Reunião onde é discutido os pontos positivos e
negativos para melhorias contínuas.
ARTEFATOS
BACKLOG DO PRODUTO
Lista priorizada de tudo que deve ser necessário no
desenvolvimento do produto. Cada funcionalidade que
será construída no produto deve ser descrita no
backlog.
BACKLOG DA SPRINT
Lista priorizada de tudo que será desenvolvido na
Sprint atual. Ou seja, itens do Backlog do produto
são incluídos no Backlog da Sprint para
desenvolvimento.
INCREMENTO
Resultado do que foi desenvolvido na Sprint. Sempre
no final de cada Sprint o time de desenvolvimento
entrega os itens que foram concluídos na Sprint, e
esse incremento deve ser entregável e utilizável
pelo cliente.
SCRUM MASTER
O Scrum Master é a pessoa que mais
conhece o framework Scrum. Ele é
responsável por fazer com que o
Scrum seja entendido e aplicado.
Além de ser muito bom em processos,
o Scrum Master é um líder servidor e
facilitador do time.
PRODUCT OWNER
O Product Owner é o dono do produto.
Ele representa o cliente dentro do
time Scrum e é responsável por
maximizar o valor do produto e do
trabalho do time de desenvolvimento.
O TIME SCRUM
TIME DE DESENVOLVIMENTO
O Time de Desenvolvimento é
responsável por desenvolver e
entregar uma versão usável que
potencialmente incrementa o produto
"Pronto" ao final de cada Sprint.
Estrutura do Scrum
KANBAN
KANBAN
KANBAN
KANBAN
KANBAN
KANBAN
O Kanban é um framework utilizado para montar um
fluxo de trabalho tendo como objetivo a melhoria
de processos existentes. O Kanban ajuda a
controlar o progresso de suas tarefas de forma
visual. Normalmente é construído em uma parede
com as colunas necessárias para o fluxo de
trabalho, utilizando post-it para descrever as
tarefas do que precisa ser feito em cada etapa.
PRINCÍPIOS
COMECE COM O QUE VOCÊ FAZ AGORA
Entender os processos atuais e como eles são
praticados na organização.
INCENTIVE ATOS DE LIDERANÇA EM TODOS OS NÍVEIS.
Indiferente do cargo que ocupa, qualquer indivíduo
pode sugerir ideias para mostrar liderança e
implementar mudanças que promovam melhorias
contínuas.
O Kanban atualmente é muito utilizado no processo de
desenvolvimento de software e está ganhando muitaforça ao redor do mundo como uma forma de
implementar uma metodologia ágil nas organizações. 
O Kanban possui quatro princípios fundamentais:
RESPEITE O PROCESSO ATUAL, PAPÉIS E RESPONSABILIDADES
Valorizar os processos, funções, responsabilidades e
títulos existentes.
CONCORDE EM BUSCAR MUDANÇAS INCREMENTAIS EVOLUTIVAS.
Buscar passos de melhorias permanente e incentivar
pequenas mudanças incrementais e evolutivas.
O Kanban é fortemente utilizado por gestores nas
equipes de projetos para gerenciar o fluxo de
trabalho e processos porém, pode ser executado
por qualquer pessoa que queira gerenciar o seu
fluxo de trabalho, tanto profissional quanto
pessoal.
BOAS PRÁTICAS
VISUALIZAR O FLUXO DE TRABALHO
Criar um fluxo de trabalho para a equipe, onde fique
visível e possível de identificar o que realmente
está sendo feito. A transparência faz com que o time
trabalhe em conjunto pensando no todo.
LIMITAR O TRABALHO EM ANDAMENTO (WIP)
WIP - Work In Progress. Estabelecer limites para a
quantidade de trabalho em andamento, resultando num
ritmo equilibrado da equipe.
GERENCIAR O FLUXO
Gerenciar o fluxo de trabalho e não as pessoas.
Deve-se focar em gerenciar o processo de trabalho e
entender como obter resultados mais rapidamente.
Exemplo de Estrutura do Kanban
TORNAR AS POLÍTICAS DO PROCESSO EXPLÍCITAS
Não se pode melhorar algo que não se entende.
Portanto, o processo deve ser claramente definido,
publicado e socializado.
FEEDBACKS CONSTANTES
Estimular as reuniões diárias para sincronização da
equipe e revisão dos processos.
MELHOR DE FORMA COLABORATIVA
Compartilhar com o time o fluxo de trabalho, processos
e riscos, assim a equipe pode sugerir etapas e
melhorias.
BENEFÍCIOS
GESTÃO VISUAL
Todos da equipe têm acesso as atividade e visualização
do movimento das tarefas.
SIMPLES
Permite que todos participem com facilidade da gestão
de sua própria tarefa.
ACESSO A INFORMAÇÃO
Permite que todas tenham acesso à informação mesmo não
sendo de sua responsabilidade.
PRIORIZAÇÃO
O time recebe as tarefas definidas e priorizadas pelo
gestor.
FACILIDADE NO FLUXO DE TRABALHO
Permite criar fases no Kanban, contribuindo para que
haja menos desperdício nas operações.
INCENTIVO A COMUNICAÇÃO
Incentiva a comunicação entre o time, pois ele tem a
visão do todo. Sabe exatamente o que cada membro está
fazendo.
LEAN STARTUP
LEAN STARTUP
LEAN STARTUP
LEAN STARTUP
LEAN STARTUP
LEAN STARTUP
LEAN STARTUP
LEAN STARTUP
 LEAN STARTUP 
LEAN STARTUP
Lean Startup ou “Startup Enxuta” é um conceito
utilizado no meio empreendedor para criação de
novos produtos ou serviços. Envolve uma dinâmica
de aprendizagem validada e eliminação de
desperdícios nos processos. Está muito atrelado
ao ambiente de Startups de tecnologia,
trabalhando com foco total na VISÃO, DIREÇÃO E
ACELERAÇÃO.
VISÃO
Defende a ideia de uma nova disciplina de
administração empresarial. Define quem é
empreendedor, define uma Startup e maneira
de as Startups medirem sua progressão,
denominada aprendizagem validada, podendo
utilizar a experimentação científica para
descobrir como desenvolver um negócio
sustentável.
DIREÇÃO
Analisa o método da Startup enxuta e o
ciclo de Feedbacks para construir-medir-
aprender. Constrói o MVP (Produto Mínimo
Viável), mede a progressão e utiliza um
método para pivotar ou perseverar.
ACELERAÇÃO
Acelera o ciclo de Feedbacks construir-
medir-aprender mesmo durante sua expansão.
Crescendo, adaptando e inovando da maneira
correta.
PRINCÍPIOS
EMPREENDEDORES ESTÃO POR TODA PARTE
Em todo mundo existe pessoas empreendendo e criando
novos produtos ou serviços e a abordagem da Startup
enxuta pode funcionar para empresas de qualquer
tamanho, setor ou atividade.
Medir
Aprender
Construir
CONSTRUIR-MEDIR-APRENDER
Pivotar ou perseverar, Startups estão trabalhando
constantemente com esse contexto. Sua atividade
principal é transformar ideias em produtos ou
serviços, medir a satisfação dos futuros clientes e
pivotar caso algo dê errado, ou perseverar se
estiver no caminho certo. O sucesso de qualquer
Startup está voltado a acelerar esse ciclo de
feedbacks.
EMPREENDER É ADMINISTRAR
Constituída em um cenário de extrema incerteza, as
Startups que dependem da inovação para seu
crescimento, necessitam de uma gestão administrativa
que vise o crescimento futuro.
APRENDIZADO VALIDADO
Startups são criadas não apenas com o propósito de
ganhar dinheiro, fabricar coisas ou atender
clientes, mas também para aprender a desenvolver um
negócio sustentável. Esse aprendizado pode ser
validado por meio de experimentações que permite
testar e validar cada elemento de sua visão.
CONTABILIDADE PARA INOVAÇÃO
Precisa-se medir o progresso, definir marcos e como
priorizar o trabalho. Isso requer um novo tipo de
contabilidade desenvolvida para Startups e para as
pessoas responsáveis por elas.
Empreendedores e para qualquer outra pessoa que
pensa em inovar ou construir algo. Neste caso, não
temos um papel específico da metodologia como temos
no SCRUM. Este conceito de Startup é para todos.
Caso você pense em construir algo, aprofunde-se
nesse conceito e terá resultados incríveis.
PAPÉIS
LEAN INCEPTION
LEAN INCEPTION
LEAN INCEPTION
LEAN INCEPTION
LEAN INCEPTION
LEAN INCEPTION
LEAN INCEPTION
LEAN INCEPTION
LEAN INCEPTION
LEAN INCEPTION
Lean Inception é uma sequência de atividades que
ajuda uma equipe a definir as funcionalidades de
um MVP (Minimum Viable Product). Muito semelhante
ao Lean Startup quando fala-se em aprender, medir
e construir, porém o Lean Inception foca em
“construir” o produto certo.
A Lean Inception é utilizada quando a empresa
precisa desenvolver um MVP de um produto que será
de forma iterativa e incremental. Ou seja,
primeiro é definido o MVP, construído, validado e
após isso, é possível identificar se o caminho
está certo e se pode continuar a desenvolver o
produto.
A Lean Inception tem um papel específico que é o
facilitador, este conduz as etapas facilitando a
construção do MVP.
MINIMUM VIABLE PRODUCT
MVP (Minimum Viable Product), de acordo com Paulo
Caroli, é a versão mais simples de um produto que
pode ser disponibilizada para o negócio. O MVP
determina quais são as funcionalidades mais
essenciais para que se tenha o mínimo de produto
funcional que agrega valor para o negócio e que
possa ser efetivamente utilizado e validado pelo
usuário final.
Após vários experimentos com atividades que buscam
aceitar o todo, mas que focam em MVPs, o autor da
Lean Inception documentou uma receita, um passo a
passo que está sendo aplicado em todo o mundo e
tendo muito sucesso nos projetos.
NÃO É UM MVP
É UM MVP
OS 7 PASSOS DA LEAN INCEPTION
2 6
1
3 4 51
2 3 4
VISÃO DO PRODUTO - Entender claramente a visão
do produto, o caminho e a estratégia a ser
trilhada.
Para [cliente final]
cujo [problema que precisa ser resolvido],
o [nome do produto]
é um[categoria do produto]
que [benefício-chave, razão para adquiri-lo].
Diferentemente da [alternativa da concorrência],
o nosso produto[diferença-chave]
O produto é…
O produto não é…
O produto faz…
O produto não faz…
OBJETIVOS DO PRODUTO - Decidir o que é o
produto, o que não é, o que faz e o que não
faz.
1
2
PERSONAS - Descrever a persona, suas
características e suas necessidades
específicas.
FUNCIONALIDADES - Descrever as funcionalidades
do produto, que é a interação da persona com o
produto.
Values
These are the guiding
principles that will influence
your actions to fulfill your
company's mission and
vision.
3
4
JORNADA DO USUÁRIO - Descrever a jornada do
usuário através de uma sequência de passos dados
para alcançar um objetivo com a utilização do
produto.
SEQUENCIADOR DE FUNCIONALIDADES - Definir a
prioridade das funcionalidades do produto.
Qual objetivo tal persona quer
alcançar?
Como ela começa seu dia?
O que ela faz antes disso?
5
6
1
2
3
4
5
O CANVAS MVP é a ultima etapa da Lean Inception, e
é nessa atividade que todas as etapas anteriores
são colocadas a prova com blocos bem definidos,
específicose essenciais para confirmar o MVP em
questão.
O Canvas MVP é dividido em sete blocos, que
respondem as seguintes perguntas.
PROPOSTA DO MVP
Qual é a proposta deste MVP?
PERSONAS SEGMENTADAS
Para quem é esse MVP? Pode-se segmentar e
testar este MVP em um grupo menor?
JORNADAS
Quais jornadas são atendidas ou melhoradas com
este MVP?
FUNCIONALIDADES
O que será construido neste MVP? Que ações
serão simplificadas ou melhoradas neste MVP?
RESULTADO ESPERADO
Qual aprendizado ou resultado será buscado
neste MVP?
MÉTRICAS VALIDAÇÃO DE HIPÓTESES DE NEGÓCIOS
Como pode-se medir os resultados deste MVP?
CUSTO E CRONOGRAMA
Qual é o custo e a data prevista para a
entrega deste MVP?
2
6
1
3
4
5
7
DESIGN THINKING
DESIGN THINKING
DESIGN THINKING
DESIGN THINKING
DESIGN THINKING
DESIGN THINKING
DESIGN THINKING
DESIGN THINKING
DESIGN THINKING
 
DESIGN THINKING
É uma abordagem que veio para revolucionar a
maneira de encontrar soluções para os problemas e
desafios das organizações e da sociedade, focadas
nas necessidades reais do mercado e sobretudo nas
pessoas.
O DESIGN THINKING É UMA MANEIRA DE RESOLVER
PROBLEMAS ATRAVÉS DA CRIATIVIDADE .
O DESIGN THINKING BASEIA-SE
EM TRÊS VALORES .
Basear-se nesses três modelos significa trabalhar em
grupos, se colocar no lugar das outras pessoas,
estudar seus comportamentos, explorar e
experimentar.
EMPATIA COLABORAÇÃO
EXPERIMENTAÇÃO
Os Designers Thinkers são apaixonados por resolver
problemas, independentemente do nível de
complexidade e do contexto. A partir da visão do
design, consegue-se mapear o sistema e as pessoas,
extraindo quais são as reais dores e a partir disso,
são capazes de experimentar e criar novas soluções.
ETAPAS DO DESIGN THINKING
Aproximar as pessoas interessadas e levantar as
informações para entendimento do problema.
IMERSÃO
IDEAÇÃO
PROTOTIPAÇÃO
VALIDAÇÃO
Gerar ideias inovadoras através de atividades
colaborativas que promovem a criatividade e
inovação.
Tangibilizar as ideias a fim de retira-las do papel
através de protótipos funcionais.
Validar os protótipos e coloca-los a prova. Nesta
etapa busca-se apresentar ao cliente os protótipos
funcionais através de provas de conceito, para ver
se realmente atende a necessidade do cliente.
DESIGNERS THINKERS
SERVICE DESIGN
SERVICE DESIGN
SERVICE DESIGN
SERVICE DESIGN
SERVICE DESIGN
SERVICE DESIGN
SERVICE DESIGN
SERVICE DESIGN
SERVICE DESIGN
SERVICE DESIGN
Marc Stickdorn e Jakob Schneider, autores do livro
best-seller This is Service Design Thinking,
descrevem cinco princípios fundamentais a serem
lembrados ao repensar em serviço.
O Service Design é uma abordagem que coloca as
pessoas em primeiro lugar para projetar
experiências de serviços ao invés de produtos.
PRINCÍPIOS
CENTRADO NO USUÁRIO
Serviços concebidos e testados através do olhar do
cliente.
SEQUENCIAL
Ações sequenciais inter-relacionadas promovendo a
experiência completa e gerando um resultado final na
mente do cliente.
EVIDENTE
Evidenciar os processos e os entregáveis intangíveis
para o cliente.
CO-CRIATIVO
Todos os stakeholders devem estar incluídos no
processo e trabalharem colaborativamente.
VISÃO HOLÍSTICA
Visão organizacional com um todo.
DESIGN SPRINT
DESIGN SPRINT
DESIGN SPRINT
DESIGN SPRINT
DESIGN SPRINT
DESIGN SPRINT
DESIGN SPRINT
DESIGN SPRINT
DESIGN SPRINT
DESIGN SPRINT
O Design Sprint é uma metodologia desenvolvida
pela Google Ventures, que ocorre durante um
período de 5 dias. Tem como objetivo responder
questões críticas de negócios por meio de
prototipagem rápida e testes do usuário.
Não existe um papel específico para esta
metodologia. Apenas, recomenda-se que o facilitador
tenha habilidades para conduzir essas fases.
CRONOGRAMA 
O time vai compartilhar tudo que eles sabem
sobre o assunto. É o dia de mapear e
entender o problema.DIA 1
FASES DO SPRINT
Após discutidas e lapidadas todas as
soluções, o time escolhe uma única solução
a ser prototipada. Além da solução, é
definido um storyboad com o passo a passo
para o protótipo.
Hora de validar os protótipos e colocá-los
à prova. Nesta etapa busca-se apresentar ao
cliente os protótipos funcionais, através
de provas de conceito para ver se realmente
atende a necessidade do cliente.
Dia de produzir. O time concentra-se em
gerar um protótipo mais próximo do real.
Por esse motivo é importante escolher uma
ferramenta em que o time esteja
habitualmente confortável para trabalhar
rapidamente.
DIA 3
DIA 4
DIA 5
DIA 2
Cada membro do time rabisca suas ideias,
colocando suas soluções no papel. Feito
isso, o time analisa e discute todas as
soluções.
KA IZEN
KA IZEN
KA IZEN
KA IZEN
KA IZEN
KA IZEN
Kaizen vem do japonês e significa “Mudança para
Melhor”. Não é uma metodologia ágil, mas é tão
importante quanto as já citadas. O Kaizen é uma
filosofia e no contexto empresarial é utilizado
para ciclos de melhorias contínuas, resultando na
redução de custos e desperdícios, e no aumento de
produtividade.
" HOJE MELHOR DO QUE ONTEM . AMANHÃ MELHOR DO QUE HOJE . "
ZEN = MELHOR
- Todos os desperdícios devem ser eliminados;
 
- Todos os colaboradores devem ser envolvidos no
processo de melhoria;
 
- O aumento da produtividade deve ser baseado em
ações de baixo investimento;
 
- Pode ser aplicado em qualquer ambiente;
 
- Apoia-se em uma gestão visual. Funciona muito bem
com o Kanban;
 
- As ações devem ser priorizadas para áreas de maior
necessidade;
 
- Deve ser orientado à processos;
 
- Priorizar as pessoas e depois os processos;
 
- Aprender na prática.
MANDAMENTOS
KA I = MUDAR MELHORIA CONTÍNUA
+ =
KA IZEN TAMBÉM TRABALHA EM CONJUNTO COM O 5S
BENEFÍCIOS
Seiton | Organização : Organizar o espaço de
trabalho de forma eficaz.
Seiri | Utilização : Eliminar do espaço de
trabalho o que é inútil.
Seisou | Limpeza : Melhorar o nível de limpeza de
trabalho.
Shitsuke | Disciplina : Todos ajudam na melhoria
contínua.
Seiketsu | Padronização : Regras a serem seguidas
no ambiente de trabalho.
- Redução e eliminação de gastos e desperdícios;
 
- Aumento da produtividade;
 
- Aumento de eficiência operacional;
 
- Maximização de resultados;
 
- Melhoria na qualidade dos serviços;
 
- Organização da estrutura;
 
- Melhoria nos processos internos;
 
- Maior comprometimento e satisfação das pessoas com 
o trabalho.
 
PAPÉIS
O Kaizen não tem um papel específico. Pode ser
gerenciado por um facilitador que tenha conhecimento
da filosofia e que saiba conduzir as etapas de
implementação do Kaizen.
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
EXTREME PROGRAMMING
Extreme Programming, mais conhecida como XP, é uma
estrutura ágil das práticas de engenharia
apropriadas para o desenvolvimento de software. E
uma das metodologias ágeis que cobrem diversos
aspectos técnicos de desenvolvimento de software,
como codificação, design, testes e arquiteturas.
VALORES
COMUNICAÇÃO
O desenvolvimento de software é semelhante à um
esporte de equipe que depende da comunicação para
transferir conhecimento de um membro para todos os
demais da equipe.
SIMPLICIDADE
Trabalhar de forma simples e funcional. O objetivo é
evitar o desperdício e fazer apenas as coisas
absolutamente necessárias, facilitando o suporte e a
manutenção.
FEEDBACKS
Por meio de feedbacks constantes sobre seus esforços
anteriores, as equipes podem identificar áreas de
melhorias e revisar suas práticas.
RESPEITO
Os membros da equipe precisam se respeitar para se
comunicar, trabalhar juntos e fornecer e aceitar
feedbacks que honra este relacionamento.
PRÁTICAS
CORAGEM
Necessita-se de coragem para levantar questões
organizacionais que reduzam a eficácia da equipe.
Necessita-se de coragem para parar de fazer algo que
não funciona e tentar outra coisa. Necessita-se de
coragem para aceitar eagir com base no feedback,
mesmo quando é difícil de aceitar.
INTEGRAÇÃO
CONTÍNUA
TESTE DE
ACEITAÇÃO
PLANEJAMENTO
PROPRIEDADE
COLETIVA
CODIFICAÇÃO
PADRÃO
RITMO
SUSTENTÁVEL
TIME
COESO
ENTREGAS
FREQUENTES
METÁFORA
REFATORAÇÃO
PROGRAMAÇÃO
EM PARES
DESIGN
SIMPLES
TESTE
1
PLANEJAMENTO
Planejamento do que será desenvolvido e definição
das prioridades.
2
ENTREGAS FREQUENTES
Entregas pequenas ao cliente, gerando sempre uma
nova versão publicada.
3
METÁFORA
Transparência ao cliente. As equipes de
programação extrema desenvolvem uma visão comum
de como o programa funciona, nomeada de
"metáfora".
4
DESIGN SIMPLES
Entregar realmente o que o cliente está pedindo,
mas sempre adequado para atender à necessidade.
5
TESTE
Validação durante todo o processo de
desenvolvimento, onde os desenvolvedores
implementam o software criando primeiramente os
testes.
6
TIME COESO
A equipe é formada por desenvolvedores e
clientes.
7
TESTE DE ACEITAÇÃO
Testes construídos pelo cliente para aceitar um
determinado requisito.
8
RITMO SUSTENTÁVEL
Trabalhar com qualidade e seguindo um ritmo de
trabalho consistente, sem fazer horas a mais.
9
REFATORAÇÃO
Limpeza e simplificação no código fonte, sem perder
nenhuma funcionalidade.
10
INTEGRAÇÃO CONTÍNUA
Integrações diárias de funcionalidades na versão
atual do sistema.
11
CODIFICAÇÃO PADRÃO
Padronização na forma de codificação.
12
PRIORIDADE COLETIVA
A responsabilidade é de todos os programadores.
Todos têm acesso e podem melhorar qualquer código
a qualquer momento.
13
PROGRAMAÇÃO EM PARES
A implementação do código é feito em dupla, onde
dois desenvolvedores trabalham em um único
computador.
PAPÉIS
Programador - Responsável pela estimativa e
desenvolvimento da aplicação.
Testador - Responsável por realizar os testes da
aplicação.
Tracker - Responsável por inspecionar o trabalho dos
desenvolvedores.
Cliente - Peça principal no XP. Responsável por
escrever as histórias de usuários da aplicação.
Treinador - Responsável por manter o projeto e ensinar
os membros da equipe.
Gerente - Responsável por conduzir os processos.
Doomsayer - Responsável por acompanhar o projeto e
evitar problemas em sua realização.
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT
FEATURE DRIVEN DEVELOPMENT 
Feature Driven Development, mais conhecida como
(FDD), é uma metodologia que foi criada entre 1997
e 1999, antes do manifesto ágil e que busca o
desenvolvimento por funcionalidades e requisitos
funcionais do sistema.
Planejar as funcionalidades a serem
implementadas, considerando priorização
das tarefas e esforço. Muito parecido
com a organização/priorização do
Backlog no SCRUM.
Elaborar diagramas de sequência e
diagramas de classes, para entendimento
detalhado da funcionalidade a ser
desenvolvida.
ETAPAS DO PROCESSO
Desenvolver um modelo a ser seguido,
identificando o escopo e o contexto do
projeto.
Listar as funcionalidades que devem ser
desenvolvidas. Muito parecido com o
Product Backlog do SCRUM.
Desenvolver e testar as funcionalidades.
CONSTRUIR E TESTAR
POR FUNCIONALIDADES
DESIGNER POR
FUNCIONALIDADES
PLANEJAR POR
FUNCIONALIDADES
CONSTRUIR A LISTA DE
FUNCIONALIDADES
DESENVOLVER UM
MODELO GERAL
BOAS PRÁTICAS
2
DESENVOLVIMENTO POR FUNCIONALIDADE
Implementação orientada por funcionalidade.
3
INSPEÇÕES
Deve ser realizada a revisão de código para garantir
a qualidade do que está sendo desenvolvido.
4
CÓDIGO PROPRIETÁRIO
O código deve ser realizado apenas por um
desenvolvedor, ou seja, iniciado e finalizado pelo
mesmo desenvolvedor.
5
EQUIPE
Equipe preparada para desenvolver funcionalidades
necessárias ao projeto.
6
VISIBILIDADE DOS RESULTADOS
Todos os envolvidos devem saber o status de
desenvolvimento das funcionalidades.
7
INTEGRAÇÃO REGULAR
Em  um determinado período de tempo fixo devem ser
integradas as características já terminadas,
permitindo a verificação de erros e também criando
uma versão atual que pode ser demonstrada ao
cliente.
8
GERÊNCIA DE CONFIGURAÇÃO
Ter ambientes diferentes com versões da
funcionalidade desenvolvida. Atualmente é muito
utilizado um ambiente de desenvolvimento, um de
homologação e outro que é o ambiente estável para
que os clientes utilizem.
MODELAGEM ORIENTADA A OBJETOS DE DOMÍNIO
A modelagem deve ser básica, apenas algo
ilustrativo para os envolvidos no projeto.1
PAPÉIS
Gestor de Projetos
Gestor de Desenvolvimento
Equipe de Designer
Dono da Classe
Escritor Técnico
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
ADAPTIVE SOFTWARE DEVELOPMENT
Adaptive Software Development, mais conhecido como
ASD, ou Desenvolvimento de Software Adaptativo é
uma das metodologias ágeis utilizadas no mercado.
Baseia-se nos ciclos iterativos e incrementais e
na presença constante do cliente durante o
processo. Foi criado em meados dos anos 90 por
John Highsmith e tem como objetivo adaptar as
equipes rapidamente as mudanças de necessidades do
mercado.
Colaboração
PILARES
COLABORAÇÃO
Trabalho em equipe, presença do cliente,
envolvimento de todas as partes e
compartilhamento de informações.
Especulação
Aprendizado
APRENDIZADO
Aprender com os erros e corrigi-los para
as próximas iterações. Isso pode ser feito
com retrospectivas do projeto.
ESPECULAÇÃO
Planejamento do ciclo adaptativo orientado
à riscos. Essa fase consiste em mapeamento
e entendimento de projeto que resultará em
ações para as próximas fases.
PRINCÍPIOS
FOCO NA MISSÃO DO PROJETO
As atividades de cada ciclo de desenvolvimento devem
ser justificadas em relação à missão global do
projeto.
BASEADO EM COMPONENTES
Focar no desenvolvimento e entrega da funcionalidade
como um todo e não apenas em tarefas
individualmente.
ITERATIVIDADE
Desenvolvimento com foco na evolução do produto.
TIME-BOXES
Prazos tangíveis, fixos e realistas.
TOLERANTE À MUDANÇAS
Incorporar as mudanças que forem aparecendo no
desenvolvimento do projeto, dando assim mais valor
ao produto.
RISCOS CONTROLADOS
Analisar os itens de altos riscos e se possível
prioriza-los no desenvolvimento.
PAPÉIS
O time do ASD é muito parecido com o time do FDD,
mas no ASD a presença do cliente é muito importante
e este faz parte do time, além dos gestores de
projetos, equipe de design, desenvolvedores,
analistas de requisitos e testadores.
DSDM
DSDM
DSDM
DSDM
DSDM
DSDM
Dynamic Systems Development Methodology [DSDM],
ou Metodologia de Desenvolvimento de Sistemas
Dinâmicos, foi criada em 1994 e é uma extensão do
método cascata RAD. Também é uma das metodologias
ágeis utilizadas no mercado e usado para
desenvolver softwares com participação contínua
do usuário, baseando-se em um modelo incremental
e iterativo.
 
O DSDM trabalha com orçamento fixo, prazos curtos
e bem definidos. Se difere das demais
metodologias ágeis pois é composta por processos
interligados de modelagem e é restrita no tempo,
sendo um método um pouco mais rígido que os
outros.
PRINCÍPIOS
2
1
3
4
ENVOLVIMENTO
Usuários e desenvolvedores trabalhando juntos de
forma colaborativa para a sucesso do projeto.
AUTONOMIA
As  equipesdevem ter autoridade para tomada de
decisão.
ENTREGAS
Entregas frequentes e incrementais que funcionem
perfeitamente.
CRITÉRIO DE ACEITE
Os entregáveis de desenvolvimento devem ser
funcionalidades que atendem as necessidades
críticas atuais de negócios.
6
5
7
DESENVOLVIMENTO ITERATIVO E INCREMENTAL
O desenvolvimento é incremental e evolutivo por
natureza. É orientado por feedback regulares e
iterativos dos usuários.
REVERSIBILIDADE
Todas as alterações introduzidas durante o
desenvolvimento devem ser reversíveis.
PREVISIBILIDADE
Escopo e requisitos de alto nível devem ser
definidos antes que o projeto se inicie.
8
TESTES CONTÍNUOS
Os testes contínuos de integração e garantia de
qualidade são realizados durante todo o ciclo de
vida do projeto.
9
COMUNICAÇÃO
A visibilidade e a transparência são incentivadas
por meio de comunicação e colaboração regulares
entre todas as partes interessadas no projeto.
O DSDM CONSISTE EM TRÊS FASES
SEQUENCIA IS 
PRÉ-PROJETO
CICLO DE VIDA
DO PROJETO
PÓS-PROJETO
Na fase de Pré-Projetos trabalha-se na definição de
orçamentos, controles rigorosos de recursos e
assinatura de contratos.
Na fase de Pós-Projeto é garantido a eficiência do
software, onde é realizado manutenções, melhorias e
ajustes de acordo com os princípios do DSDM, e
retomando as etapas anteriores se necessário.
Na fase de Ciclo de Vida do Projeto iniciamos um
estudo de viabilidade e negócios, tanto do ponto
funcional como econômico. Nesta fase também é
produzido protótipos incrementais que demonstram
praticidades ao cliente. E através de ciclos de
feedback o software é desenvolvido de forma iterativa
e incremental até chegar ao implemento final.
CRYSTAL METHOD
CRYSTAL METHOD
CRYSTAL METHOD
CRYSTAL METHOD
CRYSTAL METHOD
CRYSTAL METHOD
CRYSTAL METHOD
CRYSTAL METHOD
CRYSTAL METHOD
CRYSTAL METHOD
CRYSTAL METHOD
CRYSTAL METHOD
O Método Crystal é uma abordagem ágil de
desenvolvimento de software que se concentra
principalmente nas pessoas e suas interações ao
trabalhar em um projeto e não em processos e
ferramentas.
 
O método Crystal foi desenvolvido por Alistair
Cockburn em 1991 para IBM. É uma grande família
contendo categorias baseadas em tamanho da equipe,
criticidade e prioridades do projeto.
PILARES
Tamanho do Time
6 pessoas
CLEAR
20 pessoas
YELLOW
40 pessoas
ORANGE
80 pessoas
RED
+ pessoas
MARROM
LARGER SIZE
AZUL
PODER HUMANO
ULTRA LEVE ADAPTATIVO
Pessoas são mais importantes do que processos e
ferramentas. O envolvimento das pessoas nos projetos é
vital, dessa forma os processos e ferramentas devem
ser adaptados para atender às necessidades das
pessoas.
Processos e ferramentas precisam ser adaptados aos
requisitos e características do projeto. Significa que
processos e ferramentas não são fixos, mas precisam
ser ajustados para atender aos requisitos da equipe e
do projeto.
Transparência entre a equipe de desenvolvimento e
cliente sem envolver muita documentação e relatórios.
Isso mantém as coisas leves, concentrando-se no fluxo
de trabalho transparente entre a equipe e o cliente, e
praticando a comunicação aberta entre os membros da
equipe.
PROPRIEDADES
2
1
3
ENTREGA FREQUENTE
Entregas frequentes e testadas a usuários reais.
Dessa forma não é investido tempo no produto que
ninguém deseja comprar.
MELHORIA REFLEXIVA
Não é prescritivo e a experimentação é um
elemento chave no Crystal Clear. Permite que a
equipe reflita após as execuções e implemente
melhorias futuras.
ACESSO FÁCIL A USUÁRIOS ESPECIALIZADOS
O Crystal Clear permite que a equipe de
desenvolvimento mantenha a comunicação e obtenha
feedback regular de usuários reais.
6
5
7
FOCO
Cada membro da equipe sabe exatamente no que
trabalhar, o que lhes permite concentrar sua
atenção e evitar a alternância de uma tarefa
para outra.
SEGURANÇA PESSOAL
Os membros da equipe devem ser transparentes sem
medo de serem interrogados. Devem se sentir à
vontade para trazer novas ideias quanto para
falar de problemas correntes.
AMBIENTE TÉCNICO
O objetivo principal do ambiente técnico é fazer
integração e teste contínuos para identificar
erros. A integração contínua ocorre regularmente
usando testes automatizados, gerenciamento de
configuração e integração frequente.
4
COMUNICAÇÃO OSMÓTICA
Refere-se a um bate papo com o time de
desenvolvimento para discutir alguns assuntos
que podem estar ocorrendo no dia a dia da
equipe. O time deve estar concentrado no
objetivo da conversa, onde a ideia é aproximar o
time e remover barreiras.
PAPÉIS
Patrocinador Executivo
Designer Líder
Desenvolvedores
Desenvolvedor
Especialista
Testador
Usuários
Coordenadores de
Projetos
Escritor Técnico
Especialista de
Negócios
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
DISCIPLINED AGILE DELIVERY
O Disciplined Agile Delivery (D.A.D) é uma
metodologia desenvolvida por Scott Ambler e Mark
Lines em 2009 para a IBM e que adota práticas e
estratégias de diversos métodos, pois uma das
grandes vantagens do desenvolvimento ágil e enxuto
é a riqueza de práticas, técnicas e estratégias
disponíveis.
 
Foi construído para cobrir todo o ciclo de vida da
entrega do produto, tendo seu foco na entrega. É um
ciclo de vida de três fases no qual você constrói
incrementalmente um produto.
CONSTRUÇÃO
Fase de construção do produto. Onde o time
desenvolve o que foi solicitado e através de um
fluxo incremental vai evoluindo o produto.
TRANSIÇÃO
Simplicidade nos processos de implantação. Essa fase
deve ser rápida, sem dificuldades e transparente
para o cliente.
IMERSÃO
Fase de iniciação do projeto, entendimento,
levantamento das informações, construção do MVP e
definição do time de desenvolvimento.
Planejamento Construção Incremental Release
Imersão Construção Transição
Próxima Release
Tester
Independente
Expert de Domínio
Técnico Expert
Integrador
Especialista
PAPÉIS
Stakeholder
Lider do Time
Membros do Time Dono do Produto
Dono da Arquitetura
AGILE MODELING
AGILE MODELING
AGILE MODELING
AGILE MODELING
AGILE MODELING
AGILE MODELING
AGILE MODELING
AGILE MODELING
AGILE MODELING
AGILE MODELING
AGILE MODELING
AGILE MODELING
Agile Modeling é uma metodologia baseada nas
práticas para modelagem e documentação eficazes de
sistemas baseados em software”. O objetivo é
aplicar as práticas recomendadas ao software de
modelagem no processo de desenvolvimento ágil para
garantir que as necessidades da equipe de
desenvolvimento e das partes interessadas sejam
atendidas.
O Agile Modeling tem princípios e práticas a serem
seguidas para que a execução tenha exito em um
projeto. Para garantir o sucesso da modelagem,deve-
se manter um registro da evolução da modelagem, isso
permite o fornecimento de uma imagem do que está
sendo feito as partes interessadas, além de obter 
feedbacks.
VALORES
COMUNICAÇÃO
Promover a comunicação entre as equipes através dos
modelos desenvolvidos.
SIMPLICIDADE
Desenhar as ideias e aprimorá-las através de
diagramas.
FEEDBACK
Feedback rápido ao apresentar as ideias através de
diagramas.
CORAGEM
Coragem para tomada de decisão.
HUMILDADE
Humildade para reconhecer os erros e aprender com
os outros.
OPEN UP
OPEN UP
OPEN UP
OPEN UP
OPEN UP
OPEN UP
OPEN UP
OPEN UP
Open UP, ou Processo Unificado aberto, é uma
metodologia ágil de desenvolvimento de software
criada pela IBM e baseada nas principais
características do RUP. Aplica uma abordagem
iterativa e incremental dentro de um ciclo de vida
estruturado e abraça uma filosofia pragmática e
ágil que foca na natureza colaborativa do
desenvolvimento de software.
IMERSÃO
Fase onde os  stakeholders  e os membros da equipe
colaborampara determinar o escopo e os objetivos do
projeto, dando menor ênfase na arquitetura e
implementação.
ELABORAÇÃO
Fase onde se enfatiza o processo de desenvolvimento
da análise arquitetural da solução proposta.
CONSTRUÇÃO
Fase em que se enfatiza o processo de
desenvolvimento e implementação da solução proposta,
bem como, testes e integração.
TRANSIÇÃO
Fase de implantação, onde a aplicação desenvolvida
passa para o ambiente do cliente e na obtenção da
concordância dos  stakeholders  de que o
desenvolvimento do produto está completo.
Imersão Elaboração Construção Transição
PRINCÍPIOS
EQUILIBRAR AS PRIORIDADES
Promover práticas que permitam aos stakeholders
desenvolver uma solução que maximize os benefícios,
e que seja compatível com as restrições impostas ao
projeto.
ALINHAR INTERESSES
Promover práticas que estimulem um ambiente de
trabalho saudável, e que as equipes colaborem e
desenvolvam uma compreensão compartilhada do
projeto.
ARQUITETURA
Focar na arquitetura o mais cedo possível, para que
ao começar o desenvolvimento da aplicação, o time de
desenvolvedores já tenha tudo definido, reduzindo
assim riscos e retrabalhos da equipe.
FEEDBACKS
Promover ciclos de feedback entre os stakeholders.
PAPÉIS
O time do OPEN UP é formado por arquitetos, gerentes
de projetos, analistas, testadores, desenvolvedores
e stakeholders.
MANAGEMENT 3 .0
MANAGEMENT 3 .0
MANAGEMENT 3 .0
MANAGEMENT 3 .0
MANAGEMENT 3 .0
MANAGEMENT 3 .0
MANAGEMENT 3 .0
MANAGEMENT 3 .0
MANAGEMENT 3 .0
 MANAGEMENT 3 .0 
MANAGEMENT 3 .0
MANAGEMENT 3 .0
O Management 3.0 é uma mentalidade combinada com
uma coleção de jogos em constante mudança,
ferramentas e práticas para ajudar qualquer
trabalhador a gerenciar a organização. É uma
maneira de ver os sistemas de trabalho e uma nova
forma de gestão de liderança.
Não é uma metodologia ágil, mas ao trabalhar com
pessoas, é necessário saber tratá-las da maneira
certa. O management 3.0 ensina os líderes, através
de técnicas e jogos a deixarem de ser
centralizadores da informação e ensina a
compartilhar a responsabilidade com todos do grupo.
"O MANAGEMENT 3 .0 ESTÁ REDEFININDO A DEFINIÇÃO
DE LIDERANÇA, COM O GERENCIAMENTO COMO UMA
RESPONSABILIDADE DO GRUPO".
O MANAGEMENT 3 .0 É UMA REVOLUÇÃO GLOBAL DE
GERENCIAMENTO QUE REÚNE MILHARES DE GERENTES
DE PROJETO , GERENTES DE NÍVEL INTERMEDIÁRIO ,
CEO 'S E EMPREENDEDORES , DESENVOLVENDO
SOLUÇÕES JUNTOS , USANDO JOGOS PARA INCENTIVAR
O FEEDBACK DOS FUNCIONÁRIOS E A COLABORAÇÃO
EM EQUIPE .
MARTIE
É um monstro do gerenciamento
de seis olhos e simboliza as
seis visões organizacionais do
Management 3.0
ENERGIZAR PESSOAS
Manter o time motivado e engajado.
EMPONDERAR TIMES
Capacitar e delegar responsabilidades ao time.
ALINHAR RESTRIÇÕES
Manter os propósitos claros e objetivos definidos.
DESENVOLVER COMPETÊNCIAS
Contribuir para o desenvolvimento das competências
do time.
ESTRUTURA DE CRESCIMENTO
Criar uma estrutura organizacional que contribua na
facilidade de comunicação.
MELHORAR TUDO
Pessoas, equipes e organizações precisam melhorar
continuamente.
LESS
LESS
LESS
LESS
LESS
LESS
O Large Scale Scrum (LESS) é o Framework SCRUM em
larga escala. Utiliza as mesmas cerimônias e
papéis, porém de forma escalável. É um único
Backlog do Produto dividido entre os times que
estão fazendo parte do projeto, e cada time tem os
itens selecionados a serem desenvolvidos e
entregues na Sprint.
LESS
Utilizado para até 8 equipes de 8 pessoas.
LESS HUGE
Adequado para projetos com mais de 8 times. Milhares
de pessoas trabalhando em um único projeto.
PRINCÍPIOS
SCRUM EM LARGA ESCALA É SCRUM
Scrum aplicado em conceito de grande escala.
TRANSPARÊNCIA
Transparência entre todos os membros da equipe.
FOCO EM TODO O PRODUTO
Foco na gestão do produto como um todo e não em
partes do produto.
MELHORIA CONTÍNUA RUMA A PERFEIÇÃO
Criar e entregar um produto o tempo todo. Ciclo
incremental.
PENSAMENTO ENXUTO
Melhoria contínua e eliminação de desperdícios.
CONTROLE DE PROCESSOS EMPÍRICOS
Inspeção, adaptação e transparência do Scrum.
MAIS COM MENOS
Mais aprendizados e menos processos definidos.
FOCO CENTRADO NO CLIENTE
Identificar o valor agregado para o cliente
eliminando desperdício.
ESTRUTURA
PENSAMENTO SISTÊMICO
Ver, compreender e otimizar o sistema como um todo.
TEORIA DAS FILAS
Gerenciar tamanho de fila, limites de trabalho em
andamento, multitarefas e pacotes de trabalho.
PAPÉIS
O time do LESS é o mesmo time do Scrum, porem vai
crescendo de forma escalável. Em até 8 equipes é
apenas um Product Owner, e conforme as equipes
aumentam, o numero de Product Owners também
aumentam.
SCRUM@SCALE
SCRUM@SCALE
SCRUM@SCALE
SCRUM@SCALE
SCRUM@SCALE
SCRUM@SCALE
SCRUM@SCALE
SCRUM@SCALE
SCRUM@SCALE
SCRUM@SCALE
Scrum@Scaled  é uma estrutura dentro da qual as
redes de Equipes Scrum, operando consistentemente
com o Guia Scrum podem resolver problemas
adaptativos complexos, ao mesmo tempo em que
oferece produtos de forma criativa do maior valor
possível.  Scrum@Scale assim como o Scrum, visa
construir organizações saudáveis, criando uma
cultura orientada por valores em um ambiente
empírico.
A ESTRUTURA
A estrutura em escala do Scrum of Scrums baseia-se
em um conjunto de equipes Scrum que precisam ser
coordenadas para oferecer valor aos clientes. Essa
equipe é responsável por um conjunto totalmente
integrado de incrementos de produto potencialmente
entregáveis no final de cada Sprint de todas as
equipes participantes.
ESCALANDO SOS
FUNÇÕES SOS
Equipe com habilidades necessárias para fornecer um
incremento de produto e facilitar a coordenação
entre as equipes.
EQUIPE DO PROPRIETÁRIO DO PRODUTO
Equipe de proprietários de produtos que alinham as
prioridades da equipe e expectativas com as partes
interessadas.
PROPRIETÁRIO CHEFE DO PRODUTO (CPO)
O proprietário principal do produto (CPO) coordena
prioridades entre os proprietários de produtos que
trabalham com equipes individuais.
SCRUM OF SCRUM MASTER (SOSM)
Responsável pela divulgação do esforço conjunto dos
times e deve tornar o progresso viável para a
organização.
Dependendo do tamanho da organização ou
implementação, pode ser necessário mais de um SoS
para fornecer um produto muito complexo. Nesses
casos, um Scrum de Scrum de Scrums (SoSoS) pode ser
criado a partir de vários Scrums de Scrums.
EQUIPE DE AÇÃO EXECUTIVA (EAT)
A  Equipe de Ação Executiva (EAT)  cumpre a função
Scrum Master para toda a organização ágil. Essa
equipe é responsável pela transformação
organizacional e pela qualidade do Scrum dentro da
organização
EQUIPES DE LIDERANÇA 
EQUIPE METASCRUM (EMT)
A  equipe executiva do MetaScrum (EMT)  cumpre a
função de Product Owner para toda a organização
ágil. Possui uma visão organizacional e é
responsável por definir as prioridades estratégicas,
alinhando todas as equipes em torno de objetivos
comuns.
ESCALANDO O CPO
Assim como o SoS pode se transformar em SoSoS, as
equipes de Product Owner também se expandem pelo
mesmo mecanismo.
DESIGN ORGANIZACIONAL
Scrum@Scale é projetado para saturar uma organização
com Scrum. Todas as equipes, incluindo liderança,
recursos humanos, jurídico, consultoria e
treinamento, e equipes de produtos e serviços,
implementam o mesmo estilo de Scrum enquanto
simplificam e melhoram uma organização.
SAFE
SAFE
SAFE
SAFE
SAFE
SAFE
Scaled Agile Framework, o SAFe é um framework
projetado por Dean Leffinqwell e teve seu
lançamento inicial em 2011, para expandir o
desenvolvimento ágil a nível corporativo escalado
no desenvolvimento de softwares. O SAFe leva como
base o Scrum, Kanban, XP e o Lean, além das
experiências obtidas através de implementações que
funcionaram e não funcionaram em grande escala.
VALORES
ALINHAMENTO
O alinhamento é necessário para acompanhar o ritmo
das mudanças rápidas, forças competitivas
disruptivas e equipes distribuídas geograficamente.
QUALIDADE INTEGRADA
A Qualidade Integrada garante que todos os elementos
e todos os incrementosda solução reflitam os
padrões de qualidade ao longo do ciclo de vida do
desenvolvimento.
TRÂNSPARÊNCIA
Para garantir a abertura e transparência, é
necessária confiança. Existe confiança quando os
negócios e o desenvolvimento podem confiar em outra
pessoa para agir com integridade, principalmente em
momentos de dificuldade.
EXECUÇÃO DE PROGRAMAS
Obviamente, nada do restante do SAFe importa se as
equipes não puderem executar e entregar valor
continuamente. Portanto, a SAFe concentra-se
intensamente em sistemas de trabalho e resultados de
negócios.
PAPÉIS
EQUIPES ÁGEIS
Equipe de Desenvolvimento
Product Owner
Scrum Master
EQUIPE PROGRAMA
Gerenciamento de Produtos
Arquiteto/Engenheiro de 
Sistemas
Engenheiro de Treinamento
de Liberação.
Proprietários de Empresas
EQUIPE DE SOLUÇÕES
GRANDES
Gerenciamento 
de Soluções
Arquiteto/Engenheiro
de Soluções
Engenheiro de Trem de
Soluções
EQUIPE DE PORTFÓLIO
Lean Portfólio 
Management
Arquiteto Corporativo
Proprietários Épicos
OUTRAS FUNÇÕES
System Team
Lean User Experience
Lean Agile Leaders
NEXUS
NEXUS
NEXUS
NEXUS
NEXUS
NEXUS
O Nexus é um framework constituído de papéis,
eventos, artefatos e regras que os unem e
entrelaçam junto o trabalho de aproximadamente três
a nove Times Scrum em um único Backlog do Produto
para construir um incremento integrado que alcance
uma meta.
EVENTOS
REFINAMENTO DO PRODUCT BACKLOG
Representantes apropriados de cada Time Scrum se
reúnem para discutir e revisar o refinamento do
Backlog do Produto.
PLANEJAMENTO DE SPRINT DO NEXUS
Os representantes de cada time scrum selecionam os
itens do backlog em que seu time vai trabalhar e
então com o time planeja sua própria Sprint.
TRABALHO DE DESENVOLVIMENTO
Todos os times frequentemente integram seu trabalho
em um ambiente comum que pode ser testado para
garantir que a integração está feita.
REVISÃO DA SPRINT DO NEXUS
Todos os Times Scrum individualmente se encontram
com as partes interessadas para revisarem o
Incremento Integrado.
ARTEFATOS
REUNIAO DIÁRIA DO NEXUS
Representantes apropriados de cada Time de
Desenvolvimento se encontram diariamente para
identificar se existe alguma questão de integração.
INCREMENTO INTEGRADO
Um Incremento Intregrado representa a soma atual de
todos os trabalhos integrados completados para o
Nexus.
RETROSPECTIVA DA SPRINT DO NEXUS
Representantes apropriados de cada Time Scrum se
encontram para identificar os desafios
compartilhados. Então, cada Time Scrum realiza sua
Reunião de Retrospectiva do Scrum individualmente.
BACKLOG DO PRODUTO
Há um único Backlog do Produto para todo o Nexus e
todos os Times Scrum.
BACKLOG DA SPRINT DO NEXUS
O Backlog da Sprint do Nexus é composto pelos itens
de Backlog do Produto dos Backlogs das Sprints dos
Times Scrum individuais.
 
partida ao buscar mais especialização e
aprofundamento nos métodos abordados aqui.
 
Transformar uma empresa é muito difícil, pois
depende de vários fatores: cultura, pessoas,
processos, tecnologias, mindset, entre outros. Então
comece devagar, experimente esses métodos em
pequenas equipes, faça pilotos e comece a ganhar
maturidade durante o processo. 
 
Feito isso, comece aplicar em outras equipes e quando 
perceber, sua empresa já estará ganhando
maturidade e conseguindo dar os primeiros passos
para a transformação ágil.
 
Não esqueça de medir o progresso do que você está
aplicando. Só assim você saberá se as coisas estão
evoluindo como você planejou.
 
Tenho certeza que, após você conhecer os métodos
ágeis, se aprofundar e entender na prática como
funciona, o cenário da sua organização vai ser
diferente.
o
Uma mensagem para você
objetivo principal desse e-book é te tornar
conhecedor das metodologias mais utilizadas no
mercado, para que você tenha um ponto de 
MICHEL DEUNIZIO
Desenvolvido por
Micheldeunizio
Micheldeunizio
Micheldeunizio@gmail.com
		2020-09-21T04:54:06+0000
	Preflight Ticket Signature