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

2,537 views
2,456 views

Published on

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

Published in: Education
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,537
On SlideShare
0
From Embeds
0
Number of Embeds
1,771
Actions
Shares
0
Downloads
32
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Como eramosprojetos antes das metodologias?Como osprogramadorestrabalhavamnaqueles tempos?
  • Artigo de Royce
  • Mostrar o retroimpacto
  • Program design come firstDocument the design – How much documentation?Do it twicePlan, control and monitor testingInvolve the customer
  • O legado do waterfall
  • Ler o manifesto todoLembrar a todosospresentesqueexiste um cabeçalho e aliestá o espírito da coisa
  • Gestão Visual = Mapear o processoLimite o WIP / TrabalharosgargalosMedir o tempo de ciclo
  • FocoVantagensDesvantagens
  • Foco dos papéis: PessoasFoco do processo: disciplina
  • Tudoétimeboxem Scrum. Cerimônias (Planning, Daily Scrum, Review, Retrospective), todassão “timeboxeadas”. O timeboxdisciplina, dá o sentimento de urgêncianecessárioparamotivardeterminadaspessoas. Gera também o sentimento de sucessoaoentregarhistóriasfeitasao final de cada sprint.
  • Timeboxgerapressão. As vezesgerapressãodemais. Além disso times podem se sentirdesmotivadosquandofalhamsucessivos sprints.
  • FocoVantagensDesvantagens
  • FocoVantagensDesvantagens
  • Fábulaindiana dos cegos e o elefanteBarrigaCaudaOrelhaTrombaPernas
  • Invertemos o comprometimento de um total de históriasparaumahistóriaporvez, completa, namelhorqualidadepossível
  • Kai = MudançaZen = Bom
  • Ler o manifesto todoManeirasmelhores de desenvolver softwareLembrar a todosospresentesqueexiste um cabeçalho e aliestá o espírito da coisa
  • Quando os rótulos não atendem as suas necessidades

    1. 1. Quando os rótulos não atendem assuas necessidades@JulianoRibeiro /
    2. 2. DisclaimerEsta apresentação representa a minhaopinião sobre os assuntos aqui apresentados.Não a julgue apressadamente antes de serapresentado ao conteúdo todo e compreende-lo, afinal esse é um dos pontosdefenderemos aqui.
    3. 3. Período pré-waterfall
    4. 4. Waterfall
    5. 5. WaterfallManaging The Development of Large Software Systems – Dr Winston Royce
    6. 6. WaterfallManaging The Development of Large Software Systems – Dr Winston Royce
    7. 7. WaterfallManaging The Development of Large Software Systems – Dr Winston Royce
    8. 8. O Legado do Waterfall
    9. 9. Manifesto ágilhttp://manifestoagil.com.br/
    10. 10. KanbanJeff Patton
    11. 11. Scrum
    12. 12. Pessoas
    13. 13. Timebox
    14. 14. Timebox
    15. 15. Extreme Programming
    16. 16. Extreme Programming
    17. 17. 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)
    18. 18. LEAN SOFTWARE DEVELOPMENT
    19. 19. O que é Lean?Entregar continuamente aumentandoo valor do produtoContinuamente diminuir o esforço gastoNo prazo mais curto possívelCom a melhor qualidade possívelUma jornada, não um destino
    20. 20. "Acelerar a produção do desenvolvimento deSoftware é geralmente uma questão demelhorar o processo ao invés de adicionarpessoas. Pare de fazer coisas que o cliente nãovaloriza! Vista os óculos do cliente! "Mary e Tom Poppendieck
    21. 21. Elimine DesperdíciosInclua a Qualidade no ProcessoCrie ConhecimentoAdie Decisões e ComprometimentosEntregue o quanto antesRespeite as Pessoas e "Empower" a equipeOtimize o TodoPrincípios Lean aplicados ao software
    22. 22. Fábula Indiana
    23. 23. VertexSoftComeçamos com ScrumTime distribuídoProduct Owner em outro país
    24. 24. Estado inicialScrumTDDContinuous Integration
    25. 25. Como foi?Sprints falhando…Foco na entrega versus qualidadeVárias histórias quase aceitas…Cliente insatisfeitoPor consequência, nós também!
    26. 26. As mudançasAdoção de Pair ProgrammingContinuous Integration = Continuous deliveryMudança no comprometimentoNão estimar mais
    27. 27. ResultadosTime entrega apenas 5 históriaspor semana/iteração/sprintO cliente tem seu pedido atendido no menortempo possível, podendo valida-loimediatamente, com a maior qualidade que otime consegue entregar
    28. 28. Objective SolutionsComeçaram com Scrum “by the book”Desde o início com técnicas de XP
    29. 29. ObservaçõesOverhead de planejamento, cerimônias…Sprints constantemente cancelados,os requisitos mudavam frequentementePair programming exige maisque disciplina, exige métodoO time precisa do controle sutil,mesmo um time maduro
    30. 30. MudançasIterações > Fluxo ContínuoAs tarefas levam o tempo que levaremAlgoritmo para disciplinar o Pair ProgrammingCriaram a ronda ativa
    31. 31. Não desenvolva apego a nenhumaarma ou escola de combate.Miyamoto Musashi
    32. 32. Manifesto ágilhttp://manifestoagil.com.br/
    33. 33. Obrigado@JulianoRibeirojuliano@massimus.com@HRorizhroriz@massimus.com

    ×