产品视角｜这是一次敏捷项目的总结

作者：pauly

全文共 2080 字 2 图，阅读需要 5 分钟

———— / BEGIN / ————

说到敏捷开发，相信大家都多少有了解。

目前大部分互联网公司的开发模式肯定不是传统的瀑布式开发，更多的应该是偏向于敏捷开发。

最近一段时间参与的项目，项目组采用的是敏捷开发迭代制度，虽然可能和严格意义上的敏捷开发有所区别，但是适合的才是最好的。

在实践中，通过项目的反思总结，制定适合自己团队的敏捷模式是最好的。

首先简单来介绍一下敏捷开发：

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态——来自百度百科。

简单来讲，在快速发展的互联网时代，开发周期不宜太长，采取小步迭代，更能适应当今这个时代。

网上的敏捷开发的流程图是这样的：

我们项目组的流程，实际是这样的：

虽然和许多标准的敏捷流程不完全一样，但其实我们的流程保留了核心的几个环节。

接下来聊聊每个环节的主要任务及内容：

一、需求整理阶段

时间：

此环节的时间往往不计入迭代周期，一方面是需求和设计经常会发生变动，而功能设计确定后，进入开发阶段的变动比较少；另一方面是开发在进入当前迭代的时候，此时产品就应该进入到下一个迭代的设计周期了。

参与人员：

产品人员、技术负责人、项目经理

工作任务：

此环节任务其实不少，包括了产品人员对迭代的需求进行梳理，对需求完成设计。产品在完成产品方案后，小范围召集产品经理、技术负责人、进行评审。在交互稿、设计稿都完成后，进行召开迭代会议。

产品关注：

此阶段产品的主要工作是在需求池中进行筛选，整理出高优先级的任务，作为此次迭代的功能列表。因笔者都是在小公司，所以产品文档、交互稿都是由产品人员通过原型来展现。

踩过的坑：

某次该会议叫了过多的人，导致会议时间过长，会议效果也不好（由于此环节主要是对总体功能列表进行讨论，只需叫上产品小队、技术负责人就够了）。

还有就是：设计的原型在此阶段就做的太细，导致部分需求其实并不需要（此环节设计以大的框架及流程为主，细节的交互、规则等可以在之后再根据需要进行完善）

二、迭代会议阶段

时间：

此环节为迭代周期正式开始

参与人员：

项目组所有人员

工作任务：

此阶段为任务讲解、计划。主要为产品经理对此次迭代的主要任务进行讲解，包括需求来源、产品设计，技术人员对此次迭代的时间进行排期。

产品关注：

该会议就是传说中的评审会议。

产品要多做准备工作，因为会有很多人来怼你，主要还是以业务流程、规则、交互等具体实现的东西，因为技术要进行开发，很多东西需要问清楚。

踩过的坑：

这个环节坑就是看被怼的惨不惨