Agilidade Alternativa com Corrente Crítica

Porto Alegre Agile Weekend 25/04/2009 Agilidade Alternativa com Corrente Crítica Engº Adail Muniz Retamal adail@heptagon.com.br 25/04/2009

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 25/04/2009 © 2009 2

O 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 2001 25/04/2009 © 2009 3

Pessoas X Tecnologia? Ações Objetivo Necessidades Vontades Equipes motivadas Foco nos e comunicação indivíduos e eficaz interações Ter um ambiente de projeto eficaz Conflito? e eficiente Padronização, Foco nos produtividade, processos e controle e medição ferramentas 25/04/2009 © 2009 4

Examinando as Premissas • Equipes motivadas, • Maior interação causa comunicando-se melhor, Ações Objetivo produzem com mais qualidade, Necessidades melhor comunicação o • Alta interação fortalece Vontades aumentando a eficácia do sentimento de equipe processo Foco nos indivíduos e interações Ter um ambiente • Não é possível ter de projeto eficaz foco em ambos! Conflito? e eficiente Foco nos processos e ferramentas • Um projeto necessita de • Processos são essenciais para padronização, mecanismos de controle monitoramento, medição e controle • Padronização leva à reutilização, • Ferramentas automatizam partes do processo, facilitam que aumenta a produtividade e a padronização, aumentam a produtividade e permitem diminui os erros a coleta automática de medidas 25/04/2009 © 2009 5

Pessoas & Tecnologia! Ações Objetivo Necessidades Vontades Indivíduos amparados por processos e Ter um ambiente ferramentas de projeto eficaz apropriadas, e eficiente otimizando suas interações 25/04/2009 © 2009 6

Triângulo de Ferro? Ações Objetivo Necessidades Vontades Entregar um produto Responder às que o cliente deseja mudanças Completar um projeto com Conflito? sucesso Entregar no prazo e Seguir um dentro do orçamento plano 25/04/2009 © 2009 7

Examinando as Premissas • O cliente e a equipe • Nenhum cliente fica satisfeito se aprendem durante o Ações não obtiver o que deseja, não Objetivo Necessidadesprojeto importando que tenha mudado • Murphy participa Vontades de idéia durante o projeto ativamente dos projetos Entregar um produto Responder às que o cliente deseja mudanças Completar um • Não é possível projeto com conseguir ambos! Conflito? sucesso Entregar no prazo e Seguir um dentro do orçamento plano • É importante ter uma estimativa de prazo e custo, até mesmo • Ter um mapa do caminho para decidir se o projeto é viável ajuda muitíssimo na viagem • Cumprir essas expectativas é • Sem um plano, como saber um sinal de confiança e quando há mudança? competência 25/04/2009 © 2009 8

Triângulo de Ouro! Ações Objetivo Necessidades Vontades Entregar um produto Planejar com que o cliente deseja Objetivos, Entregáveis e Completar um Critérios de projeto com Sucesso, sucesso abraçando e Entregar no prazo e monitorando a dentro do orçamento variação 25/04/2009 © 2009 9

1) 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 25/04/2009 © 2009 12

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 Demonstrar atitude Aceitar novas de “posso fazer” tarefas Ter uma carreira de sucesso Completar o Cumprir os trabalho compromissos compromissado 25/04/2009 © 2009 13

O Paradoxo da Multitarefa  Intenção: acabar mais tarefas mais rapidamente  Conseqüência: todas as tarefas atrasam, e sofrem potencialmente de má qualidade A B C Preparo Preparo Preparo A B C A B C Preparo Preparo Preparo Preparo Preparo Preparo Preparo Preparo Preparo A B C A B C A B C A B C 25/04/2009 © 2009 14

2) Lei de Parkinson  “O trabalho se expande para ocupar todo o 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 Contribuir para Entregar o trabalho completar mais cedo mais cedo Ser um membro de equipe considerado de sucesso Ter o tempo Não entregar o suficiente no trabalho mais cedo próximo projeto 25/04/2009 © 2009 15

Outra 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 25/04/2009 © 2009 16

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! 25/04/2009 © 2009 17

3) Síndrome do Estudante  Quando alguém espera até o último momento possível para iniciar uma tarefa  “Por que fazer hoje o que eu posso deixar para amanhã? Tenho tempo...”  A segurança embutida já é consumida antes Data de entrega Imaginou-se assim... Trabalho real na tarefa Tempo da Segurança tarefa Mas na realidade foi assim... Segurança Tempo da tarefa Tempo 25/04/2009 © 2009 18

4) Dependência Entre Tarefas  Como os projetos atrasam? – “Um dia por vez.” (Fred Brooks)  No cronograma abaixo, sabendo-se que as tarefas não podem iniciar antes da data planejada, qual foi o prazo de Adiantamentos não entrega real? se propagam, atrasos sim! Tarefa Estimado Realizado A 10 8 A10 B10 A8 B13 B 10 13 C15 E5 C 15 17 C17 E5 D10 D 10 9 D9 E 5 5 25 28 25/04/2009 © 2009 19

Probabilidade Cumulativa  A probabilidade total de eventos dependentes é o produto das probabilidades individuais Tarefa 1 (90%) Tarefa 2 (90%) Tarefa 3 (90%) Feito 90% de chance da tarefa 1 81% de chance terminar no prazo das tarefas 1 e 2 73% de chance terminarem no prazo das tarefas 1, 2 e 3 terminarem no prazo 90% de chance da tarefa 1 terminar no prazo Tarefa 1 (90%) 90% de chance da tarefa 2 terminar no prazo Isso vale para execução em Tarefa 2 (90%) Feito 73% de chance série e em das tarefas 1, 2 e 3 terminarem no prazo paralelo! Tarefa 3 (90%) 90% de chance da tarefa 3 terminar no prazo 25/04/2009 © 2009 20

Dependência de Recursos  É o tipo de dependência mais negligenciada, e a mais fatal para o projeto  No projeto abaixo, se as tarefas B e D tiverem que ser feitas pelo mesmo recurso, qual o A10 B10 novo prazo de entrega Cenário C15 E5 estimado? Otimista D10 25 A10 B10 A10 B10 C15 E5 C15 E5 Cenário D10 Pessimista D10 (+ provável) 25 35 25/04/2009 © 2009 21

5) 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 confia que a estimativa seja suficiente – Subtração: cada nível desconta uma 8+7=19  parcela, pois presume-se que há 8 7 muita segurança embutida  Como não se sabe o fator de inflação/deflação, usa-se o  1+3+2=8 Critério 1 3 2 Hipotético Universal de Tentativa e Erro  25/04/2009 © 2009 22

2) Decidir Como Explorar a Restrição A B E Corrente Crítica antes da remoção B C D da segurança B 0 20 40 60 80 100 120 140 Pulmão do Projeto •50% da segurança removida A B E pulmão •mínimo 1/3 do tempo total Corrente Crítica B C D após a remoção da segurança B 0 20 40 60 80 100 120 140 25/04/2009 © 2009 26

3) 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 A B pi E pulmão proj. pi B C D pi pi pi = pulmão de integração pi B pi 50% da duração das atividades pi que se integram à Corrente Crítica pi 0 20 40 60 80 100 120 140 25/04/2009 © 2009 27

Ciclo de Vida da Corrente Crítica 1. Duração média das tarefas 2. Remoção dos conflitos por recursos (multitarefa é proibida!) A 3. Identificação da Corrente Crítica A B C 8. Comportamento de corrida de revezamento A C D 7. Gestão dos pulmões B E C 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 Tempo 25/04/2009 © 2009 28

O 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 25/04/2009 © 2009 29

Indicador 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 Pulmão Verde Amarela Vermelha Tranqüilo Preparar um plano Executar o plano de recuperação de recuperação 0% 33% 66% 100% 25/04/2009 © 2009 30

Cálculo do Consumo do Pulmão (CP) Dia de relato de status... Consumi 4 dias, mas acho que ainda CP=20% precisarei de mais 10 dias... Planejado A: 12 B: 8 Pulmão: 10 Realizado A: 14 B: 8 25/04/2009 © 2009 31

Pulmograma : © CP x CC (Corrente Completada) Histórico do Pulmão em dd/mm/aaaa hh:mm Projeto: xxxx Marco de Referência: Final do Projeto 100 90 Consumo do Pulmão do Projeto (%) 80 Pulmograma é um termo criado por Adail Muniz Retamal ©2007-2009 Executar recuperação 70 60 Planejar recuperação 50 40 Projeto com Projeto em problema recuperação 30 20 Observar 10 Projeto normal 0 0 10 20 30 40 50 60 70 80 90 100 Corrente Crítica Completada (%) 25/04/2009 © 2009 32

Pulmograma : © Portfólio de Projetos Portfolio de Projetos em dd/mm/aaaa hh:mm Marco de Referência: Final do Projeto 100 90 Projeto A Consumo do Pulmão do Projeto (%) 80 Pulmograma é um termo criado por Adail Muniz Retamal ©2007-2009 Executar recuperação 70 60 Projeto C Planejar Projeto D recuperação 50 40 Projeto E 30 20 Projeto B Observar 10 0 0 10 20 30 40 50 60 70 80 90 100 Corrente Crítica Completada (%) 25/04/2009 © 2009 33

Cenários Mistos Corrente Iterativa Iteração 1 Iteração 2 Iteração 3 Iteração 5 Pulmão do Projeto Iteração 4 pi Iteração Crítica pi Pulmão Iteração Dia cução 2) Exe pi pi pi Iteração 1) Planejamento da Iteração 25/04/2009 © 2009 35

FDD & CCPM Concepção e Planejamento Desenvolver Construir Planejar um Modelo a Lista de por Abrangente Features Feature CF A CF B CF C Pulmão 10d 15d 13d 11d Conc. Pulm. CF D CF E CF F Integr. Testes Pulmão Projeto 10d 10d 25d 32d 17d 10d 20d 30d CF G CF H CF I Pulm. 8d 23d 19d 16d Construção Detalhar Construir por por Feature Feature 25/04/2009 © 2009 36

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 25/04/2009 © 2009 38

Agilidade Alternativa com Corrente Crítica

0 comments

Notes on slide 1

Favorites, Groups & Events