Baixado 20 vezes
Carregado porSompo Seguros
Desenvolvimento ágil de software
O documento discute as vantagens do desenvolvimento ágil de software e apresenta várias metodologias ágeis como Scrum, Kanban, XP e FDD. Ele destaca que pesquisas mostram que projetos ágeis têm maior taxa de sucesso do que projetos tradicionais e que a adoção de práticas ágeis pode ajudar equipes a entregar software funcionando com mais frequência e a se adaptar melhor às mudanças.
![[Webinar] Scrum - Você está fazendo do jeito certo?](https://cdn.slidesharecdn.com/ss_thumbnails/webinar-scrumdojeitocerto-targettrust-180417193100-thumbnail.jpg?width=640&height=640&fit=bounds)
![[CEFETMG] [ESw] Aula 3 - Processos tradicionais x metodologia ágil](https://cdn.slidesharecdn.com/ss_thumbnails/aula3-processostradicionaisxmetodologiagil-150406172100-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
Desenvolvimento ágil de software
- 1. Desenvolvimento Ágil de Software Autor: Giuliano Ben-Hur Firmino
- 2. As estatísticas nãomentem Pesquisa com 280 mil projetos nos EUA Cancelados Falham 17% 72%
- 3. As estatísticas nãomentem Motivos de falhas nos projetos +63% +45% -37%
- 4. As estatísticas nãomentem Utilização das funcionalidades
- 5. O quão próximovocê está de seu cliente? http://www.youtube.com/watch?
- 6. Quais artefatos sãorealmente necessários? O que eu vou fazer com essa pilha de documentos???
- 7.
- 8. Você se prendea 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. Seu processo nãoé tão flexível? Mais prescritivo Mais adaptativo
- 10. Os prazos nãosão cumpridos?
- 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. Deixe seus projetosmais ágeis XP KANBAN SCRUM
- 13. Manifesto Ágil Indivíduose 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. SCRUM Scrum éuma metodologia ágil para gestão e planejamento de projetos de software.
- 15. FDD (Feature DrivenDevelopment) FDD é uma metodologia ágil para gestão e desenvolvimento de software.
- 16. SCRUM + FDD Sprint Planning Meeting Sprint Review Meeting Levantamento inicial Sprint Retrospective
- 17. Levantamento Inicial Detalharemos e priorizaremos as histórias, criando o product backlog. Esboçaremos os diagramas necessários (UML).
- 18. Planning Poker Pontuaremos as Histórias levantadas.
- 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. KANBAN (Quadro) O Kanban nasceu na Toyota e significa literalmente registro ou placa visível.
- 21. XP (eXtreme Programming) XP é uma metodologia de desenvolvimento para software em constante mudança.
- 22. Valores do DesenvolvimentoXP http://www.youtube.com/watch? v=hB9bt_dmlBQ&feature=player_embedd ed Comunicação Simplicidade Feedback Coragem
- 23. Reunião diária O que foi feito? Qual o próximo passo? Há algum impedimento?
- 24. Gráficos de acompanhamento Burndown (Sprint) Burndown (Sprint)
- 25. Gráficos de acompanhamento Progresso (Módulos / Funcionalidades)
- 26. Gráficos de acompanhamento Progresso (Projeto)
- 27. Sprint Review Meeting Estamos aqui para apresentar as histórias trabalhadas no Sprint…
- 28. Sprint Retrospective Neste Sprint o que funcionou bem? O que precisamos melhorar para os próximos? Funcionou Bem Precisa melhorar
- 29. Melhoria Eliminar o desperdício Pensamento Lean Melhorar continuamente LEAN Avaliação Respeitar as Planejamento pessoas Ação
- 30. "Uma longa viagemcomeça com um único passo." (Lao Tsé) “Metodologias ágeis são processos, agilidade é cultura.”
- 31. Motivação para adoção Pesquisa término de Projetos Ágeis Sucesso 80%
- 32.
Notas do Editor
- #3 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 .
- #4 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 .
- #5 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 .
- #7 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.
- #10 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.
- #12 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
- #14 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
- #18 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.
- #19 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.
- #20 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.
- #24 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 .
- #25 Com ciclos menores, tomadas de decisão podem ser feitas, a tempo de resolver problemas a curto prazo.
- #26 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.
- #27 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.
- #30 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).