从5个会议入手，聊聊Scrum敏捷开发实战

加关注，带你看世界

笔者介绍了Scrum敏捷开发模式应该包含的五个会议及内容，并举例说明了该如何解决迭代中遇到的问题。

一、开发模式

我们团队用的是Scrum敏捷开发模式，这个模式的优点是：比传统的瀑布式开发灵活，但是对于团队中每个人的要求又比较高。

Scrum中有三个角色，分别由PO、Scrum Master、项目成员组成。那我在这边就是Product Owner的角色，也就是项目的负责人。

一般产品经理在需求分析、确定需求之后可能就开始做原型设计和写PRD文档了。但是在这个开发模式下，我是不写PRD文档的，我会把所有想法体现在原型上，再加上相应的备注，如果说开发人员遇到问题就会找到我问清需求。因为Scrum的最关键的点就是多沟通，用沟通来替代文档。

当然，如果在开发的时候直接扔个原型给开发，那他们肯定一脸懵逼然后想把你打一顿。

为了产品经理的人身安全，所以这就涉及到我接下来要说的Scrum五个会议：由需求澄清会、计划分析会、站立会、评审会和回顾会组成。

1. 需求澄清会

顾名思义，就是澄清需求，但是人家就会问了，你没有PRD你澄清什么需求。

对的，我准备的是User Story，也就是用户故事：如果说我是这个产品的用户，我要实现什么功能。

这边的功能描述可能就是“我想要有XXX增删改查的功能”而不是详细到“我的提交按钮要放在哪里”。

简单点说，就是这个用户故事是有一定的颗粒度的，但是它在所有产品的设计者、开发者和使用者的理解下是没有歧义的。只要我们大家都确定了，我们要做的就是这样的一个东西那就没有问题。

因为用户故事都比较多，我们一般会把用户故事排一下优先级，然后根据优先级把用户故事分成几次sprint来做，就是不断地迭代。每次迭代的周期很短，一般是一周或者是两周，还有迭代出来的一定是一个可以使用的产品，可能功能有点缺陷，但一定是可以正常使用的产品。

2. 计划分析会

计划分析会，就是根据原型还有用户故事分task。

这个会议一般由SM来主持，当然这里的SM不是你想的那个SM。

因为之前已经开过需求澄清会了，开发人员也知道了需要开发什么样的产品，这时候就可以根据每个用户故事对着原型分任务了。

需要注意的是：这里的每个任务都是开发人员自己分给自己的，比如：后端开发看到这个页面，需要写几个接口，每个接口大概需要多少小时，需要前端人员如何配合，这都是需要在这个会议搞清楚。所以为了后续的正常开发，这个会议一般都会比较长，大概需要4-5个小时左右。

3. 站立会

这个是每天都需要开的会议，每个项目成员都说一下自己昨天做了什么工作、今天做了什么工作。

这个会议的话主要是前端开发和后端开发之前的互相配合，就是为了避免前端已经撸好了一个界面但是没有接口对的尴尬情况。

4. 评审会

主要是进行本次迭代的功能评审，对照用户故事，我们是不是已经完成了这几个用户故事所说的内容。

5. 回顾会

分析这次迭代我们团队有什么优点、有什么缺点、可以怎样改进，产出对应的改进措施。

敏捷宣言：个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。

二、第一次迭代遇到的问题及改进方案

1. Task漏项

在第一次使用该模式开发的时候，遇到的最大问题就是task漏项。这说明了我们在开计划会的时候并没有把task分好，缺乏沟通可能是导致这个问题的主要原因。

解决问题的方案就是：我们的前端和后端在领取task的时候需要考虑任务的优先级，先做哪个后做哪个，多沟通。

如果说有某个task工作量大于8小时的话，我们建议将这个task再细分，尽量做到每个task的工作量都在一天之内，这样把task分得更细的方法也是可以避免task漏项的。毕竟在开发的时候发现漏task了，那只能是通过加班来解决了。

2. 接口文档未及时更新

这个锅直接甩给了后端开发小哥。当然解决方案就是接口文档及时更新和署名。

3. 用户故事漏项，原型不够细致

当然，迭代出问题，PO也是要背锅的。

在没有详细的PRD文档的情况下，原型成为了开发人员的主要参考对象。如果用户故事漏项并且原型画得不清不楚的话，导致的问题就是开发人员无法开发。

即使我们使用的是敏捷开发模式，核心就是沟通，但是这也会大大大大增加了沟通成本。

所以，对用户故事的把控、对原型设计的理解还有对业务流程的思考应该算是对刚使用敏捷模式的产品经理最大的挑战。

4. 测试不规范

在没有测试人员的情况下，产品经理就是项目中最好的测试。

其实，这样子说并不是最准确的，产品经理应该把控住测试的最后一道关卡，而不是在开发人员开发完一个模块还未自测的情况下就把这个模块丢给你测。这样不仅增加了产品经理的工作量，还可能会导致项目延期。

所以说，敏捷模式其实非常考验每个人在整个团队中的能力的。

5. 在sprint之前未确认好资源

像我们初创的小团队，我们不仅没有测试，也没有UI。如果我们需要UI的话就需要向外部申请资源，要是我们在迭代之前未考虑到这点，那我们的页面做出来有可能真的会不忍直视。

三、总结

作为一个刚出生不久的产品经理，我对于敏捷的理解还是在持续的工作中不断加深的，从最开始Mike Cohn的《用户故事与敏捷方法》一书中了解到的理论内容，再到实际开发中的一点点实践，敏捷的思想也在慢慢成长。

#声明#