如何更好地导入Scrum?

原创
📘
春哥
2023-06-12 10:11:44
826
摘要: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过程中的一些经验体会,与大家分享。
高丽亚
高级客户经理
17667930330
3645260865
统一服务热线 4006-8899-23
我要提问提问有任何问题,您都可以在这里提问。 问题反馈反馈点击这里,让我们聆听您的建议与反馈。