Transferir como PDF, PPTX
Carregado porEric Cavalcanti
Agile
O documento fornece um resumo sobre a abordagem ágil para desenvolvimento de software. Ele descreve os principais problemas com o desenvolvimento tradicional de software, como requisitos incompletos e mudanças frequentes, e introduz os princípios ágeis de entrega contínua e colaboração próxima com os clientes. Também resume alguns métodos ágeis populares como Scrum e Kanban, destacando práticas como sprints curtas e limitação de trabalho em andamento.
Agile
- 1. Agile Eric Cavalcanti [email protected] @ericoc
- 2. O Problema Chaos Report 18% 2004 53% 29% 19% 2006 46% Fracassados 35% Comprometidos Bem sucedidos 24% 2009 44% 32% !"#$%&'(")&*%+,-."/0$12""
- 3. Principais fatores de insucesso requisitos incompletos falta de envolvimento de usuários mudanças de requisitos e especificações falta de apoio de negócios falta de recursos
- 4.
- 5.
- 6. BDUF Big DesignUp Front
- 7. Analista de Requisitos,Analista de Negócios, Engenheiro de Requisitos, Engenheiro de Qualidade, Gerente de Configuração, Líder de Projeto... Programadores
- 8.
- 9.
- 10. Ainda mais... Código Complexo. Manutençãodifícil. Baixa produtividade. Cronograma sempre atrasado. Insatisfação de todos. Design degradado. Documentação defasada, excessiva e ilegível. Fracasso em grande parte dos projetos.
- 11.
- 12.
- 13. O desenvolvimento desoftware depende muito mais das pessoas e da comunicação
- 14. “Ao contrário docenário numa linha de produção em massa, o software não é algo previsível ou imune a mudanças” Larman
- 15. “Desenvolver software écomo desenvolver novos produtos” Larman
- 16. “Desenvolver é comocriar uma receita, enquanto produzir é seguir a receita” Poppendieck
- 17. “O desenvolvimento éum processo de aprendizado, que envolve tentativa e erros” Larman
- 18. “Como a manufaturaprevisível, não pode ser comparada ao software, dificilmente as práticas e valores enraizados nesse paradigma trazem algum benefício” Larman
- 19. 64% das funcionalidades desenvolvidasnos softwares não são utilizadas Standish Group
- 20. Muitas vezes, pelofato do cliente só poder pedir uma vez, ele acaba pedindo coisas que não tem certeza que precisa
- 21. Essas funcionalidades fazem partedos 64% que ele nem repara que estão lá, quando o software é entregue
- 22. 70% dos usuários utilizam as funcionalidades básicas de um software. 20% utilizam as funcionalidades intermediárias. 10% utilizam as funcionalidades avançadas. Microsoft
- 23. Cone da Incerteza Construx
- 24. É natural queos usuários tenham novas idéias e suas opiniões mudem quando vêem as primeiras versões do software
- 25. Os softwares maisfamosos e utilizados no mundo são os mais simples
- 29. “Menos é Mais” A cabeça de Steve Jobs (Inside Steve’s Brain) - Agir 2008
- 30.
- 31.
- 32. Final da décadade 90 eXtreme Programming Feature Driven Development Scrum Adaptive Development Crystal Clear Dynamic Systems Development Method
- 33. 2001 Kent Beck Ron Jeffries Mike Beedle Jon Kern Arie van Brian Marick Bennekum Robert C. Martin Alistair Cockburn Steve Mellor Ward Cunningham Ken Schwaber Martin Fowler Jeff Sutherland James Grenning Manifesto Ágil Dave Thomas Jim Highsmith Andrew Hunt
- 34. Indivíduos e interaçãoentre eles mais que processos e ferramentas
- 35. Software em funcionamento maisque documentação abrangente
- 36. Colaboração com ocliente mais que negociação de contratos
- 37. Responder a mudançasmais que seguir um plano
- 38. Princípios por trásdo manifesto ágil
- 39. Nossa maior prioridadeé satisfazer o cliente, através da entrega adiantada e contínua de software de valor
- 40. Aceitar mudanças derequisitos, mesmo no fim do desenvolvimento
- 41. Processos ágeis seadequam a mudanças, para que o cliente possa tirar vantagens competitivas
- 42. Entregar software funcionando com frequencia, na escala de semanas até meses, com preferência aos períodos mais curtos
- 43. Pessoas relacionadas ànegócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto
- 44. Construir projetos aoredor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
- 45. O método maiseficiente e eficaz de transmitir informações é através de uma conversa cara a cara.
- 46. Software funcional é a medidaprimária de progresso.
- 47. Processos ágeis promovemum ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
- 48. Contínua atenção àexcelência técnica e bom design, aumenta a agilidade.
- 49. Simplicidade: a artede maximizar a quantidade de trabalho que não precisou ser feito
- 50. As melhores arquiteturas, requisitose designs emergem de times auto-organizáveis
- 51. Em intervalos regulares,o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo
- 52.
- 53. STATE OF AGILE SURVEY 2011 6.042 participantes VersionOne
- 54. STATE OF AGILE SURVEY 2011 >80% 90% trabalham em são pelo menos"esclarecido" organizações que usam sobre técnicas de práticas de desenvolvimento ágil de desenvolvimento ágil software em um certo grau VersionOne
- 55. STATE OF AGILE SURVEY 2011 45% utilizam abordagem ágil a mais de 2 anos VersionOne
- 56. STATE OF AGILE SURVEY 2011 Scrum e variantes de Scrum são de longe os mais utilizados VersionOne
- 57. STATE OF AGILE SURVEY 2011 As razões mais comuns para a adoção ágil gira em torno de tempo de aceleração para o mercado, gereciamento de mudanças de prioridade e aumento produtividade VersionOne
- 58. STATE OF AGILE SURVEY 2011 Princípiosfundamentais ágeis atualmente em uso são Daily Standup, Iteration Planning e Unit Testing. O mais notável é o uso crescente de Kanban (24%). VersionOne
- 59.
- 60. A origem 1995 Jeff Sutherland Ken Schwaber 1986
- 61. Se destaca dosdemais métodos ágeis pela ênfase dada ao gerenciamento do projeto
- 62. Práticas de Engenharia de d c lu t in No
- 63.
- 64. Product Product Owner Determina a visão do produto Owner Define as funcionalidades Escolhe as datas de release Dá o feedback Gerencia os stakeholders Aceita ou rejeita os resultados Prioriza de acordo com o ROI
- 65. Pequenos (5 a9 pessoas) Desenvolve as funcionalidades Auto-organizável Auto-gerenciável Multifuncional Estima o esforço Defina as tarefas O Time Responsável pela qualidade
- 66. Scrum Master Líder Servidor Protegeo time Remove impedimentos Guia do Scrum
- 67.
- 68. Então ao invésde um grande grupo gastando um monte de tempo construindo uma grande coisa, temos uma equipe pequena gastando um tempo curto construindo uma pequena coisa. Mas integrando regularmente para ver o todo. Henrik Kniberg
- 69. Product Backlog Umalista de coisas que queremos que sejam entregues
- 70. As funcionalidades são geralmenteescritas em estórias de usuários.
- 71. Como um <perfil>, quero<funcionalidade>, para <valor de negócio> Como um agente de viagens, quero reservar lugar, para facilitar o atendimento dos clientes corporativos
- 72. O time estimao trabalho associado a cada estória.
- 73. As estórias sãorankeadas em ordem de importância pelo product owner.
- 74. O product owneré o dono do backlog do produto.
- 75.
- 76.
- 77. Executando a Sprint Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Análise Código Testa Análise Código Testa Análise Código Testa Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Análise Análise Análise Código Código Código Testa Testa Testa
- 78. Daily Scrum Meeting •O que você fez ontem? • O que você fará de hoje para amanhã? • Há algum impedimento em seu caminho? 15 minutos
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86. Mude alguma coisa=> Saiba como foi => Aprenda com isso => Mude alguma coisa novamente. Falando de um modo geral, você quer o ciclo de feedback o mais rápido possível, Scrum + XP e ciclos feedbackfeedback para que seja possa adaptar o processo rapidamente. Em Scrum, a iteração básica de um de é o sprint. Há mais, porém, especialmente se você combinar com o XP (eXtreme Programm ing): Quando feito corretamente, Scrum + XP lhe oferece vários ciclos de feedback extremamente valiosos.
- 87.
- 88. O Kanban ébaseado numa idéia muito simples. As atividades em andamento devem ser limitadas. Algo novo só deve ser iniciado quando uma peça de trabalho existente é liberada ou quando uma função automática inicia isso.
- 89. O princípio doKanban é que você inicia com o que estiver fazendo agora.
- 90.
- 91. Visualize o fluxode trabalho Divida o trabalho em partes, escreva cada item em um cartão e coloque na parede Use colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho
- 92. Limite o trabalhoem progresso (WIP - work in progress) Associe limites explícitos para quantos itens podem estar em progresso em cada estado do fluxo de trabalho
- 93. Acompanhe o tempode execução da tarefa Tempo médio para completar um item, algumas vezes chamado de “Lead Time” Otimize o processo para tornar o tempo de execução o menor e mais previsível possível.
- 96. Referências Lean Software Development:An Agile Toolkit, Mary Poppendieck e Tom Poppendieck, 2003, Addison- Wesley Professional Agile Project Management with Scrum, Ken Schwaber, 2004, Microsoft Professional The Enterprise and Scrum, Ken Schwaber, 2007, Microsoft Press Kanban e Scrum - obtendo o melhor de ambos, Henrik Kniberg e Mattias Skarin, 2009, C3 Media Inc. Kanban: Mudança Evolucionária de Sucesso para seu Negócio de Tecnologia, David Anderson, 2011, Blue Hole Press Agile Estimating and Planning, Mike Cohn, 2005, Prentice Hall User Stories Applied: For Agile Software Development, Mike Cohn, 2004, Addison-Wesley Professional Extreme Programming Explained: Embrace Change (2nd Edition), Kent Beck, 2004, Addison-Wesley Professional Test Driven Development, Kent Beck, 2002, Addison-Wesley Professional Refactoring: Improving the Design of Existing Code, Martin Fowler, Kent Beck, 1999, Addison-Wesley Professional
- 97. Obrigado! Eric Cavalcanti [email protected] @ericoc