敏捷软件开发（Agile ）介绍.pptx

敏捷软件开发介绍 Davin 2009年06月 N.001 目录 敏捷理念 敏捷优秀实践 敏捷应用建议 2018-11-5 Page 3 软件作坊 软件过程控制 重型过程 2001~今 敏捷正在流行 软件规模小，以作坊式开发为主； 硬件飞速发展，软件规模和复杂度激增，引发软件危机； 引入成熟生产制造管理方法，以“过程为中心”分阶段来控制软件开发（瀑布模型），一定程度上缓解了软件危机； 软件失败的经验促使过程被不断增加约束和限制，软件开发过程日益“重型化”，开发效率降低、响应速度变慢； 随着信息时代到来，需求变化更快，交付周期成为企业核心竞争力，轻量级的，更能适应变化的敏捷软件开发方法被普遍认可并迅速流行。 软件危机 20世纪60年代 80年代 90年代 软件开发顺应时代变化，从重型过程转向轻量型敏捷 70年代 敏捷诞生的历史背景 Page 4 Hw敏捷的发展： 2006年之前：IPD （集成产品开发） 2006~2008年：从咨询公司ThoughtWorks引入敏捷软件开发，开展软件项目试点 2008后：产品试点，全部软件项目使用，硬件项目使用优秀实践 腾讯敏捷的发展： 2006年之前：IPD （集成产品开发） 2006年之后：从咨询公司ThoughtWorks引入敏捷软件开发，正式命名为 TAPD（Tencent Agile Product Development） HW敏捷和腾讯敏捷的发展 Page 5 敏捷宣言揭示更好的软件开发方法 敏捷宣言（ 2001年）是敏捷起源的基础，由上述4个简单的价值观组成，敏捷宣言的签署推动了敏捷运动 敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作 敏捷宣言 Page 6 软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长 敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品 传统开发 敏捷开发 敏捷更符合软件开发规律 Page 7 对敏捷的常见误解 误解一： 敏捷开发意味着可以不需要文档、设计和计划 误解二： 敏捷只是一些优秀实践，或者是优秀实践的结合 误解三： 敏捷只适用于小项目开发 误解四： 敏捷只会对研发产生改变 误解五： 管理者不需要亲自了解敏捷，只需要管理上支持就可以了 误解六： 引入敏捷只需要按照既定的步骤去做就可以了 误解七： 敏捷是CMM的替代品，是另一种流程 误解八： 敏捷只注重特性的快速交付，在敏捷下架构不重要了 Page 8 统一认识：敏捷=理念+优秀实践+具体应用 理念（敏捷核心思想） 敏捷包括3个层次 优秀实践（敏捷的经验积累） 具体应用（能够结合自身灵活应用才是真正敏捷） 理念 优秀实践 具体应用 Page 9 敏捷理念 不断调整以适应(Adapting)变化 激发团队(Team)潜能，加强协作 聚焦客户价值(Value)，消除浪费 Page 10 优秀实践: 业界敏捷优秀实践概览 结对编程 测试驱动开发 客户参与验收 计划游戏 代码集体所有 每日站立会议 产品backlog （带优先级的需求清单） 燃烧图 迭代计划会议 回顾会议 Scrum Master Product Owner Anatomy（系统解剖） One Track Systemakut（缺陷管理和决策） 重构 完整团队 稳定开发节奏 Lagomising（需求决策） 隐喻 电信业偏重大规模产品实践、Scrum偏重项目管理，XP偏重编程实践 电信业 Scrum XP 持续集成 迭代交付 敏捷软件开发典型场景 Page 11 PO和开发团队对产品业务目标形成共识 PO建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序 PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发 开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成 开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明 PO对每轮迭代（2－4周）交付的可工作软件进行现场验收和反馈 回到第3步，开始下一轮迭代 Page 12 什么是完整团队 敏捷开发中，以Story为单位的持续交付要求系统组、开发和测试等跨功能团队进行密切协同，相互独立的功能团队难以应对。 完整团队是跨功能领域（需求分析师、设计师、开发人员、测试人员、资料人员等）的人员组成一个团队，坐在一起工作，团队成员遵循同一份计划，服从于同一个项目经理。 完整团队的好处 有助于团队成员形成共同目标和全局意识，促进各功能领域的拉通和融合； 通过面对面沟通提升沟通效率。 实现团队成员的高度