30 张图看懂《Scrum 捷径》

《SCRUM捷径》可谓是经典中的经典，语言质朴，中文版的翻译质量也很高，没有任何长篇大论。文中Ilan 根据多年经验，用30个捷径来阐明组织如何能更好地实践Scrum这个轻量级框架。我在多次阅读过程中，对照近年走过的弯路，觉得字字玑珠，每次都能产生更加深刻的共鸣。之所以有这样的体会，是因为这些捷径我们大多数都听说过；说它不容易，是因为这世间有太多的道理知易行难。以下图片均是原创，文字多数出自中文翻译本，或精简、或摘抄、或提炼、或重排，虽仁者见仁，智者见智，但初衷仍是尊重作者观点，以期透过30张图一窥书中精彩。

#SCRUM捷径1#虽然SCRUM不难推，但如何高效实施为自己打的广告牌撑腰，是完全不同的故事。即使已经设法建立了基本的SCRUM设置，但如果想把团队培养成“SCRUM法拉利”而不是”夏利”，则需要耐心、开放的心态、教训以及方便实用的经验指导！

#SCRUM捷径2#几个Sprint的误用模式：第一、单独的测试Sprint. 第二、没完没了的Sprint0.  第三、长短不一的Sprint.

#SCRUM捷径3#真诚的赞赏，哪怕是最简单的赞赏，也会使我们有安全感，充满活力。像家一样的工作环境，能把我们带回无忧无虑的童年，那个时候我们最高兴，也最有创造力。来！一起做个开心的人吧！

#SCRUM捷径4#想融入一个团队难，带领一个团队更难，没有官方授权而需要带领一个团队则是难上加难。作为起步，可借助如下五个小窍门。

#SCRUM捷径5#SCRUM需要的不是摇滚明星，而是演播室音乐人。除了开放、勇气、专注、承诺和尊重以外，还需要活力（正能量满满）、共情（某个伙伴临时有事，其他伙伴能站出来揽过重任）、好奇（做些非专业的事情以消除团队技能的瓶颈）和友善。总之，态度比能力更重要！

#SCRUM捷径6#就像是儿科大夫是医生，心脑血管大夫也是医生一样，无论是编码还是测试，都是开发人员，他们仅仅是精深领域有所不同罢了。同时我们也鼓励，每个开发人员都是一专多能，这样的T型技能团队更能快速的分享知识，加快价值流动速度。加油，T型的我们！

#SCRUM捷径7#任何组织在寻求筹建紧密团队时都要遵守一个原则，即保全和维护成功的团队。这包括不随便把团队成员调离，也包括不轻易空降成员。否则，没完没了的变动必然使保持一个卓越团队越来越困难，尤其是无形的损失，比如失去动力、士气受影响以及损失有价值的隐性知识。

#SCRUM捷径8#Story points和person days谁对谁错？举个例子，用大大小小的球填满一个杯子是件又快又容易的事情。如果把这些球打开，则有三种可能性：1、内容不满；2、内容刚好；3、内容膨胀。如果把所有的内容再次倒入杯子，也可能发生三种情况：1、杯子不满；2、满；3、溢出。假如把大小不一的球儿看作是Story points，内容物看作Person days的话，那么把球儿破开的过程也正是计划会议中要做的事情。将Story分解成task可以有效地帮助团队权衡决策，确保团队成员对迭代要交付哪些内容做到心中有数。如果基于故事点的估算与基于小时数的估算出入太大，则需要与PO进行进一步沟通。所以基于故事点和小时数的估算并不矛盾，两者的结合更能得出较为准确的计划。但有一点切忌：任务需要多少小时完成，绝对不是我们的目的，如果用小时数来衡量团队成员的效率和产出，必将适得其反。

（注：杯子的隐喻仅代表个人观点）

#SCRUM捷径9#受累于障碍：阻碍某个具体任务但不一定会延缓整个项目进度的问题叫做“阻碍（blocker），延缓整个团队Sprint进展的叫做“障碍（Impediment）”。典型的阻碍是一个有相互依赖关系的任务因为某些原因停了下来，短暂临时的阻碍是比较合理的，也很普遍，不必特别当心，因为解决依赖问题的同时多半有其他工作可以做；但如果遇到障碍的时候，SCRUM妈妈就必须第一时间着手解决，这包括：来自外部的冗长的会议、不成功的构建、开发 工具 和环境问题、产品列表未细化、产品负责人缺席或者无权最重要决定、组织里太关注到个人的激励方案。

#SCRUM捷径10#拆分用户故事好比切蛋糕，最好纵向切片，确保每一个用户故事都是独立的、有端到端的业务价值。同样不到万不得已的时候不要创建单独的技术故事，如果非要创建不可，也不必拘泥于传统的“作为一个......我希望....这样我就可以......” 这样的格式，因为这听上去很刻板生硬，就好比硬要把一个方塞进一个圆里一样，让人觉得不自然！

#SCRUM捷径11#我们在制定最初的DoD时，一定要现实甚至保守，犯不着穷己一生深思熟虑到底应该如何定义DoD，因为它会随着团队的成熟而演进。一开始就雄心勃勃制定一个过于详细的DoD也许会让人钦佩不已，但它一旦变得不现实，就会挫伤团队信誉和士气。就如做菜一样，盐要一点一点慢慢加，如果一下子加过了，就很难收场了。

#SCRUM捷径12#随着我们一天天变老，身体也会渐渐发生变化，怎么才能与老化作斗争？方法之一是使用镜子，通过每天照镜及时发现新生的皱纹，多摸点面霜，多燃烧点脂肪，这样可以拯救许多老化问题。同理，虽然SCRUM不是银弹，但它是一面银镜，经常做检视可以帮我们尽早发现哪些地方可以改进，如此便能更好的响应变化。

#SCRUM捷径13#不管喜不喜欢，为软件项目提供估算这个需求永远不会消失，估算是如此之痛，让我们觉得仿佛走进一条又长又黑的隧道无法解脱，这时相对估算给我们带来了一线光亮。相对估算不去“拆分”故事，而是采用“比较”的原则进行。假如要爬三栋不同的楼房，一栋较矮，一栋较高，另一栋是摩天大厦，怎么办？我们可以花时间去数一数每栋楼有多少层，每层几个台阶，然后估算爬那么多台阶要多长时间。但是我们不知道我们的体力状况，也不知道楼道状况，这样的估算不仅耗时，而且如果假设设置的离谱的话，得出的估算也有巨大误差。假如我们将最矮的楼设为基准（10点）；第二栋楼与它进行高度的比较，同时再综合大楼的新旧情况，我们估算25点；同理，摩天大楼计算为40点。把这个概念应用到软件项目，需要考虑三个因素：重复性、复杂度和风险。虽然相对估算依然不是一件容易的事情，但与其他方法相比，至少是一样的准确，且更加简洁优美。

#SCRUM捷径14#规划扑克的游戏，把相对估算的方法发扬光大。而且大部分团队，都喜欢使用修改过的“斐波那契”数列，因为它很好地体现了需求越大，不确定性越大的特点，同时也避免了对准确性的错觉（比如从20改到21，42改成40等等）。尽管如此，这仍然给团队估算带来困扰。扑克会的关注点是利用打点的方法，经过故事间的比较，快速估算长期产品列表，不要求有详细规范和复杂的依赖性分析，且能够充分利用到过去获得的经验。如果SCEUM MASTER控制不好扑克会的节奏和关注点，就会使这个会议变成无休无止的口水大战！此外一定要严格控制讨论时间，始终牢记帕金森定律：不到最后一刻，工作总是做不完。

#SCRUM捷径15#为了识别基准1，我们花了太多力气挑选产品列表中最小的用户故事，结果是团队为了就到底要选哪个故事做为初始基线争的面红耳赤，最终也没达成一致。找出历史数据，经过识别、 排序 、估算、进一步分类、过滤的步骤之后，最终确定团队未来的参照基准库。

#SCRUM捷径16#关于处理bug的原则，例1: 如果bug是在当前sprint发现的，则developer应该给予最高优先级，立即解决；例2: 如果该developer手里正在处理另一个bug，且它们属于同一个用户故事，则不应该去打断他，而是做一个简单记录用于稍后沟通；例3: 如果bug非常琐碎且相互有关联，可以统一建一个故事来跟踪以节省记录成本；例4: 如果在sprint demo中才发现的问题，可以根据它的重要程度，按照优先级在下一个迭代处理。

#SCRUM捷径17#SCRUM转型像是让测试人员重生，她们在新的环境下拥有了新的身份：1、咨询师：测试人员是她所在领域的工艺专家，她能帮助非测试人员提高测试技能，还可以作为 程序员 的共鸣板，一起做测试驱动开发从而定期交付可以工作的软件；2、设计师：测试员的核心技能是设计，没有人比她更能设计出有效的测试用例了；3、探索者：无论拥有多么彻底全面的自动化，都离不开手工探索性测试，任何层次的自动化都不能够代替人的智能。所以与其说测试是科学，不如说更接近于艺术。测试人员应该摆脱手工测试的束缚，有机会更多专注于自己擅长的事情：设计、提供咨询以及探索性测试，以更有趣的方式发挥她们的技能。

#SCRUM捷径18#在没有自动化的情况下试图实现SCRUM就像是在一条破旧的土路上开一辆赛车，你体验不到赛车那种让人觉得刺激的强大动力，相反，你会感到非常沮丧，还会怀疑赛车。自动化需要大笔投资，且也许是没法立刻收回的投资，尤其是使用哪个测试架构以及自己开发还是使用外部工具，都是需要投入时间和人力研究决定。任何一个scrum团队必须极尽可能实现所有环境下的构建-部署的自动化，有一点总胜于一点没有，30分钟的自动构建胜过好几个小时的构建。千里之行始于足下！

#SCRUM捷径19#关于指标：不管大家喜不喜欢，人们天生就喜欢测量，所以谈到指标，无论怎样，迟早都要面对。指标有善意和恶意之分，用来作为团队识别大致进展的信号，帮助团队检查和调整流程并不断提高的就是善意指标；否则，用于微观管理个人业绩的僵化指标，更重要的是打击人和抹杀士气的就是恶意指标。善意的指标有：燃尽图、增强型交付燃尽图、sprint干扰图以及补救关注点图等。引入任何一种指标的时候都要谨慎，要出于善意，绝不能不停地生产新指标，染上“分析麻痹症”。

#SCRUM捷径20#站会就是团队的脉搏，脉搏的稳定、持续、轻快而有力，直接关系到团队的健康。出色的站会应该为团队带来活力，而非带走活力。每日站会很简单，但如果使用不当也会变成每日混乱。

#SCRUM捷径21#对于坐在SCRUM团队外围的人，五颜六色的任务板可能是最显眼的特征，无论是白板的构造还是组成的要素都变化纷繁，如何创建SCRUM板没有对错之分，适合团队自己的就是最好的。

#SCRUM捷径22#表面来看，SCRUM的每一个活动都简单直接，但是如果不精心准备，可能在这个会议上看到有的人狂怒的拍桌子，有的人却委屈地掉眼泪。SPRINT REVIRW尤其如此，是最需要小心对待且精心引导的一个活动，最核心的问题是如何统一团队外部形形色色的干系人的期望。SCRUM嘛嘛一定要好好准备并且要极力避免SPRINT REVIEW变成枯燥的单向展示。

#SCRUM捷径23#很不幸，当团队面临压力时，最容易想到的就是取消重要的sprint回顾会议，直到情况缓和下来再回到正规。实际上在有压力或者事情进展不顺利时，回顾会议反而更有价值。SCRUM的核心价值观很重要：开放、勇气、尊重、专注和承诺，这些价值观在回顾会议时得以充分体现，每个人都需要时刻牢记这些价值观。

#SCRUM捷径24#团队的典型畏惧：1、害怕变革：变革让人害怕，它将人们推出舒适区，经常被许多安于现状的人视为对他们的威胁。一个悲哀的现实是无论变革有何受益，组织里总会有人反对。在这种情况下，我们依然要大胆变革，将变革描述成为实验，当大家了解到我们可以安全失败，并且可以一起检查调整时，这种畏惧便会得到缓解；2、害怕曝光：SCRUM重要的一环是measurement，宗旨是发现浪费或者错误的行为，这些检查可能曝光那些不愿意为团队出力的个人，所以这也会引起畏惧。我们要大胆曝光，使检查以正面的形式进行，更早更及时地发现问题以免带来更大的痛苦；3、害怕犯错：如果一个组织被相互指责、掩盖问题和内部冲突的文化所扭曲，scrum就像一本打开的书，无情地揭示出软件开发中的错误。我们要大胆犯错，最有价值的学习往往都来自于冒险和犯错，建设有心理安全感的环境十分重要；4、放松心情：放松心情有利于缓解畏惧，“福兮祸所依”，能够从问题中吸取教训并争取机会的个人和组织，必然能很快走出畏惧，迎接新生活！

#SCRUM捷径25#始终牢记：“谁有黄金谁定法则”，项目发起人有权利决定他们喜欢的工作方式。团队要积极主动地安排一个常规性的项目通气会，与项目发起人建立稳定的合作关系，使自己有机会获取直接或者间接的线索以应对可能存在的办公室政治所带来的障碍。要让发起人参与到问题的解决过程，保证他们在信息圈内，保持良好的外交规则，要有艺术地说不。

#SCRUM捷径26#当组织中的SCRUM master增多时，就需要引进一个新的角色，首席SCRUM master，来维持团队间一定程度的一致性和纪律性。这个角色实际上充当了若干个SCRUM master的SCRUM教练，负责组织整体的培训和辅导，挑战现有行为、提供和维护工具、定义指标且善用指标、帮助建立实践社区、确保一致性、通过集体回顾会议来保证持续流程的改进、以及负责团队之间的协调等。SCRUM变革成功的关键在于一致、规范和继续教育，维持成功的SCRUM生态系统非同小可。

#SCRUM捷径27#许多SCRUM的采用推广需要典型的权力中心的演变。不同于以往的“职能型组织”、“项目型组织”以及现在流行的“平衡矩阵组织”，“以团队为中心的组织”更有利于SCRUM成长。职能经理需要重新定义指责，一方面要减少对团队“保姆般”的照顾，另一方面，增加更多导师或者师傅般的辅导，帮助他们学习、成长和表现。并不是因为SCRUM只介绍了三个角色，就意味着其他人都要变得多余或者重复，以开放的心态思考，在不破坏真正SCRUM模式的前提下转变职能。切勿将时间花在无聊的会议、分配授权任务并在行政管理中虚度光阴。

#SCRUM捷径28#人类天生就喜欢测量。我们到底有多敏捷？85% 还是50%？SCRUM的基石就是持续改进，100%完美是根本不可能实现的，运用百分比来计算敏捷程度根本没有意义。那么怎么判断最初的SCRUM是否成功？SCRUM不是一个机械的流程，它对人和文化的依赖性极高，不是靠表格中的一堆数字前后做做比较就能衡量的。一个简单的、主观的和协作性的问卷调查反而更能帮助我们定量反馈：我们变得更好了么？

#SCRUM捷径29#自组织确实非常强大，它没有自上而下的命令和控制权威人士来指挥团队应该采用什么样的具体工作方式；相反，自组织团队由团队自己选择最合适自己的方式工作。但无论怎么宣扬自组织的好处，都不能忽视对边界的考虑。团队成员不可能奇迹般地在某个早晨睡醒后就直接达到自组织的状态。就像植物一样，自组织需要在有鲜明边界的特定环境里种植和培养，否则会有失控的风险，最后爬满邻居的篱笆。这些边界不可能自己形成，也不可能不需要维护，我们需要建立足够合适的检查点，以防不稳定、不确定性和紧张演变成混乱。

#SCRUM捷径30#SCRUM是一个只有少数规则和有限实践的轻量级框架，在Scrum框架的指导下，团队可以大胆尝试，找到适合自己的工作方法。保持透明—> 检查 —> 适应，持续改进，不固步自封，一定会达到预期，甚至渗透到生活的其他领域，成为一种与生俱来的思维方法和行为模式。

作者 | 爱米粒 ：IBM软件开发工程师, Visual Agibility Community发起人、视觉爱好者、敏捷实践者、痴迷手工、擅长厨艺的跨界达人。

Visual Agibility社区 ：https://t.zsxq.com/JeEyNJm