Desenvolvimento ágil de software

798 views
646 views

Published on

Published in: Self Improvement
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
798
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • A empresa americana chamada  Standish Group , há pouco mais de uma década, vem produzindo um relatório chamado  The Chaos Report que pesquisou 280 mil projetos de software nos EUA e revelou: 72% deles falham por algum motivo. 17% desse fracassaram tão vigorosamente que foram cancelados .
  • Os atrasos normalmente representam 63%  mais tempo que o estimado. Os gastos normalmente são  45%  maiores que o orçado. No geral apenas  67%  das funcionalidades prometidas são efetivamente entregues .
  • Concluiu-se com a pesquisa que o   Princípio de Pareto também se aplica ao desenvolvimento de software, onde 20% das funcionalidades costumam gerar 80% ou mais do benefício esperado . Não há priorização no desenvolvimento de funcionalidades. Os programadores priorizam da forma que acharem melhor e normalmente preferem desenvolver as funcionalidades mais simples primeiro. Resultado entrega de parte do sistema que o cliente não irá utilizar .
  • Muitas pessoas e empresas acreditam que UML é documentação . UML é uma linguagem universal entre analistas, desenvolvedores e stakeholders e deve ser usada de forma a ser útil, não um fardo. Uma das soluções para diminuir o volume de documentos gerados é a utilização de boas práticas, na codificação. código simples , padronizado , organizado e bem comentado muitas vezes tem mais valor. Outro recurso que pode ser utilizado é automatizar o processo de documentação , a fim de evitar as prováveis defasagens.
  • Uma das principais diferenças entre Metodologias Ágeis e RUP é que no RUP você recebe coisas demais, e você supostamente remove o material que não precisa. Nas Metodologias Ágeis você recebe muito pouco, e supostamente adiciona o material que lhe falta.
  • Fenômeno onde pessoas começam a se esforçar para finalizar uma tarefa no último momento possível, ou seja antes do final do prazo. Isso leva a perda de qualquer buffer (gordura) reservado para comprimento de outras tarefas. Na hora da implementação, o desenvolvedor acaba usando todo o tempo reservado para a tarefa na melhor das hipoteses. Devido a isso, quando uma tarefa apresenta maior complexidade do que o esperado, todos os buffers individuais que foram reservados para as tarefas anteriores já foram usados, fazendo com que o tempo para todas as tarefas seja maior do que o previsto
  • Nos dias 11 a 13 de fevereiro de 2001, em uma estação de ski nas montanhas Wasatch de Utah, 17 pessoas se encontraram para conversar, esquiar, relaxar, e tentar encontrar um lugar comum e claro, para comer. O que emergiu foi o Manifesto para Desenvolvimetno Ágil de Software. Representantes da Extremme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, e outros simpatizaram com a necessidade de uma alternativa aos pesados processos de desenvolvimetno de software orientados a documentação Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas
  • Conta com a experiência dos desenvolvedores. Utilização de seqüência fibonaci : 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Depois de esclarecidas todas as dúvidas em relação a história, todos pontuam . As menores e as maiores pontuações devem ser justificadas . A re-pontuação é feita até que se entre em um consenso . Se a pontuação for 40 ou 100 , a história deve ser revisada , verificando se a mesma esta bem coesa . Conforme a equipe se familiariza com o sistema, a duração passa a ser baseada na complexidade: Tamanho ≠ Duração , com base no histórico de pontuações.
  • Conta com a experiência dos desenvolvedores. Utilização de seqüência fibonaci : 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Depois de esclarecidas todas as dúvidas em relação a história, todos pontuam . As menores e as maiores pontuações devem ser justificadas . A re-pontuação é feita até que se entre em um consenso . Se a pontuação for 40 ou 100 , a história deve ser revisada , verificando se a mesma esta bem coesa . Conforme a equipe se familiariza com o sistema, a duração passa a ser baseada na complexidade: Tamanho ≠ Duração , com base no histórico de pontuações.
  • Conta com a experiência dos desenvolvedores. Utilização de seqüência fibonaci : 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Depois de esclarecidas todas as dúvidas em relação a história, todos pontuam . As menores e as maiores pontuações devem ser justificadas . A re-pontuação é feita até que se entre em um consenso . Se a pontuação for 40 ou 100 , a história deve ser revisada , verificando se a mesma esta bem coesa . Conforme a equipe se familiariza com o sistema, a duração passa a ser baseada na complexidade: Tamanho ≠ Duração , com base no histórico de pontuações.
  • Reunião em pé (15 minutos) Deve ser respondido: O que foi feito? Qual o próximo passo? Há algum impedimento? Comemoração a cada história finalizada ( sinergia ). Depois da reunião: Atualização dos indicadores .
  • Com ciclos menores, tomadas de decisão podem ser feitas, a tempo de resolver problemas a curto prazo.
  • O acompanhamento das da evolução dos Sprints, é necessário para controlar a saúde do projeto e tomar decisões de médio e longo prazo.
  • O acompanhamento das da evolução dos Sprints, é necessário para controlar a saúde do projeto e tomar decisões de médio e longo prazo.
  • O termo lean foi cunhado ao final da década de 80 em um projeto de pesquisa do Massachusetts Institute of Technology (MIT) sobre a indústria automobilística mundial. A pesquisa revelou que a Toyota havia desenvolvido um novo e superior paradigma de gestão nas principais dimensões dos negócios. Naquela época, a montadora japonesa não estava nem entre as dez maiores do mundo. Em 2009, a Toyota tornou-se a maior em volume de vendas, acumulando vitória após vitória ao longo destas décadas, mostrando as vantagens e benefícios do sistema que desenvolveu. Os 3 Pilares: Eliminar o desperdício , Melhorar continuamente e Respeitar as pessoas . Reduzir o desperdício ou otimizar qualquer processo de trabalho é um grande desafio , pois não basta apenas eliminar tarefas julgadas como desnecessárias, mas sim, trata-se de uma grande mudança na mentalidade das pessoas . É disso que trata o  Pensamento Lean  (Lean Thinking).
  • Desenvolvimento ágil de software

    1. 1. DesenvolvimentoÁgil de Software Autor: Giuliano Ben-Hur Firmino
    2. 2. As estatísticas não mentem Pesquisa com 280 mil projetos nos EUA Cancelados Falham 17% 72%
    3. 3. As estatísticas não mentem Motivos de falhas nos projetos +63% +45% -37%
    4. 4. As estatísticas não mentem Utilização das funcionalidades
    5. 5. O quão próximo você está de seu cliente? http://www.youtube.com/watch?
    6. 6. Quais artefatos são realmente necessários? O que eu vou fazer com essa pilha de documentos???
    7. 7. Está faltando comprometimento?
    8. 8. Você se prende a paradigmas?Não desenvolva apego a nenhuma arma ou escola de combate. Miyamoto Musashi (famoso samurai do século 17, se destacava por sua técnica de luta das espadas gêmeas)
    9. 9. Seu processo não é tão flexível? Mais prescritivo Mais adaptativo
    10. 10. Os prazos não são cumpridos?
    11. 11. Sua equipe só está apagando fogo? Esse fenômeno da engenharia de software é conhecido como Síndrome do Estudante Eu devia ter estudado antes… Executado Planejamento
    12. 12. Deixe seus projetos mais ágeis XP KANBAN SCRUM
    13. 13. Manifesto Ágil Indivíduos e interações 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
    14. 14. SCRUM Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.
    15. 15. FDD (Feature Driven Development) FDD é uma metodologia ágil para gestão e desenvolvimento de software.
    16. 16. SCRUM + FDD Sprint Planning Meeting Sprint Review Meeting Levantamento inicial Sprint Retrospective
    17. 17. Levantamento Inicial Detalharemos e priorizaremos as histórias, criando o product backlog. Esboçaremos os diagramas necessários (UML).
    18. 18. Planning Poker Pontuaremos as Histórias levantadas.
    19. 19. Sprint Planning Meeting De acordo com a priorização e pontuação, vamos criar as tarefas e montar o próximo Sprint no quadro.
    20. 20. KANBAN (Quadro) O Kanban nasceu na Toyota e significa literalmente registro ou placa visível.
    21. 21. XP (eXtreme Programming) XP é uma metodologia de desenvolvimento para software em constante mudança.
    22. 22. Valores do Desenvolvimento XP http://www.youtube.com/watch? v=hB9bt_dmlBQ&feature=player_embedd ed Comunicação Simplicidade Feedback Coragem
    23. 23. Reunião diária O que foi feito? Qual o próximo passo? Há algum impedimento?
    24. 24. Gráficos de acompanhamento Burndown (Sprint)  Burndown (Sprint)
    25. 25. Gráficos de acompanhamento Progresso (Módulos / Funcionalidades)
    26. 26. Gráficos de acompanhamento Progresso (Projeto)
    27. 27. Sprint Review Meeting Estamos aqui para apresentar as histórias trabalhadas no Sprint…
    28. 28. Sprint Retrospective Neste Sprint o que funcionou bem? O que precisamos melhorar para os próximos? Funcionou Bem Precisa melhorar
    29. 29. Melhoria Eliminar o desperdício Pensamento Lean Melhorar continuamente LEANAvaliação Respeitar as Planejamento pessoas Ação
    30. 30. "Uma longa viagem começa com um único passo." (Lao Tsé)“Metodologias ágeis são processos,agilidade é cultura.”
    31. 31. Motivação para adoção Pesquisa término de Projetos Ágeis Sucesso  80%
    32. 32. Empresas que adotam

    ×