Scrum事件预告

上篇我们已经对Scrum整体的运作框架进行了整体性的阐述，相信大家对Scrum也有了一定的认识。接下来的时间，笔者将围绕着Scrum中的4个事件对Scrum的玩法进行更详细的介绍与分享。这期只是预告性文章，具体内容不会探讨过深的见解，大家可持续关注笔者后续的文章。

Scrum是一个轻量的框架，它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织创造价值，即尽早持续、频繁的交付增量价值。

在Scrum框架中，针对不同的团队，我们可以使用不同的过程、技术和方法。业界常说的Scrum3组件、4事件是由一批前沿的经验主义者们总结出来的，前辈们将自己在实践过程中的经验包装成延续至今的可行方法论。就如同“迭代”这个词本身而言，Scrum方法论也是历经了漫长的岁月沉淀和无数次的迭代更新，所以我们无需对方法论的可行性和能带来的价值产生过多的怀疑。我们需要做的是如何精读Scrum精髓并将其运行在我们的每一个敏捷团队中。

Scrum的三个支柱：透明、检视和适应。

Scrum基于经验主义和精益思维。经验主义主张知识源自实际经验以及根据当前观察到的事物做出的判断所获得。精益的思维即减少浪费，专注于根本。 

Scrum用一种迭代和增量的方式优化未来的预测性并控制风险。

Scrum事件：

Sprint是所有Scrum事件的容器。Scrum中的每个事件都是检视和适应Scrum工作的手段，这些事件都是为了实现所需的透明度而特别设计的。未能按规定运作任何事件将会导致失去检视和适应的机会。Scrum使用事件创造团队的规律性和节奏感。

Scrum迭代中的事件可分为：需求梳理会、迭代计划会、日常站会、迭代评审会、迭代回顾会（需求梳理会和迭代计划会的目标是确定Sprint goal，即Sprint Planning）。大家可以根据组织或者敏捷团队的实际运作情况，合理的裁剪和合并，以消除浪费。因为我们的目标是在实践中寻找一种适合组织的软件开发方式，提高组织的研发效能，更快的为企业客户提供最大的交付价值。

Sprint Planning

Sprint Planning，即迭代计划会，该事件的主要目的是确定本次迭代要实现哪些用户故事。它发生在每个迭代开始之前，Sprint Planning会议通常分为两个阶段：第一阶段聚焦于决定哪些产品待办事项（Product Backlog）将被纳入本次Sprint（上面我们讲到的需求梳理会），第二阶段则结合团队资源日历、成员水平等因素考量团队能实现哪些用户故事及如何实现这些用户故事。

通过Sprint Planning，团队可以确保每个迭代都有一个清晰明确的迭代目标和可行计划，从而提高工作效率和质量，最终实现更高质量和更快速交付软件的目的。

Daily Scrum

站会，也被称为每日站立会议，是敏捷软件开发中一种短暂且频繁的团队会议。它的主要目的是保持团队成员之间的沟通、协作和同步，确保每个人都知道项目的最新进展，识别并解决问题。站会通常在每个工作日的固定时间举行，时间控制在15分钟左右，以避免占用过多的工作时间。 

注：这是教科书提倡的做法，敏捷团队前期可按照这种方式来做，后期可自行裁剪。 

Sprint Review

Sprint Review，即迭代评审，它通常在每一个迭代周期（Sprint）结束时进行。该活动的核心目的是展示团队在迭代期间完成的工作，并向利益相关者收集反馈。迭代评审会不仅能够作为一个展示成果的平台，还能成为促进团队学习和持续改进的重要环节。

Sprint Retrospective 

Retrospective Meeting，即迭代回顾会议，是敏捷开发中一个至关重要的会议，它帮助研发团队回顾和改善开发流程，实现持续过程改进。在Scrum框架中，迭代回顾会议是PDCA（计划-执行-检查-行动）循环的关键一环，它允许团队从过去的迭代中学习，并对未来的工作进行改进。 

闲聊篇

按照教科书说，为减少运作的复杂性，尽量所有的时间都在同一时间同一地点举行。笔者想说，如果以结果为导向，前期可以按照教科书式去运作，在组织间建立迭代的节奏，后期任何事件任何地点均可。不要拘泥于形式，sprint goal达成即可。但是敏捷教练们一定要在日常的scrum运作中，检视组织的实践过程，勤于思考，勤于记录，用运作数据做组织间的横向分享和方法论的复用，即持续的过程改进、全局优化。 

谨记，打开格局，打开思考的维度，4大事件最本质的目的是通过sprint goal实现product goal，最终实现产品价值的交付。别忘了前辈们做这件事的初衷也是提高组织效能。 

注：4个Scrum事件笔者可能不会严格按照顺序分享，在实际实践工作中，如果笔者对哪一部分产生极大的创作灵感了，笔者就会对这一部分进行创作分享。精力有限，敬请谅解。