产品经理如何用Scrum敏捷开发带领团队

加入人人都是产品经理【起点学院】产品经理实战训练营，BAT产品总监手把手带你学产品

前段时间，我们发现开发过程有些混乱并且不容易管理。为了团队更好的协作，我们在顾问的引导下，开始尝试使用Scrum敏捷开发。（Scrum相对官方的资料，附在文章最后）

几轮Sprint下来，有点个人体会，和大家share之。立场当然是是不褒不贬，纯客观描述啦！不过，每个团队情况不一致；因此，这个“客观”针对的是我们团队。啊哈~

首先，Scrum的官方流程如下：

我们的Scrum流程如下：

接下来会详细讲解每个步骤中应当注意的点：

开发前：

阐述&调整需求：

产品要在这之前需要考虑清楚每个需求的逻辑、页面交互展示，不然在这一步就会造成很多讨论，延长开会时长，影响效果。至于如何思考清楚内在逻辑，有多钟方法，这又是一个topic；

对于优先级的确认，一定要明确，这是后面实现的先后基础；

如果程序猿们对某个需求逻辑提出质疑的话，最好不要太任由发散讨论，能立刻调整的，那么就调整；不能立刻确认调整的，先保留，然后在真正开发前要确认；

如果产品汪在阐述需求的同时，开发人员们开始相互沟通如何实现的问题，那么建议开发们先听完所有内容，在后面的需求分解中再进行详细讨论，不然在需求源头错过就容易有需求上的认知偏差；

需求分解为任务：

小团队没有项目经理的情况下，建议项目负责人（Scrum Master）是经验比较丰富的技术人，这样对项目进度比较容易有把控，同时对需求的分解以及后期的追踪会有很大的帮助；

要强化需求追踪人（Owner）追踪需求的意识，不要流于形式：有个这么个角色，但是并没有发挥作用这种情况。owner的存在可以分担SM的责任的同时让开发人员之间关联性更强，因为一般某个需求会同时涉及到前端、后端、API、移动端，让开发去推动开发；

开发人员们要适当把需求拆的细一些，这样在拆的过程中更容易吃透需求、理清逻辑，发现逻辑上的问题。针对需求，相关的人进行技术讨论，有疑问的地方要及时和产品这边沟通，问题越早发现越好。最后，要把每个任务对应的人以及需要的完成时间都记录下来。

有关于时间预估问题，我暂时还不知道哪种方法比较好。在文末最后有个敏捷估算的方法，乃们可以参考看看。

在拆分的过程中，SM最好能够根据需求的难易程度，进行辅助沟通。这样，能够相对避免因为具体代码人员因为经验/能力不够而导致的拆分、预估问题；

产品汪要在讨论过程中，时刻穿插在其中，尽量保证需求理解的正确性；

确认该期目标：

• 完整过一遍每个需求的分解情况，看是否有遗漏或者误差，有疑问即刻提；
• 必须按照需求的优先级来确认目标；
• 要明确目标，确认哪些一定要做完（这里有个argue/挖坑的地方，会在下文“开发中”-“3其他”-2中进行描述）；

开发中：

有关中期会议：

一定要在一期sprint的中间进行进度回顾和确认，如果进度偏差很大的话，要适当的调整目标，以免最终跟预期相差太大；

中期的时候，可以check下人力分配，如果有相对空闲，那么可以再安排一些任务。看不同情况，是安排产品线的新任务还是基础建设任务或是代码优化任务等等；

有关测试：

在开发过程中，建议开发完一个功能就跟进一个功能的测试，以免最终测试任务都堆积起来；

提测可以在项目结束的前2-3天开始，这样可以保证有足够的时间进行修正；

如果功能和业务强关联，可以让业务人员在提测阶段使用测试版本，一起发现问题；

开发人员在开发新功能过程中，可能会遇到之前存在的bug或者突然发现了之前没发现的bug，这时候应该要告诉测试人员跟进，而不是自己直接修掉。因为你以为的修掉并不一定真正没问题，一定要进行回测，同时留下记录，可能会给以后的追溯带来帮助；

其他：

团队每天开站会，目的在于描述自己的进度情况。一定要明确！要明确！要明确！如果不明确表述，其实等于没有开站会；

在适应新开发流程的初期，SM最好能够每天or每两天确认下组员们的真实开发情况，包括进度and需求理解上；

一开始尝试Scrum敏捷开发时，容易预估（目标、时间）不准确，导致2周一个迭代版本比较困难，可能会经常延迟。面对这种情况，我目前是倾向砍掉部分需求，先满足2周一个版本，让团队先形成这么一个周期惯性，再去优化惯性内的效率问题（也就是之后再提高目标的要求)；

Scrum要求是：

1. 目标、质量验收标准不能改变；
2. 完成目标的要求不能过低；（文末有相关资料）

关于如何解决这个问题，也还在摸索状态 T_T，大家如果有好的建议和想法，求沟通呀~

开发后：

1. 组员们要一定总结下这期开发中存在哪些问题，如何解决或者减弱这些问题的影响，不要流于形式。毕竟对团队来说，这是新的开发流程，不适应或者做的不好很正常，不要怕说不要的地方，大家在错误中磨合、改善、成长才是最重要的；
2. 结合上一点，每期也要对上期提出来的问题进行回顾，看在这期中是否有改善这个问题。只记录不回顾，等于什么都没干；

以上，是目前的一些体会和总结，希望在不断实践中，能够得到新的解决方法和体会...

最后附Scrum的官方资料:

什么是Scrum？

Scrum团队的三个角色？

Scrum的三个工件？

Scrum的五个活动？

敏捷估算？

sprint？

每日站会？

完成的“定义”？

本文由华尔街见闻产品经理 @梁露瑶（微信公众号killifer） 原创发布于人人都是产品经理 ，未经许可，禁止转载。