敏捷开发流程
一、迭代周期
我们团队的迭代周期一般是2周，如果研发评估时间过长的话也会将周期延长至一个月，但是大多数我们是2周的迭代周期。
这里说的2周是研发开始coding、提测、测试、上线，也就是说2周以后要上线相应的能力。并不包括产品需求设计与评审的时间。
2周的时间一般coding的时间为6到7天，本次迭代功能测试3天，整体功能回归测试2天。一般会分步提测（某些能力在第三天的时候开发完成就能提测），不然整体时间会超出两周（10工作日）。
二、敏捷开发流程
1. 需求准备阶段
作为产品经理我一般都是在迭代开始前2周或提前一个月来准备需求，不然会导致研发资源空置同时也会影响下一个阶段的排期计划。
需求准备时要想好本次迭代要解决用户的哪些问题或为用户创造的价值，也可以称为本次迭代的主题，是否是在整体roadmap的路线上。确认本次的迭代方向后及时与团队成员进行沟通与信息的同步，如有问题需要及时调整迭代方向。
需求来源主要包含之前制定的roadmap能力以及用户高频反馈的问题，所有需求统一管理在需求池中，通过我们内部的项目管理工具进行统一管理。
该阶段主要产出产品文档与UI设计稿(产品经理协同UI产出设计稿)并通过产品内部的初步评审。每个需求需要保证完整的闭环，而且要控制整体的需求研发时间，防止无法按时交付的问题。在需求准备阶段可能会出现需求不符，需要重新设计的情况，需要产品经理能顶住压力重新设计新的方案。一般情况，需求文档需要改进2到3次才能通过内部的初审。UI设计稿也需要多次调整直至符合产品需求为止。
2. 需求评审阶段
一般会在上个迭代的整体功能回归测试时，大概有2到3天的时间进行本次迭代的需求评审，产品经理负责同步本次的需求文档和UI设计稿（产品主讲，UI辅助）。
在这个阶段是需要产品，研发 ，测试，UI深度参与的阶段，研发和测试会提出很多问题，可能是逻辑问题，交互细节问题，甚至有些问题会推翻整个需求设计进行重构。这期间需要产品经理记录并解决研发提出的所有的问题，有些问题能立刻解决，但是有些问题会耗时长一些。
需要鼓励大家提出问题（最好是站在用户角度提问题），这样避免在后续的阶段造成成本浪费。大家提出问题非常考验产品经理的处理方式，产品经理需要站在用户角度去分析解决问题，提升大家在此阶段的参与度。同时产品经理要能接受不同的声音，如果是真的问题需要敢于否定自己，并抓紧准备新的需求。
需求评审完成后产品经理将相关的产品资料同步至迭代看板中（内部的项目管理工具），供技术负责人进行整体排期。
3. 研发评估排期阶段
该阶段技术负责人会与研发同步技术方案，各端研发会按照实际情况评估所需时间。会存在评估时间与迭代时间冲突的情况，产品经理需要协调团队内部解决，无法解决的需要上升解决。协调资源或者赶进度等方式。减少需求的情况也会发生，但属于比较差的解决方案
研发评估排期后需要与测试、产品经理确认提测时间与上线时间。测试会依据研发时间评估测试所需时间，出现整体排期问题时，产品经理需要协调各方资源与时间保证本次迭代的落地。
一经确认排期时间需要各方准确保证，因为涉及多方协作，需要避免出现延期问题。保证准确交付。评估排期需要每个人都对自己的排期负责，需要保证排期的准确性。一经确认排期时间需要各方准确保证，因为涉及多方协作，需要避免出现延期问题。保证准确交付。评估排期需要每个人都对自己的排期负责，需要保证排期的准确性。
排期确认后需求就进入了研发阶段，每个需求在研发阶段都会确认一个研发负责人，该负责人负责跟进需求的进度，解决需求开发过程中遇到的技术问题，保证需求能顺利提测并上线。基本上每个研发都会负责一个需求，该措施能确保每个需求都有负责人进行跟进，保证需求在开发过程中能直接找到对应负责人，同时也锻炼了负责人的横向能力。
4. 研发阶段
研发阶段团队成员每天通过早站会的方式同步每个需求的进度，在会议之前需求的研发负责人都会在需求看板中更新当前的研发进度，问题与风险，当天的问题原则上需要当天解决，会议中大家也会对着需求看板同步进展。
虽然研发阶段遇到的问题也会很多，但是基本上不会遇到颠覆性的问题(因为前期团队已经解决了大方向上的问题，在需求准备与排期阶段已经有了比较充分的讨论)，如果真的遇到颠覆性的问题需要产品经理协调相关成员尽快确认解决方案同时要避免再次出现此类问题。
研发阶段开始时产品经理就需要开始准备下个迭代的需求，以保证下个迭代能顺利开始。在此阶段测试人员会准备好测试用例，并在研发开发完成前完成测试用例评审，研发自测也会依据测试用例完成自测走查
5. 测试阶段
开发完一个需求后，产品经理会进行功能验证并发起提测单，产品验证后提测能保证是按需求开发的，提高测试人员的效率。测试人员在此阶段会进行3天(一般为3天左右，实际会按照需求进行调整)的功能测试(包括app web pc客户端)，研发也会在这三天内修改bug。
在此阶段产生的bug需要解决并趋向于零，bug的产生有可能是产品需求引起的，可能是历史原因引起的，整体的原则是不能带问题上线，需要尽快解决问题，有些bug属于需求问题的需要尽快给出解决方案。如遇到当前迭代不能解决的问题也需要确认解决方案后安排到最近的排期迭代中。
此阶段是产品上线前的最后阶段，对测试人员的要求很高，需要进行功能，视觉，交互等测试，也需要提出自己在测试中遇到的需求问题。总之需要对测试结果与线上问题负责。同时产品经理在此阶段也需要提前介入测试，如遇到问题提前调整，避免遗留问题。
功能测试完成后，研发会将本次迭代功能上线至预发环境将整体的能力进行回归测试，回归测试大概有2到3天的时间，产品与研发可以在此阶段评审下个迭代的需求。
6. 上线与用户反馈
上线后要及时通知用户本次的上线内容并收集用户反馈，对用户反馈的问题要及时跟进处理，处理完成后要反馈用户。整体原则是避免线上存在问题对用户产生影响，线上问题属于优先级比较高的问题，要第一时间处理。
用户反馈的问题也可能是需求，需要产品经理判断好优先级并给出相对准确的回复，比如什么时间上线，或者不做的原因，维护好与用户之间的关系。
每一个能力都是解决用户的问题，如果某项能力上线后没有达到预期，团队则需要复盘原因，避免下一次出现此类问题，每次都需要保证研发资源都用在了正确的产品路径上。
总结
敏捷如果用好了，真的可以提高产研效率，拥抱变化、快速迭代，但是敏捷也不是万金油，需要满足天时地利人和，条件有些苛刻，下面是一些经验之谈：
老板大力支持：这个是一切的前提，比如我们之前是老板大力推广敏捷，全部门就能搞起来，后来老板方向变了，敏捷就不搞了；项目能支持小步迭代：敏捷比较适合探索类的项目、或者是 APP 之类的迭代快的项目，因为需求非常容易变更、任务好拆分；如果是传统项目，需求一开始就定好了，任务也不好拆，你就还是老实用瀑布模型吧；团队成员闭环：敏捷的团队成员，需要全部 follow 到该项目中，因为迭代节奏很快，任何一个人不可能再去搞别的项目，否则他会成为敏捷的瓶颈；团队成员目标一致：因为迭代节奏非常快，所以产品、研发、测试和UI必须目标一致，如果有任何一位同学心不齐，敏捷也很难搞起来
敏捷不是万能的，结合自己的场景，合理使用，适合自己的才是最好的。
好文阅读
您阅读本篇文章共花了：
发表评论