Kanban Apresentação Encontro Rational 2013

1.165 visualizações

Publicada em

Apresentação de Kanban do Moacyr Mello realizada no Encontro de Desenvolvimento Rational (Março/2013)

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.165
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
37
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Author Notes: This is the IBM Rational standard template for internal and external Rational presentations. It was created in Microsoft PowerPoint Standard Edition 2003. This template is also converted and provided in Lotus Symphony v3.0. Additional IBM Rational presentation assets and resources can be found on Rational ’s Managing the Brand W3 Intranet site : https://w3-03.ibm.com/software/marketing/marksite.nsf/AllMarketingPages/Brand-Rational-rt_rtb?opendocument?opendocument IBM Rational Brand Overview slides, as well as other important brand messaging assets, can be found on the Rational Brand Content Page : http://w3-103.ibm.com/software/xl/portal/content?synKey=R789607U42052O71 If internal presentations are confidential, please add: “IBM Confidential” to the slide masters Select: View / Master / Slide Master and add “IBM Confidential” to both the title master and slide master Use sentence case capitalization for presentation titles, slide titles, category labels and bullets: Format / Change Case / Sentence Case. Initial capitalization is limited to our products and offerings. Applying this template to your existing presentation Task Pane needs to be viewable: Select View / Task Pane Select Slide Design - Design Templates from the Task Pane pull-down menu Select “Browse” at the bottom, and find “Rational_Standard_Template.pot” on your hardrive and click Apply Please note that not all slides will reformat appropriately once template is applied. Some reformatting will be necessary Printing your presentation on a black and white printer Prior to printing your presentation, view the slides in grayscale mode: Select View / Color/Grayscale / Grayscale Select problem graphics or text and right-click and select Grayscale Setting Select the grayscale setting that displays the problem graphic/text the best Note: Changing the greyscale setting does not affect the color view Return to Normal View by selecting View / Color/Grayscale / Color
  • Author notes: Note that the contents/agenda items are written in sentence case. Initial caps are reserved for IBM-branded solution names. When referring to IBM products, use the correct full name, (e.g., IBM Rational ClearCase). Title the page “Table of contents” if the document is meant to be read or is a “leave behind.” Use “Agenda” if the document will be presented formally This page should appear at the beginning of each section, with the highlighted section appearing in blue and bold
  • Too often, processes are owned by a centralized Software Engineering Process Group. The people who use the processes are not sufficiently empowered to drive improvements. Resolving this issue is CRITICAL to the successful implementation of disciplined agile delivery and Agility@Scale. Toyota Production 7 Wastes – Some apply to or are related to software development: Defects - Quality defects prevent the customers from accepting the product produced. The effort to create these defects is wasted. New waste management processes must be added to reclaim some value for the otherwise scrap product. Overproduction - Overproduction is the production or acquisition of items before they are actually required. It is the most dangerous waste for the company because it hides the production problems. Overproduction must be stored, managed, and protected. Transportation - Each time a product is moved, it stands the risk of being damaged, lost, or delayed. And, transportation does not make any transformation to the product that the consumer is disposed to pay for. Waiting - Refers to the time spent by the workers waiting for resources to arrive, the queue for their products to empty, and the capital sunk in goods and services that are not yet delivered to the customer. Inventory – Whether in the form of Raw Materials, Work-In-Progress (WIP), or Finished Goods, inventory represents a capital outlay that has not yet produced an income either by the producer or for the consumer. Any of these three items not being actively processed to add value is waste. Motion - As compared to Transportation, Motion refers to the producer, worker, or equipment. Motion relates to issues of damage, wear, and safety. It also includes fixed assets, and expenses incurred in the production process. Over processing – Can include using a more expensive or otherwise valuable resource than is needed for the task, or adding features that are not needed by the customer. Lean Software Development (or LSD) was adapted from the work done at Toyota Production Systems and was first proposed in a book written by Mary and Tom Poppendieck.
  • According to the Poppendiecks, the people behind Lean Software Development, the three biggest wastes in software development are: Extra features Churn Crossing boundaries What are the 7 Wastes? Eliminate Waste - Seeing Waste and Value Stream Mapping Amplify Learning - Feedback, Iterations, Synchronization, and Set-Based Development Decide as Late as Possible – Options Thinking, The Last Responsible Moment, and Making the Decision Deliver as Fast as Possible – Pull Systems, Queuing Theory, and Cost of Delay Empower the Team – Self-Determination, Motivation, Leadership, and Expertise Build Integrity In – Perceived Integrity, Conceptual Integrity, Refactoring and Testing See the Whole – Measurements and Contracts
  • Author Note: Optional Rational slide. Graphic is available in English only.
  • Author Note: Mandatory Rational closing slide (includes appropriate legal disclaimer). Graphic is available in English only.
  • Kanban Apresentação Encontro Rational 2013

    1. 1. Encontro Rational de Desenvolvimento de Software – 12 de março de 2013 – São PauloAplicando Kanban ao Desenvolvimento deSoftwareMoacyr Mello – mcmello@br.ibm.com Encontro Rational de Desenvolvimento de Software Building better software © 2012 IBM Corporation
    2. 2. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Agenda Kanban, o quadro Kanban, o sistema – Método empírico e receita de aplicação – Conceitos para comparação com Scrum – Limitação de WIP e visualizações2 © 2013 IBM Corporation
    3. 3. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013É antiga a história de processos iterativos  1930’s – processo iterativo Plan-Do-Study-Act  1940’s – Deming promove o ciclo PDSA  1950’s – Projeto NASA X15 foi iterativo e de muito sucesso – Projeto NASA Mercury – iterações de ½ dia com time-boxed e TDD  1950’s – Conceitos de produção Lean – Kaizen – Eliminação de desperdício através de melhoria contínua em atividades, padrões e processos – O trabalho padrão é apenas uma referência para fazer melhor... kaizen, melhoria contínua – Aproveitar a capacidade de pessoas comuns  1968 – IBM Research recomenda o desenvolvimento iterativo ….. © 2013 IBM Corporation
    4. 4. Encontro Rational de Desenvolvimento de Software – 12 de Março de 20132000’s – Lean software development Baseado nos conceitos do Toyota Lean Production http://www.poppendieck.com/  Conceitos Lean - Agile, aplicados ao desenvolvimento  Após o manifesto Agile, muitas direções de busca  Alternativas aos processos da década de 90  Simplificação do desenvolvimento 改 善 Kaizen 看板 kanban © 2013 IBM Corporation
    5. 5. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013O que é kanban?看板 kanban  cartão de sinalização ou sistema de sinalização O que ele sinaliza? Essencialmente sinaliza a disponibilidade para realizar um trabalho. Um cartão é anexado a um trabalho. O trabalho pode ser iniciado apenas quando o cartão está disponível. O cartão segue o trabalho através do fluxo do sistema de trabalho. Um novo trabalho deve esperar na fila até que um cartão esteja disponível. Portanto na sua essencia há limitação de WIP e reconhecimento da limitação de capacidade do sistema de trabalho. (WIP: Work In Progress) Como o novo trabalho depende da liberação de capacidade, o sistema é conhecido como “sistema puxado”, ao invés de “empurrado com base na demanda”. © 2013 IBM Corporation
    6. 6. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Sistemas “puxados” e a visualização do kanban Permitem que as pessoas examinem por si mesmas o que precisa ser feito. O trabalho torna- se auto-dirigido Tem melhor comportamento quando enfrentam variabilidade É uma abordagem “just in time” que permite decisões de trabalho em tempo real A forma de visualização é através de um quadro onde aparecem “estados” do fluxo de trabalho: Reference: M & T Poppendieck, Lean Software Development. 2003 : Chapter 4 © 2013 IBM Corporation
    7. 7. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Teoria das filas  A chave é reduzir o tempo de ciclo, o tempo que leva da entrada até a saída do sistema. Entrada  Praticar uma taxa constante de chegada e controlar o que entra na fila  Liberar pequenas quantidades de trabalho  Definir prioridades e selecionar trabalho é crítico  Liberar trabalho continuamente é ainda mais crítico  Taxa de entrada > taxa de saída  saturação  Taxa de entrada = taxa de saída  instabilidade ol ga  Taxa de entrada < taxa de saída  estabilidade ia rf Cr © 2013 IBM Corporation
    8. 8. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Metáfora dos escoteiros Mais capacidade que o gargalo Folga na capacidade Tempo ocioso Abordagem do Kanban Conceito   Objetivo  Escoteiros   Desenvolvimento DRUM Define o passo O mais vagaroso Gargalo BUFFER Protege o passo Folga na corda Fila do gargalo A corda é presa entre o primeiro Sistema puxado ROPE Obriga o passo escoteiro e o mais vagaroso (Kanban) © 2013 IBM Corporation
    9. 9. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Visualização do kanban Limitando WIP (work in progress) – designa explicitamente quantos itens de trabalho (work itens) podem ser trabalhados em cada estado WIP é limitado por estado do fluxo de trabalho Papéis Pessoas Atividades Ordem de tarefas Arquitetura 3 2 u fila o lo g back fila Reference: M & T Poppendieck, Lean Software Development. 2003 : Chapter 4 © 2013 IBM Corporation
    10. 10. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Visualização do Scrum Limitando Velocity (produção num time-box) – utiliza a velocidade média de consumo de itens de trabalho (work itens) para limitar o tamanho do Sprint Backlog WIP é limitado por unidade de tempo l og back Reference: M & T Poppendieck, Lean Software Development. 2003 : Chapter 4 © 2013 IBM Corporation
    11. 11. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Scrum Pequenos times, cross-funcionais e auto-organizados Pequenos itens de trabalho em unidades de entrega bem específicas, priorizados e estimados Tempo  dividido em iterações curtas de comprimento fixo Plano de Releases  e priorização de acordo com o cliente Otimização do processo através de retrospectiva a cada iteração ou sprintKanban Visualize o fluxo de trabalho através de estados do fluxo num quadro visual Limite o  WIP designando explicitamente a quantidade de itens por estado do fluxo Medir o lead time (tempo médio para completar um item) também chamado cycle time Utilize Lead time como a métrica básica para o planejamento e melhoria do processo Gargalos, procure vazios no quadro kanban O tamanho do loop de feedback vc pode escolher! © 2013 IBM Corporation
    12. 12. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Acompanhamento Em Scrum usamos Sprint Burndown charts como a forma básica de acompanhar a sprint Não há necessariamente um gráfico para Kanban, é costume usar Cumulative Flow diagram: © 2013 IBM Corporation
    13. 13. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Scrum-kanban  Scrum prescreve time-box e portanto algum tipo de “batch” na implementação dos requisitos – A sucessão de sprints produzem uma cadência positiva para as releases  Kanban não prescreve time-box – Podemos escolher quando planejar, melhorar o processo ou liberar releases. Seja de uma forma sob-demanda ou em períodos regulares, para construir uma cadência  Scrum prescreve 3 papéis  Kanban não prescreve nenhum papel – Isto não significa que não podemos ter um Product Owner junto com Kanban, significa apenas que o método não exige um PO  Ambos prescrevem que o time deve seguir num passo sustentável – O propósito é entregar valor e perpetuar a empresa  A filosofia de Kanban é Kaisen: mude pouco mas para melhor, constantemente. Portanto kanban é o que menos impacta o processo corrente © 2013 IBM Corporation
    14. 14. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Kaisenさんむ 3 Mu‘sむだ muda • Desperdício, o que não agrega valorむら mura • Desencontro das coisasむり muri a g r f ol • Trabalhar acima da capacidade ia Cr © 2013 IBM Corporation
    15. 15. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Caminho suave para amadurecimento e prosperidade... Não buscar igualar a capacidade à demanda (forçando a capacidade) Equilibrar o fluxo primeiro limitando WIP, então encurtando prazos e entregando frequentemente Ao equilibrar demanda e rendimento, criar folga para permitir melhoria Ganhar a confiança da organização com aumento de previsibilidade Avaliar alocação de capacidade por tipo de iten de trabalho (wi) ou classe de serviço Melhorar a priorização para aumentar valor Criar ritmo sustentável ! © 2013 IBM Corporation
    16. 16. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Previsibilidade Limitando WIP (work in progress) para estados e filas, (buffers e backlogs), criamos folga e aumentamos a previsibilidade 5 3 3 2 u fila o lo g back fila Reference: M & T Poppendieck, Lean Software Development. 2003 : Chapter 4 © 2013 IBM Corporation
    17. 17. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Variabilidade Causas internas e/ou externas Templates tendem a diminuir a variação de itens de escrita de requisitos Treinamento, exemplos e uma teoria consistente de requisitos também diminuem a variabilidade (um bom Modelo de Uso de requisitos) Rework – Taxa de defeitos e outras métricas, ajudam a entender a variabilidade de retrabalho Ambiguidade Classes de serviço mal formuladas © 2013 IBM Corporation
    18. 18. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Classes de serviço Classes de serviço classificam o trabalho de modo a priorizar os recursos. São uma política de priorização que determina uma maneira prévia de como os itens são puxados no sistema. Solicitação de novas features – Padrão ou com data de entrega fixa Solicitação de mudança Manutenção Defeitos – Defeitos em produção – Defeitos de alto impacto – Defeitos com alta prioridade Melhoram a valiação do sistema, evitam estimativas desnecesárias e/ou detalhadas Tem uma política previamente definida: WIP?, Release? FIFO? Equipe? Linha de SCM? © 2013 IBM Corporation
    19. 19. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Classes de serviço Limitando WIP para estados e filas, de acordo com a classe de serviço, aumentamos a previsibilidde 5 3 3 220%40%40% R © 2013 IBM Corporation
    20. 20. Encontro Rational de Desenvolvimento de Software – 12 de Março de 2013Técnicas podem ser combinadas! Observe valores e princípios “Não desenvolva apêgo a nenhuma arma ou tradição de luta” Miyamoto Musashi © 2013 IBM Corporation
    21. 21. Encontro Rational de Desenvolvimento de Software – 12 de Março de 201321 © 2013 IBM Corporation
    22. 22. Encontro Rational de Desenvolvimento de Software – 12 de Março de 201322 © 2013 IBM Corporation

    ×