quando os rótulos não atendem as suas necessidades

Quando os rótulos não atendem as suas necessidades

@JulianoRibeiro / @HRoriz

Disclaimer

Esta apresentação representa a minha opinião sobre os assuntos aqui apresentados.

Não a julgue apressadamente antes de ser apresentado ao conteúdo todo e compreende-

lo, afinal esse é um dos pontos defenderemos aqui.

Período pré-waterfall

Waterfall

Waterfall

Managing The Development of Large Software Systems – Dr Winston Royce

Waterfall

Managing The Development of Large Software Systems – Dr Winston Royce

Waterfall

Managing The Development of Large Software Systems – Dr Winston Royce

O Legado do Waterfall

Manifesto ágil

http://manifestoagil.com.br/

Kanban

Jeff Patton

Scrum

Pessoas

Timebox

Timebox

Extreme Programming

Extreme Programming

Extreme Programming• Jogo de Planejamento (Planning Game)• Fases pequenas (Small Releases)• Metáfora (Metaphor)• Design Simples (Simple Design)• Time Coeso (Whole Team)• Testes de Aceitação (Customer Tests)• Semana de 40 horas (Sustainable Pace)• Reuniões em pé (Stand-up Meeting)• Propriedade Coletiva (Collective Ownership)• Programação Pareada (Pair Programming)• Padronização do Codigo (Coding Standards)• Desenvolvimento Orientado a Testes (Test Driven Development)• Refatoração (Refactoring)• Integração Contínua (Continuous Integration)

LEAN SOFTWARE DEVELOPMENT

O que é Lean?

Entregar continuamente aumentando o valor do produto

Continuamente diminuir o esforço gasto

No prazo mais curto possível

Com a melhor qualidade possível

Uma jornada, não um destino

"Acelerar a produção do desenvolvimento de Software é geralmente uma questão de

melhorar o processo ao invés de adicionar pessoas. Pare de fazer coisas que o cliente não

valoriza! Vista os óculos do cliente! "

Mary e Tom Poppendieck

Elimine Desperdícios

Inclua a Qualidade no Processo

Crie Conhecimento

Adie Decisões e Comprometimentos

Entregue o quanto antes

Respeite as Pessoas e "Empower" a equipe

Otimize o Todo

Princípios Lean aplicados ao software

Fábula Indiana

VertexSoft

Começamos com Scrum

Time distribuído

Product Owner em outro país

Estado inicial

Scrum

TDD

Continuous Integration

Como foi?

Sprints falhando…Foco na entrega versus qualidade

Várias histórias quase aceitas…Cliente insatisfeito

Por consequência, nós também!

As mudanças

Adoção de Pair Programming

Continuous Integration = Continuous delivery

Mudança no comprometimento

Não estimar mais

Resultados

Time entrega apenas 5 histórias por semana/iteração/sprint

O cliente tem seu pedido atendido no menor tempo possível, podendo valida-lo

imediatamente, com a maior qualidade que o time consegue entregar

Objective Solutions

Começaram com Scrum “by the book”

Desde o início com técnicas de XP

ObservaçõesOverhead de planejamento, cerimônias…

Sprints constantemente cancelados, os requisitos mudavam frequentemente

Pair programming exige mais que disciplina, exige método

O time precisa do controle sutil, mesmo um time maduro

Mudanças

Iterações > Fluxo Contínuo

As tarefas levam o tempo que levarem

Algoritmo para disciplinar o Pair Programming

Criaram a ronda ativa

Não desenvolva apego a nenhuma arma ou escola de combate.

Miyamoto Musashi

Manifesto ágil

http://manifestoagil.com.br/

Obrigado

@JulianoRibeirojuliano@massimus.com

@HRorizhroriz@massimus.com