敏捷开发是很多互联网公司的运行模式，但不同公司有着不同的运作方式。这篇文章，作者分享了自己在大厂做敏捷开发的流程，可以和大家所在公司的流程相互印证，查漏补缺。

互联网产研团队一般都是按照敏捷开发的流程进行协作的，我在互联网大厂的敏捷开发是怎么进行的呢。

一、迭代周期

我们团队的迭代周期一般是2周，如果研发评估时间过长的话也会将周期延长至一个月，但是大多数我们是2周的迭代周期。

这里说的2周是研发开始coding、提测、测试、上线，也就是说2周以后要上线相应的能力。并不包括产品需求设计与评审的时间。

2周的时间一般coding的时间为6到7天，本次迭代功能测试3天，整体功能回归测试2天。一般会分步提测（某些能力在第三天的时候开发完成就能提测），不然整体时间会超出两周（10工作日）。

二、团队规模与职责

我们团队当时负责的是一个新产品，产品形态包括app，web，pc客户端，整个团队成员包括产品1人，研发6人，测试1人。UED有通用的部门支持。产品经理负责产品设计与项目管理，横向与纵向的信息同步沟通并对结果负责，研发会选出一人兼职来当技术负责人，主要负责制定技术方案与研发排期的工作，对最终的研发落地负责。

三、需求准备阶段

作为产品经理我一般都是在迭代开始前2周或提前一个月来准备需求，不然会导致研发资源空置同时也会影响下一个阶段的排期计划。

需求准备时要想好本次迭代要解决用户的哪些问题或为用户创造的价值，也可以称为本次迭代的主题，是否是在整体roadmap的路线上。确认本次的迭代方向后及时与团队成员进行沟通与信息的同步，如有问题需要及时调整迭代方向。

需求来源主要包含之前制定的roadmap能力以及用户高频反馈的问题，所有需求统一管理在需求池中，通过我们内部的项目管理工具进行统一管理。

需求准备阶段要提前协调各方资源与信息的同步，看看各方对需求的看法与问题，不要把问题遗留到需求评审阶段，提前做好相关准备。

该阶段主要产出产品文档与UI设计稿(产品经理协同UI产出设计稿)并通过产品内部的初步评审。每个需求需要保证完整的闭环，而且要控制整体的需求研发时间，防止无法按时交付的问题。在需求准备阶段可能会出现需求不符，需要重新设计的情况，需要产品经理能顶住压力重新设计新的方案。一般情况，需求文档需要改进2到3次才能通过内部的初审。UI设计稿也需要多次调整直至符合产品需求为止。

需求准备阶段是敏捷开发开始阶段也是最最重要的阶段，准备的需求需要与上级，各干系人，核心用户都同步且没有大方向问题后再进入下一个阶段。

四、需求评审阶段

一般会在上个迭代的整体功能回归测试时，大概有2到3天的时间进行本次迭代的需求评审，产品经理负责同步本次的需求文档和UI设计稿（产品主讲，UI辅助）。

在这个阶段是需要产品，研发 ，测试，UI深度参与的阶段，研发和测试会提出很多问题，可能是逻辑问题，交互细节问题，甚至有些问题会推翻整个需求设计进行重构。这期间需要产品经理记录并解决研发提出的所有的问题，有些问题能立刻解决，但是有些问题会耗时长一些。

需要鼓励大家提出问题（最好是站在用户角度提问题），这样避免在后续的阶段造成成本浪费。大家提出问题非常考验产品经理的处理方式，产品经理需要站在用户角度去分析解决问题，提升大家在此阶段的参与度。同时产品经理要能接受不同的声音，如果是真的问题需要敢于否定自己，并抓紧准备新的需求。

需求评审完成后产品经理将相关的产品资料同步至迭代看板中（内部的项目管理工具），供技术负责人进行整体排期。

五、研发评估排期阶段

该阶段技术负责人会与研发同步技术方案，各端研发会按照实际情况评估所需时间。会存在评估时间与迭代时间冲突的情况，产品经理需要协调团队内部解决，无法解决的需要上升解决。协调资源或者赶进度等方式。减少需求的情况也会发生，但属于比较差的解决方案。

研发评估排期后需要与测试、产品经理确认提测时间与上线时间。测试会依据研发时间评估测试所需时间，出现整体排期问题时，产品经理需要协调各方资源与时间保证本次迭代的落地。

一经确认排期时间需要各方准确保证，因为涉及多方协作，需要避免出现延期问题。保证准确交付。评估排期需要每个人都对自己的排期负责，需要保证排期的准确性。

排期确认后需求就进入了研发阶段，每个需求在研发阶段都会确认一个研发负责人，该负责人负责跟进需求的进度，解决需求开发过程中遇到的技术问题，保证需求能顺利提测并上线。基本上每个研发都会负责一个需求，该措施能确保每个需求都有负责人进行跟进，保证需求在开发过程中能直接找到对应负责人，同时也锻炼了负责人的横向能力。

六、研发阶段

研发阶段团队成员每天通过早站会的方式同步每个需求的进度，在会议之前需求的研发负责人都会在需求看板中更新当前的研发进度，问题与风险，当天的问题原则上需要当天解决，会议中大家也会对着需求看板同步进展。

虽然研发阶段遇到的问题也会很多，但是基本上不会遇到颠覆性的问题(因为前期团队已经解决了大方向上的问题，在需求准备与排期阶段已经有了比较充分的讨论)，如果真的遇到颠覆性的问题需要产品经理协调相关成员尽快确认解决方案同时要避免再次出现此类问题。

研发阶段开始时产品经理就需要开始准备下个迭代的需求，以保证下个迭代能顺利开始。

在此阶段测试人员会准备好测试用例，并在研发开发完成前完成测试用例评审，研发自测也会依据测试用例完成自测走查

七、测试阶段

开发完一个需求后，产品经理会进行功能验证并发起提测单，产品验证后提测能保证是按需求开发的，提高测试人员的效率。

测试人员在此阶段会进行3天(一般为3天左右，实际会按照需求进行调整)的功能测试(包括app web pc客户端)，研发也会在这三天内修改bug。

在此阶段产生的bug需要解决并趋向于零，bug的产生有可能是产品需求引起的，可能是历史原因引起的，整体的原则是不能带问题上线，需要尽快解决问题，有些bug属于需求问题的需要尽快给出解决方案。如遇到当前迭代不能解决的问题也需要确认解决方案后安排到最近的排期迭代中。

此阶段是产品上线前的最后阶段，对测试人员的要求很高，需要进行功能，视觉，交互等测试，也需要提出自己在测试中遇到的需求问题。总之需要对测试结果与线上问题负责。同时产品经理在此阶段也需要提前介入测试，如遇到问题提前调整，避免遗留问题。

功能测试完成后，研发会将本次迭代功能上线至预发环境将整体的能力进行回归测试，回归测试大概有2到3天的时间，产品与研发可以在此阶段评审下个迭代的需求。

八、上线与用户反馈跟进

上线后要及时通知用户本次的上线内容并收集用户反馈，对用户反馈的问题要及时跟进处理，处理完成后要反馈用户。整体原则是避免线上存在问题对用户产生影响，线上问题属于优先级比较高的问题，要第一时间处理。

用户反馈的问题也可能是需求，需要产品经理判断好优先级并给出相对准确的回复，比如什么时间上线，或者不做的原因，维护好与用户之间的关系。

每一个能力都是解决用户的问题，如果某项能力上线后没有达到预期，团队则需要复盘原因，避免下一次出现此类问题，每次都需要保证研发资源都用在了正确的产品路径上。

九、小结

我们团队迭代总体来说是非常紧凑的，人效使用是比较高的，每天都会遇到各种各样的问题，有些问题甚至会影响排期时间，但是基本不会出现最终交付延期的情况，因为前期的计划会同步上级也会同步到用户，出现延期的话影响的范围是非常广的，而且对用户也会造成不诚信的问题，所以一旦计划制定后就不能轻易更改，这也推动了产品经理与研发在前期要进行充分的讨论与评估，也会促进成员抗压能力的提升。同时延期一旦产生也就代表团队的交付能力出现了问题，要及时进行复盘并进行解决方案的落地。

每个阶段在推进的过程中不会很理想，比如会出现需求延期，研发评估不准，成员参与度不高等问题，需要团队的多次磨合才能达到比较平衡的状态，最终提升团队的交付能力。

由于产品经理对结果负责，需要产品经理在每个阶段都需要深度参与同时也需要推动引导团队成员深度参与，解决每个阶段遇到的问题，提升自己的领导力，带领团队准确交付。由于节奏比较快，随时会遇到问题，需要产品经理始终站在用户角度去思考问题，去寻找解决方案。

快速迭代的目的是快速交付，快速接触用户，比如对于一个3到5个月的目标，可能需要等几个月才能上线，上线以后还会存在大量的问题，也可能偏离了用户需求，但是通过敏捷迭代的方式，2周就能为用户提供第一个版本，较早的触达了用户，后续迭代也都能收集用户需求，相当于后续三个月的需求都是与用户互动后产生的。同时这个机制也会倒逼产品研发团队聚焦MVP能力与需求，不会浪费研发资源。大目标拆解成小目标去实现分阶段验证，大大提高了产品成功几率。

目前存在一个问题就是整体迭代节奏比较快，持续推进会造成大家有一定的压力，对组织来说是提高了人效，但是对成员来说一直处于紧凑的环境会降低大家的创新能力，也会产生一定的疲惫感。但是十分适合时间紧任务重的项目(比如为期3个月左右的冲刺项目)，大家在实施时可以根据自己团队的实际情况进行调整。