敏捷软件开发Agile介绍.pptx

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