概述
身处移动时代，移动产品竞争激烈、功能体验日新月异，不论软件产品还是硬件产品，产品迭代速度日益加快，从硬件产品而言，即便是卓越如iPhone，也从最开始从从容容两年打磨一个产品被逼着敏捷至一年（甚至半年）推出一个新品；而软件行业，产品迭代更新速度更快，从古老的年度版本，到现在月度版本甚至双周周版本，大家都在追求速度致胜、产品快速试错。而所有这一切，都绕不开一个词——敏捷。
其实敏捷运作已经谈了很多年了，只是理想很丰满、现实很骨感。现阶段中国IT界的主要矛盾就是先进的团队运作思想与落后的人员专业能力之间的矛盾，时代变化太快，个人要不断适应技术、团队的变化与要求，就需要不断紧跟时代步伐、自我提升，而且这种提升不仅需要专业能力方面的提升，甚至还需要思维意思的转变，说实在话很难、很累！毕竟大部分人终究还是喜欢窝在自己那个最熟悉的安全区，悠然度日，不然何为生活呢。
扯得有点远了，赶紧收回来——敏捷迭代是个好东西，能让产品更快速、更精确地应对用户需求的变化。但是，正所谓好马需要好鞍配，先进快速的团队运作模式，也需要相应强力高效的人员配置才能与之相匹配，才能发挥其最大价值。如若不然，产品就会走上颠簸之路或者伪敏捷之路，前者的体现是敏捷反而会导致版本稳定性下降，后者的表现是在快速版本周期内只能做小打小闹式修改，并不能真正使产品核心功能完成迭代式演进、不断提升产品品质。
迭代模型说明
当然，除了角色能力这一关键因素，合适的敏捷运作流程也是甚为关键，两者是相得益彰的，为讲清楚这一点，笔者特意将所在产品团队的敏捷迭代模型规划图贴出来，以便做针对性讲解。
图中要素说明：
1、绿色字样的是整个团队的核心里程碑交付节点；
2、蓝色字样是各角色各阶段工作需完成里程碑节点；
3、此迭代模型迭代周期为三周，故仅适用于后台开发工作量在两周以内的需求，如果后台开发周期超过两周，建议另起后台版本专做后台开发，待开发完成后再统一纳入前端版本规划；
时点周名称约定与工作要点说明
版本按周划分工作、制定里程碑，按照时间顺序依次命名为前置第一周（后台开发与UI设计周）、前置第二周（中台开发周）、版本第一周（前端开发周）、版本第二周（测试周）、版本第三周（发布周）。
前置第一周：也叫后台开发与UI设计周，主要工作是完成全量需求的分析工作与原型开发工作、完成核心需求UI设计、完成核心需求的后台方案设计、完成核心需求后台开发、中台启动方案设计、疑难需求的前端技术可行性预研，以及相应时点的需求范围确定会、后台方案评审会等里程碑会议；
前置第二周： 也叫中台开发周，主要工作为完成全量UI设计稿交付、完成全量后台开发、完成中台方案设计、完成核心需求开发、完成前端方案设计，以及相应时点的需求详细宣讲会、全量UI设计评审会、中台方案评审会、前端方案评审会；
版本第一周：也叫前端开发周，主要工作是前端开发以及前后端联调、完成中台开发、测试用例设计、根据需求交付进度进行的代码Review工作、启动Sit测试，以及相应时点的测试用例评审会；
版本第二周，也叫测试周，主要工作是完成前端开发、进行Sit测试、产品介入冒烟测试、UI完成视觉还原工作，以及后台在预部署环境灰度发布、生产发布，中台在预部署环境灰度发布；
版本第三周，也叫发布周，主要是完成SiT测试、开始并完成UAT测试、完成中台生产环境发布、完成App生产环境发布提审，以及相应时点的产品上线评审会；
各角色职责与能力要求说明
产品经理角色：
此角色既要求专业的移动产品鉴赏能力，也需要专业的需求分析能力，还要有较强的版本规划意识。上图版本迭代周期虽然为两周，但实际运作是五周，版本核心需求的梳理与规划要至少前置两周完成，以便后台开发人员能提前两周启动后台方案设计与开发工作；需求的交付目标是专业细致的需求描述文本与详实清晰的交互原型稿（推荐用Azure快速绘制），绝不能遗漏核心交互流程分支与重点需求边界条件，交互原型稿至少要符合主流移动产品交互规范。
需求描述坚决拒绝一句话需求，杜绝大而全的全场景粒度需求。前者说明产品经理缺乏最基本的专业需求分析能力，后者说明产品经理对需求粒度把握能力不够。前者就不说了，重点说说后者，这是最常见的需求交付形式，因为看上去需求描述是最全面清晰的，也最能直观体现产品经理的辛苦劳动程度。但其实这是最危险的需求交付方式，因为粒度太大，虽然主流程不至于遗漏，但是二级、三级细化分支场景无法面面俱到，从而容易导致异常分支流程疏漏或者重要低频细节被忽略，也不利于开发团队做需求工作量评估，测试团队不容易深挖业务场景。
需求的梳理虽然最初是基于业务场景来开展的，但最终落地应该是以业务流程为维度来实现的。一个完整业务场景如果包含两条及以上操作流程，就要考虑做需求拆分。如果一个流程操作链太长（例如超过五步），甚至需要做二次截断性分拆，最终拆分基准是能保证一个需求的开发工作量能比较准确的评估出来。如果以上图三周模型来量化的话，一个需求最好能由单人不超过5人天完成（三周迭代，不考虑联调工作量，单人独自开发时长不会超过7人天）。
产品经理的需求开发工作起点其实是还要早于五周的，因为要保证在前置第一周周一二的时候将核心需求的原型稿交付出来，这是产品经理的第一个里程碑，用于与后台开发团队、UI设计团队做主流程交互与核心页面数据的第一遍串讲；产品经理的第二个里程碑式前置第一周周四输出全量需求的原型交互稿，然后组织各个角色核心成员做版本的需求范围明确，此会议上需要评议出版本最终要交付的全量需求，此为需求的第二遍串讲；产品经理的第三个里程碑是版本前置第二周的周一二，结合全量UI初稿给全团队成员做详细需求宣讲与UI评审；接下来的两周产品经理团队的主要工作就是下个版本的需求分析了，当前目标版本的工作就是正式版本第二周（即测试周）介入冒烟测试，版本第三周进行UAT验收测试以及版本上线支持工作。
UI设计师角色（统称，包括所谓UE/UX与UI）：
如果UI团队够大，一般会细分为UE/UX设计师与UI设计师两类角色，前者负责整体交互设计与体验把关，后者负责将前者的设计进行落地实现。如果是小团队，基本就只会有UI设计师角色。不论哪种团队组织模式，都要求设计师具备较深的移动交互素养积累，具备一定的设计创意能力与交互规范度意识。移动端的设计从来都是首先服从于主流交互体验、硬件局限与主流用户习惯，然后再进行局部创新与品牌融入。最忌讳设计师在交互流程与交互方式上做所谓的创新，去颠覆现有用户操作习惯。如果一种全新的交互方式，你是第一个1，那用户就会成为你后面的0，将你无限放大；但如果你只是后来的1，那用户就会把你变成小数点后面的1，然后在前面加无数个0，最终将你抛弃。在移动交互的世界里，用户从来都是懒惰、因循守旧的。
对于设计师而言，除了本身的专业设计能力要求外，还要求有很强的需求理解能力、需求具化能力与一定的体验执着，毕竟所谓的设计潮流日新月异，我们既要紧跟主流，也要适当沉淀，不要为变而变，一切以能为产品创造更多用户价值为衡量标准。
UI团队的工作起点是紧跟产品需求交付进度的，在前置第一周的周一，产品经理交付核心需求原型稿之后，即开始进行核心需求的设计工作。UI团队的工作进程总体是与后台团队同步的：第一个里程碑是在前置第一周周四完成核心需求UI设计初稿的输出，期间当然需要UI与产品做持续的需求澄清与核心交互确认；然后在前置第二周的周一二完成全量需求的初稿输出并组织UI评审，此评审一般是跟需求详细宣讲一起组织，既做UI评审，也用于给开发做需求实现的直观展示；最后，结合评审意见进行UI终稿修订，在版本正式启动的第一周周二前后实现第二个里程碑——全量UI终稿输出；在这之后，UI就要开始准备下一版本的UI输出工作了，而在当前版本剩余的主要工作是版本第二周周四前后给前端开发做视觉还原，以评阅并调校需求的最终实现效果。
后台开发角色：
在上图三周迭代模型中，后台开发是最早启动的，综合技术能力要求也是最高的，但是可以专注于单一微服务模块的开发。后台开发团队需要在仅仅依托产品原型交互稿的基础上完成核心需求的方案设计与开发工作，需要很强的需求抽象能力与方案设计能力，同时要有一定的双版本并行开发能力，从上图中可以看到，后台开发人员大部分时候是既要进行当前版本的联调与bug修复工作，同时也要进行下一版本的后台开发工作，其交付质量的保障是通过拉长联调验证时长来最终保障的（总计5周）；
后台开发团队的工作时点也是紧跟产品需求交付进度的，基本与UI设计工作并行，其第一个里程碑在前置第一周周二前后，需要完成核心需求的方案设计与评审；其第二个里程碑是前置第一周的周四前后，核心交付项是后台接口设计文档，中台基于此才能开始中台方案设计工作；第三个工作里程碑是在版本第一周周一前后完成全量后台开发工作；第四个里程碑到了版本第二周周二，将后台代码发布到预部署灰度发布环境测试；第五个里程碑是版本第二周周四，将后台代码发布到生产环境验证，到此当前版本的后台工作基本就算结束了，版本第二周后台主要精力放在下一版本的后台方案设计与开发。
中台开发角色：
在移动团队中，除了核心后台，一般还有API网关这一中台开发角色。中台既用于聚合不同后台服务，也用于做一些与业务无关的全局性管理与监控的工作，例如登录、日志管理、接口拦截与监控等。中台开发人员的技术能力要求相关低一点，但是对于整体后台业务熟悉度要求很高，这样才能知道一个中台接口的实现需要从哪些后台服务中提取数据。中台开发人员也需要一定的双版本并行开发能力。
中台开发团队的工作时点是紧跟后台开发交付时点的，一般在前置第一周周四前后开始中台方案设计工作（既后台完成后台接口方案设计文档的交付）；第一个里程碑节点出现在前置第二周周一前后，需要交付中台方案设计文档并组织方案评审，中台方案评审最后也是跟详细需求宣讲会一起，既能减少会议次数，也能反哺需求澄清，从中台角度帮助产品完善需求场景与边界条件；中台的第二个里程碑是在版本第一周周一前后，需要交付中台接口设计文档（其实最好能提前到前置第二周周四）；中台的第三个里程碑节点出现在版本第一周周四前后，需要完成全量需求的中台开发工作，并与后台完成联调；中台的第四个里程碑节点是版本第二周周四，将中台代码发布到预部署灰度发布环境供测试进行灰度测试；中台的第五个里程碑节点是版本第三周周二，将中台代码发布到生产环境，供测试进行生产Uat测试，至此当前版本中台的工作基本就算结束了，当前周中台的主要工作放在下一版本的中台方案设计与开发上。
前端开发角色：
其实整个敏捷迭代模型都是围绕前端开发人员的工作时点来设计的，既是因为前端交付才是产品可测试的功能交付，也是因为前端联调验证通过了才算得上真正意义上的中后台交付通过。前端功能因为直接面向用户，因此需求准备程度是最充分的，但是可供缓冲的开发时长也是最短的，因此对于前端开发的交付质量其实是最高的，基本不允许方案失误或单个需求级别的开发返工，一旦出现往往就会导致版本延期。从运作经验来看，三周版本迭代，真正可用于前端开发的时间最多也就在七天左右，因此每个版本的需求交付量，就可以基于单人七人天来做量化评估。
前端开发团队的工作时点相对固定，基本是在前一版本测试转Uat之后开始进行当前版本的方案设计，一般是在前置第二周周二前后；前端开发的第一个里程碑节点出现在前置第二周周四左右，也即与前一版本的发布时点重合，可以在前一版本的上线评审会上作下一版本的前端方案评审；前端开发的第二个里程碑是在版本第二周周二前后，此时需要完成所有需求的前端开发工作与自测试；前端的第三个里程碑节点就是App版本的发布，也即版本第三周周四；对于前端而言，并没有一个明确的里程碑节点来做专门的代码Review工作，代码Review工作是细分到每一个需求的，哪个需求完成了开发与自测试，即可找核心员工作代码Review工作，Review之前需求才可以转测试，这样既保证了代码Review的时效性，也降低了单次Review的工作量从而能较好地保证Review质量。
测试角色：
测试团队的工作启动是最晚的，基本要到前置第二周周四之后才能开始测试用例设计工作（因为要先保证前一版本的验证通过、发布上线）；其第一个里程碑出现在版本第一周周四左右，需要完成所有需求测试用例的输出同时组织用例评审会议，此时前端开发的需求也已经完成一大半了，就可以立马进行Sit测试；测试的第二个里程碑是Sit测试结束，出现在版本第三周周二（当然也可以前置到第二周周四）；之后就是转Uat测试，带周四Uat测试完成即可以组织版本上线评审会议，然后开始下一版本用例设计工作。
综上所述，敏捷迭代运作必然是多角色工作递延启动、并行运作，而且环环相扣的，对每一个角色的要求都很高，任意一个角色拖后腿都会影响整个团队进度，迭代运作初期团队人员可能会比较累（特别是产品跟设计，差不多要同时准备两个版本的需求与设计稿），但是一旦运作节奏顺畅了，在交付节点反而会比较轻松，因为主要工作量在前面已经完成了。
不过，此模型要求各角色成员一定要有产品主人翁意识，充分发挥各人的主观能动性，尽可能把事情往前赶，这样才能事半功倍、稳步快跑。
九大原罪
同时，此模型非常强调各个里程碑的交付质量，坚决禁止需求错误或者方案错误级别的返工行为，以下便是笔者带领团队进行迭代运作过程中总结的九条迭代原罪以及相应影响：
原罪一：
产品经理的移动产品专业积累不够，功能规划能力欠缺，对于核心需求缺少前瞻性规划，版本迭代只能且做且走，无法达到前后端双版本差量并行运作的高速要求，导致版本迭代节奏受累需求交付节奏，版本周期无法稳定下来，团队开发节奏被频繁打乱；
原罪二：
产品经理需求分析意识匮乏，无能力区分业务需求与功能需求，更不懂如何把用户需求转化成真正产品功能需求，经常直接把用户诉求当成产品需求纳入版本规划，从而造成需求细节不明确、重要场景遗漏、业务流程冲突等问题，最终导致UI返工、中后台方案调整与开发反复、版本延期等严重后果；
原罪三：
UI设计师缺乏专业的移动产品设计素养，对基础移动交互规范漠视，经常创造“新的”交互流程，导致用户习惯轻易被破坏、体验流畅性下降；
原罪四：
UI设计师一味追求所谓最新设计潮流，缺乏品牌植入意识与设计能力，最终导致App风格体验经常变换，用户的产品熟识度降低，甚至造成业务流程冲突、UI设计返工，拖慢前端开发进度；
原罪五：
核心开发人员技术能力欠缺，对需求的技术实现复杂度缺少量化评判，导致工作量评估失误，直接影响版本周期评估；
原罪六：
核心开发人员方案设计能力欠缺，导致概要方案错误、经常性返工，最终影响开发进度、版本延期；
原罪七：
普通开发人员技术能力欠缺抑或任务分工没有量才为用，导致代码交付质量差、开发返工，最终影响项目进度；
原罪八：
测试人员专业能力欠缺，测试用例无法深入业务场景，造成重要场景遗漏或者关键细节漏测，最终影响版本交付质量；
原罪九：
自动化测试建设缺失，导致测试人员在原有功能回归测试方面耗费太多时间，造成有效测试时长偏低、测试效率低下，迭代周期内测试覆盖度明显不够，最终影响版本上线稳定性；
综述
敏捷软件团队的管理与运作，是最能直观体现木桶理论的，不论哪个角色，只要出现能力短板，都会被无限放大、进而影响到整个团队的运作效果，因为软件生命周期中各项工作虽然可以双版本（甚至多版本）并行运作，但是单一版本内的各项工作内容终究还是串行运作、彼此依赖的，都是牵一发动全身。即便上述迭代模型是以前端开发为中心而设计的，但是各个角色并没有主次之分，只有职责先后之别。
如果人员能力基本满足要求，严格按照上述运作模型迭代，App的运作效果应该基本可以达到个60分，但如果要达到80分甚至90分，除了有赖Product Owner的精细化管理、Scrum Master的专业引导，更有赖于各个角色自身专业能力的质变。软件行业是精益流程与卓越个人共同助益才能达到巅峰的，既需要“照章办事”的黄牛精神，也需要独当一面的“个人英雄主义”引领。
