极简敏捷：解析SCRUM落地常见问题

Posted 2023-04-09

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了极简敏捷：解析SCRUM落地常见问题相关的知识，希望对你有一定的参考价值。

参考技术A SCRUM 作为最流行的敏捷框架，这些年已经得到广泛的流行。

但是很多团队在落地SCRUM的时候，通常会产生以下问题：

一，概念性问题：

SCRUM就是敏捷么？

SCRUM就是开各种会么？

SCRUM有什么好的，能对我的团队产生什么作用？

二，SCRUM执行过程问题：

计划会和需求评审会有啥区别？计划会时候发现需求经常有问题，并且还会有很多问题在迭代中出现。

站会为什么要每天开，每天重复3个问题很乏味。

评审会，业务方没空参加，时间也很紧张了，会议干脆被省掉了。

回顾会，回顾了几次后，已经没有了热情，总是那几个问题，有什么好回顾的。

迭代周期如何定？版本发布怎么做？

为什么看起来SCRUM没什么内容，落地执行却问题多多？

三，SM的角色和发展问题：

SM一定是全职的么？

SM对我的职业发展有什么帮助？

SM的发展路径是什么？

针对以上三类问题，接下来我们尝试解答。

一，概念性问题：

SCRUM就是敏捷么？

答：不是，SCRUM是敏捷的一种落地框架，敏捷的核心是敏捷宣言和十二项原则，是我们前进道路的指明灯，具体落地方法有 SCRUM,XP,KANBAN,等多种实践框架，而SCRUM是其中最流行的一种敏捷落地框架。现实中，企业落地敏捷往往是多种框架和其中部分实践的按需结合，这也符合敏捷宣言的第一句：我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。

SCRUM就是开各种会么？

答：不是，SCRUM是一个框架，帮助我们打造高效团队。SCRUM的主张是尽可能减少不必要的会议，保留最简的必要会议流程。也就是说工作中只需要开这些最少的会就够了，如果有其他会议，可以考虑和现有会议融合，或者简化形式、次数，甚至减少掉。只保留必要的会议，明确会议内容、流程，严格控制会议时长，是减少浪费的体现。

SCRUM有什么好的，能对我的团队产生什么作用？

答：SCRUM帮助团队建立以价值交付为目标的工作方式，清晰的节奏感，短迭代的计划性，及时的过程和风险管理，成果评审展示，持续回顾改进，等，将一系列优秀的实践融合到一起，为建立价值驱动的高效团队，提供了一套简单清晰易行的落地框架。

二，SCRUM执行过程问题：

计划会和需求评审会有啥区别？计划会时候发现需求经常有问题，并且还会有很多问题在迭代中出现。

答：SCRUM的计划会，需要做好三个方面：

1）会前：需求梳理，确保需求达到就绪状态（满足DOR，团队约定需求的就绪标准），并且准备超过1个迭代约20%的故事数量。（故事可以包含业务需求和技术任务，约定好比例和排列好优先级）

2）会中：PO依次讲解需求，并且和团队沟通，在内容、优先级、验收标准达成一致。（如果有采用估算，则按照优先级依次放入迭代，达到团队产能上限为止）

3）会后：团队自组织讨论如何做，明确设计和执行细节，PO不需要参与。（此部分工作也可在计划会议的后半段进行）

最终形成一份具体可执行的，识别了所有依赖关系和风险的迭代计划。

站会为什么要每天开，每天重复3个问题很乏味。

答：

1）站会并不是每天开，计划会当天，不需要开。团队根据实际的需要来调整沟通频次即可，通常情况下迭代过程中，是每天开。

2）每天沟通3个问题，建议的站会方式是围绕看板上的故事卡片，从右到左的顺序，依次沟通个人相关的故事进展。

注意不要机械的沟通，而是以同步进度，披露超出个人能力之外的问题、障碍和风险，寻求协作和支持为主。

站会总体时间通常约在10分钟左右，最长不超过15分钟。如果时间过短或过长，作为SM就要反思下，是哪里出现了问题，是否合理和需要改善。

很多人说站会讲完三个问题就可以了，不要讨论。这一点我有不同的看法，没有沟通的站会，就真的是机械的3个问题了，沟通还是需要的，但是要控制沟通时间盒，例如：每个人讲解故事卡片发言后，允许短暂约20秒左右的沟通。做到这一点，团队氛围立刻会得到改善，高效且不再乏味。

评审会，业务方没空参加，时间也很紧张了，会议干脆被省掉了。

答：这通常和迭代的周期有关系，如果是单周迭代，时间确实很紧张了，评审会通常会被简化为简单的业务验收过程，可能就没有独立的评审会了。如果是双周及以上迭代，评审会将是一个很好的展示团队工作成果和业务方干系人交流获得反馈的过程，反馈意见可以进入下一个迭代，持续改善和调整。

曾经见到有些研发团队，完成了几个迭代并且交付了产品增量，但是产品功能上线后遇到需求方的强烈不满，功能不好用或者有偏差，最终导致团队被投诉的情况。如果能在每个迭代的评审会上及时沟通，也许就能改善这种情况，这是评审会议设立的初衷，也是值得我们去思考的问题。

回顾会，回顾了几次后，已经没有了热情，总是那几个问题，有什么好回顾的。

答：回顾会是给团队成员创造的一个共同沟通交流的机会，哪怕是吐吐槽，谈谈心，吃吃喝喝，也是团队情感的交流，促进了团队合作。

回顾会，最重要的是针对主要的几个问题，形成改进行动项。改进行动项，必须是经过深度讨论，团队相信是可以改善，具体可执行落地的行动，并且明确人员，时间，跟进效果。

如果有和业务和技术相关的任务，可以放入下一个迭代的待办列表。

回顾会通常在每个迭代的结尾开，俗话说：一张一弛，文武之道，让大家在紧张工作之余，能有一个简短的总结和休息的时间，也是很好的。

迭代周期如何定？版本发布怎么做？

答：迭代周期要和业务需求的变化，以及团队的持续交付能力相结合。

建议的迭代周期通常情况下是2周。如果业务需求通常需要1个月交付一次，那么迭代周期2周/4周都是合适的。如果业务变化很快，需要每周做一次交付，那么迭代周期1周是合适的。

通常的版本发布频率和迭代周期需要对齐，例如：1周发一次版本，迭代周期1周。2周发一次版本，迭代周期2周。

也可以多个迭代做一次发布，例如：4周发一次版本，迭代周期2周，即2个迭代，做一次发布。

或者迭代内，根据业务需要，做多次发布。但是一定要注意发布成本。每次发布，都涉及测试、验收和发布的过程，这些都会耗费大量成本，并且对迭代的研发工作造成一定的影响。

发布的频繁程度一方面是业务需要，另一方面是持续交付能力的体现，如果还是大量人工测试和验收过程，并且发布过程自动化程度不高，频繁发布就得不偿失了。

为什么看起来SCRUM没什么内容，落地执行却问题多多？

答：因为你对SCRUM还不够理解。SCRUM要做好，需要多看几遍SCRUM GUIDE领悟其理念和设计思想，并且在实践之中反复练习和思考改进。如果工作中更多的是机械照搬3355，过于形式化就会导致很多负面结果。

在落地SCRUM的时候，最重要的是先行动起来，先照着做，落地层面简单化，通过不断尝试和思考改善，逐步摸索出一套适合团队的做事方法。

只有在持续不断的实践之中，才能更加了解了这些KNOW HOW，经过实践和思考才能更好的掌握SCRUM。

SCRUM对很多执行细节没有定义清楚，这是为了给团队自行发挥的空间，没有完全一样的团队和环境。只有理解了SCRUM的设计理念和方法，并且持续不断的在实践中思考和改进，才能真的做好SCRUM。

我想这也是SCRUM作为一个简单的敏捷框架，为何很多人会说SCRUM简单却难以掌握，并且很多团队却难以落地执行好的原因。

三，SM的角色和发展问题：

SM一定是全职的么？

答：否，SM可以是兼职，也可以是全职，根据团队实际的需要来设定。

不建议SM耗费过多的精力，更应该营造一个好的团队氛围，让团队在轻松愉快的氛围之中做好SCRUM。

SCRUM的创始人之一的Jeff老师，在前段时间直播活动时候说过这样一句话：快乐的团队是高效的，可以让团队事半功倍。

SM对我的职业发展有什么帮助？

答：SM所具备的能力，是新时代的企业和团队组织形式对团队管理者提出的要求，是打造高效的有创造力的团队的基础。

具备了相关能力，就具备了本身职业技能之外的一种打造高效团队的能力，也使自身的职业发展更具备竞争力。

SM的发展路径是什么？

答：兼职教练，可以把相关能力成为自身职业发展的加分项。

全职教练，可以参考团队级教练，组织级教练，咨询顾问的发展路线.

如何做好需求管理，团队管理，项目管理，敏捷开发，高效团队的打造，精益创业，产品探索，以及如何让产品更加有创造力和生命力，等，这些都是敏捷教练需要深入研究的课题，也为你将来能够成就一番事业打好基础。

无论怎样，持续不断的学习知识，持续的练习和改进，你会获得终身成长。

Scrum落地关键实践

为什么你的Scrum总是难以落地？而大多数都是“形似而实非”的“敏捷Cosplay”。我们都知道，Scrum流程是简单的，那么落地的难点在哪里呢？其实是人，人是最难搞定的。所以，如何搞定形形色色的人呢？或许，你少了很多敏捷实践，帮你打通各个角色间的竖井，真正的实现价值的流动。

1.为什么你觉得Scrum难以落地？

每天都在讲Scrum，你可以徒手画出Scrum的框架图吗？那个经典的“3355”，还记得吗？不妨试试看。

思考：

1）Scrum流程本身有问题吗？

2) 若流程没问题，那么到底哪里出了问题，没什么难以落地？

3) 还记得《敏捷宣言》第一条吗？

所以是个体和互动（人）出了问题！也就是人出了问题！

很多人可能都看过甚至可以对《敏捷宣言》倒背如流。但是，你看过2001年在美国犹他州雪鸟山那次会议上，Andy Hunt 当时记录的《敏捷宣言》手稿吗？

有发现吗？从手稿上来看，4条宣言的排序上，17位敏捷大师们有过多次纠结且一定伴随了多次的讨论，但是只有第一条“个体和互动高于流程和工具”是始终排在第一位没有变动过的。所以，Scrum难以落地的根源，一定是最根本的“个体和交互”出了问题。

继续思考，如果每种角色间的交互都会形成一堵墙，Scrum会变成怎样？

是的，会形成很明显的边界，或者你可以叫做“竖井”。业务如何变成需求，需求如何传递业务，研发如何实现业务价值等，这类问题就会变得很棘手，甚至形成角色对立。

2.如何打通各个域，让价值流动起来？

上图是在IDCF训练营学习时，王立杰老师取自李涛老师原创的一个MoMoCo模型，为了更加便于理解，所以对命名进行了小小的修改。

从宏观的角度的展示了，如何利用影响地图，用户故事地图，及看板，来打通业务域到需求域再到实现域的一个框架体系，下面我们来详细的看下。

在这里不得不的提到一个非常牛X的法则——黄金圈法则！

扩展一下：

1）什么是黄金圈？

很简单，三个同心圆，最里面的一个是Why，中间一层是How，最外面一层是What。

2）什么是黄金圈法则？

举个例子，比如一般的电脑公司的市场营销会这么做：我们做了最好的电脑(What)，我们的产品设计很好，使用简单（How）。接着会问：怎么样，你想买一台吗？典型的从外向内的交流和沟通的方式，也是大多数市场推广的方式。上来先告诉你我们是干什么的，我们是怎么不一样，然后期待着别人的反应。但其实这种沟通的方式是很低效的。

我们再来看一看，用黄金圈法则的苹果公司，他们是怎么做的？首先告诉你，我们做的每一件事都是为了创新和突破，我们坚信应该以不同的方式来思考（Why)，接着我们挑战现状的方式是将产品设计的十分精美，使用简单并且界面友好（How）。最后再告诉你，我们顺便也就做出了一台最好的电脑、最好的Iphone（What）。你想来一台吗？

其实这种逆向思维的真相在于：要想最大程度影响他人，最关键的不在于传递“是什么”的信息，而在于给出“为什么”的理由

大量的事实已经证明，人们在决定购买的时候，买的并不是产品，而是在为你的信念和宗旨在买单。因为认同，所以买单。不是你把产品卖给了需要产品的人，而是卖给了跟你有相同理念的人。你看看苹果出新品的时候，那些彻夜不眠排队的大军，就是认同的人。

为什么要提到这个黄金圈法则呢，因为他和我们接下来提到的影响地图（Impact Mapping）很像，而且和OKR的原理也有像，都是从Why出发，聚焦目标价值。

再聊回我们在业务域上碰到的问题，看一看影响地图在其中是如何发挥作用的。

如果你还不了解“影响地图”，那么你可以建议大家去看看上面推荐的那本书。这里不做赘述。或者你对它感兴趣，可以留言，如果感兴趣的人多，我会做个专题分享。

总结下：有的产品，它还活着，其实已经死了；还有的产品，还没发布，就已经已经被判死刑。太多的产品失败的案例，源于方向性错误，基于错误的假设，功能与业务目标/价值之间缺乏必然的关联与一致性，在做的事与期望的目标南辕北辙。而影响地图（Impact Mapping）就是这样一种试图通过结构化、可视化、协作化的方式来从源头解决上述问题的工程实践。

首选要弄清楚什么是需求？很多时候，我们从源头就搞错了，结果后面肯定是一错再错！

需求就是客户想从你这里获得的 价值服务，但不一定是他说的那样！

所以，我们一定要避免把用户描述的他想要的功能或解决方案当作需求记录下来，这样很危险！

其一，用户可能描述不清楚，掩盖了价值的本意；

其二，用户不了解现有技术架构，所以可能提出了不适宜的解决方案，以至于实现成本很高。

比如：用户说，我要一座桥。产品把这个当作需求记录下来，然后叫研发去做。过了N久，用户一催再催之下终于交付了，可是用户已经不需要了，因为他已经租了一条船，早早的过河去了。从这个例子中，我们可以看到，用户的需求到底是什么？其实就是——尽早的过河。

学会，多问几个Why，直到问到和用户切身利益相关为止。想了解更多，访问《6 Success Questions You Must Ask》：https://www.slideshare.net/AndreasVonderHeydt/6-success-questions-you-must-ask