针对互联网从业者，软件开发流程是团队协作的主要方式，合适的流程协作不仅能大大提高效率更能提高产品效能。相比较于传统的开发流程，目前比较流行的应该就是scrum敏捷开发。

大家去网上搜敏捷开发一定能搜到很多关于敏捷开发的定义以及做法，但从理论过渡到实践却不是一蹴而就的。今天我们不聊那些比较理论的论点，但就当下红尘在用的一套敏捷开发流程分享给大家。

再说敏捷开发流程之前，我们先看一下常规的研发流程，我问了身边一些朋友，基本还是比较常规的。

相比较于传统开发流程，敏捷开发以小而快为特点。一般来说，2-4个礼拜为一个迭代周期，在这个时间周期下，产品与研发团队的协作非常重要，我们看一下大体流程。

可以看到，其实大体的流程和常规的没有太大的差异。最主要的区别在于需求的做法以及版本发布的管理，同时敏捷开发团队一般会有一个主控人，在大多数公司一般是产品人员担任。

先说说需求工作，对于敏捷开发来说，所有需求尽量不要以传统的原型+说明给予开发。因为时间以及质量的管控，所有需求尽量做到可以量化且明确，目前红尘主要用的方法就是写ac。

ac主要是用前置条件、实际情景、预期结果的三步骤来明确需求。一个迭代具体要做哪些需求，所有ac会清晰的列在开发管理系统中。例如：

这样描述方式最大的特点其实就是清晰，而且比较于PRD最大的好处就是开发看起来会比较舒服也不会遗漏需求。

此处开发与产品人员开会有一个开卡的步骤，就是在需求研发前，开发测试会和产品人员再次确认需求以及自己的方案，确保内部能够达成一致不浪费研发资源。

第二个比较大的区别就是版本管理，对于敏捷开发流程的产品来说，只有两三周才有的一个迭代发布周期是远远不够的。我们的线上bug以及严重影响用户使用的功能需要一个单独的发布通道。

因此，我们会需要一条单独的分支master进行版本发布。master不同于常规的版本管理，只要运营或者客户有比较紧急的问题，都可以申请master通道进行需求发布，当然这些都需要主控人的同意才能操作。

而针对研发同学的概要设计以及冒烟用例都是按照需求走的，只有需求本身到了一定的量级才需要。

在需求评审的时候，团队还会根据需求进行故事点评级。根据故事点的多少来定义此次版本具备做的需求。

同时，为了确保进度，整个团队每天基本上会花5分钟进行信息同步，一般就是早晨的站立会。每个人会把前一天的主要工作进度进行说明，同时遇到了什么问题，确保迭代能按时上线。

其实看了上面的流程后，基本可以发现所有主要节点的推进、资源的协调基本都是主控人（产品经理）进行处理，整个迭代做的好不好甚至说是产品本身的成败与产品经理都有着很大的关联。那么产品经理们又要怎么做呢？

1、做好需求的同时管理好需求；两三周的迭代周期看似不长其实也不短，如果迭代需求没有分清主次，内部产品矩阵因为你一人负责的产品而受到影响，问题是很严重的。

敏捷开发需求往往会领先实际开发版本两个周期，所以尽量安排好整个产品长期的走向，不要为了做需求而做需求。

2、学会协调资源；同组内的开发其实有时候还好，当团队遇上一些外部团队协作的时候，尽量提早进行排期。同时，其他组的人员也会有自己的排期，要想让人家根据你的排期进行调整，你一定要对自己的安排有规划且有信心，这在沟通协作上真的很重要也很有用。

3、提升综合能力；产品经理在敏捷开发流程中是很重要的，如果你没有能力而且瞎指挥久而久之，团队对你是没有信任的，你的计划也不会有人当回事。面对团队内部分歧、开发间的矛盾，甚至是当前团队对上所处的地位，你都要学会处理，说服不是目的，处理事情才是能力。（其实个人会觉得方案能力是一个很不错的能力，之后看能不能给大家专门再讲一下）

最后就是想告诉所有产品人员，流程都是外在的，真正想做好产品还是要靠思维和能力。如果你的团队现在没有使用敏捷开发流程，其实一点也不影响你增加实力。

毕竟你可以关注我嘛！（手动狗头）

公众号：都市摆渡人

我是红尘，我们下期见！