时间: 2021-07-30 09:49:40 人气: 4 评论: 0
团队引入Scrum的初期，**有一个常见的现象，就是成员们发现开的**变多了，自己安静开发写代码的时间变少了。在这篇文章中，我尝试基于自己曾经参与和指导过的Scrum团队阐述一下这些**议的意义，以及如何规划并且让团队更好地执行Scrum**议。
标准的Scrum流程包含了四个类型的**议，即Sprint Plan、Daily Scrum、Sprint Review和Sprint Retrospective。首先我们要知道，Scrum是敏捷开发的一种实践，它自然也遵循敏捷开发原则。它的目标是交付可使用的软件，所以上面提到的这些**议都对这个目标有着直接的帮助。
Sprint Plan**议主要是计划当前迭代的工作内容做计划。和传统开发流程里面项目例**或者启动**不同，Sprint Plan着重于Product Owner 和Dev Team的交流和互动。通过Product Owner的讲解，Dev Team的理解和提问，整个团队对于每一个Work Item最终都**达成充分一致，同时对于每一个Work Item的工作难度、涉及范围、可出现的问题和潜在的难点都**有充分的预判。最终在这个基础上，团队对Work Item的工作量（复杂度）进行打分。这些**上工作看似耗时，但是它的作用是把开发中可能遇到的问题提前暴露。如果以整个Sprint周期来衡量，这种充分的沟通能缩短开发时间，而且最大限度的规避了开发中出现问题的风险。所以Sprint Plan**议占用的时间是完全有意义且必要的。
Daily Scrum作为每天都**进行的**议，主要保证了团队成员充分的沟通。虽然时长较短，但是因为它需要每个成员介绍自己当天的工作内容、第二天的工作计划以及目前的困难，从流程上确保了大家必须提前安排好自己的工作。而且这个**议也能督促没有工作的成员主动领取任务。
Sprint Review作为团队工作的验收，要求成员通过现场演示的方式展示自己的成果。这种验收方式践行了敏捷宣言中“可工作的软件高于详尽的文档”。Product Owner作为最终用户的代表，基于实际可演示（可工作）的软件进行验收。
Sprint Retrospective作为对当前Sprint的总结，看似和产品开发无关，其实在某种意义上可以说是最重要的**议。敏捷的原则就是在实践中不断总结和改进。Sprint Retrospective**议就是专门为团队总结Scrum执行过程的问题而设立的。
对于一个新成立或者刚开始实践Scrum的团队，建议在第一次Sprint Plan或者启动**的时候对上述Scrum各种**议的作用和意义有一个简单介绍，尽量让团队成员认识到它们的重要性，从而最大限度的避免对**议的抵触情绪。
当然，仅仅了解**议的重要性还不够。为了保证**议高效而有序的进行，需要在**前、**中以及**后做很多工作，让团队切实感受到重要性。接下来我们针对不同类型的**议简单介绍一下如何执行的。
Sprint Plan**议最主要的就是讨论和评估Product Backlog里面的Work Item。首先，Product Owner需要在平时就注意维护好Product Backlog，即保证Backlog里面的Work Item都反映了最新的需求，内容具体明确，优先级合理。
其次，在开始Sprint Plan**议前，Product Owner需要预先对需要讨论的Work Item在进行一次梳理。必要的时候，可以和团队的技术骨干或者主要开发人员事先沟通。这样的好处是，在Sprint Plan**议中，团队针对每个Work Item的讨论更加高效，避免**上花大量时间思考和讨论具体的需求细节。
另外，Sprint Plan**议还有一个可能引起拖延的问题就是对Work Item的打分。在标准的Scrum流程中，团队成员需要根据自己对Work Item的理解，在不被其他成员影响的情况下独立打分，然后针对不同的分数进行讨论，直到达成一致为止。但是实际情况往往是，团队成员由于各自的专业技能不同、知识面不同、能力不同，打出的分数各不相同。或者由于一些技术细节，导致几名成员讨论的时候各不相让。最终导致一个Work Item迟迟无法确定Effort。虽然充分的讨论有助于提前发现问题和规避风险，但是这种过于陷入细节的争论却不利于**议的进程。因此可借鉴的做法是，在对Work Item打分的时候，选一个对此任务最为熟悉的成员打一个基准分，然后大家针对这个基准分投票。如果有不同意见再讨论。
最后，当团队工作量已经饱和后，**上来说Sprint Plan**议就结束了。但是为了应对估算误差导致Sprint后期没有任务可做的情况，可以适当多估算几个Work Item作为备用。
Daily Scrum**议相对简单，因此只需要注意成员在发言的时候避免几个人过多的讨论细节，导致**议无限期延长的情况。一旦出现这种情况，Scrum Master需要及时制止。
另外，有的团队因为Product Owner参与多个Scrum团队，或者Product Owner和Dev Team距离较远（地理位置、时差），导致无法每次都参与Daily Scrum。为此可以考虑Dev Team的一个成员作为Product Owner Agent，临时代理Product Owner的职责。对于相对简单的需求问题可以直接决定，而对于那些不好判断的问题则在**后单独和Product Owner沟通。而这个Product Owner Agent的人选建议从测试人员中寻找，因为在Dev Team中测试人员对于需求的理解和把握是相对准确且中立的。
Sprint Review一定要保证每一个Work Item都是以演示的形式进行验收。对于功能性的Work Item，演示起来相对比较好实现。而对于那些非功能性Work Item，比如架构设计、技术调研、可行性分析等，则看上去很难演示。对此，一般的做法是，对于架构设计，通常在Work Item分解到Task的时候就包含和设计、评审、更新三个部分。而在评审部分，团队成员和相关技术专家已经Review过设计，并且在后续的更新环节针对评审结果做了修改。因此在最终的Sprint Review**议可以直接略过，或者简单介绍一下评审结果。对于技术调研和可行性分析，则需要在Sprint Review**议上演示调研分析的成果，譬如例子程序、测试报告、分析报告等。总之，Sprint Review**议里面要求的演示并不仅仅指狭义的界面操作，也可以是文档、例子、报告等一切能够展示工作结果的东西。
Sprint Review的演示不宜过长，一般控制在每个5分钟之内，这就要求每个Work Item的负责人在**前准备好自己的演示环境和步骤。有一个可行的做法，就是在**前每个成员都在自己的测试环境准备好演示要用到的场景，**议开始后轮流接入投影仪演示。对于一些比较耗时或者操作等待时间很长的演示，也可以实现通过屏幕录像的方式进行演示。这么做可以让成员在演示前细心准备，也就是进行必要的测试。而进一步的，能够让团队在开发过程中就对自己负责的Work Item的质量进行持续关注。
Sprint Retrospective**议是对Sprint流程的总结**，因此需要注意不要成为对Sprint结果，或者对于团队成员的总结**。Retrospective经常**变成成员的批评与自我批评**议，这其实是不对的，需要Scrum Master特别注意。Scrum倡导的是团队而非个人，因此Retrospective总结的也是团队而非个人。
鉴于东方人大多比较含蓄和内敛，Retrospective也有可能变成无声静默**议。这时候需要Scrum Master在**议前就能总结出一些待改进的事项，**上带头提出，引导其他成员参与。或者采取轮流发言的机制，强制每个成员都要参与。但是无论什么手段，都要确保对流程不对结果，对事不对人。
最后，为了防止Retrospective只抱怨不解决，**议记录需要明确提出来的每个问题的提出者、内容、解决方案、负责人和截止时间。在下一次Retrospective**议中，Scrum Master可以先汇报上次Retrospective**议的记录以及解决结果。这样做的好处是用实际行动表明成员提出的每一个改进建议都是被重视被落实的，鼓励大家继续提出问题并改进。同时要指出，对于解决结果来说，某个问题最终没能解决也是一种可接受结果。
准时参**
– **议开始前5分钟之前，可以申请迟到。
– **议开始后5分钟内到场，不算迟到。
– **议开始后5分钟之后，算迟到。
– 每一个迟到的成员需要给团队发红包或请吃零食等。
发言权
– 只有对项目有直接贡献的成员可以发言
准时结束
– 绝不拖堂
– 未讨论的内容另行组织**议
**议记录
– 除Daily Scrum外，所有**议均保存**议记录，使用统一模板
– **议记录包括：时间、参**人、议题、决议、负责人和截止时间。
Scrum流程中，各种**议是其主要的组成部分，也是推进Scrum进行的基础。确保这些**议有序高效的进行是能否成功开展Scrum的关键。因此团队，特别是Scrum Master要对此给予足够的重视。
上面提到的一些原则、经验和流程仅仅是基于我之前参与过的Scrum项目总结而来的。而实际上，Scrum团队各不相同，**议的内容、进程和安排也不**完全一样。这需要整个团队不断地尝试、磨合、改进。最重要的，确保**议的讨论是有意义的，是得到团队认可的，才能最终达到目的。
袁林，人人都是产品经理专栏作家。分享SaaS运营和企业管理／协作／办公的相关知识
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Pexels ，基于 CC0 协议
