本文作者将结合自身经验，与大家一起来聊聊敏捷流程中每个环节的主要任务及内容。enjoy~
说到敏捷开发，相信大家都多少有了解。目前大部分互联网公司的开发模式肯定不是传统的瀑布式开发，更多的应该是偏向于敏捷开发。最近一段时间参与的项目，项目组采用的是敏捷开发迭代制度，虽然可能和严格意义上的敏捷开发有所区别，但是适合的才是最好的。在实践中，通过项目的反思总结，制定适合自己团队的敏捷模式是最好的。
首先简单来介绍一下敏捷开发：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态——来自百度百科。简单来讲，在快速发展的互联网时代，开发周期不宜太长，采取小步迭代，更能适应当今这个时代。
网上的敏捷开发的流程图是这样的：
我们项目组的流程，实际是这样的：
虽然和许多标准的敏捷流程不完全一样，但其实我们的流程保留了核心的几个环节。接下去来聊聊每个环节的主要任务及内容。
需求整理阶段
时间：此环节的时间往往不计入迭代周期，一方面是需求和设计经常会发生变动，而功能设计确定后，进入开发阶段的变动比较少；另一方面是开发在进入当前迭代的时候，此时产品就应该进入到下一个迭代的设计周期了。
参与人员：产品人员、技术负责人、项目经理
工作任务：此环节任务其实不少，包括了产品人员对迭代的需求进行梳理，对需求完成设计。产品在完成产品方案后，小范围召集产品经理、技术负责人、进行评审。在交互稿、设计稿都完成后，进行召开迭代会议。
产品关注：此阶段产品的主要工作是在需求池中进行筛选，整理出高优先级的任务，作为此次迭代的功能列表。因笔者都是在小公司，所以产品文档、交互稿都是由产品人员通过原型来展现。
踩过的坑：某次该会议叫了过多的人，导致会议时间过长，会议效果也不好（由于此环节主要是对总体功能列表进行讨论，只需叫上产品小队、技术负责人就够了）；还有就是设计的原型在此阶段就做的太细，导致部分需求其实并不需要（此环节设计以大的框架及流程为主，细节的交互、规则等可以在之后再根据需要进行完善）；
迭代会议阶段
时间：此环节为迭代周期正式开始
参与人员：项目组所有人员
工作任务：此阶段为任务讲解、计划。主要为产品经理对此次迭代的主要任务进行讲解，包括需求来源、产品设计，技术人员对此次迭代的时间进行排期。
产品关注：该会议就是传说中的评审会议。产品要多做准备工作，因为会有很多人来怼你，主要还是以业务流程、规则、交互等具体实现的东西，因为技术要进行开发，很多东西需要问清楚。
踩过的坑：这个环节坑就是看被怼的惨不惨😂 。主要有两方面的准备吧，一个是人，因为前期有准备过小范围的评审（需求整理会议），你要拉拢其他的人员认可你的东西，这样在会议中，这部分人会帮你回答（至少不会提问你）；另一方面还是文档（原型），在设计的时候要多思考，把各种情况考虑全，这样在会议中被提问时，就能够很好的回答他人。
迭代计划阶段
时间：开发、测试阶段
参与人员：项目组所有人员
工作任务：此阶段为开发阶段，技术负责人对功能列表进行拆分、排期，开发人员开始进入编码阶段。测试人员根据需求书写测试用例，在开发完成提成后，进行产品测试。
产品关注：本阶段产品主要是和开发人员保持沟通，一些在开发过程中会发现的有疑问的地方，需要产品去决策，该如何做。产品提测后，产品人员也要及时去对开发好的功能进行验证，看是否符合预期。在这间隙，产品需要开始对下一个迭代的需求进行梳理。
每日例会：此会议初衷是对每天的工作进行回顾，主要是看当天的任务完成情况，是否有难处等，让大家对项目的进度有一个了解。但是实际应用中，我们的例会效果不是很好。建议通过一些协作工具，用图表来展示，这样更有直观性。
踩过的坑：迭代过程中最大的坑应该是需求变更了。原则上迭代会结束后，不能在此迭代里新增需求。但是需求变更常常就会有新增，这时候需要去评估。如果是改动大的需求，需要召集小分队人员进行讨论，看是否必要加入此次需求；如果是小的改动，则进行相关文档的更新，并通知到项目组成员。
发布演示阶段
时间：开发测试完成后，进行产品的发布更新
参与人员：项目组所有人员
工作任务：此阶段为迭代的尾声，在测试完成后，根据需要在不同的环境进行发布，发布后，可能需要去演示。
产品关注：到此阶段，就正式完成一个迭代的周期了。产品人员应该也梳理好了下一个迭代的需求，在本迭代发布且通过后，就需要开始新一轮的迭代工作了。
踩过的坑：更新经常到更凌晨。发布前一定要做好测试、发布前准备工作，要定好发布计划，不然很容易陷入到发布-测试-发现bug-修改bug-测试-发现新的bug….反正每次更新都不省心，经常到凌晨。
