Uma boa reflexão sobre como não entendemos o todo antes de julgar uma metodologia

1. Quando os rótulos não atendem as
suas necessidades
@JulianoRibeiro /

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

3. Período pré-waterfall

4. Waterfall

5. Waterfall
Managing The Development of Large Software Systems – Dr Winston Royce

6. Waterfall
Managing The Development of Large Software Systems – Dr Winston Royce

7. Waterfall
Managing The Development of Large Software Systems – Dr Winston Royce

8. O Legado do Waterfall

9. Manifesto ágil
http://manifestoagil.com.br/

10. Kanban
Jeff Patton

12. Scrum

13. Pessoas

14. Timebox

15. Timebox

16. Extreme Programming

17. Extreme Programming

18. 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)

19. LEAN SOFTWARE DEVELOPMENT

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

21. "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

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

23. Fábula Indiana

25. VertexSoft
Começamos com Scrum
Time distribuído
Product Owner em outro país

26. Estado inicial
Scrum
TDD
Continuous Integration

27. Como foi?
Sprints falhando…
Foco na entrega versus qualidade
Várias histórias quase aceitas…
Cliente insatisfeito
Por consequência, nós também!

28. As mudanças
Adoção de Pair Programming
Continuous Integration = Continuous delivery
Mudança no comprometimento
Não estimar mais

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

31. Objective Solutions
Começaram com Scrum “by the book”
Desde o início com técnicas de XP

32. Observações
Overhead 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

33. Mudanças
Iterações > Fluxo Contínuo
As tarefas levam o tempo que levarem
Algoritmo para disciplinar o Pair Programming
Criaram a ronda ativa

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

36. Manifesto ágil
http://manifestoagil.com.br/

37. Obrigado
@JulianoRibeiro
juliano@massimus.com
@HRoriz
hroriz@massimus.com