agilidade alternativa com corrente crítica
DESCRIPTION
Apresentação feita em 25/04/09, no Porto Alegre Agile Weekend 2009. A idéia é mostrar que há casos de sucesso em desenvolvimento de produtos (software e/ou hardware) utilizando uma abordagem turbinada pela Corrente Crítica, em complemento ou mesmo substituindo metodologias Ágeis.TRANSCRIPT
Agilidade Alternativa com Corrente Crítica
Agilidade Alternativa com Corrente Crítica
Engº Adail Muniz Retamal
Engº Adail Muniz Retamal
Porto AlegrePorto AlegreAgile WeekendAgile Weekend
25/04/200925/04/2009
25/04/2009
© 2009
Agilidade!Agilidade!
a.gi.li.da.de sf (lat agilitate)1. Qualidade do que é ágil.
2. Desembaraço, ligeireza, presteza de movimentos.
3. Mobilidade, perspicácia, vivacidade.
Geralmente associa-se Agilidade com:– Rapidez, Flexibilidade, Leveza– Resumo: Habilidade para mudar
m
P = m.g
m
P = m.g
25/04/2009 2
© 200925/04/2009
O Manifesto ÁgilO Manifesto Ágil
“Estamos descobrindo melhores maneiras de desenvolver software,fazendo software e ajudando outros a fazê-lo.Através deste trabalho passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas.
Software que funciona mais que documentação detalhada.
Colaboração do cliente mais que negociações contratuais.
Responder às mudanças mais que seguir um plano.
Isto é, embora haja valor nos itens do lado direito,nós valorizamos mais os do lado esquerdo.”
http://www.agilemanifesto.org 20013
© 2009
Ter um ambiente de projeto eficaz
e eficiente
25/04/2009
Pessoas X Tecnologia?Pessoas X Tecnologia?
Conflito?
Equipes motivadas e comunicação
eficaz
Padronização, produtividade,
controle e medição
Objetivo NecessidadesAções
Vontades
Foco nos indivíduos e interações
Foco nos processos e ferramentas
4
© 200925/04/2009
Objetivo NecessidadesAções
Vontades
Examinando as PremissasExaminando as Premissas
Conflito?
Ter um ambiente de projeto eficaz
e eficiente
• Maior interação causa melhor comunicação
• Alta interação fortalece o sentimento de equipe
• Processos são essenciais para padronização, monitoramento, medição e controle
• Ferramentas automatizam partes do processo, facilitam a padronização, aumentam a produtividade e permitem a coleta automática de medidas
• Equipes motivadas, comunicando-se melhor, produzem com mais qualidade, aumentando a eficácia do processo
• Um projeto necessita de mecanismos de controle
• Padronização leva à reutilização, que aumenta a produtividade e diminui os erros
• Não é possível ter foco em ambos!
Foco nos indivíduos e interações
Foco nos processos e ferramentas
5
© 200925/04/2009
Objetivo NecessidadesAções
Vontades
Pessoas & Tecnologia!Pessoas & Tecnologia!
Indivíduos amparados por
processos e ferramentas apropriadas, otimizando
suas interações
Ter um ambiente de projeto eficaz
e eficiente
6
© 200925/04/2009
Triângulo de Ferro?Triângulo de Ferro?
Responder às mudanças
Seguir um plano
Conflito?
Entregar um produto que o cliente deseja
Entregar no prazo e dentro do orçamento
Completar um projeto com
sucesso
Objetivo NecessidadesAções
Vontades
7
© 200925/04/2009
Examinando as PremissasExaminando as Premissas
Responder às mudanças
Seguir um plano
Conflito?
Entregar um produto que o cliente deseja
Entregar no prazo e dentro do orçamento
Completar um projeto com
sucesso
Objetivo NecessidadesAções
Vontades
• O cliente e a equipe aprendem durante o projeto
• Murphy participa ativamente dos projetos
• Ter um mapa do caminho ajuda muitíssimo na viagem
• Sem um plano, como saber quando há mudança?
• Nenhum cliente fica satisfeito se não obtiver o que deseja, não importando que tenha mudado de idéia durante o projeto
• É importante ter uma estimativa de prazo e custo, até mesmo para decidir se o projeto é viável
• Cumprir essas expectativas é um sinal de confiança e competência
• Não é possível conseguir ambos!
8
© 200925/04/2009
Triângulo de Ouro!Triângulo de Ouro!
Entregar um produto que o cliente deseja
Entregar no prazo e dentro do orçamento
Completar um projeto com
sucesso
Objetivo NecessidadesAções
Vontades
Planejar com Objetivos,
Entregáveis e Critérios de Sucesso,
abraçando e monitorando a
variação
9
© 200925/04/2009
Projetos Doentes: Os SintomasProjetos Doentes: Os Sintomas
Atrasos
Recursos sobrecarregados
Excesso de mudanças
Retrabalho
Recursos não disponíveis
Prioridades mutáveis
10
© 200925/04/2009
As CausasAs Causas
1. Multitarefa Nociva
2. Lei de Parkinson
3. Síndrome do Estudante
4. Dependência Entre Tarefas
5. Matemática da Gerência de Projetos
11
© 200925/04/2009
1) Multitarefa Nociva1) Multitarefa Nociva
Multitarefa é a execução “simultânea” de várias tarefas, onde freqüentemente há a interrupção de uma tarefa para trabalhar em outra– Nociva: se houver alguém esperando pela saída da tarefa interrompida– Benigna: se corresponde ao aproveitamento do tempo relativo a
alguma espera/execução da tarefa anterior
Motivos:– Prioridades que mudam– Falha no planejamento– Tédio em trabalhar numa só tarefa– Atenção dispersa– Síndrome da eficiência– Políticas, métricas, cultura
12
© 200925/04/2009
Por que Aceitamos a Multitarefa?Por que Aceitamos a Multitarefa?
Cultura de “manter-se ocupado” Impressão de que “quantidade” aparece mais que
“qualidade” Não sabemos dizer “NÃO”
– Fórmula do sucesso: não sei– Fórmula do fracasso: querer agradar a todo mundo
Ter uma carreirade sucesso
Demonstrar atitude de “posso fazer”
Cumprir os compromissos
Aceitar novas tarefas
Completar o trabalho
compromissado
13
© 200925/04/2009
O Paradoxo da MultitarefaO Paradoxo da Multitarefa
Intenção: acabar mais tarefas mais rapidamente Conseqüência: todas as tarefas atrasam, e sofrem
potencialmente de má qualidade
A
Pre
paro
BP
repa
roC
Pre
paro
A B C
A
Pre
paro
Pre
paro
B
Pre
paro
C
Pre
paro
AB
Pre
paro
BP
repa
roC
Pre
paro
A
Pre
paro
B
Pre
paro
C
A B C
ABC
14
© 200925/04/2009
2) Lei de Parkinson2) Lei de Parkinson
“O trabalho se expande para ocupar todoo tempo previsto para ser realizado”
A estimativa acaba sendo cumprida– Profecia auto-realizada– A estimativa é inchada a cada projeto
Impede o término “oficial” e a entrega antecipada de uma tarefa
Ser um membro de equipe considerado
de sucesso
Contribuir para completar mais cedo
Ter o tempo suficiente no
próximo projeto
Entregar o trabalho mais cedo
Não entregar o trabalho mais cedo
15
© 200925/04/2009
Outra Impressão ErrôneaOutra Impressão Errônea
• Ao estimar uma tarefa, a imagem mental que temos é que a curva de probabilidade seria uma distribuição normal (Gauss)
• Assim, uma margem de 30% de segurança resultaria num pequeno aumento do prazo estimado
• Mas a realidade é que a curva é assimétrica, com uma longa cauda para o futuro
• Assim, a margem de 30% resulta em quase o dobro de prazo
16
© 200925/04/2009
Quanto Mais Segurança...Quanto Mais Segurança...
Se há tanta segurança embutida nas tarefas, por que elas atrasam tanto?
E se a segurança está embutida por causa de Murphy, e ele não ataca todas as tarefas, porque elas não terminam antes?– Mesmo se terminarem no prazo, é inaceitável, pois sabemos que o
prazo está mais do que inchado, para esperar eventos que não aconteceram
Qual é a recompensa para quem termina as tarefas antes do prazo estimado?– Menos segurança nas próximas estimativas!
Utilizar datas de início e término de tarefas é reforçar a Lei de Parkinson!
17
© 200925/04/2009
3) Síndrome do Estudante3) Síndrome do Estudante
Quando alguém espera até o últimomomento possível para iniciar uma tarefa
“Por que fazer hoje o que eu possodeixar para amanhã? Tenho tempo...”
A segurança embutida já é consumida antes
Tempo
Tra
balh
o r
eal
na
tare
fa
Data de entrega
Tempo da tarefa
Segurança
Imaginou-se assim...
Tempo da tarefaSegurança
Mas na realidade foi assim...
18
© 200925/04/2009
4) Dependência Entre Tarefas4) Dependência Entre Tarefas
Como os projetos atrasam?– “Um dia por vez.” (Fred Brooks)
No cronograma abaixo, sabendo-se queas tarefas não podem iniciar antes dadata planejada, qual foi o prazo deentrega real?
A10 B10
C15
D10
E5
Tarefa Estimado Realizado
A 10 8
B 10 13
C 15 17
D 10 9
E 5 525
A8 B13
C17
D9
E5
28
Adiantamentos não se propagam,atrasos sim!
19
© 200925/04/2009
Probabilidade CumulativaProbabilidade Cumulativa
A probabilidade total de eventos dependentes é o produto das probabilidades individuais
Tarefa 1 (90%) Tarefa 2 (90%) Tarefa 3 (90%)
90% de chanceda tarefa 1
terminar no prazo
81% de chancedas tarefas 1 e 2
terminarem no prazo
73% de chancedas tarefas 1, 2 e 3
terminarem no prazo
Feito
Tarefa 1 (90%)
Tarefa 2 (90%)
Tarefa 3 (90%)
Feito
90% de chanceda tarefa 3terminar no prazo
90% de chanceda tarefa 1terminar no prazo
90% de chanceda tarefa 2terminar no prazo
73% de chancedas tarefas 1, 2 e 3 terminarem no prazo
Isso vale para execução em
série e em paralelo!
20
© 200925/04/2009
Dependência de RecursosDependência de Recursos
É o tipo de dependência mais negligenciada, e a mais fatal para o projeto
No projeto abaixo, se astarefas B e D tiveremque ser feitas pelomesmo recurso, qual onovo prazo de entregaestimado?
A10 B10
C15
D10
E5
25
A10 B10
C15
D10
E5
25
CenárioOtimista
CenárioPessimista(+ provável)
A10 B10
C15
D10
E5
35
21
© 200925/04/2009
5) A Matemática do Ger. Projetos5) A Matemática do Ger. Projetos
Duas operações são geralmente feitas:– Adição: cada nível hierárquico adiciona
sua própria segurança, pois não confiaque a estimativa seja suficiente
– Subtração: cada nível desconta umaparcela, pois presume-se que hámuita segurança embutida
Como não se sabe o fator deinflação/deflação, usa-se o
1 3 2
8 7
1+3+2=8
8+7=19
CritérioHipotéticoUniversal deTentativa eErro
22
© 2009
Planejamento pelaCorrente Crítica
Planejamento pelaCorrente Crítica
25/04/2009 23
© 200925/04/2009
Projeto de ExemploProjeto de Exemplo
Este é o nosso projeto piloto para aplicação dos conceitos da Corrente Crítica
A B
0 20 40 60 80 100 120 140
B C D
B
E
A, B, C, D, ESão recursos
individuais
24
© 200925/04/2009
1) Identificar a Restrição do Sistema1) Identificar a Restrição do Sistema
Corrente Crítica– A corrente mais longa de tarefas dependentes
A B
0 20 40 60 80 100 120 140
B C D
B
E
Após onivelamentode recursos
25
© 200925/04/2009
2) Decidir Como Explorar a Restrição2) Decidir Como Explorar a Restrição
A B
0 20 40 60 80 100 120 140
B C D
B
ECorrente Críticaantes da remoçãoda segurança
A B
0 20 40 60 80 100 120 140
B C D
B
ECorrente Críticaapós a remoçãoda segurança
pulmão
Pulmão do Projeto•50% da segurança removida•mínimo 1/3 do tempo total
26
© 200925/04/2009
3) Subordinar Tudo à Decisão Anterior3) Subordinar Tudo à Decisão Anterior
Devemos proteger a Corrente Crítica contra distúrbios nos caminhos que se integram a ela– Inserimos pulmões de integração
pi = pulmão de integração
50% da duração das atividadesque se integram à Corrente Crítica
A B
0 20 40 60 80 100 120 140
B C D
B
E
pi
pi
pi
pi pi
pi
pi
pi
pulmão proj.
27
© 2009
Ciclo de Vida da Corrente CríticaCiclo de Vida da Corrente Crítica
A B C
A C D
B E C
Tempo
3. Identificação da Corrente Crítica
1. Duração média das tarefas
A
2. Remoção dos conflitos por recursos (multitarefa é proibida!)
4. Definição do pulmão do projeto
5. Alocação dos pulmões de integração
6. Ajustar a data de início dos caminhos não críticos para o mais tarde possível
8. Comportamento de corrida de revezamento
7. Gestão dos pulmões
25/04/2009 28
© 200925/04/2009
O Comportamento Individual:Efeito Papa-LéguasO Comportamento Individual:Efeito Papa-Léguas No Método da Corrente Crítica, os membros da equipe
geralmente não possuem datas de início e fim das tarefas, mas sim uma lista de tarefas em ordem de prioridade
Assim, não há necessidade de ficar esperando uma data para finalizar uma tarefa, nem para começar outra
A ordem é: há alguma tarefa atribuída e as entradas necessárias estão disponíveis?– Sim Trabalhe o mais rápido possível!– Não Pode relaxar ou fazer outra coisa, mas
esteja pronto para voltar, caso necessário
29
© 2009
Indicador do Pulmão:CP: Consumo de PulmãoIndicador do Pulmão:CP: Consumo de Pulmão Usado para todos os pulmões (de projeto e de integração) Ajuda na definição das prioridades das tarefas:
– Tarefas de Corrente Crítica possuem prioridade sobre as outras tarefas– Se duas tarefas de Corrente Crítica estiverem competindo, aquela que
estiver consumindo mais o pulmão do projeto possui prioridade– Se duas tarefas não críticas estiverem competindo, aquela que estiver
consumindo relativamente mais o pulmão de integração possui prioridade– Se o consumo de pulmão for igual, o projeto com a data de entrega mais
próxima possui prioridade
Verde
Tranqüilo
Amarela
Preparar um planode recuperação
Vermelha
Executar o planode recuperação
Pulmão
33% 66% 100%0%
25/04/2009 30
© 2009
Cálculo do Consumo do Pulmão (CP)Cálculo do Consumo do Pulmão (CP)
B: 8
A: 14
A: 12
B: 8
Pulmão: 10Planejado
Realizado
CP=20%Consumi 4 dias, mas
acho que ainda precisarei de mais 10
dias...
Dia de relato de status...
25/04/2009 31
© 2009
Pulmograma©:CP x CC (Corrente Completada)Pulmograma©:CP x CC (Corrente Completada)
0
100
0 100
10
20
30
40
50
60
70
80
90
10 20 30 40 50 60 70 80 90
Corrente Crítica Completada (%)
Con
sum
o d
o P
ulm
ão
do P
roje
to (
%)
Executar recuperação
Planejarrecuperação
Observar
Histórico do Pulmão em dd/mm/aaaa hh:mmProjeto: xxxx
Marco de Referência: Final do Projeto
Projeto comproblema
Projeto normalProjeto normal
Projeto emProjeto emrecuperaçãorecuperação
25/04/2009
Pu
lmo
gra
ma
é u
m te
rmo
criad
o p
or
Ad
ail M
un
iz Re
tam
al ©
20
07
-20
09
32
© 2009
Pulmograma©:Portfólio de ProjetosPulmograma©:Portfólio de Projetos
0
100
0 100
10
20
30
40
50
60
70
80
90
10 20 30 40 50 60 70 80 90
Corrente Crítica Completada (%)
Con
sum
o d
o P
ulm
ão
do P
roje
to (
%)
Executar recuperação
Planejarrecuperação
Observar
Portfolio de Projetos em dd/mm/aaaa hh:mmMarco de Referência: Final do Projeto
Projeto A
Projeto B
Projeto C
Projeto D
Projeto E
25/04/2009
Pu
lmo
gra
ma
é u
m te
rmo
criad
o p
or
Ad
ail M
un
iz Re
tam
al ©
20
07
-20
09
33
© 2009
Corrente Crítica& Agile
Corrente Crítica& Agile
25/04/2009 34
© 2009
Cenários MistosCenários Mistos
Iteração 1 Iteração 2 Iteração 3
Iteração 4
Iteração 5
pi
Pulmão do Projeto
Corrente Iterativa
pi
pi
pi pi
Pulmão Iteração
1) Planejamento da Iteração
2) Execução
Dia
Iteração
Iteração Crítica
25/04/2009 35
© 2009
FDD & CCPMFDD & CCPM
25/04/2009 36
CF A10d
CF B15d
CF C13d
Pulmão11d
CF D25d
CF E32d
CF F17d
CF G8d
CF H23d
CF I19d
Pulm.16d
Integr.10d
Testes20d
Pulmão Projeto30d
Pulm.10d
Conc.10d
Concepção e PlanejamentoDesenvolverum ModeloAbrangente
Planejarpor
Feature
Construira Lista de Features
Construção
Detalharpor
Feature
Construirpor
Feature
© 2009
Casos de SucessoCasos de Sucesso
25/04/2009 37
Artigos disponíveis emwww.heptagon.com.br/toc-links
© 200925/04/2009
Manifesto TOC Ágil?Manifesto TOC Ágil?
“Estamos questionando as maneiras como os projetos são gerenciados e executados, identificando as restrições, explorando-as ao máximo e
elevando-as. Através deste trabalho notamos que:
Indivíduos amparados por processos, métricas e ferramentas apropriados comportam-se de forma a obter o melhor para o sistema.
Entregar o escopo prometido, incluindo as mudanças necessárias, dentro do prazo e orçamento, é importante para o cliente e plenamente possível.
Usar um método que define um plano que incorpora a variação e que permite visibilidade e ação oportuna dá segurança ao cliente e à equipe.”
Adail Muniz Retamal© 2008
38
© 2009
Onde Aprender Mais?Onde Aprender Mais?
www.heptagon.com.brArtigos, links, ferramentas, workshops
25/04/2009 39
© 2009
Heptabraço!Heptabraço!
Adail Muniz [email protected]
www.heptagon.com.br
Adail Muniz [email protected]
www.heptagon.com.br
25/04/2009 40