今天要给大家介绍的是很多产品经理都会用到的敏捷软件开发方法又叫做按照消费指标表明，那么我的重点会介绍其中一种流程叫做scrum，我们会讲到具体有谁参与 scrum和怎么参与scrum呢？

所以敏捷软件开发方式相对于比较传统的软件开发方式可以说是有两大目标，第一个是它非常注重人与人之间的互动，第二个则是我们能够缩短提交软件的一个周期，敏捷开发方式中又属scrum，流程最有名，我自己在开发产品的时候也是用scrum流程，这个流程是在90年代有两名工程师Ken Schwaberr和Jeff Sutherland文所发表的，如果你有兴趣的话，你也不用拍什么书，只要直接在Google上面查the scrum Guide，你就可以看到他们两个的手稿，其实很简单的PDF，最近的更新是在2016年，我今天分享的流程也就是以他们的手稿作为基础。

好了，要在介绍之前当然要把今天的内容列个表，第一点我们会讲到 scrum团队，第二点则是希望团队的价值观。第三点我们会讲到scrum流程和环节，最后我会分享一下我个人用strong的心得。那么下面我就先来介绍一下scrum团队的组成，一般来说scrum团队有三种角色，第一个就是开发团队又称作development team，请你们其实就是工程师，他们的工作是把软件从设计变为现实，他扮演的是科技专家的角色，他们会决定说一以上产品我们做出来吗？怎么做，然后把它实现出来。

第二个角色就是产品负责人product owner,其实就是产品经理，我们之前也讲过产品经理的职责，在这个团队里面产品经理会决定说我们要研发的产品我们要做什么时候做，然后交给开发团队，最后一个角色是scrum master，也就是这个流程的主管人，我感觉要解释的话，它像是一个比较运营走向的角色，像是这个流程的一个主持人，我们下面就讲到scrum流程的环节，那么scrum master就是确保这些环节能够正确的顺利的进行，那么在我的经验里面，scrum master通常是由比较资深的工程师去担任，不过我也听说过产品经理或者工程师经理有的时候也会担任这个角色。

Amazon创办人Jeff Bezos有一个著名的two pizza rule，意思就是说如果一个团队不能用两个大的披萨喂饱的话，人就太多了，在scrum团队里面也是适用的。一个双团队大小一般来说是3~8人，如果过小的话，在短时间内要提交软件会很困难，不过如果大的话则是很难确保与少女的互动，因为大家都有意见，人会太多。

接下来我想讲的是scrum团队的价值观，我觉得当我们理解了scrum团队应有的价值观以后，就很容易懂得说为什么scrum流程是这样子设计的。在Jack和count你的手稿里面描述了5个核心的价值观，第一个是commitment，也就是承诺，第二个courage勇气，第三个focus专注，第四个openness也就是开放，最后一个就是respect尊重。在这里所宣扬的态度就是在双流程里面，我们每一个人都要把自己承诺的事情在承诺的时间里面做好，我们要接受别人的观点，也要勇于提出自己的观点，才能够共同的把产品做到最好。

那么下面让我们一起来看看创流程里面有什么环节。首先每一个环节都有它的时间限制，我要先定义一下冲刺的概念，冲刺 sprint它代表的就是希望流程的一个时间单位，sprint的长度你可以自己定义，不过我的经验一般来说都是两个礼拜，也就是说每两个礼拜我们要跑一次希望的所有流程，目标则是每两个礼拜团队就可以完成一些新的东西，而在每一个冲刺里面又会有以下的环节。

第一个环节是冲刺计划叫做sprint planning，在每个冲刺的一开始，产品经理和开发团队会决定说我们冲刺要完成几件产品要开发的事项，其实开发的事项又称为用户故事，user story，用户故事的优先顺序一般是由产品经理来决定的，而能完成几个用户故事则会由开发团队去决定。

第二个流程则是代办清单的一个梳理，就会叫做product backlog、refinement或是grooming，这里产品经理和开发团队会花时间去讨论说我们近期要做的产品的一个商业价值，技术的可行性。

在这个过程里面，整个团队对于该不该完成某个用户故事，怎么完成这个用户故事，会达到一个统一的认识，可以说是一个去无存金的过程。也在这个时候开发团队会预估每一个用户故事需要多久才能完成。那么创意原则是说每一个用户故事你不能超过一个工程师在一个冲刺里面所能完成的难度。如果有一个用户故事过于大，那产品经理就会把它拆成几个。

第三个流程则是每日的站立会议，也就是定时间的，这就是我一开始说的工程师，产品经理每天早上在圈圈互相汇报，互相问题，这样子每一天每一个人都能够掌握到最及时的资讯，避免资讯不同步，造成补仓效应的危险。补仓上inside在我们之前的专案经理产品经理的话题上面也有解释过，你可能觉得我们为什么要这样子，这也是为了确保大家能够保持专心讲重点，因为这样他就很累。

还有一点就是每天汇报以更加深成人们的一个责任。下面一个流程则是冲刺结构展示，sprint review也就是说两个礼拜的冲刺结束了，开发团队会在置业的时候展示软体的开发成果，这个流程反映了敏捷开发的重要目标，那就是我们要缩短软件提交的周期。这样的好处是说对用户来说软件实时在改善，而对于开发团队来说也可以及时的得到反馈，而不会在一个项目里面埋头苦干，很就就发现方向错的。

最后一个环节就是冲刺回顾，也就是sprint retrospect在这个结果展示结束以后，跟他团队会根据这两个礼拜来做一个回顾。它的意义是说我们要有意识的不断改善团队合作的能力，在这个会议里面大家会提出团队在冲刺里面哪里做的不错，哪里可能做的不是那么好，这又反映了敏捷开发里面运营的目标，就是我们注重人与人之间的互动，可以使团队的合作变得更好。

好的，以上就是希望主要的成员和流程。当然了上面还有其他的细节和术语，我们可以分子来讲，如果感觉做一个产品经理，因为学习送流程蛮快的，不需要花什么时间，但是我说没有什么优点的发挥出来，就没有那么简单了。我觉得做一个产品经理，你的目的性一定要很明确，而且要注重和工程师之间的协调和相互理解。在这里我想简单分享一下这几年来使用scrum流程的一个心情，最重要的就是不要忽略了台上一分钟需要台下的十年功。我记得刚开始当产品经理的时候，我那时候想 sprint planning冲刺计划会议一定是最重要的，我那个时候理想或者是幻想好了，是说工程师看着我提出的用户故事，你可以了然于心。

我还说我还说，然后大家一下子就分配好了，然后大家分头就开始做事情，可是一开始完全不是这个样子，在冲刺计划会议上面，工程师总是不明白我提出的要求，结果我们花很多时间去解释，通常两个小时过去了，大家还是觉得冲刺到底要完成什么，还是没有共识。在那个时候大家就会开始饿累要热会议就曹操结束了。这倒是有一段时间，我有点怕主持冲刺计划会议，因为我感觉很没效率很累，然后常常觉得是不是我哪里做的不够好，是蛮挫折的，直到后来我发现要做出好的产品也没有捷径。

如果我想在计划会议的时候，大家已经理解一致该做什么的话，在之前一定要肯花功夫在梳理问题上面，也就是我们刚刚讲到的一个梳理代办清单的流程上面，因为在梳理的过程其实是要帮团队去理清几个问题，第一个问题我们为什么要做这个功能？接下来是这个功能该怎么完成？

第三个问题要做好这个功能，我们要和谁合作？接下来这个功能要为用户所喜爱，是不是还要配上其他的功能等等的问题，只有我们理清了这些问题以后，你的团队才会有能力去预估完成某一个功能最好的方式是什么和需要的资源。是什么？

我才发现难怪之前计划会议这么困难，是因为大家都还没准备好，所以我现在很愿意在梳理代班，清单上面花时间，所以你说敏捷开发方法总是比较快，不见得要实时能够给scrum流程做好准备，也是给产品经理提出了一定的要求，其实它的好处是给你的开发团队一个既定的模式，让大家在长期合作中能够规律的去维持一个我们要持续沟通持续提高的意识。这样子长期做下去，即便有新的工程师加入或是产品经理换了，团队还是可以尽量的不受干扰，维持不断推出新产品的一个模式。好了，如果对今天主题任何问题和想法，欢迎和我们留言。