AGILIDADE ORGANIZACIONAL DAD (NPG5638) Disciplined Agile

Prévia do material em texto

E-book
Disciplined Agile
Fundamentos 
Sumário 
1. Introdução ao DA – Disciplined Agile
2. Mindset do DA
3. Pessoas no DA
4. DAD: Disciplined Agile Delivery
5. Disciplined DevOps
6. DA Flex: Fluxo de Valor
7. DAE: Delivery Agile Enterprise
8. DA em escala
9. Governança Lean Ágil
10. Definindo o WoW (Way of Work)
Capítulo 1 – Introdução ao Disciplined Agile
1.1 Definindo Agilidade Organizacional
1.2 Definindo o Disciplined Agile 
1.3 Histórico do Disciplined Agile
1.4 Escopo do DA
1.1 Definindo Agilidade Organizacional 
O que é Agilidade Organizacional/Empresarial?
É a habilidade que a organização possui em
adaptar-se rapidamente às mudanças no mercado
e no ambiente corporativo em termos de
produtividade e eficácia dos custos.
É altamente focado na entrega de valor aos
stakeholders identificados e na sequência
priorizada de trabalho a ser realizado, alocando
apropriadamente as equipes de produto/serviço.
1.1 Definindo Agilidade Organizacional 
O que é Agilidade Organizacional/Empresarial?
Permite a realização de resultados de alto valor
em menor tempo, com previsibilidade,
sustentabilidade e alta qualidade.
Trabalhando em pequenos incrementos de
entrega que são continuamente ajustados à
necessidade de momento, habilitando mudanças
em direção a custos menores.
É crucial ao sucesso empresarial e não somente à
organizações de TI!
1.2 Definindo o DA - Disciplined Agile 
O que é o DA?
É um kit de ferramentas (tool kit) agnóstico e
pragmático totalmente adaptável ao contexto,
orientado a resultados de valor de forma empírica,
que traz agilidade organizacional/empresarial
(Business Agility).
1.2 Definindo o DA - Disciplined Agile
O que é o DA?
É um compêndio de diversos métodos e abordagens ágeis e tradicionais existentes
que nos orienta na melhor forma das pessoas trabalharem com os arranjos, fluxos,
processos e práticas organizacionais (WoW: Way of Work). Abrange desde o time
de desenvolvimento de soluções e de TI até o nível de operação e estratégia de
negócios, ou seja, vai além da TI.
1.2 Definindo o DA - Disciplined Agile 
O que é o DA?
Agilidade vem como resultado de melhoria
contínua de forma guiada (GCI – Guided
Continuous Improvement) dos processos
organizacionais (PDCA, PDCLearn, PDStudyA),
desde a base até o nível estratégico em produtos,
portfólios, projetos, programas e operações, por
processos de Kaizen estruturados e simplificados,
conforme o contexto, libertando-se de um único
jeito e forma de fazer, um único framework
(portanto, adapta-se constantemente).
Plan Do
CheckAct
Adapt
Plan Do
CheckLearn
Plan Do
StudyAct
Adapt
1.2 Definindo o DA - Disciplined Agile 
O que não é DA?
DA não é um substituto, mas sim um
complemento, uma extensão para os diversos
métodos existentes preparados para o ambiente
corporativo. O DA vai além do projeto e produto.
Não é uma “receita de bolo”: o seu compêndio
deve ser estudado e adaptado a cada realidade
organizacional, por isso, tampouco garante
resultados de transformação imediata.
1.3 Histórico do DA - Disciplined Agile 
2009: IBM, Canadá
O DA nasceu originalmente na IBM em
2009 (DADelivery 0.x) com Scott
Ambler e Mark Lines, que juntos
desenvolveram uma versão DA 0.5, na
qual estabeleceram formalmente o
Disciplined Agile.
1.3 Histórico do DA - Disciplined Agile 
2012: Disciplined Agile Consortium
A partir de 2012, Scott Ambler e Mark
Lines desenvolveram novas versões do
DAD como um “toolkit”, ao qual
estabeleceram o Disciplined Agile
Consortium, que passou a possuir a
propriedade intelectual do DA.
1.3 Histórico do DA - Disciplined Agile 
Jul./2019: Disciplined Agile Consortium
Desde então, o Disciplined Agile
Consortium desenvolveu versões
continuamente melhoradas do DA 1.x a
4.0 e proporcionou treinamento e
consultoria em mais de 30 países,
formando mais de 12 mil praticantes
com mais de 50 mil livros vendidos,
sendo os três principais:
1.3 Histórico do DA - Disciplined Agile 
Ago./2019: Project Management Institute
Em agosto de 2019, o PMI – Project
Management Institute anunciou a
aquisição do DA, unindo forças entre as
instituições para a agilidade
organizacional. Mark e Scott estavam
então focados no desenvolvimento e
melhoria contínua do DA.
1.3 Histórico do DA - Disciplined Agile 
maio/2020: Project Management Institute
Em maio de 2020, o PMI – Project
Management Institute anunciou o
lançamento da última versão, o DA 5.x,
com a atualização do livro “Choose Your
WoW” (principal guia e referência do DA),
mantendo esforços de melhoria contínua e
desenvolvimento empírico do Disciplines
Agile e sua comunidade.
1.4 Escopo do DA: Visões 
O DA considera quatro visões na aplicação e adaptação da agilidade organizacional:
MindSet:
• Princípios
• Promessas
• Guias
Pessoas
Fluxos Práticas
• Estruturas e Equipes
• Papéis
• Responsabilidades
• Diagramas de 
objetivos (Goals)
• Fluxos de trabalho
• Processos 
• Ciclos de Entregas
1.4.1 Escopo do DA: níveis organizacionais 
O toolkit do DA possui um escopo de fundação e mais três níveis que organiza as
quatro visões, de forma a aplicar o DA em todos os níveis organizacionais. (PMI,
2020.)
1) Fundação: contém o mindset do DA (princípios, promessas e guias gerais), práticas (agilidade, Lean, 
abordagens tradicionais, como serial), pessoas (papéis e estruturas de times, além do “passo a passo” de 
escolha da “forma de trabalho” ou WoW - Way of Work). 
3) Fluxo de Valor: une estratégias, governança e gestão (direção - DAE) com a base (DevOps e DAD) em forma de fluxos 
de entrega de valor ao cliente (DA Flex), permitindo tomada de decisão e melhoria de cada parte da organização em 
um contexto geral. Contém: P&D, estratégia, governança, vendas, marketing, operação dos negócios, melhoria 
contínua, gestão de portfólios, programas e produtos/serviços. 
4) DAE – Disciplined Agile Enterprise: é a camada que percebe e responde as mudanças de mercado por meio da cultura 
organizacional e de estruturas que facilitam o trabalho e concentram atenção em demais atividades organizacionais: 
Financeiro, Compras (vendas), Legal (jurídico), Arquitetura Organizacional, Gestão do Pessoal, Gestão da Transformação, 
Gestão do Capital (assets), Tecnologia da Informação (business)
2) Delivered Devops: desenvolvimento de software integrado com operação de TI à operação do negócio, com a
extensão do DA para funções adicionais integradas como: - Segurança (Security), gestão da informação (Data
Management), Help Desk (Support) e gestão dos lançamentos (Release Management), entregues de soluções de
forma disciplinada (DAD).
1.4.2 Escopo do DA: Lâmina dos Processos 
Os processos referenciam as capacidades específicas da organização, compostas,
ao total, de 24 processos nos três níveis de atuação, escolhidos e aplicados
conforme o contexto (PMI, 2020).
Princípios Promessas Guias Ágil Lean Serial Papéis Times WoW
DAD
Disciplined
Agile Delivery
Segurança
Data 
Management
Release
Management
Suporte
Help Desk
Operação
TI
P&D
Pesquisa e Des.
Operação Business
Portfolio 
Management
Product
Management
Estratégia e
Gestão
Governança Marketing Melhoria
Contínua
Vendas Program
Management
Arquitetura
Empresarial
Gestão de 
Pessoas (RH) Gestão da TI
Gestão do 
capital (asset)
Gestão da 
Transformação
Finanças e 
Controladoria
Compras e 
Aquisições
Jurídico
1) Fundação
2) DISCIPLINED DEVOPS
3) FLUXO DE VALOR
4) DAE
Cada processo possui opções:
• Práticas
• Estratégias
• Fluxos específicos 
MindSet Conceitos das Práticas Pessoas 
Fl
u
xo
s:
 p
ro
ce
ss
o
s 
e 
 C
ic
lo
s 
d
e 
En
tr
eg
a 
 
D
ia
gr
am
as
 d
e 
o
b
je
ti
vo
s 
(g
o
al
s)
1.4.3 Escopo do DA: Ciclo de Valor FLEX 
Ciclo de fluxo de entrega de valor entre o cliente e a organização, com base no
modelo FLEX, vinculado ao nível 3 de atuação do DA.
DAD
Clientes
Internos + Externos
Estratégia
Gerenciamento
de Portfólio
Gerenciamento
de Produto
Governança Arquitetura
Empresarial
Segurança Gerenciamento
de dados
Melhoria
ContínuaGerenciamento
de Programa
Gerenciamento
de Release
Operação
TI
Operação Negócio
R
ealização
 d
e V
alo
r
Implementação
Solução
Consumível
MBIs – Minimum 
Business Increment
Fl
u
xo
 d
o
 
V
al
o
r
In
ic
ia
ti
va
s
fi
n
an
ci
ad
as
Suporte
1.4.4 Escopo do DA: Ciclos de Entrega 
Ciclo Waterfall: Ciclo completo de desenvolvimento com começo, meio e fim
(Beginning-to-end), para o lançamento de soluções tipicamente de hardware,
soluções físicas construídas By-Design, sob escopo definido. Não é tratado no
escopo do DAD, mas existe para escolha do ciclo no WoW (capítulo 9).
Requisitos
Validação
Validação
Teste de
Aceitação
Validação
Arquitetura
Testes de 
integração
Arquitetura Testes de 
Função
Construção Unidade de 
Teste
1.4.4 Escopo do DA: Ciclos de Entrega 
Ciclos interativos incrementais: Ciclo completo de desenvolvimento com começo,
meio e fim (Beginning-to-end), para o lançamento (release) de uma versão de
software ou projeto, que contempla aspectos híbridos de entrega e a entrega da
operação, explorada no DAD – Disciplined Agile Delivery.
DAD
Próximo lançamento (Release)
Construção (Construction) TransiçãoConstruçãoInserção
Seguir a direção
certa
Construir incrementalmente uma solução testável Lançar (release) 
solução para 
produção
1.4.5 Escopo do DA: Metas de Processos (Goals)
São guias de processos de trabalho e entregas para atingirem os objetivos de cada fase
do ciclo de entrega de forma ágil, ao total de 21 processos, que podem ser escolhidos
conforme o jeito de trabalho definido (WoW), o contexto e a escala de atuação. Cada
processo possui um diagrama associado.
Ongoing: ao longo das três fases, trabalhar e melhorar as entregas e a empresa. 
Transição: Lançar solução para produçãoConstrução: Construir incrementalmente solução testávelInserção: Seguir a direção certa
Formar equipes
Alinhar com a Direção da Empresa
Explorar o Escopo
Identificar a Estratégia da Arquitetura
Planejar o lançamento
Desenvolver a Estratégia de Teste
Desenvolver a visão comum
Assegurar o Financiamento
Desenvolver membros da equipe
Gerenciar (governar) equipes de entregaEvoluir o WoW – Way of Work
Coordenar Atividades
Analisar e endereçar Riscos
Aprimorar a infraestrutura existente
Identificar/Provar a Arquitetura logo
Endereçar mudanças necessárias dos 
Stakeholders
Produzir uma solução potencial testável
Aprimorar a Qualidade
Acelerar a Entrega de Valor
Garantir prontidão à operação
Implantar a solução
1.4.5 Escopo do DA: Metas de Processos (Goals)
Cada processo possui um “diagrama” de metas associado que ajuda na análise.
Ao total, são 21 diagramas prescritos no handbook - Choose of WoW (AMBLER;
LINES, 2020, pagina 305, figura 22.1), com a seguinte estrutura:
Desenvolver membros da equipe
Aprimorar 
habilidades e 
conhecimento
Fornecer feedback
Equipe
Sustentável
Desenvolver 
membros da equipe
1.4.6 Escopo do DA: Melhoria Contínua Guiada
É fundamental ao crescimento e à adaptação da
organização de forma cada vez mais ágil. É
altamente enfatizada no DA.
O ciclo de melhoria contínua guiada é pragmática
e influenciada pela forma de atuar do Lean
Change e vai além da entrega de produtos e
projetos. Visa também acelerar a melhoria em
todos os aspectos e níveis organizacionais e
fluxos de valor.
Identificar o 
problema
Identificar a 
potencial melhoria
Tentar novos 
experimentos
Atestar efetividade
Adotar o novo
WoW
Abandonar o novo
WoW
Compartilhar 
aprendizados 
com outros 
1.4.7 Escopo do DA: Agilidade em Escala
O toolkit do DA suporta dois tipos de agilidade 
em escala com base da avaliação e 
entendimento do contexto.
Agilidade em escala estratégica: aplicada ao 
nível dos fluxos de valor e das áreas de gestão 
além do desenvolvimento das soluções e 
operações.
Agilidade em escala tática: aplicada aos níveis 
de entrega de solução, com os times de 
desenvolvimento e operação.
Capítulo 2 – MindSet do Disciplined Agile
2.1 O mindset do Disciplined Agile 
2.2 Princípios do DA
2.3 Promessas do DA
2.4 Guias gerais do DA
2.1 O mindset do DA 
Princípios Guias geraisPromessas
O mindset é criado pelos três pilares juntos: a partir 
dos princípios, as nossas promessas em adotá-los, e 
guias gerais para suas aplicações e implementações.
Princípios
2.1 Pilares do mindset do DA 
Fornecem a base ou 
fundação psicológica para 
a agilidade 
organizacional. 
Tem fundamentação do 
Lean e conceitos de fluxo.
Guias geraisPromessas
Acordos que realizamos 
com o time, stakeholders 
e outras pessoas na 
organização.
Coleção de 
comportamentos 
disciplinados que nos faz 
colaborar de forma mais 
eficaz e profissional. 
Nos ajudam a ser mais 
eficazes na definição e 
condução do nosso “jeito 
de trabalhar” 
(WoW – Way of Work).
Nos ajudam a melhorar 
continuamente. 
2.1 Pilares do Mindset do DA 
Guias gerais
• Validar o aprendizado;
• Aplicar o Design Thinking;
• Atender ao relacionamento 
por meio de entrega de valor;
• Criar ambientes de alegria e 
satisfação;
• Mudar a cultura por meio da 
melhoria do sistema;
• Criar equipes autogeridas e 
semiautônomas;
• Adotar índices de medição 
para a melhoria;
• Melhorar o capital 
organizacional.
Princípios
• Encantar os clientes;
• Ser incrível;
• Contextualizar; 
• Ser pragmático;
• Ter escolhas;
• Otimizar o fluxo;
• Organizar em 
produtos/serviços;
• Conhecer a empresa.
Promessas
• Criar segurança psicológica e 
abraçar a diversidade;
• Acelerar a entrega de valor;
• Colaborar proativamente;
• Fazer todo o trabalho e seu 
fluxo visível;
• Melhorar a previsibilidade;
• Manter o fluxo de trabalho 
conforme a capacidade;
• Melhorar continuamente.
2.2 Princípios do DA 
• Encantar os clientes: precisamos ir além de
satisfazer as necessidades, além de atender
expectativas: devemos buscar encantar! Se não o
fizermos, alguém o fará e perderemos o cliente,
sejam externos ou internos.
• Ser incrível: buscar fazer o melhor que podemos
e sempre melhorar. Quem não quer trabalhar com
pessoas incríveis, em times incríveis e em
organizações incríveis?
• Contextualizar: cada pessoa, cada time, cada
organização é única, onde enfrentamos situações
únicas. Devemos escolher “o jeito de trabalhar”
(WoW: Way of Work) que atenda a esse contexto.
Princípios
• Encantar os clientes;
• Ser incrível;
• Contextualizar ;
• Ser pragmático;
• Ter escolhas;
• Otimizar o fluxo;
• Organizar em 
produtos/serviços;
• Conhecer a empresa.
2.2 Princípios do DA 
• Ser pragmático: nossa meta não é ser ágil, é ser o
mais efetivo possível e melhorar a partir daí. Para
isso, precisamos ser pragmáticos, usar o ágil, o
Lean, as abordagens tradicionais e as híbridas ou
quaisquer que façam sentido ao nosso contexto.
• Fazer escolhas: para definir o WoW orientado, é
necessário escolher de forma pragmática as
técnicas e práticas que melhor se adequam ao
contexto e entender os possíveis resultados
(trade-offs) associados.
• Otimizar o fluxo: otimizar o fluxo de entrega de
valor ao qual participamos e ainda melhorar o
fluxo na organização, ir além do WoW do seu time
para melhorar as entregas aos clientes.
Princípios
• Encantar os clientes;
• Ser incrível;
• Contextualizar; 
• Ser pragmático;
• Ter escolhas;
• Otimizar o fluxo;
• Organizar em 
produtos/serviços;
• Conhecer a empresa.
2.2 Princípios do DA 
• Organizar em produtos/serviços: para encantar
clientes, precisamos organizar, nós mesmos, os
produtos e serviços que eles precisam e que
atendam o fluxo de valor.
• Conhecer a empresa: Agilistas Disciplinados
(Disciplined Agilists) olham além das necessidades
do time, tendo em consideração as necessidades
da organização. Adotam, personalizam (tailoring)
e orientam a agilidade organizacional. Pedem,
interpretam e emitem feedbacks, potencializam e
melhoram o capital organizacional, buscando o
melhor possível.
Princípios
• Encantar os clientes;
• Ser incrível;
• Contextualizar; 
• Ser pragmático
• Fazer escolhas;
• Otimizar o fluxo;
• Organizar em 
produtos/serviços;• Conhecer a empresa.
2.2 Princípios do DA 
Escolhendo o jeito de trabalhar (WoW): A
organização deve, de forma estruturada, definir o
jeito de trabalhar conforme o contexto, sempre o
revendo com novo olhar a fim adaptá-lo; os
princípios assim são priorizados, por exemplo:
1. Encantar clientes;
2. Organizar em produtos e serviços;
3. Ser pragmático;
4. Contextualizar;
5. Conhecer a empresa;
6. Fazer escolhas;
7. Otimizar o fluxo;
8. Ser incrível.
Princípios
• Encantar os clientes;
• Ser incrível;
• Contextualizar; 
• Ser pragmático;
• Fazer escolhas;
• Otimizar o fluxo;
• Organizar em 
produtos/serviços;
• Conhecer a empresa. +
 Im
p
o
rt
an
te
2.3 Promessas do DA 
• Criar segurança psicológica e abraçar a
diversidade:
Significa dar conforto às pessoas para expressar suas
ideias e pontos de vista sem o medo de represálias,
além de incentivar um ambiente de diversidade,
reconhecendo a unicidade de cada um e da própria
organização como fator de desenvolvimento criativo
e de inovação. Quanto mais diverso o time, melhores
são as ideias, melhor o WoW e cada vez mais iremos
aprender e desenvolver.
Promessas
• Criar segurança psicológica 
e abraçar a diversidade;
• Acelerar a entrega de valor;
• Colaborar proativamente;
• Fazer todo o trabalho e seu 
fluxo visível;
• Melhorar a previsibilidade;
• Manter o fluxo de trabalho 
conforme a capacidade;
• Melhorar continuamente.
2.3 Promessas do DA 
• Acelerar a entrega de valor: no DA, valor se
refere à relevância (o valor) que se dá aos clientes
e ao negócio.
Valor ao cliente: algo que traz benefício a quem
consome um produto ou serviço que nosso time
criou ou desenvolveu. É tipicamente o que o ágil foca
no DA e é evidente que o range abrange outras
partes interessadas internas.
Valor ao negócio: algo que traz benefício à
organização e talvez, indiretamente, aos clientes. Por
exemplo, a redução de custos e de recursos usados
com a melhoria dos processos de forma constante e
substancial.
Promessas
• Criar segurança psicológica e 
abraçar a diversidade;
• Acelerar a entrega de valor;
• Colaborar proativamente;
• Fazer todo o trabalho e seu 
fluxo visível;
• Melhorar a previsibilidade;
• Manter o fluxo de trabalho 
conforme a capacidade;
• Melhorar continuamente.
2.3 Promessas do DA 
• Colaborar proativamente: Agilistas disciplinados
buscam por adicionar valor, como um todo, aos
seus times e aos seus indivíduos, assim como
além destes. Isso implica em colaborar com
pessoas além do time de trabalho, em outros
papéis ou em outros times. Não por requisição,
mas sim voluntariamente!
• Fazer todo o trabalho e seu fluxo visível: Times
DA fazem o fluxo do trabalho individual e do time
sempre visível, com foco crítico e exclusivo no
status do trabalho em processo, mediante regras
explícitas, sendo:
trabalho em processo = trabalho em progresso + trabalho em espera 
Promessas
• Criar segurança psicológica 
e abraçar a diversidade.
• Acelerar a entrega de valor;
• Colaborar proativamente;
• Fazer todo o trabalho e seu 
fluxo visível;
• Melhorar a previsibilidade;
• Manter o fluxo de trabalho 
conforme a capacidade;
• Melhorar continuamente.
2.3 Promessas do DA 
• Melhorar a previsibilidade: Times DA buscam
melhorar a previsibilidade para permitir maior
colaboração e autogerenciamento de forma
eficiente, além de aumentar a chance de atender
as expectativas das partes interessadas.
• Manter o fluxo de trabalho conforme a
capacidade: Operar além da capacidade é
problemático, tanto a nível individual como em
time, com efeito direto na produtividade.
Individualmente, muitas pessoas irão se
desmotivar e se frustrar, outros se sentirão
empoderados, mas terão burnout no longo prazo.
Em visão de time, irá gerar excesso de multitarefa
que, por sua vez, irá aumentar o overhead.
Promessas
• Criar segurança psicológica 
e abraçar a diversidade;
• Acelerar a entrega de valor;
• Colaborar proativamente;
• Fazer todo o trabalho e seu 
fluxo visível;
• Melhorar a previsibilidade;
• Manter o fluxo de trabalho 
conforme a capacidade;
• Melhorar continuamente.
2.3 Promessas do DA 
• Melhorar continuamente:
As organizações realmente bem sucedidas, tais como
Apple, Amazon, eBay, Facebook, Google, Sony,
Toyota, dentre outras, possuem uma única
característica em comum: elas buscam melhorias
continuamente.
Essas organizações entenderam que, para
permanecerem competitivos, precisam olhar
regularmente para dentro, encontrar maneiras de
melhorar as competências das pessoas, das
estruturas, dos processos e dos resultados
entregues.
Promessas
• Criar segurança psicológica 
e abraçar a diversidade;
• Acelerar a entrega de valor;
• Colaborar proativamente;
• Fazer todo o trabalho e seu 
fluxo visível;
• Melhorar a previsibilidade;
• Manter o fluxo de trabalho 
conforme a capacidade;
• Melhorar continuamente.
2.4 Guias gerais do DA 
• Validar nosso aprendizado:
A única forma de melhorar é experimentar e
encontrar novas formas de trabalhar (WoW). No GCI
– Guided continuous improvement, ou Melhoria
Contínua Orientada, novas formas são testadas,
avaliadas, aprendidas e validadas. Se os resultados
forem de valor, são implementadas!
Se faz necessário estar aberto ao empirismo para
que o processo de melhoria por meio do
aprendizado seja recompensado!
Guias gerais
• Validar o aprendizado;
• Aplicar o Design Thinking;
• Atender ao relacionamento 
por meio da entrega de valor;
• Criar ambientes de alegria e 
satisfação;
• Mudar a cultura por meio da 
melhoria do sistema;
• Criar equipes autogeridas e 
semiautônomas;
• Adotar índices de medição 
para a melhoria;
• Melhorar o capital 
organizacional.
2.4 Guias gerais do DA 
• Aplicar o Design Thinking: Encantar os clientes
resulta em criar fluxos de processos operacionais
de valor desenhados com a visão orientado ao
cliente. Design Thinking significa empatia com a
visão do cliente, entendendo o cliente e o
ambiente, antes de desenvolver uma solução.
• Atender ao relacionamento por meio da entrega
de valor: A interação entre as pessoas para criar o
trabalho/produto é a chave, sendo ou não parte
do time. Por exemplo, especialistas em outras
áreas podem testar as soluções ou participar de
partes do desenvolvimento e fornecer
observações. Portanto, é importante garantir
interações eficazes.
Guias gerais
• Validar o aprendizado;
• Aplicar o Design Thinking;
• Atender ao relacionamento
por meio da entrega de valor;
• Criar ambientes de alegria e 
satisfação;
• Mudar a cultura por meio da 
melhoria do sistema;
• Criar equipes autogeridas e 
semiautônomas;
• Adotar índices de medição 
para a melhoria;
• Melhorar o capital 
organizacional.
2.4 Guias gerais do DA 
• Criar ambientes de alegria e satisfação:
Queremos trabalhar em uma empresa que nos
traga experiências e que também nos faça sentir
satisfeitos e realizados. Ambientes agradáveis e
desafiadores mantêm e atraem as melhores
pessoas.
• Mudar a cultura por meio da melhoria do
sistema: Cultura é importante! A mudança de
cultura é um fator crítico em transformação ágil
organizacional. A realidade é que não se muda
isso diretamente, pois a cultura da empresa é o
reflexo do sistema de gerenciamento vigente.
Portanto, é preciso melhorar o sistema antes de
possibilitar a melhora da cultura.
Guias gerais
• Validar o aprendizado;
• Aplicar o Design Thinking;
• Atender ao relacionamento 
por meio da entrega de valor;
• Criar ambientes de alegria e 
satisfação;
• Mudar a cultura por meio da 
melhoria do sistema;
• Criar equipes autogeridas e 
semiautônomas;
• Adotar índices de medição 
para a melhoria;
• Melhorar o capital 
organizacional.
2.4 Guias gerais do DA 
• Criar equipes autogeridas e semiautônomas:
Organizações são sistemas complexos adaptativos
(CAS - Complex Adaptative Systems) feitos da rede de
times e/ou de times de times. O conceito de
agilidade evidencia a necessidade de um “grande
time” autônomo (ideal).
Mas, em uma organização, nenhum time trabalha
sozinho. Existem interdependências entre times
horizontaise verticais, assim como dependências
entre produtos e serviços ofertados em virtude dos
recursos. Dessa forma, as equipes precisam de uma
coordenação que é necessária para garantir esse
alinhamento e uma alocação de recursos.
Guias gerais
• Validar o aprendizado;
• Aplicar o Design Thinking;
• Atender ao relacionamento por 
meio da entrega de valor;
• Criar ambientes de alegria e 
satisfação;
• Mudar a cultura por meio da 
melhoria do sistema;
• Criar equipes autogeridas e 
semiautônomas;
• Adotar índices de medição 
para a melhoria;
• Melhorar o capital 
organizacional.
2.4 Guias gerais do DA 
• Adotar índices de medição para a melhoria:
Metas e prioridades são definidas para todas as
equipes e, para melhorar, se faz necessário medir
o progresso e o desempenho, porém, de forma
flexível e ajustada ao contexto.
• Melhorar o capital organizacional: uma empresa
tem muitos bens e capital (assets), como sistemas
de informação, ferramentas, procedimentos,
processos, modelos, dentre outros, que os times
podem usar e adotar para melhorar a eficácia,
bem como adaptá-los e melhorá-los com base no
aprendizado.
Guias gerais
• Validar o aprendizado;
• Aplicar o Design Thinking;
• Atender ao relacionamento por 
meio da entrega de valor;
• Criar ambientes de alegria e 
satisfação;
• Mudar a cultura por meio da 
melhoria do sistema;
• Criar equipes autogeridas e 
semiautônomas;
• Adotar índices de medição 
para a melhoria;
• Melhorar o capital 
organizacional.
Capítulo 3 – Pessoas no Disciplined Agile
3.1 Organização DA 
3.2 Equipes DA: características
3.3 Equipes DA: papéis e responsabilidades
3.4 CoP: Comunidades de Práticas
3.5 CoE: Centros de Excelência 
3.1 Organização DA 
Como o próprio nome diz, o DA considera a
empresa como um “organismo” vivo feito das
pessoas que nela trabalham e interagem,
fazendo dela uma organização.
Para o DA, toda organização é um CAS –
Complex Adaptative System (Sistema
Adaptativo Complexo), um sistema em qual o
perfeito entendimento de cada parte individual
não converge em perfeito comportamento de
todo o sistema.
3.1 Organização DA 
Características singulares de um CAS:
• Possui pessoas únicas;
• Múltiplas interações;
• Múltiplas equipes;
• Equipes trabalham de forma única;
• Fluxo disperso das informações.
Um CAS ágil exige altíssimo alinhamento, coordenação e agrupamentos produtivos,
ao mesmo tempo que deve permitir genuína atuação dos princípios, promessas e
guias do DA para permitir a auto-organização e a semiautonomia dos indivíduos e
das equipes em um ambiente em constante adaptação.
3.2 Equipes DA: características 
No DA, as pessoas são organizadas em equipes de acordo com suas
características dentro da organização, tais como:
• Tipo: empresariais, de trabalho, de suporte,
líderes e especialistas.
• Tamanho das equipes: pequenas e médias.
• Tempo de permanência: longo e curto
prazo.
• Distribuição: colocadas, parcialmente
alocadas, distribuídas em subgrupos e
100% dispersas.
3.2 Equipes DA: características
Tipos de equipes:
• Empresariais: equipes formadas em
departamentos, por exemplo: compras,
recursos humanos, engenharia e TI.
• Trabalho (entrega): equipes formadas
para desenvolvimento de soluções.
É comum que os profissionais sejam
membros de ambas as equipes,
trabalhando, por vezes, simultaneamente
nas duas. A discussão sobre a eficácia é
controversa. Pragmaticamente, para o DA,
deve ser avaliado cada contexto.
Time
Time
Time
Empresarial
Trabalho
3.2 Equipes DA: características
Tipos de equipes:
• Empresariais: equipes formadas em
departamentos, por exemplo: compras,
recursos humanos, engenharia e TI.
• Trabalho (equipe): equipes formadas
para desenvolvimento de solução.
• Suporte: ajudam na gestão ou integração
entre equipes de trabalho.
• Especialistas: ajudam na solução de
problemas específicos (ex.: jurídico e
Help Desk), geralmente de caráter
técnico ou de domínio, sob requisição
(requests).
Time
Time
Time
Empresarial
Trabalho
Suporte
Especialistas
Request
Serviço
3.2 Equipes DA: características
Tamanhos das equipes:
Em termos de empresariais, o DA é
pragmático quanto ao contexto
organizacional. É comum equipes
empresariais serem maiores, em que as
pessoas são alocadas em equipes de
trabalho regularmente.
Quanto aos times de trabalho, suporte e
especialistas, sugere-se times de tamanhos
pequenos (o suficiente para possibilitar
comunicação direta e rápida entre todos).
Time
Time
Time
Empresarial
Trabalho
Especialistas
Request
Serviço
Suporte
3.2 Equipes DA: características
Tempo de permanência: times de alta performance de longo prazo estão
tomando espaço das equipes tradicionais de projetos, portanto, decidir entre um
e outro é outro passo importante e definitivo para gerir as pessoas no DA.
Equipes de Projetos Equipes de Longa Permanência
São alocadas, permanecem por um período São contínuas, permanecem em operação
Traz as pessoas para o trabalho Traz o trabalho para a equipe 
Potencial para orçamentação e gestão de recursos 
(overhead)
A Orçamentação é definida por demanda
Motiva construir times de quem está disponível para 
a equipe
Motiva por meio da construção com times existentes 
em processo evolutivo
Acréscimo de recursos é relevante Motiva a melhoria, por meio do ajuste, a forma de 
trabalho
Entrega de curto prazo estimula menor qualidade Endereça a visão de longo prazo com 
sustentabilidade, qualidade e evolução
3.2 Equipes DA: características
Distribuição: tem impacto na coordenação, na integração e na capacidade de
decisão e depende da cultura organizacional.
• Colocadas (colocated): todos em um
mesmo ambiente, ainda podemos
subdividir em mesmo local ou em um
mesmo prédio. De fato, quanto mais
próximo melhor a comunicação e
endereçamento de issues, rápido feedback
e solução de problemas do trabalho.
• Parcialmente localizados (near-located):
alguns ou vários membros estão presentes
fisicamente apenas em parte do trabalho.
3.2 Equipes DA: características
Distribuição: tem impacto na coordenação, na integração e na capacidade de
decisão e depende da cultura organizacional.
• Distribuídos em subgrupos (sub-teams): é
comum nas equipes organizacionais seus
membros, em grande parte, estarem
distribuídos em diversos times de trabalho,
ou até mesmo em subgrupos dos times de
trabalho (ambientes de programas).
• 100% dispersos (fully dispersed): todos
estão dispersos, inclusive fisicamente. É
comum em equipes virtuais e distribuídas
geograficamente à distância.
3.3 Equipes DA: papéis e responsabilidades
O toolkit do DA sugere um conjunto robusto de papéis e responsabilidades desde
equipes de entrega, (hardware, software, outros), suporte, gestão, papéis
específicos dos níveis organizacionais e processos, bem como ágil em escala:
• DAD Papéis Primários
• DAD Papéis de Suporte (Secundários)
• Papéis Disciplined DevOps
• Papéis DAE
• Papéis DA Escala Tática
• Papéis DA Comunidades de Práticas
Avaliaremos cada um desses papéis e equipes em seus respectivos módulos de
aula para facilitar o entendimento.
3.4 CoP: Comunidades de práticas
São comunidades focadas em melhoria contínua, em compartilhar e aprimorar
competências (skills) com um grupo de pessoas organizadas e alinhadas com o
propósito de aprender. Estes realizam sessões e atividades de forma voluntária,
também chamadas de guildas ou tribos, geralmente envolvendo pratictioners
certificados. Geralmente possuem um CoP Lead (líder do CoP), que tem a função
de organizar, facilitar e gerenciar as evoluções da comunidade.
Estratégias e atividades podem incluir:
• Papel CoP Lead: organizador e facilitador
• Fóruns de discussão
• Sessões de treinamento
• Brownbag Lunches
3.5 CoE: Centros de Excelência
Também são voltadas à melhoria contínua, porém, com caráter mais estatutário
(governança). É tipicamente o grupo de experts, cuja função é educar, treinar,
mentoriar as pessoas e, por vezes, também é chamado de comunidade de
experts. Estratégias e subdivisão em grupos mais específicossão comuns, visando
a melhoria contínua. Por exemplo:
• Agile CoEs
• Testing CoEs
• DevOps
• Architectures CoEs
• Compliance CoEs
• Quality CoEs
Capítulo 4 – DAD: Disciplined Agile Delivery
4.1 Definindo DAD
4.2 DAD: Ciclos de Entrega
4.3 DAD: Ciclo Ágil – Base Scrum 
4.4 DAD: Ciclo Entrega Contínua Ágil
4.5 DAD: Ciclo Lean – Base Kanban
4.6 DAD: Ciclo Entrega Contínua Lean
4.7 DAD: Exploratória – Lean StartUp
4.8 DAD: Ciclo de programas (Equipe de equipes)
4.9 DAD: Papéis e Responsabilidades
4.10 DAD: Papéis Primários
4.11 DAD: Papéis de Suporte
4.12 DAD: Aspectos importantes
4.1 Definindo o DAD - Disciplined Agile Delivery 
O que é o DAD?
É uma “abordagem” empírica e híbrida, que possui
o arcabouço dos ciclos de entrega de solução, que
prioriza o trabalho definido pelas pessoas (WoW).
É totalmente orientado ao resultado, com visão
organizacional (não somente ao produto) e
escalável.
É a base (fundação) dos ciclos de entregas com
abordagens iterativas e incrementais.
DAD
Disciplined DevOps
DAIT
DAE
4.1 Definindo o DAD - Disciplined Agile Delivery 
O toolkit de ciclos de entrega do DAD é pragmático, sendo composto de diversos
métodos e frameworks de desenvolvimento de software existentes, essencialmente
com base no Lean e no ágil, que possuem grande abrangência de práticas e técnicas
disponíveis para uso.
4.1 Definindo o DAD - Disciplined Agile Delivery 
A grande vantagem do DAD é escolher “quais” práticas e estratégias existentes
adotar, “quando”, “como” e “se” devemos usar juntos ou separadamente, e assim
definir o seu “jeito de trabalhar” (WoW), quebrando o ciclo/paradigma do método
único para desenvolvimento em ambientes complexos.
4.2 DAD: Ciclos de Entrega (Delivery)
Ciclos iterativos incrementais: com começo, meio e fim (Beginning-to-end), para o
lançamento (release) de uma versão de software ou produto com fundamentação
em abordagem iterativa incremental híbrida. É dividido em três fases sequenciais
distintas, desenvolvidos por iterações, com objetivo de entregar um incremento
(resultado):
DAD
Próximo lançamento (Release)
Construção (Construction)
TransiçãoInserção
Por meio de iterações (ciclos), construindo 
Incrementalmente a solução 
Lançamento da
Solução
Visão e 
Planejamento
de Releases
Iteração
Por meio de iterações (ciclos), construindo 
Incrementalmente a solução 
4.2 DAD: Ciclos de Entrega (Delivery)
Inception (inserção): atividades de iniciação do projeto, de inserção da ideia do
produto em protótipo e planejamento de lançamento (releases) em iterações
(ciclos ou sprints). Geralmente consome uma iteração (sprint) de duas semanas
até um mês.
DAD
Próximo lançamento (Release)
Construção (Construction)
TransiçãoInserção
Visão e 
Planejamento
de Releases
Por meio de iterações (ciclos), construindo 
Incrementalmente a solução 
Lançamento da
Solução
Iteração
Por meio de iterações (ciclos), construindo 
Incrementalmente a solução 
4.2 DAD: Ciclos de Entrega (Delivery)
Construction (Construção): a equipe constrói, por meio de iterações (sprints), os
incrementos da solução para validação e testes, e, com o conjunto sequencial de
iterações, entrega-se a solução por completo, usando práticas do Scrum, XP, Lean,
fluxos contínuos ou híbridos.
DAD
Próximo lançamento (Release)
Construção (Construction)
TransiçãoInserção
Visão e 
Planejamento
de Releases
Por meio de iterações (ciclos), construindo 
incrementalmente a solução 
Lançamento da
Solução
Iteração
Por meio de iterações (ciclos), construindo 
Incrementalmente a solução 
4.2 DAD: Ciclos de Entrega (Delivery)
Transition (Transição): atividades de entrega da solução aos stakeholders, dos
ajustes destes na estrutura e aos processos operacionais, coleta de feedbacks do
uso para revisões e próximo release. Ao longo do tempo, essa fase se torna cada
vez menor, a iteração mais curta, até idealmente desaparecer com a adoção da
entrega contínua.
DAD
Próximo lançamento (Release)
Construção (Construction)
TransiçãoInserção
Visão e 
Planejamento
de Releases
Por meio de iterações (ciclos), construindo 
incrementalmente a solução 
Lançamento da
Solução
Iteração
Por meio de iterações (ciclos), construindo 
Incrementalmente a solução 
4.2 DAD: Ciclos de Entrega (Delivery)
O toolkit do framework (estrutura) do DAD
contempla um conjunto de vários ciclos de
entrega iterativa e incremental (inception,
construction, transition) distintos,
pragmaticamente obtidos por meio de diversas
abordagens já comprovadas e consolidadas
para a escolha da equipe.
É comum os times DAD encontrarem situações
distintas que necessitam de ciclos de entregas
específicos a cada caso.
4.2 DAD: Ciclos de Entrega (Delivery)
O DAD propõe 6 ciclos de entregas:
• Ciclo Ágil: Base Scrum
• Ciclo de Entrega Contínua Ágil
• Ciclo Lean: Base Kanban
• Ciclo de Entrega Contínua Lean
• Ciclo Exploratório: com base no Lean StartUp
• Ciclo de Programa: Equipe de equipes
Os ciclos podem mudar e evoluir com o tempo e a
aplicação!
DAD
Gestão de Programa
Ágil
Lean
Entrega Continua Ágil
Entrega Contínua Lean
Exploratório
4.3 DAD: Ciclo Ágil – Base Scrum
O que é o Ciclo Ágil?
Desenvolvimento de equipes em projetos, adaptado
do framework Scrum. Também é chamado de Ciclo
Básico/Ágil, pois é geralmente pelo qual se inicia a
implementação do DA.
Essa versão de ciclo de entrega é comumente
adotada em ambientes e situações mais comuns de
transição, abrangendo uma extensão do Scrum para
suportar o DA (Disciplined Agile), saindo do RUP
(Rational Unified Process – IBM)
DAD
Ciclo Ágil
Ciclo Básico
4.3 DAD: Ciclo Ágil – Base Scrum 
Gerenciamento
de Produto
Arquitetura
empresarial
Gerenciamento 
de Portfólio: 
Modelagem
Inicial,
Planejamento 
e
Organização
Requisitos
Iniciais
Plano de
Releases
Itens de Alta 
Prioridade
Itens de 
Trabalho
Visão da Arquitetura Inicial
Iteração
Reunião de 
Coordenação 
Diária
Lista da Iteração
Backlog Iteração
Financiamento, Feedbacks e Aprendizados
Wrap-up da Iteração
• Demo com stakeholders
• Decisões de “seguir em frente
• Evoluir o WoW
Solução
Consumível
Testável
Lançamento
Liberar
(release)
na produção
Operações TI:
Solução em 
produção 
Suporte
Uma ou mais iterações curtas
Visão do stakeholder
Arquitetura comprovada
Continuidade Viabilizada
(várias)
Varias iterações produzindo as potenciais entregas (incrementos) da solução testável 
Funcionalidades
Suficientes 
Encantar stakeholders
Produção Pronta
Uma ou mais iterações curtas
Requisição de 
Mudanças
4.3 DAD: Ciclo Ágil – Base Scrum 
Aspectos relevantes:
• É um ciclo iterativo: considera incrementos em sprints,
cerimônias de inspeção, demonstração e adaptação.
• Possui uma work itens list (lista de itens de trabalho), não
um product backlog (backlog do produto).
• Possui uma iteration backlog (lista de itens da iteração)
que converte em atividades das iterações.
• Apresenta milestones (marcos) de transições entre as
fases.
• Mostra claramente as entradas e saídas do Ciclo Ágil.
Ciclo Ágil
Ciclo Básico
4.3 DAD: Ciclo Ágil – Base Scrum
Onde e quando aplicar na prática?
• Quando queremos desenvolver alguma solução com base
em requisitos, que podem vir de clientes internos e
externos mesmo que ainda incompletos.
• Quando é esperado entregas frequentes (iterações) de
incrementos, sejam MVP (Minimum Viable Product) ou
MRF (Minimum Releasable Feature).
• Os níveis de mudanças dos requisitos são altos, porém não
diários ou extremamente rápidos.
• Quando possuímos algum nível de entendimento dos
princípios ágeis e do mindset ágil.
• Onde estamos iniciando a jornada da agilidade em
ambientes de desenvolvimento.
Ciclo Ágil
Ciclo Básico
4.3 DAD: Ciclo Ágil – Base Scrum
DAD é agnóstico: no Ciclo Ágil não existe padrão para terminologias
DAD
DA XP Scrum Spotify
Release / Lançamento Release / Lançamento Release / Lançamento Release / Lançamento
Iteração Iteração Sprint Sprint
Líder de Equipe
Team leader
Treinador
Coach
Scrum Master Agile Coach
Reunião Diária decoordenação
Reunião Diária
Daily Meeting
Reunião Diária Scrum
Daily Scrum Meeting
Huddle
Retrospectiva Retrospectiva Retrospectiva Sprint Retrospectiva
Equipe / time Equipe / Time Equipe / Time Squad / Tribe / Tribo
Architecture Owner Treinador /Coach
Expert em domínio Cliente/Customer Cliente /Customer Cliente/Customer
Lista de itens Backlog Backlog Backlog
4.4 DAD: Ciclo de Entrega Contínua Ágil
O que é o Ciclo de Entrega Contínua Ágil?
Mais aderente a times de longo prazo! Não tem
inception e transições (ou supercurtas dentro das
atividades). Criar os incrementos continuamente e
em tempos menores, mesmo seguindo ritos do Ciclo
Ágil, porém, evolutivo com base no Lean (fluxo
contínuo).
As necessidades de entrega surgem muito
regularmente e são construídas e entregues ao
longo do tempo e de forma rápida. É uma evolução,
quando possível, de produtos, do Ciclo Ágil Básico.
Regularmente estamos entregando soluções.
Práticas de DevOps são importantes para
automatizar e acelerar as entregas.
Ciclo de Entrega Contínua Ágil
4.4 DAD: Ciclo de Entrega Contínua Ágil
DAD
Lançamento da
Solução
Gerenciamento
de Produto
Gerenciamento 
de Portfólio: 
Direções
Itens de Alta 
Prioridade
Itens de 
Trabalho
Arquitetura
empresarial
Iteração
Reunião de 
Coordenação 
Diária
Lista da Iteração
Backlog de 
Iteração
Financiamento, FeedBacks e Aprendizados
Requisição de Mudanças
Wrap-up da Iteração
• Demo com stakeholders
• Decisões de “seguir em frente
• Evoluir o WoW
Solução
Consumível
Testável
Lançamento
Liberar
(release)
na produção
Operações TI:
Solução em 
produção 
Suporte
Várias iterações produzindo as potenciais entregas (incrementos) da solução testável 
Funcionalidades Suficientes 
Encantar stakeholders
Produção Pronta
4.4 DAD: Ciclo de Entrega Contínua Ágil
Aspectos relevantes:
• Continua um ciclo iterativo: considera incrementos
em Sprints, cerimônias de inspeção, demonstração e
adaptação.
• Como já estamos em fluxo, podemos eliminar a fase
de inception e transição, pois o produto entra em
linha conforme é finalizado (setup definido).
• Possui elementos de uma work itens list (lista de itens
de trabalho) e iteration backlog (lista de itens da
iteração) que converte em atividades das iterações.
• Existem somente milestone (marco) de transição de
fase com a operação, de forma prática a saída são
apenas produtos entregues para o cliente. DAD
Ciclo de Entrega Contínua Ágil
4.4 DAD: Ciclo de Entrega Contínua Ágil
Onde e quando aplicar na prática?
• Quando iremos desenvolver uma solução, com base
em apenas um requisito. Requisito este que podem
vir de clientes internos ou externos.
• Os níveis de mudanças dos requisitos são muito altos
e o foco é produção sob demanda, contudo de forma
rápida.
• Espera-se, quando já estamos em fluxo de entregas
mais frequentes (iterações) de incrementos, sejam
MVP (Minimum Viable Product) ou MRF (Minimum
Releasable Feature).
• Quando possuímos nível avançado de entendimento e
experiência em entregas ágeis e “team building” ágil
em operação.
DAD
Lançamento da
Solução
Ciclo de Entrega Contínua Ágil
4.5 DAD: Ciclo de Entrega Lean
O que é o Ciclo de Entrega Lean?
Lean significa enxuto. No caso do ciclo, é realmente isso,
mas essa eficiência tem seu preço. É indispensável que
tenhamos entregas rápidas e definidas e um fluxo (não mais
ciclos) de altíssima adaptação com base em um work list
(lista de trabalho) curto e sucinto para entregar somente o
que sabemos agora, no dia.
Mais aderente a times de correção e focados em pacotes de
entrega menores ou demandas menores de entrega,
mesmo ainda tendo uma estrutura de projeto.
Ao invés de pacotes por iteração, temos fluxos de trabalho
que são entregues a times de projetos. É uma evolução do
Ciclo de Entrega Contínua Ágil.
DAD
Ciclo Lean
4.5 DAD: Ciclo de Entrega Lean
Gerenciamento
de Produto
Gerenciamento 
de Portfólio: 
Arquitetura
empresarial
Itens de Trabalho são 
“puxados” conforme a 
capacidade disponível
(sistema puxado) 
Modelagem
Inicial,
Planejamento
Organização
Sessão de 
reabastecimento 
Novos funcionalidades
Evoluir o WoW
Trabalho
Diário
Reunião de
Coordenação
Demo
Requisição de Mudanças
Lançamento
Liberar
(release)
na produção
Operações TI:
Solução em 
produção 
Suporte
Requisitos
Iniciais
Visão da Arquitetura Inicial
Visão do stakeholder
Arquitetura comprovada
Continuidade Viabilizada
(várias)
Fluxo contínuo de desenvolvimento 
Funcionalidades
Suficientes 
Encantar stakeholders
Produção Pronta
Novos funcionalidades
Valor ao 
negócio
Celeridade
Datas fixas
de entrega
Opções
Intangíveis
4.5 DAD: Ciclo de Entrega Lean
Aspectos relevantes:
• É um fluxo e não mais um ciclo iterativo: tem prazo e
custos definidos para trabalho diário.
• Entrega diária de funcionalidades na produção; às
vezes mais de uma.
• Automação e práticas de produtividade tais como:
fluxos e quadros kanban, up stream, down stream, são
aplicadas e são fatores de sucesso.
• Tem-se somente milestone (marco) de transição de
fase com a operação, que de forma prática á saída do
ciclo Lean.
Ciclo Lean
4.5 DAD: Ciclo de Entrega Lean
Onde e quando aplicar na prática?
• Quando queremos desenvolver uma solução com base em
requisitos preliminares, que podem vir de clientes internos e
externos. Temos claras restrições de prazo, custos e exigência por
celeridade.
• Os níveis de mudanças dos requisitos são MUITO altos; o foco é
produção sob demanda e rápida em caráter diário.
• Espera-se fluxo de entregas diárias (iteração diária) de
incrementos, sejam MVP (Minimum Viable Product) ou MRF
(Minimum Releasable Feature).
• Quando possuímos nível avançado de entendimento e
experiência de entregas ágeis e “team building” ágil e pronto
para operação em fluxo, com constante melhoria e adaptação do
resultado e do jeito de trabalhar.
Ciclo Lean
4.6 DAD: Ciclo de Entrega Contínua Lean
O que é o Ciclo de Entrega Contínua Lean?
É uma progressão natural do Ciclo Lean e do Ciclo
Contínuo Ágil. Nesta abordagem, os times estão
em sistema puxado de entrega com regularidades
diárias de atualização, às vezes mais de uma vez.
Geralmente, times de longo prazo que trabalham
sobre a abordagem Lean são grupos menores ou
com demandas menores de entrega, mesmo
ainda tendo uma estrutura de projeto.
Ao invés de pacotes por iteração, temos fluxos de
trabalho que são entregues a times de projetos e
o ciclo ideal para integração adequada ao
DevOps. DAD
Lançamento da
Solução
Entrega Contínua Lean
4.6 DAD: Ciclo de Entrega Contínua Lean
Gerenciamento
de Produto
Gerenciamento 
de Portfólio 
Arquitetura
empresarial
Visão
inicial
Financiamento Sessão de 
reabastecimento 
Evoluir o WoW
Trabalho
Diário
Reunião de
Coordenação
Demo
Lançamento
Liberar
(release)
na produçãoItens de Trabalho são 
“puxados” conforme a 
capacidade disponível
(sistema puxado) 
Requisição de Mudanças
Operações TI:
Solução em 
produção 
Suporte
Fluxo contínuo de desenvolvimento 
Funcionalidades suficientes 
Encantar stakeholders
Produção pronta
Valor ao 
negócio
Celeridade
Datas fixas
de entrega
Opções
Intangíveis
4.6 DAD: Ciclo de Entrega Contínua Lean
Aspectos relevantes:
• É um fluxo e não mais um ciclo iterativo: tem prazo e
custos definidos e requisitos para trabalho diário.
• Como já estamos em fluxo, podemos eliminar a fase
de inception e transição, pois o produto entra em linha
conforme é finalizado (setup definido).
• Entrega diária de funcionalidades na produção; às
vezes mais de uma.
• Roadmaps e visão são constantemente alimentados
em caráter diário para atender às dinâmicas
adaptativas do produto/sistema/software.
• Apresenta somente milestones (marcos) de transições
com a operação que, em prática, é uma saída do ciclo. DAD
Lançamento da
Solução
Entrega Contínua Lean
4.6 DAD: Ciclo de Entrega Contínua Lean
Onde e quando aplicar na prática?
• Quando queremos desenvolver alguma solução com base
em requisitos “inicias”, com restrições de prazo, custos eclara exigência por celeridade.
• Os níveis de mudanças dos requisitos são muito altos; o
foco é produção sob demanda e rápida em caráter diário.
• Espera-se um fluxo mais direto, sem inceptions e transições,
entregas diárias (iteração diária) de incrementos e MRF
(Minimum Releasable Feature).
• Quando possuímos nível muito avançado de entendimento
e experiência de entregas ágeis e “team building” ágil em
operação, melhoria contínua e adaptação do resultado e do
jeito de trabalhar é uma normalidade. DAD
Lançamento da
Solução
Entrega Contínua Lean
4.7 DAD: Ciclo Exploratório – Lean Startup
O que é o Ciclo Exploratório?
Cria hipóteses, constrói e lança a solução com
observação e medição para validação. Colocar
mesmo para testar.
Ideal para cenários de inovação e startup, total
incerteza, pesquisa e desenvolvimento em
qualquer área, como aprender uma nova
tecnologia ou uma nova área de negócio.
DAD
Lançamento da
Solução
Ciclo Exploratório
4.7 DAD: Ciclo Exploratório – Lean Startup
DAD
Lançamento da
Solução
Ideia Inicial
Criar a 
Visão
Construa
um 
pouco
Implementar
Observar 
e
medir
Produzir
Hipóteses Continue
Pivotar (voltar e ajustar)
Ideia 
aprovada
Id
e
ia 
re
p
ro
vad
a
4.7 DAD: Ciclo Exploratório – Lean Startup
Aspectos relevantes:
• Pode ser apenas uma ou algumas hipóteses;
• São ciclos super rápidos até a implementação;
• Apetite e tolerância a testes malsucedidos faz
parte da natureza da empreitada;
• Retorno à ideia original e ajustes (pivotagem)
são muito comuns e está no mindset da
equipe;
• Organizações de grande porte utilizam como
pesquisa e desenvolvimento e usam equipes
pequenas e de alta autonomia.
Ciclo Exploratório
4.7 DAD: Ciclo Exploratório – Lean Startup
Onde e quando aplicar na prática?
• Testar uma ideia com o mercado, ambiente de
completa e total experimentação.
Simplesmente existem hipóteses e não
requisitos!
• Quando temos condições claras de tolerar o
erro constante (pivotagem) na criação de MVP
(Minimum Viable Product) em termos
financeiros e comportamentais.
• Mindset de experimentação e foco na criação
rápida para obter feedbacks para pivotagem ou
para lançamento.
Ciclo Exploratório
4.8 DAD: Ciclo de Programa (time de times)
O que é o Ciclo de Programa?
Gestão e governança de vários times que podem
estar trabalhando em frentes e ciclos distintos,
um cenário de time de times ”pequenos”, ao
invés de uma grande equipe de abordagem
tradicional sobre um único projeto e um único
ciclo.
Exige alta coordenação e alta integração.
Geralmente tem um inception para pensar sobre
o programa e um período de construção com
milestones de governança, com visão mais ampla
das iniciativas.
Gestão de Programa
4.8 DAD: Ciclo de Programa (time de times)
Time 1
Time 2
Time 3
Time n
Lançar 
Solução na
produção
Desenvolvimento
em 
Paralelo
Gerenciamento
de Produto
Gerenciamento 
de Portfólio 
Arquitetura
empresarial
Requisição de mudanças
Itens de 
trabalho
Ideias e 
Dependências
Estratégia
Arquitetura
Direção
Issues e 
Sugestões
Bloco de
construção
Potenciais
Issues
(problemas)
Integração
E testes 
cruzados
So
lu
çã
o
 t
e
st
áv
e
l/
co
n
su
m
ív
e
l
Operações TI:
Solução em 
produção 
Suporte
Visão do stakeholder
Arquitetura comprovada
Funcionalidades Suficientes 
Encantar stakeholders
Produção Pronta
Trabalho
Pessoas
Coordenação
Arquitetura
4.8 DAD: Ciclo de Programa (time de times)
Aspectos Relevantes:
• Inception tem a função de nortear os times sobre o
programa, seus objetivos, visão e financiamento e
definir como serão as entregas, validações, arranjos.
• Times definem seu WoW (Way of Work) conforme sua
funcionalidade e o trabalho a ser entregue; trabalham
em paralelo, mas lideranças e suporte são necessários
para trabalho em escala.
• Durante a construção, a integração é realizada
constantemente com as entregas para gerar um
incremento conjunto.
• Requisição de mudanças são mais comuns que em
outros ciclos em virtude da integração e do
desenvolvimento paralelo.
Gestão de Programa
4.8 DAD: Ciclo de Programa (time de times)
Onde e quando aplicar na prática?
• Na prática, quando temos ao menos três equipes
trabalhando em MRF (Minimum Releasable Feature)
que podem compor um MBI (Minimum Business
Increment) e precisamos de coordenação entre estas.
• É um desenvolvimento em Ágil escalado, mesmo que
tenhamos tipos diferentes de ciclos em cada equipe de
cada MRF.
• Exige líderes com mindset apurado para gestão de
programa e nível de interação e coordenação
necessários, bem como equipes já experientes na Ágil
e na Lean.
Gestão de Programa
4.9 DAD: Papéis e Responsabilidades 
O toolkit do DA sugere um conjunto robusto de
papéis e responsabilidades em equipes de entrega
de solução (hardware, software, outros) e suporte:
• DAD Papéis Primários: comumente encontrados
nas equipes de trabalho do DA,
independentemente do nível de escala
enfrentado pela equipe.
• DAD Papéis Suporte (Secundários): geralmente
são temporários e objetivam resolver problemas
pontuais e não obrigatórios.
Primários
Suporte
4.10 DAD: Papéis Primários
1. Parte interessada/stakeholder:
Alguém impactado materialmente pelo
resultado da solução em
desenvolvimento.
Ideal e, até mesmo, inevitavelmente
iremos interagir com eles no dia a dia e,
por vezes, ao longo do projeto.
DAD
Líder 
da Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
1. Parte interessada/stakeholder:
• Usuários diretos e indiretos;
• Gerentes dos usuários;
• Membro do time operacional;
• Membros de equipe de manutenção e
help desk potencialmente afetados;
• Desenvolvedores de outras equipes
trabalhando na integração;
• Gerente de programa e portfólio;
• Auditores;
• O patrocinador do projeto. DAD
Líder 
da Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
2. Membros da equipe:
Auto-organizados e focados em produzir
a solução para os stakeholders,
realizando atividades de:
• Planejamento;
• Estimativas;
• Arquitetura;
• Análises;
• Design;
• Testes;
• Programação;
• Dentre outras, conforme o projeto. DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
2. Membros da equipe:
Simplesmente designados como
“programadores” ou “desenvolvedores”,
não possuem todas as competências
para realizar todas as atividades, porém
possuem no time especialistas,
responsáveis em algum skill específico
que, com a medida do projeto,
compartilha o conhecimento de forma
que os demais membros possam
desenvolver e adquirir competências e
habilidades conforme a sua aptidão.
Ex.: Alguns podem não escrever códigos
nunca! DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
3. Líder da equipe:
É um líder servidor e verdadeiro para
toda a equipe, criando e mantendo as
condições para que a equipe trabalhe e
performe com sucesso de forma auto-
organizada.
É também um agile coach (treinador),
ajudando a equipe a manter o foco em
entregas de trabalho, construindo os
incrementos das iterações conforme os
objetivos combinados com o PO
(Product Owner, ou dono do produto). DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
3. Líder da equipe:
É indispensável para dar suporte a times
auto-organizados:
• Facilitando a comunicação;
• Empoderando a equipe a otimizar os
seus processos de trabalho;
• Garantindo que o time tenha os recursos
necessários para realizar as entregas;
• Tratando e removendo os impedimentos
(issues) em tempo apropriado.
DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
4. PO – Dono do Produto:
Em um sistemaque possui centenas de
requisitos, é geralmente difícil ter
respostas a todas elas de forma
apropriada e em tempo adequado.
O PO (Product Owner, ou dono do
produto) tem a função de tratar de tais
requisitos, de forma a traduzir as
necessidades e expectativas dos
stakeholders, representando o cliente,
ou melhor, sendo a “voz do cliente” no
projeto. DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
4. PO – Dono do Produto:
Tem como principais responsabilidades
e atribuições:
• Listar todos os detalhes de cada
necessidade esperada da solução;
• Esclarecer todos os detalhes da solução
em forma de requisitos;
• Priorizar os requisitos por valor e
necessidade ao cliente;
• Apresentar e esclarecer aos membros
da equipe para que possam desenvolver
a solução;
• Realizar as tarefas acima em tempo
apropriado. DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
4. PO – Dono do Produto:
Cada time DAD, ou subgrupos DAD (em
caso de grandes programas, times de
times), possui seu próprio PO.
Um trabalho secundário do PO é
representar o trabalho desenvolvido
pela equipe à comunidade dos
stakeholders, não diretamente
envolvidos nas validações, como, por
exemplo: desenvolver relatórios de
status geral, bem como performance
dos incrementos até o momento. DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
4. PO – Dono do Produto:
Trabalhar próximo ao stakeholder para
constantemente refinar os requisitos e
com a equipe para esclarecer qualquer
questões ao longo do desenvolvimento
reduz significativamente a quantidade
de mais requisitos, testes e
documentação. Claro que sempre
existirão documentos necessários, como
manuais de operação e suporte, que
irão demandar entregas do time.
DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
5. Dono da Arquitetura:
Arquitetura é a chave mestra do risco do
projeto e, por isso alguém precisa estar
responsável por identificar, analisar e
propor ações para eliminar e/ou mitigar
os riscos.
Por isso, na equipe DAD, é incluído esse
papel do dono da arquitetura, que toma
as decisões sobre a arquitetura no time
e que facilita a criação e a evolução do
design geral de desenvolvimento.
DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
5. Dono da Arquitetura:
Em pequenas estruturas e equipes
ágeis, o próprio líder da equipe assume
essa função da arquitetura,
diferentemente de grandes
corporações.
Geralmente desempenhado por um
desenvolvedor sênior, às vezes
conhecido como arquiteto de software
ou arquiteto de soluções, com
conhecimento e bagagem técnica sólida
e amplo entendimento da organização e
do negócio.
DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.10 DAD: Papéis Primários
5. Dono da Arquitetura:
Esse papel, contudo, não é uma
“posição” hierárquica, e sim uma função
da equipe, como as demais funções da
equipe DAD.
Dessa forma, deve participar com
entregas de itens, pacotes e atividades
dentro dessa atribuição e conforme o
contexto do desenvolvimento.
DAD
Líder 
do Equipe
PO
Dono do Produto
Membro 
da Equipe
Dono da 
Arquitetura
Parte Interessada
Stakeholder
4.11 DAD: Papéis de Suporte
1. Especialista
Os membros de equipe são “especialistas
generalistas”, que podem ser multidisciplinares
em duas ou mais competências chaves de
desenvolvimento da solução, não
necessariamente em gestão.
Às vezes, especialmente em programas e
ambientes complexos, com diversas grandes
equipes, um ou mais agile business analysts
(especialistas em agilidade) ou agile coach
podem ser necessários para garantir a
integração do que se está sendo construído. DAD
Especialista Testador
independente
Expert
em um 
Domínio
IntegradorExpert 
Técnico
4.11 DAD: Papéis de Suporte
1. Especialista: Agile Coach
Ajuda as pessoas a aprimorarem
competências e condutas com base na
agilidade:
• Competências soft: trabalhar com
pessoas;
• Competências técnicas específicas;
• Adquirir conhecimento específico;
• Adquirir experiências específicas;
• Desenvolver liderança;
• Desenvolver flexibilidade;
• Condutas e competências em Lean e Ágil.
DAD
4.11 DAD: Papéis de Suporte
1. Especialista (modelo)
Em “times de times”, com muitas pessoas
trabalhando em diversos times, um
especialista pode ser um gerente de
programa para coordenar os líderes de
equipes nas entregas, os recursos gerais e o
foco no resultado do conjunto.
Os Especialistas podem ser requisitados em
algum projeto para complementar a equipe
com sua competência, ou ainda quando um
membro está indisponível.
DAD
Especialista Testador
independente
Expert 
em um 
Domínio
IntegradorExpert 
Técnico
4.11 DAD: Papéis de Suporte
2. Expert em um Domínio
O PO representa as expectativas de um
espectro amplo de stakeholders, mas certos
requisitos são demasiados “complexos” para
um mesmo tipo de abordagem.
Por vezes, é importante trazer à equipe um
expert em um assunto que foge ao
software, por exemplo: expert em tributos
ou legislação. Ele pode esclarecer os
requisitos com maior agilidade à equipe e
com stakeholders específicos.
DAD
Especialista Testador
independente
Expert 
em um 
Domínio
IntegradorExpert 
Técnico
4.11 DAD: Papéis de Suporte
3. Expert Técnico
Por vezes, é importante trazer à equipe um
expert em um assunto técnico ou conceitual
do desenvolvimento da solução (software)
que conheça de scripts específicos de
desenvolvimento e que atendam a
requisitos específicos, por exemplo: base de
dados em nuvem de um determinado
fabricante, designer visual com abordagem
de UX-User Experience, dentre outros.
DAD
Especialista Testador
independente
Expert 
em um 
Domínio
IntegradorExpert 
Técnico
4.11 DAD: Papéis de Suporte
3. Expert Técnico
São requisitados no projeto, geralmente de
forma temporária. Para ajudar na entrega
de um determinado incremento, nos quais a
equipe esteja com dificuldades em construir.
Podem ser parte da organização e trabalhar
para várias equipes, como consultores, que
possuem atribuições de arquitetura do
software a nível empresarial. São ótimos
suportes para solucionar problemas
técnicos. DAD
Especialista Testador
independente
Expert 
em um 
Domínio
IntegradorExpert 
Técnico
4.11 DAD: Papéis de Suporte
4. Testador Independente
Majoritariamente os testes de validação são
realizados pelos próprios membros da
equipe. Alguns times recebem suporte de
testadores independentes (time) que
trabalham paralelamente ao longo do ciclo
de vida do desenvolvimento.
São requisitados em abordagens escaladas
com ambiente de alta complexidade, em
desenvolvimento de tecnologias novas ou
complexas, ou aspectos que envolvem
compliance e regulamentação. DAD
Especialista Testador
independente
Expert 
em um 
Domínio
IntegradorExpert 
Técnico
4.11 DAD: Papéis de Suporte
5. Integrador
Grandes equipes DAD são geralmente
organizadas em “times de times” ou
“subgrupos”, sendo cada um deles
responsável por uma funcionalidade do
sistema ou um subsistema.
Quanto maior a quantidade de equipe
trabalhando simultaneamente, mais
complexa é a integração. Para reduzir a
complexidade e endereçar a integração de
forma mais fácil em ambientes como esses,
existe(m) o(s) integrador(es). DAD
Especialista Testador
independente
Expert 
em um 
Domínio
IntegradorExpert 
Técnico
4.11 DAD: Papéis de Suporte
5. Integrador
Trabalham muito próximos aos testadores
independentes, de forma a garantir o teste
de integração do sistema regularmente ao
longo do projeto.
No caso de pequenas equipes DAD, de
situações mais “simples” ou de arranjos
convencionais, o próprio Dono da
Arquiteturaassume a função de integração.
DAD
Especialista Testador
independente
Expert 
em um 
Domínio
IntegradorExpert 
Técnico
4.12 DAD: Aspectos importantes dos papéis
Por que tantos papéis e responsabilidades?
A comparação com os papéis prescritos no
Scrum e outros frameworks é comum, porém
deve-se levar em conta o escopo onde esses
frameworks propõe e o proposto pelo DAD.
O DAD tem como escopo de atuação, além dos
papéis convencionais de atuação e entrega de
equipes individuais, a visão em escala.
O DAD necessita de dez papéis, mais
especificamente, por tratar um ciclo completo
de entrega (full delivery cycle), que vai além do
desenvolvimento.
Primários
Suporte
4.12 DAD: Aspectos importantes dos Papéis
Aspectos importantes a considerar no DAD:
• Cargos tradicionais, como analista de
negócios, gerente de projetos, líderes de
projetos e gerente de engenharia, não
existem. É ideal que eles sejam migrados em
funções que possam contribuir dentro do
arranjo proposto pelo DAD, definindo
estratégias de transição, com ajuste de sua
“entrega” de trabalho conforme sua
possibilidade, formatando o “jeito de
trabalhar” (WoW).
Primários
Suporte
Capítulo 5 – Disciplined DevOps: Fundamentos
5.1 Definindo DevOps
5.2 Definindo Disciplined DevOps
5.3 Disciplined DevOps: Mindset
5.4 Disciplined DevOps: Lâminas de Processos
5.5 Disciplined DevOps: Fluxos de Trabalho
5.6 BizDevOps: Operação do Negócio
5.7 DevSecOps: Segurança Operacional
5.8 DataSecOps: Gerenciamento de Dados
5.9 Coordination DevOps: Lançamento e Suporte
5.10 Full Disciplined DevOps
5.1 Definido DevOps
O que é DevOps?
Tem como objetivo aproximar o time de
desenvolvimento (construção) ao de
operações de TI (na frente com o cliente),
com o propósito pragmático de resolver
problemas e desenvolver uma versão de
produto de TI de forma rápida.
DAD
DAD Op.TI
5.1 Definido DevOps
Por que DevOps?
• Reduzir o tempo de resposta ao mercado;
• Publicações e atualizações mais recentes;
• Melhor qualidade de serviço e produto;
• Melhor competitividade;
• Melhor tomada de solução.
Já não é mais uma tendência, é uma
realidade em diversas organizações,
totalmente alinhado com o business agility.
DAD Op.TI
5.1 Definido DevOps
DevOps Clássico
A versão do DevOps clássico preconiza que
existe um fluxo contínuo entre
desenvolvimento de soluções e
implementação nas Operações de TI,
adotando as estratégias de ciclos contínuos
de entrega prescritos no DAD.
Ótimo ponto de partida!
DAD Op.TI
5.2 Disciplined DevOps
O que temos de diferente?
O Disciplined DevOps fornece suporte e
integração da operação de TI com a TI
Empresarial (Operação do negócio),
tornando o DevOps mais alinhado ao fluxo
de valor por meio de funções de
integração, gestão, suporte e segurança.
Segurança Gestão da
informação
Gestão do 
Lançamento
DAD Op. Negócio
Op.TI Suporte 
5.3 Disciplined DevOps: Mindset
• Fluxo End to End: mais orientado ao cliente;
• Reduz o tempo/ciclo de feedback;
• Reduz o tempo/ciclo de suporte;
• Equipes e pessoas flexíveis;
• Eq. multidisciplinares: especialistas generalistas;
• Infraestrutura padronizada;
• Ferramentas de automação nos processos;
• Guias de desenvolvimento padronizados;
• “You built, you run it”: quem constrói também
opera o sistema. Tem total interação.
Segurança Gestão da
informação
Gestão do 
Lançamento
DAD Op. Negócio
Op.TI Suporte 
5.3 Disciplined DevOps: Lâmina dos Processos 
Possui seis processos, sendo um deles o DAD, os dois “x” clássicos do DevOps:
Suporte e Operação da TI, e os adicionais: Data e Release Management e
Security (segurança).
Princípios Promessas Guias Ágil Lean Serial Papéis Times WoW
DAD
Disciplined
Agile Delivery
Segurança
Data 
Management
Release
Management
Suporte
Help Desk
Operação
TI
P&D
Pesquisa e Des.
Operação Business
Portfolio 
Management
Product
Management
Estratégia
Gestão
Governança Marketing Melhoria
Contínua
Vendas Program
Management
Arquitetura
Empresarial
Gestão de 
Pessoas (RH) Gestão da TI
Gestão do 
capital (asset)
Gestão da 
Transformação
Finanças e 
Controladoria
Compras e 
Aquisições
Jurídico
1) Fundação
2) DISCIPLINED DEVOPS
3) FLUXO DE VALOR
4) DAE
Solução End to End
com o negócio
5.5 Disciplined DevOps: Fluxos de trabalho 
Pode ser escolhido e adaptado
conforme o contexto por meio de
fluxo completo com todos os
componentes e níveis de aplicação
dos processos, bem como em visões
intermediárias:
• Biz DevOps
• DevSecOps
• Data Devops
• Coordination DevOps
• Full Disciplined DevOps
Operação 
Negócio
DAD 
Segurança
Gestão da
informação
Gestão do 
Lançamento
Operação 
de TI
Suporte 
5.6 Biz DevOps: Operação de TI
Operação de TI: é o fluxo da operação integrada do ERP Cliente (sistemas
empresariais) e o time das operações de TI. É um nível básico do Disciplined
DevOps, pois ainda não envolve outros processos chaves (segurança e gestão de
informação), porém, envolve o cliente diretamente com os times DAD e de
operações de TI na rápida adaptação a novas necessidades e requisições.
DAD
Operação 
Negócio
Operação 
de TI
Lançamento
à operação
Inteligência 
operacional e
Requisição 
de Mudanças
Soluções e 
Serviços
Novas
Requisições
5.6 Biz DevOps: Operação de TI – Papéis
Eng. de Operação de TI:
• Opera e monitora a infraestrutura de TI e os softwares.
• Trabalha com os times de entrega DAD, ajudando a 
entender e a alavancar a infraestrutura existente, bem 
como lançar soluções na operação.
DAD
Operação 
Negócio
Operação 
de TI
Lançamento
à operação
Inteligência 
operacional e
Requisição 
de Mudanças
Soluções e 
Serviços
Novas
Requisições
Gerente Operação de TI:
• Gerente funcional do time de 
operações;
• Líder do time de eng. de operação;
• Gerenciar mudanças na infraestrutura 
operacional;
• Planejar e mitigar riscos operacionais;
• Direcionar o desenvolvimento de 
guias operacionais;
• Colaborar com o time de arquitetura 
empresarial, ajudando a entender a 
situação operacional e evoluir o 
roadmap técnico;
• Colaborar com o gerente de 
lançamento (Release Manager) e com 
o fluxo geral do processo de gestão 
do lançamento.
5.7 DevSecOps: Segurança Operacional
Segurança operacional (Security): traz issues (questões, problemas) relacionados
à segurança corporativa ao time das operações de TI e aos times DAD por meio de
ferramentas e guias de segurança institucional, uma visão ou nível que aprimora o
desenvolvimento e a operação de forma a entregar resultados à operação do
negócio. Além disso, monitora e responde a ameaças aos bens patrimoniais.
DAD
Segurança
Operação 
de TI
Lançamento
à operação
Inteligência 
operacional e
Requisição 
de Mudanças
Inteligência
Desenvolvimento
Guias de 
Segurança e
Ferramentas
Inteligência 
operacional
Guias de 
Segurança e
Ferramentas
5.7 DevSecOps: Segurança Operacional – Papéis
DAD
Segurança
Operação 
de TI
Lançamento
à operação
Inteligência 
operacional e
Requisição 
de Mudanças
Inteligência
Desenvolvimento
Guias de 
Segurança e
Ferramentas
Inteligência 
operacional
Guias de 
Segurança e
Ferramentas
Engenheiro de segurança: 
• Ajuda os times a construírem soluções seguras.
• Ajuda a construir a infraestrutura operacional segura.
• Avalia ferramentas de segurança, incluindo testes, análise de código, toolkits e produtos de infraestrutura.
• Trabalha com experts externos e praticantes para manter a segurança em evolução.
Gerente de segurança:
• Gerente funcional do time de eng. de 
segurança;
• Trabalha com arquitetura empresarial 
como expert da segurança;
• Trabalha com liderança executiva, 
ajudando no entendimento e nas 
implicações da segurança;
• Trabalha com experts externos e 
praticantes para manter a segurança 
em evolução.
5.8 DataDevOps: Gerenciamento de Dados
Gerenciamento de dados (Data Management): traz issues (questões, problemas)
relacionados à gestão da informação ao time das operações de TI e aos times DAD
por meio de guias de dados, tais como: evolução dos dados, analytics e qualidade
da informação.DAD
Operação 
de TI
Inteligência 
operacional e
Requisição 
de Mudanças
Inteligência 
operacional
Atualizações
Fonte de Dados
(Data Source)
Guias 
de Dados
Lançamento
à operação
Gerenciamento de Dados
5.8 DataDevOps: Gerenciamento de Dados – Papéis
DAD
Operação 
de TI
Inteligência 
operacional e
Requisição 
de Mudanças
Inteligência 
operacional
Atualizações
Fonte de Dados
(Data Source)
Guias 
de Dados
Lançamento
à operação
Gerenciamento de Dados
Administrador de Data Base:
• Opera, dá suporte e evolui o legado das bases de dados;
• Colabora com os times de entrega DAD, idealmente como membro, para garantir que as bases e 
as fontes de dados foram desenvolvidas e evoluíram de forma qualitativa.
Gerente de dados :
• Gerente funcional do time de dados;
• Líder dos administradores do Data 
Base;
• Lidera o refatoração de base e fontes 
de dados;
• Orienta as atividades com as bases de 
dados da organização;
• Colabora com times de entrega DAD, 
garantindo que a qualidade de dados 
seja mantida;
• Lidera o guia de orientação de dados.
5.9 Coordination DevOps: Lançamento
Gestão de lançamento: precisamos de coordenação em múltiplos times de
organizações, trabalhando simultaneamente, de forma a atingir consistência e
economia de escala. DAD
DAD Operação 
de TI
Requisição 
de 
Mudanças
Lançamento
à operação
Inteligência 
operacional
Suporte
Gerenciamento
de lançamento
(releases)
Lançamento
à operação
Inteligência 
Suporte
Alerta
5.9 Coordination DevOps: Lançamento - Papéis
DAD
DAD Operação 
de TI
Requisição 
de 
Mudanças
Lançamento
à operação
Inteligência 
operacional
Suporte
Gerenciamento
de lançamento
(releases)
Lançamento
à operação
Inteligência 
Suporte
Alerta
Eng. de lançamento:
• Trabalha com os times de entrega DAD, ajudando a 
lançar soluções de forma DevOps e evoluindo o 
direcionamento da gestão de lançamento.
Gerente de lançamento :
• Gerente funcional do time de release;
• Líder do time de eng. de lançamento;
• Coordena as múltiplas soluções 
lançadas em produção entre os times de 
entrega DAD;
• Facilita a definição de solução “pronta” 
para produção;
• Direciona o desenvolvimento de práticas 
comuns de lançamento;
• Gerencia o cronograma dos 
lançamentos;
• Colabora com o gerente de operação de 
TI com o fluxo geral do processo de 
gestão do lançamento.
5.9 Coordination DevOps: Suporte
Suporte: precisamos de suporte no lançamento das soluções em operação e gerar
ajustes com base em feedbacks e alertas. DAD
DAD Operação 
de TI
Requisição 
de 
Mudanças
Lançamento
à operação
Inteligência 
operacional
Suporte
Gerenciamento
de lançamento
(releases)
Lançamento
à operação
Inteligência 
Suporte
Alerta
5.9 Coordination DevOps: Suporte - Papéis
DAD
DAD Operação 
de TI
Requisição 
de 
Mudanças
Lançamento
à operação
Inteligência 
operacional
Suporte
Gerenciamento
de lançamento
(releases)
Lançamento
à operação
Inteligência 
Suporte
Alerta
Eng. de suporte (Help Desk):
• Ajuda os usuários a entender e trabalhar com as soluções de TI;
• Identifica potenciais melhorias para as soluções existentes;
• Endereça os requisitos dos usuários;
• Escala problemas difíceis à operação e a times DAD de forma apropriada.
Gerente de Suporte:
• Gerente funcional do time de 
suporte;
• Líder do time de eng. de suporte;
• Gerencia o processo de escalar as 
decisões à operação e a times DAD.
• Trabalha próximo com stakeholders
para garantir que o time de suporte 
entregue serviços de suporte em nível 
apropriado.
5.10 Full Disciplined DevOps
DAD
Operação 
Negócio
DAD 
Segurança
Gestão da informação
Gestão do 
Lançamento
Operação 
de TI
Suporte 
Potencial 
Valor
Solução
Consumível
Inteligência 
operacional
Requisição 
de Mudanças
Inteligência 
Suporte
Atualizações
Fonte de Dados
(Data Source)Guias 
de 
Dados
Alerta Potencial 
Valor
Potencial 
Valor
Inteligência 
operacional
Guias de 
Segurança e
Ferramentas
Guias de 
Segurança e
Ferramentas
Guias de 
Segurança e
Ferramentas
Ger. Lançamento Eng. Lançamento
Ger. Suporte
Eng. Suporte
Ger. Dados
Adm. Data Base
Ger. Segurança Eng. Segurança
Ger. Operação
Eng. Oper. TI
Equipes de Primárias
Equipes de Suporte
Capítulo 6 – DA Flex: Fluxo de Valor
6.1 Definindo Fluxo de Valor (Value Stream) 
6.2 DA FLEX 
6.3 DA FLEX: Lâmina dos Processos
6.4 DA FLEX: Processos e papéis de extensão do DevOps
6.5 DA FLEX: Processos e papéis de extensão com DAE
Fluxo de valor: é um conjunto ou série de ações/etapas que são
efetivadas/realizadas desde o primeiro contato do cliente com a empresa, até a
entrega completa de resultado ao cliente, o “valor”.
Sempre se inicia e termina com o cliente (customer). O grande “mote” da empresa é
atingir os clientes com o maior valor possível. Preço é o que se paga, valor é aquilo
que se leva!
6.1 Definindo Fluxo de Valor (Value Stream)
Exemplo de fluxo de valor: serviços de manutenção de carro
Cliente
Realizar
Agendamento
Deixar veículo 
para avaliação
Aprovar 
orçamento
Realizar
reparo
Verificar e 
pagar serviço
Retirar 
veículo
6.1 Definindo Fluxo de Valor (Value Stream)
Do ponto de vista organizacional, é a cola
que une a estratégia com toda a operação
para tomada de decisão para entregar valor!
O fluxo inicia com um “conceito inicial”,
movendo ou andando por vários estágios,
que engloba várias equipes e recursos,
trabalhando em sequência e paralelamente
até as etapas finais, que contemplam a
entrega e o suporte ao cliente.
É comum, em grandes organizações, vários
fluxos de valor para diversos clientes, em que
as equipes estão envolvidas em mais de um. DAD
6.2 DA FLEX
Disciplined Agile Flow for Transformation (DA FLEX): é uma abordagem de fluxo baseada no
Lean Thinking e em padrões de processos que aprimorem a habilidade de forma a atingir a
agilidade organizacional com rápida realização de valor, sustentabilidade e alta qualidade.
DAD
DAD
Clientes
Internos + Externos
Estratégia
Gerenciamento
de Portfólio
Gerenciamento
de Produto
Governança Arquitetura
Empresarial
Segurança Gerenciamento
de dados
Melhoria
Continua
Gerenciamento
de Programa
Gerenciamento
de Release
Operação
TI
Operação Negócio
R
ealização
 d
e V
alo
r
Implementação
Solução
Consumível
MBI – Minimum 
Business Increment
Fl
u
xo
 d
o
 
V
al
o
r
In
ic
ia
ti
va
s
fi
n
an
ci
ad
as
Suporte
D
ir
eç
ão
 d
o
 N
eg
ó
ci
o
Valor ao 
Cliente
Necessidades
6.2 DA FLEX
Essa parte se destina a definir, a partir de necessidades identificadas, estratégias que
desdobram portfólios de iniciativas selecionadas (financiadas) de serviços e produtos que
possam gerar MBI, que são base para a decomposição em programas e projetos.
DAD
DAD
Clientes
Internos + Externos
Estratégia
Gerenciamento
de Portfólio
Gerenciamento
de Produto
Governança Arquitetura
Empresarial
Segurança Gerenciamento
de dados
Melhoria
Continua
Gerenciamento
de Programa
Gerenciamento
de Release
Operação
TI
Operação Negócio
R
ealização
 d
e V
alo
r
Implementação
Solução
Consumível
MBIs – Minimum 
Business Increment
Fl
u
xo
 d
o
 
V
al
o
r
In
ic
ia
ti
va
s
fi
n
an
ci
ad
as
Suporte
D
ir
eç
ão
 d
o
 N
eg
ó
ci
o
Valor ao 
Cliente
Necessidades
6.2 DA FLEX
MMR – Minimum Marketable Release (Mínimo lançamento para mercado)
MMP – Minimum Marketable Product (Mínimo Produto a mercado)
• Um conjunto de MBIs que pode compor um negocio ou produto
MBI – Minimum Business Increment (Mínimo incremento de negócio):
• Menor pedaço de valor lançável (releaseble) que faz sentido sobre a
perspectiva do negócio;
• Focada em alto valor e rápida realização ao cliente;
• Mira para um mercado, segmento particular.
MMF – Minimum Releaseble Feature (Mínimo função lançável)
• Menor pedaço “pronto” que encaixa em um MBI;
• Funcionalidade Totalmente consumível, traz valor real aos clientes;
• Pode ser implementado separadamente também (ready to deploy).
MVP – Minimum Produto Viável (Mínimo Produto Viável)
• Um investimento para testar uma