GERENCIAMENTO Ă GIL DE PROJETOS Uma nova abordagem para os desafios de sempre
Leandro Faria
PMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT
• Especialista em agilidade para gestão de projetos e produtos; • Graduado em Sistemas de Informação e Pós-graduado em Gestão Estratégica de Projetos pela Universidade Fumec; • Responsável pelo Business Development e Pre-sales para a NA e EMEA na Stefanini, maior empresa de tecnologia da América Latina, com faturamento superios a 1 bilhão de dólares e operações em mais de 30 países; • Executivo nomeado do capítulo mineiro do PMI; • Fundador do Scrum Minas, um dos primeiros user groups da Scrum Alliance no Brasil, com mais de 200 membros; Fundador do Limited WIP Society Brazil, e do • Um dos primeiros profissionais no mundo a obter a certificação PMI-ACP;
SOBRE
• A Origem da Agilidade • Números da Agilidade • Scrum • Kanban • Conclusões
AGENDA
A ORIGEM DA AGILIDADE
PERGUNTA: QUAIS Sﾃグ AS PRINCIPAIS DIFICULDADES EM PROJETOS?
Falta de planejamento Mudança constante de requisitos Escopo mal definido Falta de participação do cliente Comunicação falha
Em 1995 o Departamento de Defesa dos Estados Unidos gastou $35.7 bilh玫es de d贸lares em software e somente 2% foi plenamente utilizado. Fonte: CHAOS, Standish Group
A ORIGEM DA AGILIDADE
O artigo acadêmico elaborado em 1998 na
Harvard Business School pelos pesquisadores Robert D. Austin e Richard L. Nolan expôs as dificuldades da gestão tradicional de projetos em grandes projetos de software e questionou algumas das premissas fundamentais do gerenciamento de projetos.
A ORIGEM DA AGILIDADE
“Em um novo projeto de software, os requisitos nunca serão completamente conhecidos até que o usuário os tenha utilizado.” Watts Humphrey, IBM Research
A ORIGEM DA AGILIDADE
“A incerteza é inerente e inevitável nos processos de desenvolvimento de software e produtos.”
Hadar Ziv, University of California
A ORIGEM DA AGILIDADE
Abrangendo todos estes novos conceitos, o artigo Why Evolutionary Software Development Works escrito em 2001 pelo professor assistente na Hardvard Business School, Alan MacCormack, estudou as abordagens existentes da época e suas implicações.
A ORIGEM DA AGILIDADE
O artigo não só expunha os problemas dos métodos, mas também sugeria novas abordagens e práticas que poderiam começar a substituir o ciclo de vida natural de desenvolvimento. Estas três simples ideias, ficaram marcadas como o início das práticas ágeis: • Entrega antecipada de arquitetura e codificação; • Compilação diária de código e feedback rápido; • Equipes profundamente capacitadas.
A ORIGEM DA AGILIDADE
O Manifesto Ágil foi a culminação de todas estas teorias e abordagens. Escrito em 2001 por um grupo de praticantes da teoria iterativa incremental, é o documento de fundação do movimento ágil e estabelece a filosofia do conceitos por trás da gestão ágil de projetos.
O MANIFESTO ÁGIL
Manifesto para Desenvolvimento Ágil de Software “Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.” http://agilemanifesto.org/iso/ptbr/
Entre os assinantes estão muitos dos criadores dos frameworks, práticas e manuais mais utilizados pela comunidade ágil, entre eles: • Jeff Shuterland e Ken Schwaber, criadores do Scrum; • Kent Beck e Ron Jeffries, criador do eXtreme Programming e TestDriven-Development; • Alistair Cockburn, criador do método Crystal; • Jim Highsmith, que traduziu conceitos ágeis de software em uma metodologia de Gerenciamento Ágil de Projetos.
O MANIFESTO ÁGIL
NÚMEROS DA AGILIDADE
NÚMEROS DA AGILIDADE
NÚMEROS DA AGILIDADE
NÚMEROS DA AGILIDADE
NÚMEROS DA AGILIDADE
SCRUM
• Framework de gestão de produtos complexos baseado no modelo iterativo e incremental; • Scrum não é um processo ou técnica para construir produtos, é um framework dentro do qual se pode empregar processos e técnicas variadas.
SCRUM
Transparência Inspeção Adaptação
PILARES
Transparência Todo e qualquer fator ou acontecimento relacionado ao processo de entrega, que possa impactar o resultado final do projeto (produto), deve ser visível e do conhecimento de todos envolvidos, inclusive o cliente.
Inspeção Adaptação
PILARES
Transparência Inspeção Todos os aspectos do processo de entrega que possam impactar o resultado final do projeto devem ser inspecionados freqüentemente, para que qualquer variação prejudicial possa ser identificada e corrigida o mais rápido possível.
Adaptação
PILARES
Transparência Inspeção Adaptação Toda vez que uma variação prejudicial é identificada, o processo deve ser ajustado imediatamente, como forma de evitar outros desvios.
PILARES
Derivado da engenharia, tem etapas e objetivos muito bem definidos em um fluxo no modelo cascata, onde uma etapa é executada após a outra até o fim do projeto.
FLUXO “TRADICIONAL”
Qual é o custo da mudança?
Processo baseado em iterações que incrementam a construção de um produto, com entregar parciais, baseado no feedback do cliente.
FLUXO ITERATIVO E INCREMENTAL
Product Owner
Maximza o valor do produto e o trabalho da equipe. É responsável pela definição, priorização e manutenção do backlog do projeto.
Time
Profissionais de desenvolvimento que criam o incremento do produto. Auto organizáveis e multi funcionais. Mais que três e menos que nove.
Scrum Master
O Scrum Master é responsável para garantir que o Scrum seja entendido e aplicado. É um líder facilitador e servidor para a equipe Scrum.
TIME SCRUM
Product Backlog
Sprint Backlog
Incremento
Lista ordenada de tudo que pode ser necessário no produto. Fonte única de requisitos do projeto, é mantida pelo Product Owner.
Conjunto de itens selecionados do Product Backlog para execução na Sprint corrente. Prevista e estimada pelo time de desenvolvimento. Soma de todos os itens do Product Backlog completados por um Sprint. A “definição de pronto” é previamente acordada com o PO.
ARTEFATOS SCRUM
Planejamento da Sprint (~4 horas) • • •
Planejamento da Sprint; Definição do objetivo da Sprint; O que será incluso na Sprint.
Revisão da Sprint (~4 horas) • • •
Validação do produto entregue; Discussão dos itens do backlog; Input valioso para o planning.
Reunião Diária (15 minutos) • • •
O que foi realizado desde ontem? O que será realizado hoje? Existe algum impedimento?
Retrospectiva da Sprint (~3 horas) • • •
EVENTOS SCRUM
3 horas para cada 1 mês de sprints; Lições aprendidas; Proposta de melhorias no processo.
O Scrum Board faz a gest茫o visual do ciclo de vida do projeto e o status de cada est贸ria.
SCRUM BOARD
O Release Burndown Chart acompanha o progresso da sprint comparado ao seu planejamento.
BURNDOWN CHART
ATENÇÃO! O SCRUM MASTER NÃO É O GERENTE DE PROJETOS
KANBAN
Em Tóquio no mês de Abril, os Jardins do Oriente ficam repletos de visitantes e turistas que vão lá para desfrutar da tranquilidade do parque e beleza da sakura (flor da cerejeira).
OS JARDINS DO PALÁCIO IMPERIAL DO JAPÃO
Ao entrar no parque, cada visitante recebe um “Admission Ticket”, um pequeno cartão de plástico sem identificação ou cobrança que é devolvido na saída do parque.
Fim Saída (+1 Ticket)
Início Entrada (-1 Ticket)
Visitante
OS JARDINS DO PALÁCIO IMPERIAL DO JAPÃO
PERGUNTA: SE O TICKET NÃO TEM NENHUMA IDENTIFICAÇÃO, NÃO É REGISTRADO NA ENTRADA, E NÃO É COBRADO, PRA QUE ELE EXISTE?
Para controlar o WIP.
WIP = Work in Progress Cada visitante que recebe um ticket é considerado um WIP. Como existe um limite de pessoas dentro dos jardins, quando os cartões acabam, as pessoas formam uma fila do lado de fora dos portões aguardando que novos cartões estejam disponíveis, devolvidos pelos visitantes que saíram.
OS JARDINS DO PALÁCIO IMPERIAL DO JAPÃO
• O WIP associado a um limite, põe em prática conceitos conhecidos como sistemas “puxados” (pull systems). • Em resumo, o Palácio Imperial de Tóquio utiliza um sistema Kanban!
OS JARDINS DO PALÁCIO IMPERIAL DO JAPÃO
• Um sistema puxado, determina que o WIP em uma organização, em um time, ou uma célula, deve ser configurado levando em consideração a capacidade de execução de trabalho, ou como conhecemos, pelos seus limites; • O objetivo principal é atingir um ritmo sustentável de produção, e evitar sintomas como: overstocking, bottlenecks e delays.
SISTEMAS PUXADOS
• A Teoria das Restrições (TOC – Theory of Constraints) é uma filosofia de negócios introduzida por Eliyahu M. Goldratt no seu livro “A Meta”, de 1984; • Ela é baseada na aplicação de princípios científicos e do raciocínio lógico para guiar organizações humanas; • De acordo com a TOC, toda organização tem – em um dado momento no tempo – pelo menos uma restrição que limita a performance do sistema (a organização em questão) em relação à sua meta; • Para gerir a performance do sistema, a restrição deve ser identificada e administrada.
A TEORIA DAS RESTRIÇÕES
O Kanban implementa conceitos da Teoria das Restrições em um modelo de sistema puxado.
A TEORIA DAS RESTRIÇÕES
O conceito de sistema puxado foi amplamente utilizado em aplicações de supply chain management, em especial pelo pioneiro Sistema Toyota de Produção, base para diversos frameworks e metodologias inspiradas em Lean Manufacturing, criando por exemplo, sistemas com o Just in Time.
PORQUE KANBAN?
• Kanban é uma palavra japonesa que significa “etiqueta” ou “cartão sinalizador”; • Em administração da produção, kanban significa um cartão de sinalização que controla os fluxos de produção ou transportes em uma indústria. O cartão pode ser substituído por outro sistema de sinalização, como luzes, caixa ou locais vazios demarcados; • No caso da Toyota, cartões kanban são utilizados para sinalizar a necessidade de repor estoques.
PORQUE KANBAN?
“kanban” com “k” minúsculo, refere-se aos cartões sinalizadores há muito tempo utilizados na indústria. “Kanban”, com “K” maiúsculo, é utilizado para se referir ao método de melhoria de processo incremental que surgiu entre 2006 e 2008 e é hoje amplamente utilizado e aprimorado pela comunidade lean software development.
PORQUE KANBAN?
Quadros de cartões e post-its se tornaram um mecanismo de controle visual popular no desenvolvimento de software ágil, para controle do WIP. Vale observar que os Kanban boards não são inerentemente sistemas Kanban, são apenas ferramenas de controle visual.
KANBAN BOARDS
KANBAN BOARDS
KANBAN BOARDS
KANBAN BOARDS
• Um diagrama de fluxo cumulativo é um gráfico de área que representa a quantidade de trabalho em um determinado estado; • A distância entre a primeira e última linha horizontalmente representa o WIP; • A distância entre a primeira e a última linha verticalmente representa uma média de lead time.
MÉTRICAS
• A diminuição do WIP comprovadamente diminui o lead time médio; • Isto significa menos trabalho em progresso, mais entregas, menor chance de erros e consequentemente melhoria na qualidade.
MÉTRICAS
CONCLUSÕES
TRADICIONAL
+
ÁGIL
Não opte por um ou outro. Utilize ambos, na medida certa para o cenário do projeto. O objetivo é resultado.
CONCLUSÕES
Artigos, slides, vídeos, podcasts: www.leandrofaria.com.br PMI Agile Virtual Community: agile.vc.pmi.org
REFERÊNCIAS
Congresso Brasileiro de Gerenciamento de Projetos 2013 5 a 7 de junho de 2013, Goiânia - GO www.cbgp.com.br Agile Brazil 2013 26 a 28 de junho de 2013, Brasília - DF www.agilebrazil.com Curso Preparatório para a Certificação PMI-ACP 4 a 18 de maio de 2013, Belo Horizonte - MG agile.brainss.com.br
CONVITES
LEANDRO FARIA PMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT www.leandrofaria.com.br contato@leandrofaria.com.br twitter.com/lhfaria
PERGUNTAS?