1.4 Scrum
1986年1月的《Harward Business Review》期刊登载了一篇题为《The New New Product Development Game》的文章，其要义说的是：“原有的‘接力跑’式的产品开发模式一定程度上违背了以人为本、最大化生产力、灵活生产方式的原则。相反，另一种独特的团队，采用‘橄榄球’式的团队合作方式——整个团队合作无间，灵活机动地接球、传球，并作为一个整体迅速突破防线——这可能更加适应今天更具挑战的市场需求。”
这就是Scrum源起的故事，从产品研发的角度来理解这个恰到好处的比喻，可以更好地理解Scrum的精髓：
●Scrum使我们能够专注于如何在最短的时间内实现最有价值的部分。
●Scrum使我们能够快速、经常地监督实际产品的发展状况（每两周或一个月）。
●按照商业价值的高低先完成高优先级的产品功能，采用自主管理模式，凝结团队智慧创造出最好的方法，因而效率提高。
●每隔一两周或者一个月，就可以看到实实在在的可以上线的产品。此时，可以进一步决定是继续完善功能实现更多需求或者直接发布。
Ken Schwaber在他的书中指出，Scrum不是一种构建更好产品的方法，也不是快速构建高质量软件的方法。Scrum是一种工具，一种可以帮助我们找到用来快速构建高质量软件的要素的工具。
1.4.1 发源与发展
Scrum之父Jeff Sutherland 于1993年在Easel Corp提出了Scrum的方法，而大师Ken Schwaber创作并出版了三本有关Scrum的书：《Agile Project Management with Scrum》、《Agile Software Development with Scrum》、《Enterprise Scrum》，Scrum自此开始坚实地扎根于软件行业。
2002年，Ken Schwaber和Mike Corn 联合创办了Scrum Alliance（Scrum 联盟）。在发布后的10年内，Scrum相继被微软、雅虎、谷歌、飞利浦、西门子、IBM、第一美国不动产经纪公司等知名企业采纳，所涉及的领域已经超出了软件研发的范畴，涵盖嵌入式系统、游戏、网站、手机、网络交换设备等众多领域。
1.4.2 自我管理
Scrum方法并没有特定的工程实践惯例，但是定义了几个角色，例如，团队（Team）、团队负责人（Scrum Master）、产品负责人（Product Owner），以及角色相应的职责。团队这个角色被注入了“自我管理”的使命，团队成员会主动朝着产品研发的进展方向规划自己的迭代计划、日计划，并主动完成工作。产品围绕着产品清单（Backlog）展开，这个清单作为一个容器容纳所有待完成和已完成的工作项，而每个工作项都可以继续拆分和重新排列优先级，当Scrum开发开始时，团队将从中选择重要且能够完成的产品清单，在2～4周内完成这些产品清单的发布。产品正是通过一次次的迭代（Sprint），由增量构建的产品清单所组成的。
Scrum同XP、水晶等方法一样均属于敏捷方法范畴，敏捷宣言强调，在项目实施过程中：
1.拥抱变化（embrace the change）
无论多么明智、多么正确的决定，也有可能在日后发生改变。因此，团队要充分理解利益关系人（Stakeholder）和客户代表为什么经常提出新的需求，一句话，“唯一不变的是变化”。团队要相信利益关系人做出的每次决定和需求调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风险，实现团队最大化利益，这是适应市场变化的必然行为。
而在接受变化的同时，我们应该积极地向利益关系人和客户代表反映开发过程中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目标的先后顺序，在迭代周期内，对于还没有最终决定的设计方案，可以置后实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发、测试团队也将更加适应，真正拥抱变化。
2.客户的参与（with customer representative on site）
首先，谁是客户（Customer），谁又是客户代表（Customer Representative）？利益关系人可以理解为客户、产品的最终使用者（End User）、内部使用者（Insider User）和商业伙伴（Business Partner）。利益关系人作为团队中最了解业务的人，将帮助开发团队快速达到目标和做出适时决策。开发团队拥有很好的技术，但在业务方面需要利益关系人的帮助。通常在敏捷的开发项目中，当团队中的任何一个人需要帮助时，只要简单地邀请大家参加一个15分钟会议，或一封邮件、一个电话便可以解决。
但是，如果利益关系人各执一词怎么办？为解决这个问题，将产品负责人引入到讨论中来，作为利益关系人的代表，有权在分歧中做最后抉择。因此，通过客户代表的参与，团队更好地了解了所做事情的价值和意义，其工作效率也因而得到很大提高。
利益关系人能够帮助团队中的每一个人更好、更快地完成工作，他们的直接参与成为了敏捷开发、敏捷测试的重要前提。
3.较少的文档（with less documents）
敏捷开发更重视生产出可用的产品而不是详细文档，但文档又是敏捷与传统开发、测试中不可或缺的一部分。传统开发的文档在敏捷开发里仍有大用，只是原来十来页的内容精炼到现在的一页半页。
敏捷主义者相信文档不是最佳的沟通方式，他们鼓励通畅的交流和沟通，要求避免和减少陈词滥调和空头支票。复杂的文档说明只能增加沟通成本，因而敏捷开发、测试的文档不需要长篇累牍，而是简洁清晰。任何一段清楚的文字，甚至一张图片、照片、一封会议记录邮件都是我们认可的敏捷文档。因为任何沟通方式和载体都是为了帮助团队进行更高效的交流和沟通，只有团队保持着沟通上、理解上的一致，才能够充分发挥出团队的最佳战斗力。凡是利于有效沟通的方式，敏捷团队都不会舍弃。
4.最大化的生产力（maximize productivity）
敏捷开发模式要最大化地提高团队的工作效率。无论是依靠剪除冗余的文档，还是提供民主的、通畅的沟通平台，都是为了帮助团队能够集中有限的精力处理有意义的问题。据调查，通常人会在两个或多个任务并行的情况下产生最高工作效率，而敏捷正是通过各种方法得到团队的最大生产力。
敏捷开发的Scrum模式，要求团队成员在计划阶段主动制定迭代周期的所有工作任务，因此，从开始迭代活动的那一刻起，团队已经在多重工作的压力下紧张工作了。而在日常的迭代生产活动里，各个成员需要当众简单汇报当天的工作进度并制定下一个24小时的工作计划。因此，通过增加敏捷人员的工作透明度，无形之中，团队成员的生产力进一步得到提高。
5.自动化冗余工作（automate the redundant work）
将团队成员从冗余的劳动中解放出来，无论是自动化测试还是自动化工具的开发，只要能够节约成本，都是敏捷开发、敏捷测试的目标。
6.民主的团队（democracy in team）
敏捷团队是一支民主的团队，团队关系是平行的，每个团队成员能够平等地参与讨论、决策。传统开发的垂直式机构在敏捷开发中已经过时。
7.尊重团队（respect to team）
敏捷团队的决定权在团队自己手中。无论是产品设计方案还是产品的功能实现，都是团队决定的最佳结果。团队脱离了任何一个成员的工作都是不完整的，所以我们应当足够尊重其他成员的劳动果实并表达对其他成员的充分信任。尊重团队、尊重团队中的每一个成员都是敏捷开发的原则之一。
1.4.3 七经八络
如图1-5所示，一个完整的Scrum的项目周期可以由一组迭代周期组成，这个周期也可以与极限开发（XP）的迭代周期类比，一般典型的迭代周期为2～4周，最多一个自然月，太长就失去了敏捷的意义。但这只是一般而言，真正的迭代长短由产品负责人决定，必须保障需求变化不影响产品研发。一个固定的周期能够创造出更优美的节奏感，我们用时间盒子（Time Box）来形象描述这个节奏，而所有产品的设计、开发、测试全部需在一个迭代周期内完成，时间盒子必须严格执行，每个迭代都是如此。
Scrum的重要参与角色是产品负责人、团队负责人和团队。
产品负责人的主要职责是定义产品的功能，并决定产品发布的日期和内容，在和投资人的谈判中，产品负责人负责规划产品的投入并对产出负责。产品负责人需要始终保持着对市场和来自客户的阶段性需求和反馈的敏感度，并根据这些变化对产品所需开发的功能模块进行优先顺序排列，在拥有多位业务人员的团队中，产品负责人尤其需要统一团队对需求的定义和优先级排列。在迭代开发的流程定义和产品的计划发布时，产品负责人需要合理地调整迭代主题和迭代周期长短；在产品阶段性验收时，产品负责人还需要参与并决定迭代成果是通过验收还是拒绝交付。
图1-5 Scrum的标准流程
团队负责人的主要职责是对项目进行直接管理，领导团队掌握Scrum的方法和实践，并体现其价值。当团队在产品研发过程中遇到问题时，团队负责人的首要责任是利用资源直接或间接协助其解决问题，以确保团队胜任其工作并保持高效的生产率。团队负责人需要保护团队不受外来的无端影响，让团队能够在良好的工作流程和环境中紧密合作，发挥出团队中各成员的职能价值。
团队的主要职责是完成迭代中的设计、构建、测试、维护等工作。所有成员均分享团队的一致目标，懂得如何配合，且无需外界过多监管而独立完成工作，也愿意在需要的时候帮助团队其他成员完成艰巨的工作。如图1-6所示，最佳的Scrum团队成员由5～9名成员组成，虽各司其职，如开发、测试、需求分析、图形界面设计等，但在工作中均表现为能力综合的多面手。良好的团队能够自我管理并有较强的自知力、自制力。而在一个迭代、甚至多个迭代中团队成员均应全职工作，即全心全意地从事一个项目，个人职能在当下迭代中最好是固定的，而在新的迭代开始后可以转换角色。
图1-6 Scrum团队组成
在Scrum的游戏规则里，主要有迭代计划会议、例行会议、迭代评审会议和迭代回顾会议四项主要的活动。
迭代计划会议。计划会议标志着迭代的开始，所有成员都需要参加，目的是通过分析、评估已有的产品清单，选择一些成为当前迭代的目标；决定如何通过协作完成当前计划，从选出的产品清单中细分，可以以人时为单位，或者以故事点为单位，团队成员领取工作项并评估所需要的工作量。在计划会议上，产品负责人和团队负责人领导会议的进行。其中，产品负责人需要确认哪些工作项最有商业价值，参考团队在技术角度的复杂度和可行性分析，设定当前的迭代目标。团队负责人则主要负责记录和协调团队工作项、计划的认领，在已有产品之上构建新的迭代内容。当迭代认领的工作项产生相互依赖时，团队负责人必须非常清晰地引导团队做出合理的工作项评估和必要的风险评估，并及时同团队和产品负责人沟通。团队的主要目的是根据所需要的最有价值的目标，尽可能按照价值队列来完成工作项目。而当团队成员认领的工作相互之间有依赖关系和关联关系时，需要考虑可行的计划和方案，以使自身的工作能够在不受干扰的环境中开展，且使被依赖工作项提交时间点尽可能对其他人产生小的影响。再者，就是将工作量细分，最好不要超过32个工作小时（如果以4周为迭代周期），而细分越详细，对工作量的评估也越准确。图1-7给出了迭代计划中迭代工作项工作量细分的示例。
图1-7 迭代计划中迭代工作项的计划展开
例行会议。例会是一个禁止闲聊和废话的会议，所以要求大家每天都站着开，这个会不是为了解决问题，而是为了给团队一个完整的画面——我们在哪里，我们将去向哪里？在例会上，无关的人，即使是经理，只要不是团队成员、团队负责人和产品负责人都不需要发言。会上大家会交换彼此的承诺，交换方式则是回答以下3个问题：
1）过去的24小时，我做了什么？
2）将来的24小时，我要做什么？
3）现在我有什么工作被阻碍，或者我可能有什么工作会影响到其他人？
会议时间尽量控制在最短，说话的时间控制在1～3分钟，不需要阐述细节，也不值得展开讨论。在队员回答问题的时候，尽量不要打断，团队负责人如果没有很好的协同工具，则需要即刻记录并投影出来，让每个人都看得到。
迭代评审会议。迭代评审会议意味着迭代结束。评审会议需要团队演示新增部分的功能，还要和技术利益关系人演示底层架构的实现；如果是非正式的评审会议，即没有客户参与的情况下，仍然需要提前准备，但是时间最好不要超过2～3小时。所有的利益关系人、团队成员都需要参加会议，团队需要虚心接纳产品负责人和其他各位利益关系人的意见，在时间允许的情况下，尽可能做出充分的响应，即使没有能力回答或需要调查研究后给出反馈也需要在会上给出回复的时间期限。最后，通常产品负责人将会给出结论，即此次迭代是否完成了计划的工作，迭代是否成功。在累积了一定的基础功能后，客户将被邀请加入评审会议，此时的评审会议需要更正式。
迭代回顾会议。迭代回顾会议是为了总结工作中的经验和教训，是保证团队持续性进步和提高的重要工作，一般在1～2次迭代完成后，团队成员、产品负责人、团队负责人通过讨论和自我剖析，分析在当前环境下最迫切的问题和所需提高的能力，大家尽可能地针对自己的工作提出改进意见和方案。团队负责人需要做好调节会议气氛的准备，避免讨论陷入僵局或者争吵。