这里给出的流程是经过实践得来的，在实际的运用过程中可做相对应的裁剪，不用太在意标准，适合最重要。
先回答几个问题，然后再来细致讨论研发流程。
有人说，敏捷项目是没有范围的，为什么老是在变化？
首先纠正一个问题，范围是确定的，只是说高层级的范围是确定，每次迭代的范围是确定的。而给团队有一种范围不确定的错觉，是因为产品功能是迭代的，代码同样也是迭代的，甚至需要重构。因为市场的变化，快速响应市场等原因，所以我们不得不快速迭代产品来符合用户预期，所以很多时候我们拿到一个高层级的需求范围，就得需要分解、细化、清晰化成一个个迭代计划。所以我们可执行的范围是清晰且确定的，只是也是一个迭代的过程。
有人说，敏捷项目是没有项目周期限制的，那么怎么评估整个项目周期呢？
任何一个项目，我们对整个项目周期的评估都依赖于专业知识、过往经验。敏捷项目也不例外，上面也提到了，发起人的，高层级的需求范围是确定的。这个时候我们需要组织团队里的关键人员把需求拆解成可评估的模块，并对比较模糊的地方加以风险评估。实际上和其他研发模式的评估是一样的，只是在实施方式上会有不一样的节奏。
研发流程
研发的流程关键步骤都是一样的，敏捷也一样，确定需求范围、实施研发、测试、验收。这里面作者将把平常实践出来的一种流程经验分享出来，另外会穿插一些实践过程当中的管理技巧和观点。
需求来源
需求来源一定要把握一个准则，所有需求都应来自于高层级需求，这也基本决定了项目的成败。基于这一点，所有的业务需求、功能需求、技术需求、数据需求等等，将会形成后续环节中的范围与目标。这些需求方可能来自于高层、运营、产品、技术等各个端，我们称之为userstory。举个例子说明一下userstory，我要点个外卖，要有饮料，烤肉，12：00送到XXXX地方，身上没有现金，网上支付就可以了。
需求池维护
以上所提到的需求都是离散的，这时候需要PO（Product Owner）、TL（Team Leader）把这些业务需求、功能需求、技术需求等等离散的需求结构化，收录到需求池当中。这里有个要点，那就是需要考核需求池中的需求价值和饱和度。这两个指标对后续的研发过程影响非常大，没价值的需求直接导致后续工作的无效，饱和度不够对研发资源是浪费，过饱和产品资源面临短期不足，都会影响后续工作。
需求概要
PO、TL维护好需求池后，需要对需求池里需求出概要。为什么不是PRD文档或者直接先不出概要文档就直接进入下个环节？这里首先也说个敏捷理念，个体和互动高于流程和工具，工作的软件高于详尽的文档。因为我们要对需求的准确性、价值性做审核，所以我们还是需要文档。但也因为我们遵循敏捷模式是适应变化的，而此阶段还没进入评审，恐有变化，所以过多的文档也意味着可能会产生大量浪费。所以这里建议进入评审环节前，只对需求池里的需求输出概要。而这个完成时间也应该是（N-1）sprint 的前半段时间。
需求评审
需求评审环节，这个会议叫Product backlog会议。讲究一个团队自主性，团队的成长，团队的整体性，以及项目的把控等等各方面，在评审上都会有极大的提升。那么评审应该由那些人组成？PM，PO，TL，关键成员，或者比较注重团队建设的话，可以考虑拉通所有成员评审。具体要评审的维度又是哪些？需求的可行性，价值性，优先级，相关性等，这时候可能有些细节地方可能还是模糊的，所以再对细节做下雕琢就可以了。所以这个环节要充分运用好团队之间的互动性。这个完成时间也是（N-1）sprint 的前半段时间。
需求详情
当对需求评审做完后，这个时候需要出PRD了。通常对接客户，我们需要给出行业标准的PRD文档。仅仅只内部的话，PRD可以存储在任何效率提高的工具上，也要同时兼顾团队其他同事间的高效沟通。
这时候的需求详情，无论是功能详情，还是技术详情，都应该得到体现。而这部分的工作需在（N-1） sprint后半段时间里，排任务给到PO或TL完成，形成第N个sprint 需求任务，这段时间也是对于评审后一些结果的需求修订。
任务建立
当拿到需求详情的时候，需要对任务作拆分，可以根据smart原则进行拆分，拆分成特定的、可量化、可执行、有关联性的、遵循团队颗粒度标准的任务，这个时间段应是与编写PRD并行。这里特别说明，不要一定要出完所有PRD再来拆分任务，给团队足够的自主性，灵活编写PRD再拆分，效果更好，只要通过任务跟踪工具来跟踪就好了。
颗粒度，这是平常大家都会面临的问题，这么定义是最好的？之前有朋友和作者提过，按接口或者功能点的颗粒度来定大小，其实我认为都可以，只要颗粒之间可以衔接。颗粒度的大小应该是每个任务可及时调整水平。例如我们用斐波那契数列（1、2、3、5、8）来评估工作量时，通常<=3是比较能及时调整偏差的一个水平。
创建任务，当我们按颗粒度拆分好任务后，需要把团队一个sprint的任务都创建好进行分配和跟踪。通常作者实践出来的经验是，先创建子任务，子任务是顺序是：需求任务子任务（对需求的拆分）> UI/UE任务（或者技术设计任务）> 测试任务 > 开发任务。这里说下这种排列的顺序，对需求任务我们尽量遵守颗粒度来分解成子任务，并与需求任务关联；然后分配设计任务；然后分配测试任务，这样测试可以在短时间内编写出测试用例，可以在测试用例编写完，进行一次评审，可以调整产品端、研发端之间的偏差；再创建开发任务。这个创建任务流程的在开发的任务完成之后再回流，每个关联任务按倒序逐个关闭，第一可以在项目维度快速定位问题，第二可以及时跟踪每个环节保证质量，第三当关闭到需求任务的时候，也就形成了验收单，也就形成了产品研发过程的一个闭环。
编排计划
开始进入我们的任务排期过程，这里有个会议叫Sprint Plan，也就是规划我们一个sprint里要做的事情。
需求宣讲，先对需求任务进行宣讲，然后再宣讲子任务。
任务评估，任务分配，把这两个事情放到一起来做。
刚提到通常宣讲子任务，我们这里采取这样的策略，每宣讲一个子任务，然后团队成员自提任务，如到最后无论有没有剩余任务被分配的，我们都需要做TL做一些调整，人员、工作量、优先级等都包括在内。这样在一定程度上发挥出团队积极性，也一定程度上因团队成员依据熟练度自提任务，提高了sprint的完成度。
每分配一个任务，我们评估策略是这样的。团队全员评估，通常我们利用斐波那契数列（1，2，3，5，8）来评估工作量（时、天），通过取相对比较合理的数字来作为工作量，如果很有争议的评估，这个时候需要说明一下缘由，调整出合理的评估。这里也强调一下，通常我们选择工作量评估的数字为2、3，过多过少都可以尽量重新拆分、合并任务。
执行任务
任务执行方面，我们应该抓任务执行顺序和关键任务的完成度，这关乎sprint的完成度。
下个迭代前置任务，这一部分任务是（N-1）sprint的研发需求的前置任务，这一部分任务需注意编注，记录，以及合适的工具协同，例如UI/UE，算法设计等。
测试用例，单元测试，关键任务，这些任务应该先行。这里有个控制偏差的技巧，可视情况而定需要不需要。QA代表技术端的思维，PO代表产品端思维，当测试用例编写完，可以拉一次测试用例评审，核准需求的技术端对需求理解的准确性，对于需求偏差的把控有积极意义。敏捷上也有专门的review meeting，这个会议主要是sprint运行中给团队show case，这个也是一个道理，调整任务执行过程中的偏差。
实施任务，逐个执行任务，团队成员发挥专业力量即可，这里不作过多阐述。PM的在这期间的工作内容是组织和监控，这里提几个点。
关键任务跟进，可以通过优先级、工作量等来评判，着重跟进，且及时公开透明给出进度。
standup meeting，这个会议很重要，每天对整个团队的大致情况有个了解，也让团队个体有清晰的复盘和当日的待办。
固定好会议时间，减去不必要会议的时间，例如固定好2周/sprint，这样就可以编排好product backlog，sprint plan，review，retrospective等会议。
组织好代码评审，代码按需求建分支，有利于代码合并，适应需求变化，这里不展开讲。
质量管理方面，需要注重单元测试覆盖率，功能测试，集成测试。
Bug修复
这个环节主要对代码交付作校准。
通常我们以uat环境为线，如果在uat、prod等生产或预生产环境，这里面的bug需要按需求一样排期处理，代码层面也建立bug线处理，测试也要回归测试这些bug，整个流程就不会落下任何环节。
在dev、qa类似这种开发测试环境的bug，那当然是在当前sprint内就要处理掉，在评估工作量环节，面对比较复杂的需求，要预留一部分bug处理的buffer时间。
任务单回转
当开发任务完成后，关闭任务单，回流到关联的测试单，测试完成，再关闭测试任务单，回流到需求单，这样就形成了需求研发闭环，每个环节都不会遗漏，也不会跟进不到。
验收功能
验收分阶段性验收和最终验收。
首先需要有验收标准，这里只说下验收原则，功能完整性，用户体验性，使用的稳定性，一般项目管理工具有个发布池，可以将要发布的清单罗列出来。
其次要对预生产环境验收，对生产环境一定要做一次最终核验。
最后，发布完后要验收核对交付的文档，包括用户手册、PRD、设计文档、开发文档、质量报告等。阶段性验收也应该包括这些，到最后一次验收时，将这些文件汇总就可以了，这也符合敏捷里的最小可使用的思想。
关闭需求
当每个需求都验收通过后，就可以关闭需求任务单。这里通常在里程碑复盘会议上做评审，这样也就有始有终，可以核实一遍需求单的完成情况，这样就形成了需求交付闭环，每个里程碑的交付也会非常顺畅，阶段性激励也很明显。当然如果不理想的状态情况下，当有没完成的需求单，在评审可延后的情况下，要及时导入到下个里程碑的需求池重新编排。