Massimus C&T

Coaching
ACCELERATING RESULTS
Desmistificando os Métodos
Ágeis
Aplicabilidade e restrições.
Fabiano Milani
29/07/2016
 Agenda
• TI bimodal
•A verdade sobre projetos
• Em busca da qualidade
• Mudanças acontecendo
• Manifesto ágil
• Projetos iterativos
• Scrum – Visão Geral
• Visibilidade
• Comunicação
• Comprometimento
• Retorno de Investimento
• Variações de Scrum
• Caminho para a implantação do Scrum
• Cases
 Organização Bimodal em TI

Segundo Gartner 75% da TI utilizará métodos ágeis até 2018

 Organização Bimodal em TI

De acordo com Gartner, a TI bimodal associa dois modos de TI

• Escalabilidade • Não sequencial

• Eficiência • Inovação

• Segurança • Agilidade

• Precisão • Velocidade
Organização Bimodal em TI
Organização Bimodal em TI
Organização Bimodal em TI
Organização Bimodal em TI
Organização Bimodal em TI
Organização Bimodal em TI
 Chaos Report
• O Standish Group vem, há mais de uma década,
realizando estudos em volta dos resultados dos projetos
de software ao redor do mundo. O resultado destes
estudos é um relatório batizado de Chaos Report;

Fonte : Standish Group (www. Standishgroup.com)

 PARA REFLETIR …
maglev chinês

US$ 1Bi
 PARA REFLETIR …

Junho/01 a Dezembro/03

30 km
 PARA REFLETIR …

O Maglev Chinês
• Projeto: Construção do Maglev que
liga Shanghai Business Center aos
arredores do Pudong International
Airport.
• Este projeto
Orçameno: seria bi
US$ 1.08 considerado de sucesso pelo CHAOS REPORT.
para 30 Km
Mas o seu sucesso técnico não significava nada para a sua
• Tempo: Jun01 – Dez03 (2 anos e 7financeira ?
viabilidade
meses)
• Resultados técnicos: projeto concluído
no prazo, no orçamento e escopo
• Resultados de negócio: O trem rodava
inicialmente quase vazio : ROI não é
obtido quando esperado
 PARA REFLETIR …

Orçado
US$200 mi
1 ano e meio

Realizado
US$400 mi
1 ano de atraso
 PARA REFLETIR …

Premios
11 Oscar
O projeto se daria como desafiado pelo CHAOS
REPORT, apesar do seu sucesso financeiro.

Receita
US$1,8 Bi
 Mas por que ?

A vasta maioria dos projetos de software falha por falta

de clareza – sobre funções pessoais, responsabilidades e
requisitos – e também por inabilidade para acompanhar
o que ocorre em cada um dos diferentes passos do ciclo
de vida da aplicação.
 Para refletir …

• Segundo o Standish Group quais foram os principais

fatores para esta melhora?
 Controlando o imprevisível
waterfall
4 meses
Planejamento 6 meses
Execução 2 meses
Teste 2 meses
Homologação
Previsibilidade
14 meses
iterativo
1 mês 1 mês 1 mês 1 mês 1 mês
Iteração 01 Iteração 02 Iteração 03 Iteração 04 Iteração n

Adaptabilidade
 Previsibilidade

• Os processos baseados
no modelo waterfall
(cascata) buscam
organizar o
desenvolvimento de
produtos no formato de
linha de produção;
• Isto se parece com
projetos da áre de TI?
 Adaptabilidade

• Imagine um projeto
iterativo como uma
viagem a ser feita;
• Você terá que planejar
sua viagem, mas como
garantir os programas
ideais, se você só
conhecerá mais sobre o
seu destino quando lá
estiver;
 Resumindo …
• A comunicação entre as partes envolvidas nos projetos
é muito fraca;
• A visibilidade do andamento real e dos problemas
existentes nos projetos é muito fraca;
• Clientes pedem sempre mais do que realmente
precisam;
• Os projetos são caros e, ainda em sua maioria, não
alcançam sucesso;
• Os conflitos existentes entre TI e negócios durante os
projetos são muitos;
Uso de funcionalidades

Fonte : Standish Group (www. Standishgroup.com)

 O Problema do cliente

• Clientes sabem que fornecedores

odeiam mudanças de requisitos;
• Clientes são “forçados” a definir
tudo que precisam para um produto
na fase inicial do projeto;
• Clientes – no início de um projeto -
estão inseguros quanto ao que
precisam;
 A solução do cliente

• Colocar o máximo possível de

requisitos na lista inicial;
• Entende-se por “o máximo possível”
tudo que lhe vier à cabeça naquele
momento;
• Desta forma a possibilidade de
“faltar” requisitos no produto final é
menor;
O Problema do fornecedor

• Fornecedores sabem que os

requisitos fornecidos pelo cliente são
vagos;
• Fornecedores sabem que no
decorrer do projeto o cliente
precisará mudar requisitos;
• Fornecedores sabem que sempre ao
validar o produto com o cliente
surgirão novas idéias para o produto;
A solução do fornecedor

• Documentar ao máximo tudo que

foi passado pelo cliente para que o
fornecedor possa estar protegido;
• Colocar margens de tempo por
todo o projeto;
• Entregar o produto para o cliente
apenas no final do projeto;
O Que isso gera ?
Quem perde com isso ?

A EMPRESA
Uso de funcionalidades

Fonte : Standish Group (www. Standishgroup.com)

A solução
Ignorou a cultura da empresa?

Cultura
O Que vem se falando ?
O Que vem se falando
 O Que é essa nova onda ?

Kanban Lean Modelagem Ágil

Domain-Driven
Design
Test-Driven
Development
OpenUp
 Por que surgiu essa nova onda?

A resposta pode ser

filosófica: ele é
resultado de uma
dialética
 Analise da necessidade
contraposta por
Tese Antítese
reconciliadas em

Síntese Dialética ...

contraposta por
Tese Antítese
reconciliadas em

Síntese A Síntese Perfeita (?)

...
Tese: O Não-Processo
 Antítese:
O Processo Monumental
Síntese: O Processo Ágil
Quem vem mudando
 Scrum

• É um processo iterativo e incremental para o

desenvolvimento de qualquer produto e
gerenciamento de qualquer projeto;

• É mais um framework que uma metodologia,

mais atitute que um processo;
Um Scrum no Rugby
43
Metodologia de Desenvolvimento Ágil
 Pilares do scrum
Transparência Inspeção

Adaptação
 Product owner

AUTORIDADE COM
RELAÇÃO AO
NEGÓCIO
 ScrumMaster

AUTORIDADE COM
RELAÇÃO AO
SCRUM
 Time
AUTORIDADE TÉCNICA
SUPORTANTO O NEGÓCIO
 O Fluxo do scrum

Parte I Parte II
Lista de
Funcionalidades Reunião de Planejamento

Lista de Tarefas
Visão

Retrospectiva Execução e
Reunião Diária
 Kanban
ITENS TAREFAS TAREFAS EM TAREFAS HORAS
DESEJADAS ANDAMENTO FINALIZADAS
Definir M a p ear M o ntar
Como um DBA eu estr atégia t a belas S c r ipt 58
quero um refactoring 04 06 10

no BD para aumentar Ap l icar R e a lizar An a lisar

a velocidade de S c r ipt
04
t e ste
08
e fi ciência
06
respota 13
At u alizar G e r ar G e r ar docto
d o cument e s p ecifica r e gra
03 05 06

V a l idar c/
c l iente
06

Como um Gerente de G e r ar M o ntar D e s ign da

vendas e gostaria de
e s trutura q u er y t e la 40
r e latorio 04 08 06
relatório de comissão
Cr iar R e a lizar An a lisar
para pagto dos i n teligencia t e ste e fi ciência
vendedores 10 03 02

5 At u alizar G e r ar G e r ar docto
d o cto e s p ecifica r e gra
01 02 03

V a l idar c/
Pontos : 18 c l iente
01

Conceito de pronto: 98
- Codificado
- Desenhado
- Testado META : Atender as
- Manual funcionalidades : 12, 16
- Documentos
gerados/atualizados
 Gráfico de burndown
100
95
90
85
80
75
70
65
60
55
50 Ideal
45 Realizado
40
35
30
25
20
15
10
5
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Gráficos de acompanhamento
 Um Sprint na vida
de um quadro de
tarefas...
52
Ambiente Informativo

53
 O Iceberg do Scrum
Processos: Reunião de
planejamento, Retrospectiva,
20 % Reunião diária, Planejamento
de Release e Sprints, ...
Ferramentas: Quadro
Kanban, Ferramentas, Post-it,
User Stories, Burndown...
Pessoas: ScrumMaster,
Product Owner, Time, ...

80 % Cultura: Time multi-

disciplinar, Auto-
gerenciamento, Valores,
Envolvimento do cliente,
Entrega frequente,
Liderança-colaboração,
Respeito, ...
… como mudar esse cenário?

com disciplina
… como mudar esse cenário?

( ...) quando você tem uma

combinação da cultura da
disciplina com o
empreendedorismo ético, você
tem a alquimia mágia da grande
performance.”

JIM COLLINS
Autor do livro : Good to Great
 The Definition of Done
(DoD)
• An essential definition to actually get
increments of a product
• Builds quality in
• Includes all activities needed to have a
feature actually fully completed
“Pronto”
└Acceptance criteria
└Process documentation 1.
2.
Testar...
Testar...

└Unit tests, integration tests

3. Implementar
4. Documentar...
5. Etc., etc.
└Black and white box testing, etc.
• What is your DoD?

© massimus c&t 57
© massimus c&t
 Fonte: https://cafecomscrum.com/2016/03/27/as-7-dimensoes-do-produto/

© massimus c&t
Scrum of scrums
Comunicação efetiva

Original by Alistair Cockburn

Documentação …
 Mitologia Ágil
Projetos ágeis não precisam Projetos ágeis não precisam de
de organização documentação

Times ágeis fazem o que Times ágeis não planejam

querem

Projetos ágeis não precisam

Qualidade será baixa de gerentes

Não há visibilidade do que está Projetos ágeis são simples e fáceis de

acontecendo implementar
 Referências visão geral
• Agile Project Management with Scrum
(Schwaber)

• Extreme Programming Explained, 2a edição

(Beck)

• User Stories Applied (Cohn)

• The Enterprise and Scrum (Schwaber)

• Agile Estimating and Planning (Cohn)

• Planning Extreme Programming (Beck,

Fowler)
Leitura obrigatória

www.livrometodosageis.com.br
Nosso jeito de trabalhar
OBRIGADO