Your SlideShare is downloading. ×
Lean Kanban
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lean Kanban

5,492
views

Published on

Apresentação realizada na Semana Acadêmica da FTEC Caxias do Sul - RS

Apresentação realizada na Semana Acadêmica da FTEC Caxias do Sul - RS

Published in: Technology

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,492
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
249
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Eduardo Bobsin e Lucas Toniazzo
  • 2. Metodologia Tradicional Engenharia de Software x Metodologias Ágeis Artesanato de Software
  • 3.
    • Crise do Software
      • 1968, conferência da OTAN
      • Cunhado o termo Engenharia de Software
    • Grandes Projetos
      • Defesa
      • Aeroespacial
    • Baixa confiança, alto risco
      • Alto “controle”
  • 4.
    • Era da Internet
    • Nascimento de pequenas aplicações
    • Empresas iniciantes (startups)
    • Alta confiança e baixo risco
      • Baixo “controle”
    • Artesanato de Software
      • Software Craftsmanship, 2001 (Pete McBreen)
  • 5. Indivíduos e interação entre eles 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
  • 6.
    • eXtreme Programming
    • Scrum
    • FDD
    • Crystal
    • DSDM
    • Lean Software Development
    • Kanban Software Development
    • OpenUP
  • 7.
    • Lean é o termo ocidental para o Sistema Toyota de Produção
      • James Womack (The Machine that Changed the World)
    • Lean é sobre melhoria de qualidade, eficiencia e redução de custos e desperdícios
  • 8.
    • Teares no Japão com a família Toyoda
    • Os melhores engenheiros criando maquinários mais resistentes às falhas e com maior automação
      • Menos pessoas para operar as máquinas
      • 520 teares para 20 operadores (26 por operador)
    • Com os lucros, criaram a montadora de automóveis
  • 9.
    • No pós guerra, decidiram que iriam competir com os EUA
      • Recursos escassos
      • Não adotariam o modelo de produção em massa
    • Criaram os conceitos
      • Just-in-Time (Kiichiro Toyoda)
      • Stop-the-line (Taiichi Ohno)
      • Zero inspection (Shigeo Shingo)
  • 10.
    • Lean Supply Chain
    • Lean Product Development
    • Lean Software Development
      • Tom & Mary Poppendieck
  • 11.
    • Princípios são verdades fundamentais que não mudam com o tempo
    • Lean é um conjunto de princípios e NÃO é um processo
      • Por isso não é fácil ou muito menos simples replicar usando um passo-a-passo
  • 12.
    • Eliminar desperdícios
    • Embutir qualidade dentro do processo
    • Criar conhecimento
    • Postergar o comprometimento
    • Entregar rapidamente
    • Respeitar as pessoas
    • Otimizar o todo
  • 13.
    • Manufatura
    • Estoque entre processos
    • Super-produção
    • Processamento “extra”
    • Transporte
    • Movimentação
    • Espera
    • Defeitos
    • Software
    • Trabalho parcialmente concluído
    • Features “extra”
    • Reaprendizado
    • Transferência de trabalho
    • Alternar tarefas
    • Atrasos
    • Defeitos
    Desperdícios
  • 14.
    • Literalmente, cartão sinalizador
      • Kan = sinal ou visual
      • Ban = cartão ou placa
  • 15.
    • Limitar o WIP (Work in Process)
    • Puxar valor através do fluxo (usando limite WIP)
    • Tornar visível (controle visual)
    • Aumentar a vazão
    • Qualidade está embutida (e não inspecionada)
  • 16.
    • O foco é ser bem sucedido. Agilidade pode ser uma conseqüência!
    • Não construir features que ninguém precisa agora
    • Não escrever mais especificações do que se pode codificar
    • Não escrever mais código do que se pode testar
    • Não testar mais código do que se pode entregar
  • 17.
    • Passos para entregar um produto ou valor para o cliente através de um fluxo “suave”
      • Da matéria-prima à solução
  • 18.
    • Puxar unidades de trabalho individualmente através das atividades que adicionam valor
      • Rapidamente
      • Sem interrupção
    • É o oposto de mover lotes de trabalho entre grandes estágios
  • 19.
    • Fila de unidades de trabalho que passam por uma seqüência de estágios até a conclusão
    • Unidade de trabalho concluída “desce” para o próximo estágio
    • Nova unidade de trabalho é puxada do estágio acima
  • 20.
    • Limitar o trabalho simultâneo nos estágios
    • Se estágio está abaixo do limite
      • Puxa um item do estágio anterior
    • Se estágio está no limite
      • Aguardar um item ser concluído no estágio seguinte
      • Aguardar um item ser puxado pelo estágio seguinte
  • 21.
    • Filas antes de cada estágio podem ser usadas para absorver a variação natural do processo
    • A fila também deve ter um limite
    • Diferencia trabalho não iniciado (pronto para ser puxado) de trabalho em processo
    • O tamanho ideal de fila é 1
  • 22.
    • Começar com o que se tem
    • Modificar o necessário para transformar o sistema em “puxado”
    • Dar visibilidade do trabalho
    • Limitar o WIP
    • A partir daí, evoluir, encontrando gargalos, desperdícios e variâncias que afetam o desempenho
  • 23.
    • Qualidade é a regra maior, todos devem primar por ela, porém, sem a necessidade de uma equipe de inspeção.
    • Cada membro da equipe busca desenvolver sua atividade com o máximo de atenção focado na qualidade, evitando retrabalho no fluxo de desenvolvimento.
  • 24.
    • Proporcione seções técnicas dentro da equipe
    • Instigue a busca pelo conhecimento evitando o débito técnico
    • Desenvolvimento em duplas, TDD e reviews são ótimas fontes para se compartilhar conhecimento e proporcionar crescimento técnico e pessoal da equipe
  • 25.
    • Proporcione feedback para a equipe
    • Veja sempre o todo e não a unidade
    • Reconheça o esforço de cada um, mostrando o ganho para todos
    • Proporcione o melhor ambiente possível para sua equipe, ultrapasse qualquer impedimento que comprometa a produtividade dos mesmos
  • 26.
    • Funcionalidade entregue é empresa competindo mais cedo. (time-to-market)
    • Diminui o tempo para incertezas e proporciona uma visão mais clara do produto pelo cliente
    • Possibilita um ritmo mais cadenciado para a equipe de desenvolvimento
    • Proporciona uma verificação mais rápida da capacidade produtiva da equipe
  • 27.
    • Agilemanifesto.org, 2001
    • Implementing Lean Software Development
      • Mary and Tom Poppendieck, 2007
    • Software Craftsmanship
      • Pete McBreen, 2001
    • Scrumban
      • Corey Ladas, 2008
  • 28.
    • Eduardo Bobsin Machado
      • [email_address]
    • Lucas Toniazzo
      • [email_address]

×