敏捷管理与Scrum模型（一）

敏捷管理框架——Scrum模型

由于最近都在备考PMP的考试，经常会听到敏捷管理的内容，并且敏捷管理是最近很火的话题，几乎所有的互联网公司都在推崇敏捷、践行敏捷，在这里，该好好学学什么是敏捷了。

敏捷管理概念源于丰田在汽车制造业中创造的“精益管理”理念，以及2001年由一组软件开发人员起草的“敏捷宣言”。宣言原则中写道，“个体和互动”高于“流程和工具”，响应变化高于遵循计划。敏捷管理经常被谷歌、亚马逊、微软等很多领先的公司作为管理创新和产品开发的一种方式。

在敏捷管理中，最著名的模型就是——Scrum模型，Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。

那么这个名字是怎么来的呢？早在1993年，美国科学家Sutherland读到了两位日本管理教授竹内弘高和野中郁次郎介绍制造业里出现的新的产品开发方法Rugby（橄榄球）的文章。这种方法的特点是整个流程都由一个高性能、跨功能的团队执行到底。他受到启发，结合自己多年的经验，与美国Easel公司的工程师John Scumniotales和Jeff McKenna一起开发了一套方法，取名为Scrum（来源于橄榄球术语，不是缩写）。从此以后，Scrum作为软件开发界的地位慢慢建立了起来。

Scrum的核心价值观是：承诺、专注、公开、尊重和勇气，关键路径为：Scrum把开发任务构造在许多周期中，每个周期为一个Sprint。Sprint的迭代时间为一到四周，并且是相互衔接的。每个Sprint都有固定的的周期—不管工作是否完成，结束于明
确的日期，从不延长，这叫做“时间盒”。

Scrum模型由三个主要角色——产品负责人（PO）、敏捷教练（SM）、自组织团队（Team）组成，三个角色分工明确，PO是利益相关方的代表，重点是产品业务方面，从业务角度出发对需求并对权重排序，合理的调整产品功能和迭代顺序；SM则是团队的导师和组织者，负责提高团队效率、提出培训团队的计划,列出障碍，让利益相关方获得最大化的投资回报、同时，提高团队的开发效率，开发思想得到利益相关方的理解与支持；Team会尽一切可能去完成任务，充分理解产品负责人的产品愿景合作完成冲刺(Sprint)中每一个目标，更好的支持可能需要进一步开发的产品发布。

除此之外，Srcum模型还有三个知名工件：产品待办事项列表（Product Backlog）、冲刺待办事项列表（Sprint Backlog）、发布燃尽图和冲刺/迭代燃尽图。

• 产品待办事项列表（Product Backlog）是一个排序的列表，通常以用户故事（User Story）的形式表现，包含所有产品需要的东西，也是产品需求变动的来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。产品待办事项列表永远是不完全的，最初的版本只列出最初始的和众所周知的需求。产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的，它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在，产品待办事项列表就存在。

• 冲刺待办事项列表（Sprint Backlog），也可成为迭代待办事项列表，是Scrum团队在Scrum sprint迭代 期间完成的任务列表。在sprint迭代计划会议期间，团队通常选择一些产品待办事项（Product Backlog），确定完成每个用户故事所需的任务。大多数团队还会估计团队中的某个人需要花费多少小时才能完成每个任务。团队如何选择冲刺待办事项中的项目和大小是非常重要的。因为他们是致力于完成任务的人，所以团队成员必须是选择他们所要承诺的任务的人，冲刺待办事项通常作为电子表格维护，但也可以使用缺陷跟踪系统或专门为Scrum或敏捷设计的软件产品。

• 发布燃尽图和冲刺/迭代燃尽图用于表示剩余工作量的工作图表，由横轴（X）和纵轴（Y）组成，横轴表示时间，纵轴表示工作量。这种图表可以直观的预测何时工作将全部完成，常用于软件开发中的敏捷软件开发方式，也可以用于其他类型的工作流程监控，主要记录了记录了在一段时间内Product Backlog/Sprint Backlog的剩
  余估算工作量。

发布燃尽图

冲刺/迭代燃尽图

敏捷项目还有很多需要学习的地方，下回再继续介绍吧。