scrum回顾_极简敏捷：解析SCRUM落地常见问题

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

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

一，概念性问题：

1. SCRUM就是敏捷么？

2. SCRUM就是开各种会么？

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

二，SCRUM执行过程问题：

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

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

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

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

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

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

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

1. SM一定是全职的么？

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

3. SM的发展路径是什么？

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

一，概念性问题：

1. SCRUM就是敏捷么？

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

2. SCRUM就是开各种会么？

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

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

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

二，SCRUM执行过程问题：

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

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

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

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

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

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

2. 站会为什么要每天开，每天重复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的角色和发展问题：

1. SM一定是全职的么？

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

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

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

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

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

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

3. SM的发展路径是什么？

   答：兼职教练，可以把相关能力成为自身职业发展的加分项。全职教练，可以参考 团队级教练，组织级教练，咨询顾问的发展路线.如何做好需求管理，团队管理，项目管理，敏捷开发，高效团队的打造，精益创业，产品探索，以及如何让产品更加有创造力和生命力，等，这些都是敏捷教练需要深入研究的课题，也为你将来能够成就一番事业打好基础。

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