Scrum 快速参考 - Reference Card

关于 Scrum (About Scrum) 

管理框架 Scrum是⼀个适⽤于增量式产品开发的管理框架，由⼀个或多个平均7⼈ 左右的团队组成。 它提供了⼀个包含⾓⾊、会议、规则和⼯件的结构。团队负责在此框架 范围内创建和调整他们的流程。 Scrum使⽤固定时间长度的迭代，称为Sprint，通常是2周到30天之间。 Scrum团队试图每⼀个迭代都构建初⼀个潜在可交付（充分测试过）的 产品增量。

替代瀑布的⼜⼀选择 (An Alternative to Waterfall)

Scrum采取增量迭代⽅式，抛弃了“瀑布”开发的传统阶段，以获得可以 快速地吸纳反馈、优先开发⼀部分⾼价值特性的能⼒。

替代瀑布的⼜⼀选择 - 图1：传统的“瀑布”开发依赖于在最开始就能够完美地理解需求，并且在执⾏每个阶段时都只产⽣最少 的错误。

图2：Scrum在每个迭代中混合了所有的开发活动，并进⾏调整，以利于定期查明实际情况

。

能够发挥Scrum最⼤功⼒的，是牵涉到知识创造和协作的复杂型⼯作， 例如新产品开发。Scrum通常都跟⾯向对象软件开发关联在⼀起。它也 被⽤在了半导体、抵押贷款和轮椅等产品的开发中。

真的做Scrum，还是在装样⼦？ Doing Scrum, or Pretending to Do Scrum?)

Scrum持续地进⾏实况检查，从⽽暴露出个体、团队和组织⽅⾯受到的 不合理约束情况。很多⼈说是在做Scrum，实际上却对那些需要去破除 组织障碍的地⽅都进⾏了修改，失去了获得⼤量好处的机会。

Scrum ⾓⾊ (Scrum Roles)

产品负责⼈ (Product Owner)

• 最⼤化研发⼯作投⼊回报（ROI）的单⼀责任⼈

• 负责产品愿景 • 持续地按优先级顺序重排产品列表，对长期性的所有预期进⾏调整， ⽐如说发布计划

• 需求问题的最终裁决者

• 接受或拒绝单个产品增量

• 决定是否要发布

• 决定是否要继续开发

• 照顾⼲系⼈的利益

• 也可能以团队成员⾝份做出贡献

• 是⼀个需要起到领导作⽤的⾓⾊

Scrum 开发团队 (Scrum Development Team)

• 跨职能（例如，包括了具备测试技能的成员，以及业务分析师、领域 专家等⼀些过去通常不被称作开发⼈员的其他⼈）

• ⾃组织/⾃管理，⽆需团队之外的专⼈管理

• 跟产品负责⼈协商Sprint的承诺问题，每个Sprint⼀次

• 可以⾃主决定如何兑现承诺

• ⾼度协作

• 都待在⼀间团队室⾥的效果最好，尤其适⽤于最开始的⼏个Sprint

• 队员长期、全职参与的⽅式效果最好。Scrum把⼯作带给灵活且快速 学习的团队，以避免调动⼈员或是把⼈拆散到团队。

• 5~9名成员 • 是⼀个需要起到领导作⽤的⾓⾊

ScrumMaster

• 引导Scrum的流程 • 协助移除障碍

• 创建⼀个可促进团队⾃组织的环境

• 收集经验数据以调整预期

• 隔离团队的外部⼲扰和分⼼事，以保持团队⼼流状态（也即⼼流区）

• 保障时间盒

• 保持Scrum⼯件始终可见

• 推动改善⼯程实践

• 没有任何团队管理职权（任何具有团队职权的⼈默认都不是团队的 ScrumMaster）

• 是⼀个需要起到领导作⽤的⾓⾊

Scrum 会议 (Scrum Meetings)

Sprint 计划会议 (Sprint Planning Meeting)

每个Sprint刚开始的时候，产品负责⼈跟团队⼀起召开Sprint计划会议， 商讨在这个Sprint中他们想把哪些产品列表条⽬变成为可⼯作的产品。 产品负责⼈负责讲清楚对于业务来说哪些需求是最重要的。团队则负责 选定在不积累技术债务情况下可完成的⼯作。团队将⼯作从“产品列表” 拉⼊Sprint列表。

在⾯对具有内在不确定性的复杂型⼯作时，团队除了参考前述Sprint的 情况，还必须协作以便更直观地了解⼤家承诺⼯作项的能⼒。计算可⽤ ⼩时数、⽐较估算值跟实际值的⽅式，会导致团队⾃以为很精确，还会 削弱团队的主⼈翁意识。除⾮⼯作真的可预测，否则他们就该在前⼏个 Sprint就放弃这类实践甚⾄是彻底不⽤。

在团队学会如何每个Sprint都能完成⼀个潜在可交付的产品增量之前， 团队应该削减他们所承诺完成功能的数量。若⽆法改变积习，将会产⽣ 技术债务甚⾄是设计坏死（如图15所⽰）。

如果产品列表顶部的内容尚未确定，那就需要占⽤计划会议⼤部分时间 都⽤来做这件事，就如列表修整会议章节所述。

Sprint计划会议快结束的时候，团队把所选择的条⽬拆分成Sprint任务， 得到⼀份初始清单，并对⼯作做出最终承诺。 30天的Sprint，分配给计划会议的最⼤时长（也即时间盒）是8个⼩时， 对于较短的Sprint，也要相应地缩减会议时间。

图4: Sprint计划会议的产出物是已承诺的产品列表条⽬以及相应的Sprint任务。ption

Scrum⽇会和Sprint执⾏ (Daily Scrum and Sprint Execution)

每天在相同时间相同地点，Scrum开发队员们花费总计15分钟相互报告 情况。每名队员都要总结他昨天做了什么、今天将要做什么，以及是否 遇到了障碍。

站着开Scrum⽇会，有助于保持会议简短。如果有需要额外关注的话题 可以等所有⼈都报告完之后感兴趣的⼈再继续讨论。

团队或许会发现，维护使⽤⼀份当前Sprint任务列表、⼀张Sprint燃尽图 以及⼀个障碍列表是很有⽤的。在Sprint执⾏过程中，发现要达成Sprint ⽬标必需新增任务，是很常见的情况。那些由团队控制范围之外的问题 所造成的障碍，应视作组织级障碍。

产品负责⼈如果能参加Scrum⽇会，通常都会有所收获。但如果有任何 参会者同时也是团队主管，隐形枪效应就会阻碍⾃组织和演进式领导⼒ 的形成。缺乏团队⾃组织的实际经验的⼈往往看不到这个问题的存在， 就跟鱼⼉看不见⽔⼀样。反过来说，产品负责⼈提⾼参与度能帮到那些 缺乏产品需求相关经验的团队，包括参加Scrum⽇会在内。

Scrum⽇会旨在破除独⾃⼯作的积习。队员们要警惕那些旧习惯复苏的 蛛丝马迹。例如，只⾯对着ScrumMaster讲话，就是其中的⼀种症状， 表明团队还没有学会如何像⾃组织实体那样运转。

Sprint 评审会议 (Scrum Review Meeting)

Sprint执⾏之后，团队召开Sprint评审会议，向产品负责⼈和其他有兴趣 了解的⼈演⽰可⼯作的产品增量。 这个会议应该是现场演⽰，⽽不是作报告。 演⽰完之后，产品负责⼈逐个检查在Sprint计划会议上所做出的承诺， 并申明他认为哪些条⽬是完成的。例如，只有“编码完成”的软件条⽬是 被算作没有完成的，因为没有测过的软件是⽆法交付的。未完成的条⽬ 会被打回产品列表，然后再根据产品负责⼈的最新优先级顺序判断是否 放⼊后续Sprint。

ScrumMaster协助产品负责⼈和⼲系⼈将他们的意见转化为新增的产品 列表条⽬，以便产品负责⼈进⾏优先级排序。新发现的需求范围往往都 会超出团队开发的速率。如果产品负责⼈觉得新范围⽐最初的预期更加 重要，新范围就会取代旧范围在产品列表中的位置。

Sprint评审会议是适合于外部⼲系⼈（甚⾄是最终⽤户）参加的会议。 它是在产品演进过程中进⾏检验及适应，和⼈们不断改进对需求理解的 机会。对于新产品，尤其是软件产品来说，凭空想象是很难想出来的。 ⼤多数客户都需要把软件运⾏起来、⽤⼀⽤，才能发现他们⾃⼰真正想 要些什么。迭代开发是⼀种价值驱动的⽅式，可⽤于创建那些⽆法按照 计划驱动⽅式要求在前期就能讲清楚的产品。

Sprint 回顾会议 (scrum Respective Meeting)

⼀个Sprint在回顾会议之后即告结束。团队将在会上反思⾃⼰的流程。 他们检验⾃⼰的⾏为、采取措施以适应后续的Sprint。

全职的ScrumMaster会想⽅设法以避免使⽤了⽆新意、让⼈畏惧的会议 形式。深度回顾需要在⼈们觉得⼼理安全的环境中才会出现，在⼤多数 组织中都缺乏这样的环境。安全感的缺失会导致回顾讨论变味，要么是 ⼀团和⽓、避⽽不谈敏感话题，要么就变成了批⽃会，⼈们互相指责、 发泄敌意。

绩效评估执⾏者的出现是影响团队能否敞开⼼扉的⼀个常见阻碍。

⼈们急于得出结论、提出⾏动建议的偏好，是有效回顾的另⼀个障碍。 《敏捷回顾》1 是相关书籍中最为流⾏的⼀本，它通过⼀系列步骤来放慢 进⾏此过程：预设会议基调、收集数据、激发灵感、决定做什么、总结 收尾。还推荐⼀本书给ScrumMaster们，《学问》将此过程拆解成⼏个 不同层次的相似步骤：客观性层次、反映性层次、诠释性层次、决定性 层次（ORID)。

地理位置分布是做到⼼理安全的第三个障碍。散布各地的团队在协作上 通常都不如共处⼀室的团队做得好。

回顾通常都会暴露出组织级障碍。在团队解决了⾃⾝影响⼒范围之内的 问题后，ScrumMaster应该接着扩⼤影响，⼊⼿解决组织级的问题。

ScrumMaster应该综合运⽤包括默写、时间线以及满意度直⽅图在内的 多种技术来引导回顾会议。任何情况下⽬标都⼀样，要汇聚多种观点以 形成共识，并寻求能够带领团队更上⼀层楼的⾏动⽅案。

产品列表修整会议 (Backlog Refinement Meeting)

⼤多数产品列表条⽬（PBI）在初期都需要修整，因为它们个头太⼤⽽且 很难理解。团队们发现，可以在每个Sprint的执⾏过程中都拿出点时间 ⽤于为下⼀个Sprint计划会议作准备，这种做法很有效。

在产品列表修整会议上，围绕着产品列表上的条⽬，团队针对他们完成 这些条⽬所需要的投⼊，并提供相关技术信息以辅助产品负责⼈对它们 进⾏优先级排序3。⼤且模糊的条⽬将被拆分并澄清，此过程中需要综合 考虑业务和技术两个⽅⾯进⾏处理。有时候也会在⼤家集体估算之前， 叫上团队的少部分⼈，再加上产品负责⼈和其他⼲系⼈，把产品列表给 先理⼀理、拆⼀拆。

技艺娴熟的ScrumMaster可以帮助团队学会，如何在严守包含适量测试 和重构的“完成”定义的同时，去发现具有业务价值的⼯作竖切⽚。

编写产品列表条⽬时普遍使⽤⽤户故事的形式 。此⽅式中，过⼤的PBI 4 被称作史诗级故事。传统开发⽅式将特性拆解为横向任务（按瀑布阶段 进⾏组装），它们既⽆法被独⽴地进⾏优先级排序，也缺乏从客户⾓度 可见的业务价值。这种习惯很难打破。

敏捷⼒要求我们学会把⼤型的史诗故事拆分为可代表⼩个头产品特性的 ⽤户故事。例如，某医疗记录应⽤的⼀个史诗故事“向医⽣显⽰患者过敏 记录的全部内容”，从中可以提炼出“不管有没有过敏记录都进⾏显⽰”。 此时，⼯程师预见的是解析过敏记录内容所存在的技术⼤难题，然⽽， 到底有还是没有过任何的过敏记录，这才是医⽣最想知道的重要信息。 拆分史诗故事时，通过业务⼈员和技术⼈员的通⼒协作，找出了只需要 原始史诗故事20%的投⼊就能得到80%商业价值的故事。

⼤多数产品的⼤多数特性⼤多数客户都不会⽤到，因⽽，明智的做法是 拆分史诗故事以便能先交付最有价值的那些故事。即便后续交付低价值 特性时可能要返⼯，那返⼯总⽐没⼯好。

产品列表修整会议没有官⽅名称，通常被叫做“列表修整”、“列表维护”或 是“故事时间”。

图5：在产品列表修整会议上，需要对产品列表顶部附近的⼤个头PBI（通常称作“史诗”）进⾏拆分， 要竖着把它们切成特性薄⽚（“故事”），⽽不是横着切成实现阶段。Caption

 

Scrum ⼯件 (Scrum Artifacts)

图6：产品列表

• 所期望功能的排⾏榜 • 所有⼲系⼈可见

• 任何⼲系⼈（包括团队）均可添加条⽬

• 产品负责⼈持续调整优先级

• 顶部条⽬的粒度⽐底部条⽬更细

• 通过产品列表修整会议进⾏维护

产品列表条（PBI） (Product Backlog Item)

• 主要澄清⼀个以客户为中⼼的特性是什么，⽽⾮如何做

• 通常都写成⽤户故事的格式

• 制定产品级公⽤完成定义以防⽌技术债务发⽣

• 可以制定条⽬专⽤的接收标准

• ⼯作规模由团队估算，理想状况是使⽤相对单位值（例如，故事点）

• ⼯作规模应该在2~3个⼈⼯作2~3天左右，⾼级团队会更⼩些

图7：⼀个产品列表条⽬代表⼀个以客户为中⼼的特性，通常都需要完成⼀些任务以满⾜完成定义。Caption

 Sprint 列表 (Sprint Backlog)

• 由Sprint计划会议上团队和产品负责⼈协商承诺的PBI所组成

• 在Sprint执⾏期间，所承诺范围是固定不变的

• 初始任务是团队在Sprint计划会议上识别确定的

• 在Sprint执⾏期间，团队将发现兑现既定范围承诺还需要的附加任务

• 团队可见

• 可供Scrum⽇会时参考使⽤

图8：Sprint列表通常都表现为“信息辐射器” 的形式，例如，⼀块实体任务板。

增量 (Increment)

• 在短跑期间完成的产品能力

• 在每次冲刺结束时带到可用的可释放状态

• 与产品所有者希望的一样频繁发布

• 在每次冲刺评审会议期间进行检查

 Sprint 任务 (Sprint Tasks)

• 澄清达成PBI⽬标的⼿段

• 完⼯需要花费⼀天或更少的时间

• 每天都要重估剩余⼯作量，通常以⼩时计数

• 在Sprint执⾏期间，每⼀个⼈可以主动认领⼀个任务

• 由整个团队拥有；需要协作

图9：完成⼀个列表条⽬需要混合开展多种不同活动的相关任务，⽽不是以往那样分不同阶段进⾏（例 如，需求提炼、分析、设计、实现、部署、测试）。ption

Sprint 燃尽图 (Sprint Burdown Chart)

• 显⽰Sprint期间团队总的任务剩余时间

• 每天都重新估算，因⽽可能⾛⾼也可能⾛低

• 旨在引导团队⾃组织

• 按⼈分条⽬或增加趋势线等表⾯功夫会削弱⿎励协作的效果

• 在Scrum发展早期很被看好，但由于在实践中常被误⽤为⼀份管理层 报告⽽备受争议。如果它成为了团队⾃组织的阻碍，ScrumMaster就 应该停⽌使⽤这个图表。 

图10：Sprint燃尽图

 产品/发布燃尽图 (Product / Release Burndown Chart)

• 跟踪记录剩余的产品列表⼯作规模跟随Sprint的变化

• Y轴可能会使⽤相对单位值，例如故事点

• 展现了过往的趋势变化以便调整预测
 

图11：⼀份流⾏的发布燃尽图变种，修改者是Mike Cohn5。红线是已完成PBI的踪迹 （速率），蓝线 是新增加PBI的踪迹（发现的新范围）。两条线的交叉点昭⽰了依据经验趋势推测出的发布完⼯⽇期。

扩张 (Scaling Scrum)

坏消息：这事⼉有难度。

Scrum将不同职能⼈员聚集于同⼀个团队（待在同⼀个团队房间⾥更为 理想），从⽽最⼤化沟通带宽、可见度和信任，以发现不确定的需求及 技术上的风险。

在需求不确定性和技术风险很⾼的情况下，增派⼈⼿⽆济于事，只会让 事情变得更糟。根据专业进⾏分组同样会让事情变得更糟。按架构模块 分组（也即，模块团队），最后也只能让事情变得更糟。

图12：沟通路径随团队规模变化⽽呈指数增长。

好消息：特性团队或许有帮助。

解决此问题最有效办法是创建完全跨职能“特性团队”，他们有能⼒操作 所有架构层从⽽交付以客户为中⼼的特性。在⼤型系统中这意味着得要 学习新技能。

当团队专注于学习⽽不是短期的些微效率时，就能创建学习型组织。

图13：特性团队学着跨越架构模块。

更多坏消息：还是有难度。

⼤型组织获得敏捷⼒的挑战尤其⼤。它们多数都陷在了装样⼦做Scrum 的泥潭⾥6。在⼤型组织⾥，ScrumMaster们应该定期聚会，通过可视化 组织级障碍清单推动转型，阅读《精益和敏捷开发⼤型应⽤指南7》这样 的书。

相关实践 (Related Practices)

精益 (Learn)

Scrum是在软件开发领域的敏捷运动期间出现的⼀个通⽤管理框架，它 部分地受到了精益⽣产⽅式的影响，⽐如说丰⽥⽣产⽅式8。

极限编程 (XP) (Extreme Programming)

ScrumMaster负责提升完成定义的严格程度，但Scrum却并未规定具体 使⽤什么⼯程实践。名副其实⽅可谓之完成。⾃动化回归测试能够防⽌ 那些吸⾎型故事逃出它们的巢⽳。设计、架构和基建必须要与时俱进， 在持续地重新考虑和修整的过程中演进，⽽不是在刚开始我们⼀⽆所知 的时候就试图“最终敲定”。

ScrumMaster可以⿎励团队去学习极限编程（XP）相关⼯程实践：持续 集成（持续的⾃动化测试）、测试驱动开发（TDD）、坚持⽆情重构、 结对编程、频繁提交，等等。据称运⽤这些实践可以预防技术债务。

图14： 绿⾊直线代表敏捷⽅法的总体⽬标：及早且持续地交付有价值的功能特性。合理地运⽤Scrum 就得学会如何才能满⾜严格的完成定义，从⽽预防技术债务9。

团队⾃组织 (Team Self-Organization)

全⼼投⼊的团队表现远胜被操纵的团队

在Sprint执⾏过程中，团队成员们对共同⽬标有着内在的兴趣，并学着 互相管理去达成⽬标。愿为同侪担责的⼈类天性与⼯作者多年来的习惯 相互⽭盾。接受⼀个团队靠⾃⾝驱动，⽽不是被外部奖惩所操纵，这跟 经理⼈们多年来的习惯也是冲突的10。ScrumMaster所具备的观察能⼒ 和说服能⼒可以克服前期的不舒适感，提⾼成功概率。

挑战与机遇

⾃组织团队彻底超越了规模更⼤的以传统⽅式管理的团队。在满⾜⼀定 条件的情况下，家庭规模的群体⾃然⽽然地就会变得⾃组织：

• 成员们以清晰的短期⽬标为⼰任

• 成员们能够衡量群体的进展如何

• 成员们可以观察得到彼此的贡献

• 成员们可以放⼼地给出坦率反馈

⼼理学家Bruce Tuckman将群体发展分为了“组建期、激荡期、规范期、 执⾏期”四个阶段11。达到⾃组织的最佳状态需要时间。团队在最初⼏个 迭代时的表现可能会不如按传统⽅式管理的⼯作组12。

多样化团队应对复杂型⼯作的表现⽐单⼀化团队更好。他们经历的冲突 也更多13。对于全⼼投⼊的团队来说，出现意见分歧很正常也很健康；团 队的表现就取决于他们是否能妥善处理这些冲突。

坏苹果理论认为，⼀名消极成员（“拖团队后腿、散播负⾯情绪或是违反 重要的⼈际交往规范14”）可以不成⽐例地拖累整个群体的表现。这种⼈ 并不多见，但如果团队未能及时清除他们，就会放任他们扩⼤其影响。 在挑选新成员时给予团队更⼤影响⼒能够部分地缓解此问题。 有些⼈在⽼板与⼯⼈情况下⽆法施展拳脚（因为挑战不⾜或被微管理的 原因），将在Scrum团队中焕发光彩。 ⾃组织受很多条件的制约，包括地理位置分布、⽼板与⼯⼈动态关系、 兼职团队成员以及与Sprint⽬标⽆关的各种⼲扰。让全职ScrumMaster 去努⼒减轻这类障碍所造成的影响，对于⼤多数团队来说都很有好处15。

何时适⽤Scrum？(When is Scrum Appropriate?)

图15：Scrum是⼀个经验式框架，适⽤于存有需求不明确与或技术不明确情况下的⼯作。1617

Scrum特别适合那种⽤预定义流程⽆法管理的⼯作，需求不确定、技术 实现风险也⽆法预测。在决定采纳Scrum还是PMBOK®指南所描述那种 计划驱动型⽅法的时候，务必要考虑：基本原理是否已经被充分理解、 ⼯作本⾝是否依赖于知识创造与协作。例如，Scrum就不是为可重复型 产品和服务⽽设计的。

同样要考虑是否有⾜够的决⼼去培养⼀⽀⾃组织的团队。

作者简介 (About the Authors)

Michael James很多年前就已经开始编程。他曾经 跟Ken Schwaber⼀起⼯作，并成为了⼀名Scrum 培训师。他辅导技术⼈员、管理⼈员和⾼管们对 业务进⾏优化以交付价值。