互联网产品都在使用「敏捷开发」模式，它的具体流程是什么样的？

前面我发过产品从发现需求到上线整个开发流程的文章，由于激烈额竞争和市场迅速的变化，几乎所有的团队在开发这块都采用了敏捷开发模式，今天就来跟大家详细聊聊这种开发模式到底是什么样的。

在这之前，简单说说另一种常见模式：瀑布流模式。它是以文档为驱动，在整个开发过程中，开发人员根据需求文档进行开发，一切以文档为依据。

而敏捷开发则是一种以人为核心、迭代、循序渐进的开发方法。它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人，注重的是人与人之间，面对面的交流，它只写有必要的文档，或尽量少写文档，采用的是迭代式开发，适用于以下情况：

敏捷开发的过程主要通过产品范围内迭代内容和周期的确认，规划合理的迭代范围，安排各岗位人员分步骤协同工作，通过开发过程中的任务项的快速跟进和渐进明细原则，保证资源的平衡和工作效率的最大化。

由产品经理驱动，订制公司产品战略，从而进行需求的采集与确定，根据竞品分析以及用户调研，进行产品原型的制作以及产品需求文档的撰写，在这个过程中，需要与项目经理进行评审，了解产品的开发难度以及可行性，从而对产品需求以及原型图进行合适地调整。

由 UE 完善产品原型的交互细节，有关页面的跳转等用户体验做到极致，然后由 UI 设计师进行界面的设计美化，及时与产品经理进行沟通，设计出与产品经理所想要的效果出来，结合自身的设计理念和技术，将界面设计得人性化、扁平化。

由开发人员进行产品具体的功能设计开发，根据项目进度安排时间，做好工作安排，认真查看设计图以及原型图、产品需求不懂，不清楚的地方及时与产品经理进行沟通，以免辛苦做出的功能与产品的意思不符，造成浪费时间精力的后果，产品进行开发完成后，由测试人员根据测试用例进行测试，将出现的问题进行反馈，及时修复产品的 bug，确保产品在规定的时间进行上线。

了解了这个流程，就容易解释为什么一旦产品出现问题，产品就成为当之无愧的背锅侠，事实上，这怨不得其他人，好比造房子，产品的工作类似打地基，地基不好，房子会塌，房子塌了怪谁，地基打得不好，当然是产品。

所以在工作中产品经理特别需要注意以下三个要点：

丨全程参与

前期的产品战略以及需求，产品经理都是参与其中的。特别是大的产品方向突出的功能点，你都必须全局进行了解。对公司的战略方向是否匹配，之后在产品的开发以及以后产品的迭代是否难度太大；这些问题一定要想清楚，不懂的就问，不断地进行评审深入下去。因为一旦进入开发阶段，突然变更需求，那么这段时间的精力以及时间就浪费了，这对于公司的损伤是巨大的。

丨勤写文档

一个人的记忆不可能会记住所有的东西，所以你必须记录下来，这样能更好地开展工作，在写需求文档的时候，我们需要要对每个用词定义紧抠，少用差不多、不确定等用词来模糊定义，千万不要以为需求文档开发不看，只看设计图，起码测试是需要根据你的需求文档写测试用例的，所以需要慎重对待。

丨做好评审记录

在评审的过程中，与项目经理进行评审后，记得做记录。哪些功能要做，哪些功能不错；什么时间开始，什么时间结束，这些都做好记录。

在互联网时代，使用敏捷开发模式可以让产品在市场上快速试错，根据数据的反馈进行及时的战略调整，让产品在市场立于不败之地，而在这个模式中，产品经理无疑是最重要的一个角色。最后用敏捷开发的 slogan 来总结它的几个特点吧：

「个体与交互」胜过「过程与工具」

「可以工作的软件」胜过「面面俱到的文挡」

「客户协作」胜过「合同谈判」

「响应变化」胜过「遵循计划」

导语：对于敏捷开发项目的管理流程，相关人员要清楚。下面是我收集整理的敏捷开发项目管理流程，供各位阅读和参考。

前段时间给大家整理了敏捷开发的流程，最近在整理敏捷开发项目的流程和管理制度，其整理的项目管理规程如下，这份规程也不完全算是敏捷专属的项目管理规程，主要是在结合我们公司实际的情况下编写出来的，大家在实际嵌入到公司的过程中可以参考下，不能照搬。

1. 目的

规范互联网软件产品开发项目管理过程，指导开展项目研发、管理等活动。

2. 适用范围

本章程的作用范围为互联网软件产品开发立项至结项管理过程。

1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导；

2.对项目团队的日常管理活动及内容进行了指导；

3. 角色及职责定义

项目经理：

进行产品开发过程中的业务目标、进度、成本、质量控制。

挑选项目团队并进行团队建设，激发、鼓舞和改进团队的生产效率。

识别项目干系人，定期向干系人汇报，并作为团队和外部的接口，屏蔽外界对团队的干扰。

确保项目中流程被遵循，组织、监督、培训项目各实践活动。

产品策划

确定产品的功能，拆分用户故事。

需求功能确定优先级。

接受或拒绝开发团队的工作成果。

参与产品开发过程中的有关会议。

UI

根据用户故事，负责产品的功能交互及界面设计

组织开展人机交互及用户体验，不断跟踪改进，提高产品表现力。

参与产品开发过程中的有关会议。

开发

根据用户故事，负责产品的技术架构设计及功能开发

评估、设计及维护产品相应模块，确保模块的稳定性、易用性、高效性。

参加产品开发过程中的有关会议。

测试

根据用户故事，设计产品测试标准，确保产品品质满足市场需求。

合理分配测试资源，组织产品测试并优化测试流程及测试标准，提高测试效率。

编写产品测试用例，提交测试问题，编写测试总结报告，以测试角度来确定产品版本是否发布。

4. 项目管理过程

按照互联网软件产品项目开发过程，可将整个项目管理过程分为立项过程、规划过程、执行与监控过程、结项过程。下面分别阐述在每个阶段过程中该如何进行项目管理。

4.1 立项过程

互联网软件产品开发项目的立项过程，通常是指从准备项目启动会到召开会议这个阶段，在立项过程中，需要完成项目目标，需求范围的初步确认，项目团队成员，其他资源的安排。

确定项目的初步目标并达成共识

对于项目目标，需要和干系人在以下几点上达成共识：

项目的背景、目标用户、核心人员及产品定位是什么

项目的资源投入预算是多少

项目的资源投入是多少

各人员在项目中扮演的角色和对项目的作用是什么

准备启动会议文档

文档内容包括：

用户画像

产品定位

市场策略

业务目标

技术可行性

研发成本预算

路标规划

召开项目启动会

参加人员包括：

管理层代表

项目经理及项目团队

其他干系人代表

主要议题包括：

申明项目目标范围及对组织目标的贡献。

管理层正式任命PM，设定期望，统一思想

文档内容的宣讲。

与PM小组确定项目管理要求

项目启动会完成后，需要与PM小组成员确定项目立项机制以及公司项目管理要求。

4.2 规划阶段

在规划阶段，团队需要共同完成产品的版本规划，迭代计划

版本规划

从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性，在规划完成后需要在项目干系人内达成共识。具体可参考《版本规划样例》

迭代如何划分

迭代划分是指将特性列表拆分形成用户故事列表，并将其对应的主要任务划分到各个迭代中去，形成粗粒度的项目迭代计划。这个过程主要考虑以下几个因素：

有些任务间是有依赖关系，某个任务的开始或结束是以另一个任务的开始或结束为前提，在划分时必须考虑这种前后依赖关系。

在安排每个迭代的任务时，需要对各种因素进行综合考虑，如平衡每个迭代中任务的技术难度和价值差异。

除了进行初步的迭代任务划分，还需要确定项目过程中迭代任务调整的规则，如迭代任务未完成时是将剩余任务延至下一迭代还是延长迭代周期。

确定人员分工

项目经理需要根据每个人员的能力和特点，初步拟定大致分工。在进行任务分工时需考虑以下因素：

任务难度与人员能力相匹配，对于明显超出能力范围或过于简单的任务容易造成负面影响。

耦合度高的尽量分配给同一个人，避免不必要的沟通消耗。

鼓励团队内部“任务认领”，提高人员的工作积极性和主动性。

确定迭代运行模式

如一周迭代、两周迭代，每个迭代包含的工作内容等。

具体的迭代计划可参考《迭代计划样例》

制定其他辅助计划

制定沟通计划、风险计划和质量计划是必要的，沟通计划主要包含以下几个方面：沟通对象、沟通方式、沟通频率即可，如：

风险计划包括风险项、负责人、重要性、应对措施，如下：

质量计划包括：bug分布满足何种条件可以发布，有几个致命bug必须停止开发新特性等。。

搭建基础技术架构

如果是一个全新的项目，需要重新开发系统框架，则这个工作应该在迭代0完成，否则会影响后期的工作开展。系统框架的每次改动必然会导致大量的重复工作量，从而给稳定的团队节奏带来很大的毛刺。

4.3 项目执行和监控过程

迭代N的执行

A、迭代N的需求细化

考虑每个迭代需要完成的用户故事；

用户故事需包含几个部分，工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》

用户故事编写完成后需要在团队内部进行需求评审，一方面是为了向团队成员解读该需求，另一方面团队成员也可在评审时给出指导性意见。

B、测试用例评审

测试人员根据用户故事要求编写对应的测试用例，并组织项目团队进行测试用例评审。根据评审意见修改测试用例

C、开发

将用户故事的'需求开发的过程。

D、开发自测

在开发过程中，每完成一个功能点，都需要及时的进行开发自测并通知产品策划人员进行验收体验。

E、验收

开发完成后，产品策划需要对开发完成的成果进行验收，验证其是否符合用户故事的要求，验证通过后方可流到测试环节，否则需与开发详细讨论其不符合性，其验收的checklist可以参考《产品验收checklist及模板》

F、测试和回归

提交测试时，必须要有正确的版本。测试人员根据测试用例进行测试，在IT平台中提交测试bug，并根据测试的角度给出产品是否发布的意见，输出《测试报告》

G、bug修改

在IT平台中获取分配给自己的bug进行修改。

H、showCase

阶段性必须有可体验版本进行showCase.需要

确定showCase时间：某个迭代开发、自测完成，准备提交测试前

会议前1-2天发出体验版给到参与人员

会议期间，由项目经理组织大家体验、反馈问题、记录问题。

项目经理根据问题情况，与开发或产品确定问题的解决时间并发出会议纪要。

I、灰度发布

迭代一定版本后，由项目经理与团队共同决定是否需要进行灰度发布。

监控方式

每日站立会

主持人轮流担任，负责控制节奏，记录问题，以备会后跟踪。

每人讲自己昨天做了什么，有什么问题，今天的计划是什么；

其他人了解别人的工作情况，并发现指出可能存在的问题。

对于发现的问题，鼓励认领，其余由项目经理指定责任人。

时间通常控制在15分钟内。

会议期间，更新任务墙，任务墙样式如下：

周报

反馈项目计划的执行情况，强调本周工作要达成的目标

暴露出项目的问题，特别是需要领导或其他团队需要协助的问题。

周报可在IT平台中输出。

月报

反馈项目当月的执行情况，包括进度、人力及质量。

反映项目存在的问题和风险。

迭代回顾

每人讲述本次迭代做的好的地方和不好的地方

回顾上个迭代不好的地方，看看改进情况。

让每个人发言。

每次迭代回顾会议完成后，可更新燃尽图

4.4 结项阶段

项目经理指导产品策划收集总结项目的产品运营数据，同时指导团队成员从自身角色进行总结，包括测试、开发、UI等。

项目经理与项目团队成员给出项目总结报告，内容可参考《项目经验教训总结-项目团队》，《项目经验教训总结-项目经理》

召开结项会议，各成员进行结项汇报。

PM小组将过程文档和经验教训总结进行归档。

        在利用敏捷开发过程中，用户（业务）也是作为相关人员参与到项目与之中，用户可以对每个周期完成的软件产品进行使用和评估，根据 *** 作体检对功能、界面等各方面提出改进意见，并且可以激发用户对进步功能点的思考，有利于促进项目特性的快速积累，迅速到达完整的软件产品。

    敏捷的三个要素是迭代开发、坦诚合作和自适应性。

    迭代开发：把功能进行小粒度的分割，采用迭代和增量式的开发方法，时间段是按周而不是按月进行度量。频每交付使用，而不是等待项目开发完成一次性提交。这样也就能有比较明显的阶段性成果，可以按周交付新功能。这对于Web应用程序尤其适合。持续性的更新，可使用户有新鲜感，提高其访问频度和使用次数。也有助于开发人员根据用户的反馈数据，应对需求的变更，及时做出响应与改进。

　坦诚合作：以我来说，做为开发人员，合作应该主要是有两类：一类是与开发人员的合作，另一类是与业务人员。与业务人员的合作很容易理解，能做到一起紧密工作，可使得产品更能切合实际的需求。而不是作完需求分析后，就将他们一脚踢开，直至产品交付。以往所做项目都不算大，几个人而已，合作也是分模块分别开发再整合。所以与开发人员的合作体会还不是很深，没看出敏捷开发有什么明显的改善。

    自适应性：现实不断发展与变化，需求也在不断改变，未来状态难以预测，也就很难提前用一个文档来规范所有的开发行为。自适应方法就是不断变化的现实情况，来及时作出改变。这也就需要信任开发人员的能力，给其更多的活动空间。相信对于一个合格的开发人员，这也会有助于调动其主观能动性，以更加积极的态度来参与开发。

1 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

2 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

4 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

7 工作的软件是首要的进度度量标准。

8 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

9 不断地关注优秀的技能和好的设计会增强敏捷能力。

10 简单——使未完成的工作最大化的艺术——是根本的。

11 最好的构架、需求和设计出自于自组织的团队。

12 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

    如果仅仅从软件过程的角度去认识敏捷实施敏捷，效果不会太好。敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。涉及到人的问题，就已经不再是过程所能覆盖的了，就到了企业管理的层面上了，包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍：把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收钱就完事儿。把人的能动性调动起来，给动力而不是给压力。要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。没有绝对的权威，每个人都有可取之处。

---