Eduardo Bobsin e Lucas Toniazzo

Metodologia TradicionalMetodologia TradicionalEngenharia de SoftwareEngenharia de Software

xxMetodologias ÁgeisMetodologias Ágeis

Artesanato de SoftwareArtesanato de Software

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”

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)

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

eXtreme Programming Scrum FDD Crystal DSDM Lean Software Development Kanban Software Development OpenUP

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

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

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)

Lean Supply Chain Lean Product Development Lean Software Development

◦ Tom & Mary Poppendieck

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

1. Eliminar desperdícios2. Embutir qualidade dentro do processo3. Criar conhecimento4. Postergar o comprometimento5. Entregar rapidamente6. Respeitar as pessoas7. Otimizar o todo

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íciosDesperdícios

Literalmente, cartão sinalizador◦ Kan = sinal ou visual◦ Ban = cartão ou placa

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)

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

Passos para entregar um produto ou valor para o cliente através de um fluxo “suave”◦ Da matéria-prima à solução

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

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

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

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

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

• 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.

• 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

• 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

• 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

Agilemanifesto.org, 2001 Implementing Lean Software Development

◦ Mary and Tom Poppendieck, 2007 Software Craftsmanship

◦ Pete McBreen, 2001 Scrumban

◦ Corey Ladas, 2008

Eduardo Bobsin Machado◦ eduardo.bobsin@gmail.com

Lucas Toniazzo◦ lucas.giovenardi@gmail.com