如何更好地导入 Scrum？

前面写了一系列极限编程的分享，目前这系列先告一段落，后面等我们禅道 20 系列版本重构完再和大家分享 TDD 方面的经验体会。极限编程聊完了，接下来和大家聊聊 Scrum。Scrum 市面上相关的书籍、视频和分享比极限编程要多很多，我不做赘述。更多地是想和大家聊聊：如何更好地导入 Scrum？如果企业有预算，最好的方式当然是请资深的敏捷教练来做 Scrum 的导入。敏捷教练有比较扎实的理论知识、丰富的经验和灵活的方法，再加上个人的影响力，可以按照标准的 Scrum 框架来进行导入。但现实中更多的情况是，团队中一位小伙伴通过自我的学习，了解掌握了 Scrum，想在团队中进行导入，这时候应该怎么办呢？如果你对团队有足够的影响力，团队也比较开放，也可以尝试按照标准 Scrum 的框架来导入。但如果上述的假设不存在，可以考虑渐进式的方式来导入。

首先是用中性化的概念来导入 Scrum。

很多团队在导入 Scrum 的时候会遇到很多阻力，执行效果比较差。如果分析原因的话大家可能会归结到团队成员的能力或者素质上面。但如果换位思考的话，这个问题也许更容易解决。人对陌生的事物是天生警惕、排斥的。如果一上来就完全按照 Scrum 的标准概念来执行，“好家伙全是新概念”，会容易遭受大家的阻力。比如 Scrum Master 这个角色，如果站在项目经理角度来思考：那还需要我做什么呢，是不是要革我的命呢？所以我们在导入 Scrum 的时候不妨使用中性化的概念来导入。

比如原来叫产品经理还是叫产品经理，不用一定叫 Product Owner；原来的项目经理还是项目经理，不用一定叫 Scrum Master；需求还可以用需求的概念，可以先不用用户故事来整理需求；计划会议可以拆分成需求讲解会议和任务拆分会议，站立会议可以叫做每日晨会，功能评审演示可以叫做验收会议，回顾会议可以叫做总结会议。总之用大家之前习惯的词汇，这样可以让大家更容易接受，减少阻力。

其次是暂缓使用故事点做规模估算。

故事点在业内有很多的讨论，也有很多的争议。我们融平台最新的一期直播还专门邀请了三位嘉宾来讨论故事点，大家也提了很多很有趣的话题。我的观点是可以不用故事点，而是使用工时或者人天的方式对需求进行估算，简单直接，也容易理解。因为用什么单位不重要，估算的准确与否也不重要，重要的是这个估算的过程。估算过程是团队对需求进行澄清对齐的过程，这才是最重要的。

第三是任务自由领取和统一调整相结合。

敏捷开发都会强调团队的自我管理。但如果从保证结果角度来看，团队分工其实是有最佳组合的。任务自由领取方式得出的组合未必是最佳组合，甚至有很大风险。比如一位新手领取了非常重要的设计任务，就不见得合适。当然从长远来看，我们是需要逐渐培养大家的自我管理意识，但这需要过程，需要通过一个个迭代结果的达成来逐渐建立团队成员的信心。所以从这个角度上讲，项目经理保留对人员分工调整的权力还是很有必要的。可以让大家先来挑选，然后再做统一的调整。

所以我的观点是采用中性化的概念、渐进式地导入 Scrum。当团队跑了若干个迭代之后，大家也都熟悉了新的流程，这时候可以再和大家做 Scrum 的培训，正式地导入标准的 Scrum。

最后还有一点就是不要对 Scrum 的流程做删减。

Scrum 是最小管理框架，它里面的每一个流程都有它的价值。我们可以不用标准的 Scrum 概念，可以不用故事点，可以做任务的指派，但 Scrum 核心的五个事件是必须要做的。如果砍掉其中的任何一个部分，都会有问题。比如假设不做需求分析会议，直接做任务拆分，带来的后果就是研发团队对需求的理解就难以达成共识、规模估算也不够精确。比如每日站会不开，就缺少信息的同步和风险的识别。比如演示会议不开，就缺少了对迭代交付物的验收，也失去了建立团队信心的好时机。

所以我的观点是 Scrum 是最小管理框架，只能对其进行补充完善，不要尝试对其进行裁剪。只要裁剪，就会有问题。很多公司实行 Scrum，到最后就只剩下冲刺这样一个时间盒的概念，成为让大家加班的正当理由。

以上是我们在导入 Scrum 过程中的一些经验体会，与大家分享。