Scrum的起源
接触过敏捷的我们，一定对Scrum都不陌生，Scrum是众多轻量级敏捷框架中应用最广泛的一种。
Scrum的历史可以追溯到1986年《哈佛商业评论》中的一篇文章《新型的新产品开发策略》（The New New Product Development Game，竹内弘高、野中郁次郎，1986）。这篇文章描述了像本田、佳能、富士施乐这样的公司是如何通过可伸缩、基于团队的并行产品开发方式开发出了世界一流的产品。文章同时强调了授权、自组织团队的重要性，并概要描述了管理在开发过程中发挥的作用。
Scrum这个词没有什么标准的中文解释，它来源于橄榄球中的一个争球的动作。
竹内弘高和野中郁次郎在《新型的新产品开发策略》首次提到将Scrum应用于产品开发，他们指出：传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这可以更好的满足当前激烈的市场竞争。
Scrum核心
“透明、检验、调整”是过程控制理论的三大支柱，也是Scrum理论的核心。
透明：建立信任的环境，尽早暴露风险。
检验：CI/CD，Code Review，验收测试。
调整：Retro，Showcase，Release Plan，IPM，Prioritization and Estimation。
Scrum的3(角色)3(工件)5(活动)5(价值观)
三个角色
Product Owner：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
作为产品负责人，PO清楚地知道产品的愿景，需要对产品待办列表的梳理、优化、优先级排序等负责。PO决定Why和What，一般可以对应为我们理解的产品经理和业务分析师的角色。
Scrum Master：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍， 一般可以对应为我们理解的项目经理的角色。
Scrum Team：主要负责软件产品在Scrum规定流程下进行开发工作。每位成员可能负责不同的技术方面（开发、测试），要求团队有很强的自组织能力，能够交付一个端到端的真正对客户有价值的产品。
三个工件
Product Backlog：PO首先将需求按照优先级进行排列，产生一个Product Backlog。作用类似于传统开发中项目经理确定需求文档。产品待办列表就是产品的“What”。PO通过“讲故事”的方式，让团队理解产品的目标，帮助整个团队对用户故事有充分和统一的理解。
Sprint Backlog：有了Product Backlog列表，我们需要通过Sprint Planning Meeting（Sprint计划会议） 挑选出用户故事（Story）作为每次迭代完成的目标。
潜在可交付的产品增量：要求每一个Sprint结束都产生用户可用的软件，也被称着“潜在可交付的产品增量”（Potential shippable product increment, PSPI）。能否每个Sprint生成满足质量定义的PSPI 是Scrum 执行效果的试金石。
因此这里关键的是团队内有一致同意的DOD（完成的定义），基于其中的内容来判断是否迭代内所有东西都做完了。同样，随着时间推移，团队DOD内容会不断修改完善 。“潜在可交付”并不意味着构建出的东西必须实际交付，交付是产品负责人的业务决策，基于发布计划来确定。
五个活动
Sprint Planning（IPM）：Sprint计划会议在Sprint一开始召开。PO和团队共同决定计划在这个Sprint完成哪些用户故事。
Daily Scrum Meeting（Standup）：每日站会，一般在15分钟以内。团队成员相互交流任务的进展，计划以及遇到的困难。
Sprint Review（Showcase）：Sprint评审会议发生在Sprint将要结束的时候。团队和客户一起评审本次Sprint的产出是否达到预期。
Retrospective：回顾会议发生在Sprint的最后，由Scrum Master负责召集团队召开。会中大家回顾和小结这个Sprint做的好的地方以及有哪些不足。保证团队能够持续改进，不断提高。
Backlog Refinement：Product Backlog的梳理，可以发生在整个Scrum周期的任何时间。
小记
Scrum Guide明确指出，Scrum的角色、工件、事件和规则是不可改变的。虽然团队可以只实施部分Scrum方法，但Scrum只有以整体的形式存在，才能作为其他技术、方法论和实践的容器而运作良好。因此，从方法论的本质上，Scrum预定义了一个最小框架，这个框架里的元素不可缺少。
五个价值观
为了让Scrum团队能够高效运作，大家需要对目标承诺，有专注精神、接受挑战的勇气和开诚布公的心态。在分享的同时互相帮助、互相尊重。
当这些价值观渗透到团队之中，前面的3（角色）3（工件）5（活动）才能发挥出最大的价值，才能使团队成为真正的“Agile Team”
勇气：有勇气去面对各种挑战。
专注：每个迭代只专注于该迭代要完成的事情。团队和个人的能力、精力是有限的，在有限的时间内专注于最有价值的事情，以取得好的结果。
承诺：作为一个自组织团队，在迭代开始的时候做出承诺，并在迭代中全力完成。
尊重：团队是能随时沟通，并且相互理解的。
公开：团队所有的进展、问题、阻碍都是对所有人可视化、透明的。这样的团队才能彼此尊重，同时也能随时暴露问题。
Scrum的精髓
亨里克.克里伯格（Henrik Kniberg，资深敏捷教练，《精益开发实战：用看板管理大型项目》的作者）从更深层次解析了Scrum的精髓，提出了Scrum的本质上有三个拆分和两个优化。
Scrum的三个拆分
拆分组织：把组织拆分成小规模、跨职能的自组织团队。
拆分产品：把工作拆分成一系列小而具体的交付物，按优先级排序，估算每项任务的相对工作量。
拆分时间：把时间拆分成固定大小的短迭代（通常为1~4周），在每个迭代结束时对可交付的产品增量进行演示。
Scrum的两个优化
优化商业价值：在每个迭代结束后跟客户一起检查发布目标，并据此优化发布计划，更新产品代办事项列表的优先级。
优化流程：每个迭代结束后进行回顾，对团队的实践过程做优化。
敏捷Scrum常见的问题：
迭代开发等于Scrum开发吗？
有人认为，敏捷Scrum就是快速迭代，快速迭代就能达到敏捷的效果，这样的理解是有偏差的。敏捷开发是一个总体概念，而迭代式开发只是几乎所有敏捷开发所采用的一个主要的基础实践。敏捷开发除迭代式开发外，还包含了其他许多管理与工程技术实践，如演进式架构设计、敏捷建模、重构、自动回归测试（ART）等等。
迭代的长度如何选择？
选择迭代长度时考虑的因素：
1）不确定性的多少。不确定越多，无论是哪种类型，迭代就应该越短；
2）获得反馈的难易程度。获得反馈越难，迭代就应该越短；
3）优先级可以保持多久不变。优先级变化越快，迭代就应该越短；
4）紧迫感的维持。越保持急迫感，迭代就应该越短。
无论你选择多长的迭代周期，最好选择一个长度然后坚持使用，而不是经常改变它。比迭代周期的初始设定更为重要的是团队在遇见问题后如何应对和改进，并切实将改进任务纳入每个迭代中去实施，逐步达到迭代结束时产品应具备的可交付状态。
开发团队的规模？
Scrum提倡，用小规模保持敏捷性，用大规模完成重要的工作，推荐了5~9人的团队规模。但是我们不用纠结这个数字。重要的是，团队能够拥有完成产品增量的所有技能，同时保持高效的协作。有些团队有11个人，如果可以确保高效协作就不必非要减去几个人。有些团队只有4个人，但是足以完成产品增量，也没必要再加人。
写在后面：
Scrum is simple，but it's not easy。
Scrum框架为团队敏捷实施定义了一个简单和明确的边界。在边界之内，团队探索和完善相关的管理和技术实践。理论的内容总是很简单，但是真正做起来，会遇到各种各样的问题，不断假设、不断验证自己的假设，并不断调整和优化。这也是敏捷的核心思想吧。
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。
