管理学精髓PA13：项目管理之敏捷之路.ppt

CASE “我们不是采用纯粹的Scrum，而是将Agile中的很多理念，包括XP的部分做法，然后结合现有的开发环境与要求，用Scrum的回顾不断地做改进， 从而趟出自己的一条路。如果这个Sprint我们回顾时觉得自己代码Review（审查）做的不好，下个Sprint就会引入新的代码Review机制。 这个Sprint觉得重复性的bug较多，下个Sprint就会引入缺陷预防机制。我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不断改进” 对敏捷的常见误解 误解一： 敏捷开发意味着可以不需要文档、设计和计划 误解二： 敏捷只是一些优秀实践，或者是优秀实践的结合 误解三： 敏捷只适用于小项目开发 误解四： 敏捷只会对研发产生改变 误解五： 管理者不需要亲自了解敏捷，只需要管理上支持就可以了 误解六： 引入敏捷只需要按照既定的步骤去做就可以了 误解七： 敏捷是CMM的替代品，是另一种流程 误解八： 敏捷只注重特性的快速交付，在敏捷下架构不重要了 统一认识：敏捷=理念+优秀实践+具体应用 理念（敏捷核心思想） 敏捷包括3个层次 优秀实践（敏捷的经验积累） 具体应用（能够结合自身灵活应用才是真正敏捷） 理念 优秀实践 具体应用 适应变化，小批量是快速交付的关键 我们首先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 ——摘自敏捷软件的十二个原则 在需求响应周期相同的情况下，批量（一次开发的需求量）越小，资源利用率更高。 在资源利用率相同的情况下，批量越小，交付周期更短。 减小批量不仅带来缩短交付周期，而且还带来提高质量、促进创新、降低管理成本、更高的效率等其他好处，大幅提升商业价值。 减少批量的好处 资源利用率 交付周期 大批量 中批量 小批量 Source：Craig Larman 减小批量 1.减少排队 3.缩短交付周期 2.加快反馈 4.增强质量 5.改善创新 6.降低管理成本 7.更高的效率 $$ 排队理论：小批量与缩短交付周期、人员有效产出的关系 敏捷实践概览 技术实践 迭代计划会议 每日站立会议 可视化管理 迭代验收 迭代回顾会议 管理实践 产品Backlog（需求清单） 迭代Backlog 完成标准 敏捷团队角色 Product Owner（PO） Scrum Master Team 完整团队实践 团队 用户故事 结对编程 TDD（测试驱动开发） 持续集成 Anatomy系统解剖 工作件 敏捷软件开发是以短周期迭代为核心，包含团队、工作件、管理和技术优秀实践的集合 迭代开发 什么样的组织容易转型成功 第三章 关于敏捷推行的指导意见 华为PSST函（2009）012号 签发人：徐直军 敏捷/迭代开发已经成为业界主流方法，与瀑布模式相比，其在应对需求变化、提升产品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具有明显优势。为了保证敏捷/迭代开发在有组织、有步骤、有策划的开展和推行，现明确要求如下： 以业务目标（交付周期、质量）为导向牵引敏捷推行，所有敏捷度量都以交付周期和交付质量为基础，而不能为了敏捷而敏捷。 公司敏捷推行分三步走：项目级敏捷、版本级敏捷和产品级敏捷，每一步要控制好入口，降低风险。 09年重点全面推进项目级敏捷，版本级敏捷进行试点。2010-2011在版本级敏捷试点基础上进行逐步推广。 项目级敏捷要求的实践包括：项目级持续集成、开发测试拉通、迭代、可视化管理、回顾会议、自动化测试、站立会议、用户代表参与现场迭代特性验收；其他敏捷实践项目组根据情况自己选择。 所有PL都要成为合格的Scrum Master（关键职责是辅导团队用正确的敏捷方法做事），在PL任职资格中将增加该要求。 项目级敏捷通用过程模型 * * * * * * * * * * * * * Sprint计划会议 Sprint计划会议包含两部分内容：“做什么”和“怎么做” Sprint计划会议1：确定该Sprint将要完成什么任务，用时4小时。 产品负责人给团队介绍最高优先级的Product Backlog条目，并一起决定接下来的Sprint中开发什么功能。Sprint计划会议需要输