1ºEDIÇÃO 2020

MÉTODOS

ÁGEIS

UM GUIA DEFINITIVO COM MAIS DE

METODOLOGIAS ÁGEIS
20
UTILIZADAS POR GRANDES EMPRESAS PARA

CRIAR O
PRODUTO CERTO

ESCRITO POR

MICHEL DEUNIZIO
 1ºEDIÇÃO 2020

MÉTODOS

ÁGEIS

UM GUIA DEFINITIVO COM MAIS DE

METODOLOGIAS ÁGEIS
20
UTILIZADAS POR GRANDES EMPRESAS PARA

CRIAR O
PRODUTO CERTO

ESCRITO POR

MICHEL DEUNIZIO
 Por que utilizar

Métodos Ágeis?

uito se ouve falar sobre cultura ágil

e a busca por essa transformação
M dentro das empresas.

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.
 SUMÁRIO

01 Manifesto Ágil
02 Scrum
03 Kanban
04 Lean Startup
05 Lean Inception
06 Design Thinking
07 Service Design
08 Design Sprint
09 Kaizen
10 Extreme Programming
11 Feature Driven Development
12 Adaptive Software Development
13 DSDM
14 Crystal Method
15 D.A.D
16 Agile Modeling
17 OpenUp
18 Management 3.0
19 LESS
20 Scrum@Scaled
21 SAFe
22 Nexus
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.
 PRINCÍPIOS

Nossa maior prioridade é satisfazer o cliente, através

1 da entrega adiantada e contínua de software de valor.

Aceitar mudanças de requisitos, mesmo no fim do

desenvolvimento. Processos ágeis se adequam a
2 mudanças, para que o cliente possa tirar vantagens
competitivas.

Entregar software funcionando com frequência, na escala

de semanas até meses, com preferência aos períodos mais
3 curtos.

Pessoas relacionadas à negócios e desenvolvedores devem

trabalhar em conjunto e diariamente, durante todo o
4 curso do projeto.

Construir projetos ao redor de indivíduos motivados,

dando a eles o ambiente e suporte necessário e
5 confiando que farão seu trabalho.

O método mais eficiente e eficaz de transmitir

informações para, e por dentro de um time de
6 desenvolvimento, é através de uma conversa cara a
cara.

Software funcional é a medida primária de progresso.

7

Processos ágeis promovem um ambiente sustentável. Os

patrocinadores, desenvolvedores e usuários, devem ser
8 capazes de manter indefinidamente passos constantes.

Contínua atenção à excelência técnica e bom design

9 aumenta a agilidade.

Simplicidade: a arte de maximizar a quantidade de

10 trabalho que não precisou ser feito.

As melhores arquiteturas, requisitos e designs emergem

11 de times auto-organizáveis.
Em intervalos regulares, o time reflete em como ficar
mais efetivo, então, se ajustam e otimizam seu
12 comportamento de acordo.
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

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.

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.
 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.
 O TIME SCRUM

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.

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

O Kanban atualmente é muito utilizado no processo de

desenvolvimento de software e está ganhando muita
força ao redor do mundo como uma forma de
implementar uma metodologia ágil nas organizações.
O Kanban possui quatro princípios fundamentais:

COMECE COM O QUE VOCÊ FAZ AGORA

Entender os processos atuais e como eles são
praticados na organização.

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.

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.
Exemplo de Estrutura do Kanban

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

Construir

Aprender

Medir

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.

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.

PAPÉIS

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.
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.
 NÃO É UM MVP

1 2 3 4

É UM MVP

1 2 3 4 5 6

OS 7 PASSOS DA LEAN INCEPTION

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.
 VISÃO DO PRODUTO - Entender claramente a visão
do produto, o caminho e a estratégia a ser
1
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]

OBJETIVOS DO PRODUTO - Decidir o que é o

produto, o que não é, o que faz e o que não
2
faz.

O produto é…
O produto não é…
O produto faz…
O produto não faz…
 PERSONAS - Descrever a persona, suas
características e suas necessidades
3
específicas.

FUNCIONALIDADES - Descrever as funcionalidades

do produto, que é a interação da persona com o
4
produto.

Values
These are the guiding
principles that will influence
your actions to fulfill your
company's mission and
vision.
 JORNADA DO USUÁRIO - Descrever a jornada do
usuário através de uma sequência de passos dados
5 para alcançar um objetivo com a utilização do
produto.

Qual objetivo tal persona quer

alcançar?
Como ela começa seu dia?
O que ela faz antes disso?

SEQUENCIADOR DE FUNCIONALIDADES - Definir a

6 prioridade das funcionalidades do produto.

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íficos e essenciais para confirmar o MVP em
questão.
O Canvas MVP é dividido em sete blocos, que
respondem as seguintes perguntas.

PROPOSTA DO MVP
1 Qual é a proposta deste MVP?

PERSONAS SEGMENTADAS
Para quem é esse MVP? Pode-se segmentar e
2
testar este MVP em um grupo menor?

JORNADAS
Quais jornadas são atendidas ou melhoradas com
3
este MVP?

FUNCIONALIDADES
O que será construido neste MVP? Que ações
4
serão simplificadas ou melhoradas neste MVP?

RESULTADO ESPERADO
Qual aprendizado ou resultado será buscado
5
neste MVP?

MÉTRICAS VALIDAÇÃO DE HIPÓTESES DE NEGÓCIOS

6 Como pode-se medir os resultados deste MVP?

CUSTO E CRONOGRAMA
Qual é o custo e a data prevista para a
7
entrega deste MVP?
DESIGN THINKING

DESIGN THINKING

DESIGN THINKING

DESIGN THINKING

DESIGN THINKING

DESIGN THINKING

DESIGN THINKING

DESIGN THINKING

DESIGN THINKING
 O DESIGN THINKING É UMA MANEIRA DE RESOLVER

PROBLEMAS ATRAVÉS DA CRIATIVIDADE.

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

EXPERIMENTAÇÃO

EMPATIA
COLABORAÇÃO
 ETAPAS DO DESIGN THINKING

IMERSÃO

Aproximar as pessoas interessadas e levantar as

informações para entendimento do problema.

IDEAÇÃO

Gerar ideias inovadoras através de atividades

colaborativas que promovem a criatividade e
inovação.

PROTOTIPAÇÃO

Tangibilizar as ideias a fim de retira-las do papel

através de protótipos funcionais.

VALIDAÇÃO

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

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.
SERVICE DESIGN

SERVICE DESIGN

SERVICE DESIGN

SERVICE DESIGN

SERVICE DESIGN

SERVICE DESIGN

SERVICE DESIGN

SERVICE DESIGN

SERVICE DESIGN
 O Service Design é uma abordagem que coloca as
pessoas em primeiro lugar para projetar
experiências de serviços ao invés de produtos.
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.

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

FASES DO SPRINT

CRONOGRAMA

O time vai compartilhar tudo que eles sabem

sobre o assunto. É o dia de mapear e
DIA 1
entender o problema.
 Cada membro do time rabisca suas ideias,
colocando suas soluções no papel. Feito
DIA 2 isso, o time analisa e discute todas as
soluções.

Após discutidas e lapidadas todas as

soluções, o time escolhe uma única solução
a ser prototipada. Além da solução, é
DIA 3
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
DIA 4
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
DIA 5 ferramenta em que o time esteja
habitualmente confortável para trabalhar
rapidamente.
KAIZEN

KAIZEN

KAIZEN

KAIZEN

KAIZEN
 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. "

+ =

KAI = MUDAR ZEN = MELHOR MELHORIA CONTÍNUA

MANDAMENTOS

- 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.
KAIZEN TAMBÉM TRABALHA EM CONJUNTO COM O 5S

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.
Seiketsu | Padronização : Regras a serem seguidas
no ambiente de trabalho.

Shitsuke | Disciplina : Todos ajudam na melhoria

contínua.

BENEFÍCIOS

- 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, 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.
 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 e agir com base no feedback,
mesmo quando é difícil de aceitar.

PRÁTICAS

TIME
COESO

PROPRIEDADE CODIFICAÇÃO
COLETIVA PADRÃO

TESTE

TESTE DE PROGRAMAÇÃO PLANEJAMENTO

REFATORAÇÃO
ACEITAÇÃO EM PARES

INTEGRAÇÃO RITMO
CONTÍNUA DESIGN SUSTENTÁVEL
SIMPLES

METÁFORA

ENTREGAS
FREQUENTES
 PLANEJAMENTO
Planejamento do que será desenvolvido e definição
1
das prioridades.
ENTREGAS FREQUENTES

2 Entregas pequenas ao cliente, gerando sempre uma

nova versão publicada.
METÁFORA
Transparência ao cliente. As equipes de
programação extrema desenvolvem uma visão comum
3
de como o programa funciona, nomeada de
"metáfora".
DESIGN SIMPLES
Entregar realmente o que o cliente está pedindo,
4
mas sempre adequado para atender à necessidade.

TESTE
Validação durante todo o processo de
desenvolvimento, onde os desenvolvedores
5
implementam o software criando primeiramente os
testes.

TIME COESO
A equipe é formada por desenvolvedores e
6
clientes.

TESTE DE ACEITAÇÃO
Testes construídos pelo cliente para aceitar um
7
determinado requisito.

RITMO SUSTENTÁVEL
Trabalhar com qualidade e seguindo um ritmo de
8
trabalho consistente, sem fazer horas a mais.

REFATORAÇÃO
Limpeza e simplificação no código fonte, sem perder
9 nenhuma funcionalidade.
 INTEGRAÇÃO CONTÍNUA
Integrações diárias de funcionalidades na versão
10
atual do sistema.

CODIFICAÇÃO PADRÃO
11 Padronização na forma de codificação.

PRIORIDADE COLETIVA
A responsabilidade é de todos os programadores.
12 Todos têm acesso e podem melhorar qualquer código
a qualquer momento.

PROGRAMAÇÃO EM PARES
A implementação do código é feito em dupla, onde
13 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, 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.

ETAPAS DO PROCESSO

Desenvolver um modelo a ser seguido,

identificando o escopo e o contexto do
projeto.
DESENVOLVER UM

MODELO GERAL

Listar as funcionalidades que devem ser

desenvolvidas. Muito parecido com o
Product Backlog do SCRUM.
CONSTRUIR A LISTA DE

FUNCIONALIDADES

Planejar as funcionalidades a serem

implementadas, considerando priorização
das tarefas e esforço. Muito parecido
PLANEJAR POR
com a organização/priorização do
FUNCIONALIDADES
Backlog no SCRUM.

Elaborar diagramas de sequência e

diagramas de classes, para entendimento
detalhado da funcionalidade a ser
desenvolvida.
DESIGNER POR

FUNCIONALIDADES

Desenvolver e testar as funcionalidades.

CONSTRUIR E TESTAR

POR FUNCIONALIDADES
 BOAS PRÁTICAS

MODELAGEM ORIENTADA A OBJETOS DE DOMÍNIO

A modelagem deve ser básica, apenas algo
1
ilustrativo para os envolvidos no projeto.

DESENVOLVIMENTO POR FUNCIONALIDADE

2 Implementação orientada por funcionalidade.

INSPEÇÕES
Deve ser realizada a revisão de código para garantir
3 a qualidade do que está sendo desenvolvido.

CÓDIGO PROPRIETÁRIO
O código deve ser realizado apenas por um
4 desenvolvedor, ou seja, iniciado e finalizado pelo
mesmo desenvolvedor.

EQUIPE
Equipe preparada para desenvolver funcionalidades
5 necessárias ao projeto.

VISIBILIDADE DOS RESULTADOS

Todos os envolvidos devem saber o status de
6
desenvolvimento das funcionalidades.

INTEGRAÇÃO REGULAR
Em um determinado período de tempo fixo devem ser
integradas as características já terminadas,
7 permitindo a verificação de erros e também criando
uma versão atual que pode ser demonstrada ao
cliente.

GERÊNCIA DE CONFIGURAÇÃO
Ter ambientes diferentes com versões da
funcionalidade desenvolvida. Atualmente é muito
8 utilizado um ambiente de desenvolvimento, um de
homologação e outro que é o ambiente estável para
que os clientes utilizem.
 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, 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.

PILARES

Colaboração

Aprendizado
Especulação

COLABORAÇÃO
Trabalho em equipe, presença do cliente,
envolvimento de todas as partes e
compartilhamento de informações.

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

ENVOLVIMENTO

1 Usuários e desenvolvedores trabalhando juntos de

forma colaborativa para a sucesso do projeto.

AUTONOMIA
As equipes devem ter autoridade para tomada de
2
decisão.

ENTREGAS
Entregas frequentes e incrementais que funcionem
3
perfeitamente.

CRITÉRIO DE ACEITE
Os entregáveis de desenvolvimento devem ser
4 funcionalidades que atendem as necessidades
críticas atuais de negócios.
 DESENVOLVIMENTO ITERATIVO E INCREMENTAL
O desenvolvimento é incremental e evolutivo por
5 natureza. É orientado por feedback regulares e
iterativos dos usuários.

REVERSIBILIDADE
Todas as alterações introduzidas durante o
6 desenvolvimento devem ser reversíveis.

PREVISIBILIDADE
Escopo e requisitos de alto nível devem ser
7 definidos antes que o projeto se inicie.

TESTES CONTÍNUOS
Os testes contínuos de integração e garantia de
8 qualidade são realizados durante todo o ciclo de
vida do projeto.

COMUNICAÇÃO
A visibilidade e a transparência são incentivadas
9 por meio de comunicação e colaboração regulares
entre todas as partes interessadas no projeto.

O DSDM CONSISTE EM TRÊS FASES

SEQUENCIAIS

PRÉ-PROJETO

CICLO DE VIDA
PÓS-PROJETO

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

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

6 pessoas 20 pessoas 40 pessoas 80 pessoas + pessoas LARGER SIZE

CLEAR YELLOW ORANGE RED MARROM AZUL

Tamanho do Time

PILARES

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

ENTREGA FREQUENTE
Entregas frequentes e testadas a usuários reais.
1 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
2 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
3 desenvolvimento mantenha a comunicação e obtenha
feedback regular de usuários reais.
 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
4
equipe. O time deve estar concentrado no
objetivo da conversa, onde a ideia é aproximar o
time e remover barreiras.

FOCO
Cada membro da equipe sabe exatamente no que
trabalhar, o que lhes permite concentrar sua
5
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 à
6 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
7 erros. A integração contínua ocorre regularmente
usando testes automatizados, gerenciamento de
configuração e integração frequente.

PAPÉIS

Patrocinador Executivo Usuários

Designer Líder Coordenadores de
Desenvolvedores Projetos
Desenvolvedor Escritor Técnico
Especialista Especialista de
Testador 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

 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.

Próxima Release

Imersão Construção Transição

Planejamento Construção Incremental Release

IMERSÃO
Fase de iniciação do projeto, entendimento,
levantamento das informações, construção do MVP e
definição do time de desenvolvimento.

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.
 PAPÉIS

Lider do Time

Membros do Time Dono do Produto

Stakeholder

Dono da Arquitetura

Especialista

Tester

Independente Técnico Expert

Expert de Domínio Integrador

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.

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.

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.
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
colaboram para 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
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".
 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.

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

ESTRUTURA

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

ESCALANDO SOS

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.
EQUIPES DE LIDERANÇA

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

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
 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 incrementos da 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 PORTFÓLIO

Equipe de Desenvolvimento Lean Portfólio
Product Owner Management
Scrum Master Arquiteto Corporativo
Proprietários Épicos

EQUIPE PROGRAMA EQUIPE DE SOLUÇÕES

GRANDES
Gerenciamento de Produtos
Arquiteto/Engenheiro de Gerenciamento
Sistemas de Soluções
Engenheiro de Treinamento Arquiteto/Engenheiro
de Liberação. de Soluções
Proprietários de Empresas Engenheiro de Trem de
Soluções

OUTRAS FUNÇÕES
System Team
Lean User Experience
Lean Agile Leaders
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.
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.

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.

ARTEFATOS

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.

INCREMENTO INTEGRADO
Um Incremento Intregrado representa a soma atual de
todos os trabalhos integrados completados para o
Nexus.
 Uma mensagem para você

objetivo principal desse e-book é te tornar

conhecedor das metodologias mais utilizadas no
o mercado, para que você tenha um ponto de
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.
 Desenvolvido por

MICHEL DEUNIZIO

Micheldeunizio

Micheldeunizio

Micheldeunizio@gmail.com