大厂的敏捷迭代到底是怎么做的呢？

接触并且执行敏捷迭代也有两年多的时间了，其中做过参与者，也做过组织者，也搞了一些变革，谈谈我对敏捷迭代的理解，和大家说说大厂的敏捷迭代到底是咋回事，有很多个人的经验认知，不看真吃亏

一、什么是敏捷迭代？

Scrum 是一种用于开发创新产品和服务的敏捷方式，它主要包括产品列表，迭代计划，迭代评审，指在一个指定时间周期内完成指定开发计划内容的一种需求开发模式

二、敏捷迭代的好处

1、客户满意度提高

在传统的瀑布模型中，我们经常需要较长的时间交付一个较为完整的作品给到客户，但是如果客户不满意，则有很大的可行性需要进行回炉重造，通过敏捷迭代的方式，在每个指定的迭代时间内容，我们交付部分的功能给到客户，然后及时让客户反馈，即使客户对当前功能不满意，我们重做的成本也相对较低，我们也可以基于客户的要求迅速的做出调整，来提高客户的满意度

2、投资回报提高

在客户不清楚他真正想要的是什么的时候，我们通过敏捷迭代交付了客户的初步想法，通过频繁的功能迭代，不留情的暴露当前系统的存在的问题，大大降低成本，并提高投资回报率

3、迅速取得成果

通过敏捷迭代，我们可以在指定时间内交付很多较为完善的功能，相比瀑布模式，它可以在短时间内快速产出成果并留住客户。

三、敏捷迭代有哪些重要角色

1、PO

指产品经理，产品经理主要负责的是进行迭代中产品需求的规划，并和其他组产品经理沟通需求内容，建好需求和画好原型图、低保真、模型图、流程图，并和SM进行需求预评审等

2、SM

指敏捷经理，主要负责敏捷迭代的践行，日常组织站会，和产品进行需求预评审，部分公司会将技术组长和SM搞成一个岗位（比如我司），其实我并不认同这种模式，身兼多职很容易导致做好管理时，技术落后了，或者一直追求技术，管理能力却下降了，只有极少数人可以二者兼得，当SM同时兼任技术组长时，也负责规划技术需求，评审组员的技术方案，跨团队技术沟通，确定团队的技术方向，员工培养等

3、开发

哈哈哈，就是指前后端开发人员，真正干活的兄弟姐妹们，在敏捷迭代中主要是负责实现需求，输出技术方案和SM评审，并写代码实现相应功能

4、测试

主要负责测试用例的编写，测试用例的评审，以及功能测试，代码发布，和自动化测试相关的工作

5、UI

画高保真的界面设计师们，页面好不好看全看他们了

6、PM

项目经理，在做客户专项或者是多团队需求时，PM主要负责推进专项的进行，组织会议，保证专项的及时落地完成

7、QA

质量工程师，主要是负责产品的质量控制，当出现事故时，他们会拉相关人员进行复盘，并给出事故报告，日常工作中也负责迭代中的需求质量跟进，同时也是建立公司各种研发规范的一群大佬们

四、敏捷迭代用什么工具？

我们使用的是腾讯的TAPD，其他的我也没有用过。就简单讲讲这个吧。

1、TAPD入门

在TAPD中首先你需要创建一个项目，对某些公司来说可能是一个产品一个项目，我们目前是一个组创建一个项目，因为一个组负责的产品比较多，根据产品来创建项目不大实际

创建好项目后，你可以在项目里创建需求

然后大家就会在指定的需求里，创建对应的任务并进行任务的排期。

同时，TAPD提供了故事墙和甘特图两个比较重要的功能。
故事墙可以看到当前迭代每个故事卡（即需求）目前的需求状态到了哪里。方便SM了解目前迭代的所有需求进度。

而甘特图可以明确知道每个员工的每天的任务排期完成情况。

基本上我们在每日站会过进度的时候都会依赖这几个。一般来说，迭代前期会比较关注任务的完成情况（看每个人工作的饱和度和工作效率），到了迭代中后期会更加关注需求的流转状态（从大局看整体）

我们以前也是把文档放在了 TAPD的文档功能上，后面觉得TAPD不属于公司真正的资产，可能会引起公司重要数据泄漏，因此我们将文档都放在了自己搭建的 confluence 上。

2、专项管理工具

我们一开始用的 jira 来管理客户专项和一线（我们是搞 saas 的，产品是卖给开发商用的，所以和客户直接对接的销售我们统称为一线）反馈的缺陷问题，后面公司搞了个自研的专项管理平台。
主要的功能，还是一线提专项需求，然后各种负责人审批，报工作量，然后PM汇总工作量报价给到客户。客户能接受就做，不接受就不做。以及线上缺陷的汇总，进度跟进。公司内部各团队相互提需求，也通过这个工具走流程。具体的系统我就不放出来了，毕竟是公司自己内部的东西。不可外传哦。

五、敏捷迭代怎么做？

这是我研究了很久，然后搞出来的符合我们目前团队的一个迭代节奏图。也是经历了很多次的修改，最后敲定的最终图。不同公司可能迭代的时间长度不同，或者是内容有些差别，这个基本上已经是很完整很规范的敏捷迭代流程了

1、需求规划

由于迭代是周期性的，因此我们一般会在下个周期开始之前，就提前把下个迭代要完成的需求进行规划，会包括产品需求和技术需求，产品需求一般是PO提的，技术需求一般由SM提。所谓的规划，其实就是由SM和PO决定下个迭代团队要做哪些需求，并标记好需求的优先级和要求上线时间

2、需求预评审

需求的预评审，主要是针对PO的需求进行评审，这是我整理的要求和相关指标（我自己原创的哦)

2.1 需求是否有价值

价值体现在几点

• 对公司是否有价值
• 对团队成员是否有价值 (技术上
• 对产品演进是否有价值 (业务上)

2.2 需求是否合理

• 逻辑是否合理
• 业务边界是否合理
• 交互是否合理

2.3 涉及交互的需求，原型图是否完整无误

• 有交互的需求，要有原型图，或者界面的简图
• 涉及列表的，要明确筛选框有哪些，涉及表单的，要明确每个输入的规则以及限制

2.4 需求优先级

• 高优:迭代内一定要交付的需求，或者重要专项、对团队有价值的事情(存在一定的价值，能拖的都不能设置为高优)
• 中优: 团队规划的需求，遇到高优可以让位 (存在价值，但价值不高)
• 低优:一些小问题的修复，价值不大的小改动(一般低优先需求占比不能超过10%，可做可不做的需求)

2.5 需求类型占比

• 产品类需求
  涉及模型变更，交互变更，有页面的改动的需求，占比 50%-70%
• 技术类需求
  技术重构，不涉及模型变更，界面改动，纯后端优化和架构演进的需求，占比30%-50%缺陷类需求
• 线上BUG
  要求线上BUG的需求控制在 10% 以内，保证线上高质量

3、需求宣讲

当需求评审预评审完，基本上需求就达到了宣讲的要求了，此时会拉整个团队一起开全员会，把规划到下个迭代的需求全员宣讲一遍（说明需求的背景以及要做的功能），开发和测试都可以在会上提出自己的想法，不过想法不一定会被SM和PO采纳（但是我们还是会思考一下，并不会无脑拒绝），需求宣讲完，大家就对下迭代要做哪些东西心里有底了，一般需求宣讲前，会提前分配好需求，一般有这么几个分配原则：

• 从职责划分的角度考虑

  • 谁负责的模块优先谁来做
  • 谁有这个能力优先谁来做

• 从团队培养的角度考虑

  • 谁缺少这方面的实践优先给谁做
  • 谁想做优先给谁做

其实我们更热衷于大家自己认领需求，但是这种要求团队里大家的自觉性和积极性要很高（其实很难做到，我也尝试做过，这种情况太理想化了），所以基本上都是靠 SM 主动分配需求，基本上大家也不会有怨言（毕竟上级给下级分配任务理所当然）

4、需求计划会

所谓的计划会，就是排期会，SM会拉通所有人的排期，标准的流程也是全员会，然后SM一个一个的过需求，看大家的排期是否合理，需求完成时间是否可以接受，大家迭代工作是否充实。这样说可能会比较虚，我举个例子吧。

怎么判断排期是否合理，排期的原则有哪些呢？

• 需求角度

  • 合理规范的需求是精准排期的关键，要求产品在输出需求时，场景考虑要足够，需求无歧义，保证需求后期不再做调整。（产品）
  • 合理的需求大小也是精准排期的关键，技术需求要求技术管理者要合理的拆分需求，产品需求要求产品做好拆分，拆分的原则包括但是不限于
    • 可以独立测试验证，具有原子性
    • 单个需求大小不建议超过五天，角色拆分人天不建议超过2天（例如 后端 2 天，前端 2 天，测试 2天，则角色拆分人天为2天）
    • 拆分的需求具有连贯性
    • 主责开发也可以自己合理拆分需求，但是要符合标准，迭代组长会进行分析，看是否可以进一步优化

• 任务角度

  • 把所有需要花费时间的事项都摆到台面上来，例如看历史代码、沟通会议、测试用例评审，如果处理的时间超过0.5h ，任务上必须要有所体现

  • 面向确定需求排期，需求不完整，或者需求没有明确范围，不做具体排期，此时的排期定是不准确的，要求需求完善后，再做时间排期

  • 面向工作时间排期 ，原则上我们不能利用下班时间和周末时间进行需求的排期，这是不合理的，长时间以往，必然会导致长期加班，工作效率低下

  • 单个任务项的时间以1天为宜，原则上不要超过2天，保证任务的原子性 后端同学做任务拆分时，可以以接口为粒度； 前端同学做任务拆分时可以按页面来划分，把页面分解成几个部分的工作，比如UI部分、js逻辑处理部分，BFF接口部分，还有前后端联调，每一部分按实际情况可以做进一步的拆分。 不要遗漏需求当中的非编码类事项。比如技术方案评审、单元测试、前后端联调、codeReview、产品验收等。 时间跨度过大要提出建议，是否应该重新拆分需求。

  • 排期是个人的承诺，大家要自己承诺并且遵守承诺，不能去帮别人排期，只能提供一定的建议

  • 任务排期前期必然有不准确的情况，这是正常的，我们需要基于已有的经验教训，明确自己的能力水平，来协调出符合自己能力的排期，应重点注重提高工作效率。
    希望大家预留一定的时间处理其他事情，保守建议每天预留1～2h 的时间，用来开会沟通，处理问题等等

  • 产品验收任务的排期由测试驱动产品进行验收时间的确认以及跟进

• 人员角度

  • 要明确组内的资源分布情况，原则上每个迭代，开发有6天的开发时间，2天的方案设计，2天的方案评审，涉及实际开发资源的时候，尽量不要占用方案设计和评审的时间，除非该迭代没有需要写方案的需求，那可以使用到方案设计和评审时间，有的时候，利用好那几天做好对应的方案设计和评审
  • 测试人员要明确什么需求影响范围比较大，要搞checklist，一般原则上，跨团队发布的，改动范围大的，需求跨度大的都需要搞checklist，需要做评审，原则上有交互或者逻辑变更的都要写用例并且评审，简单的接口需求可以不评审
  • 当存在插入需求或者是需求太多资源不够时，可以考虑几个方面处理：
    1、剔除低优需求
    2、替换需求
    3、借人
    4、周末加班处理
  • 需求评审会上，就要明确需求的参与角色，是否需要前端、后端、测试参与，会上进行快速分析，不明确的主责人会后去确定，尽量避免做的时候才发现需要其他角色参与，造成需求延期

5、用例评审

并不是所有的需求都需要进行用例评审，一般需要用例评审的需求会有这几个划分标准：
1、影响范围大的需求
2、涉及界面交互逻辑的需求
3、较为复杂的需求

测试写完测试用例后，一般是 xmind形式的，就会叫需求对应的产品和开发进行测试用例的用例确认，如果测试有理解不到位的时候，就可以指出。通过这种方式来确保大家对需求的理解是一致的。

6、发布前checklist

也并不是所有的需求都需要有发布前的checklist，一般这些需求需要：
1、多个团队一起协作的需求，且相互之间有依赖关系
2、开发时间周期比较长的需求，在发布前重新确认一下，避免时间过长出现功能遗忘、用例缺失等异常情况发生
3、影响范围大的需求，也需要 checklist 并且确定好回滚方案

7、每日站会

按照 SCRM 原则，每天早上都要开一个全员会用来同步需求进度，暴露风险。会议的原则如下：
1、只暴露问题，不在会议上讨论解决方案，问题不能发散
2、会议开始前，各成员需要提前刷新 TAPD 上的任务进度，方便管理者了解各需求进度
3、晨会的时间不可太长，尽量控制在15分钟内
4、各成员应该轮流主动的描述自己的需求进度和相关问题，组织者尽量不要用一问一答的模式进行

之所以叫站会，也不是坐会，本质上就是让大家可以高效率的告知需求风险，暴露问题。

在站会前，团队成员应该及时的根据一些原则来准备好自己的发言和排期情况。比如这样。

• 排期自检

  • 需求的任务是否有所缺失（测试、前端、后端）
  • 任务的跨度时间是否合理 （是否跨度过大）
  • 是否存在没有排期的时间 （例如某天没有排任务，要请假可以提前说明）
  • 单天排期时间是否已超过 1 天
  • 是否优先排了高优需求（原则上先排高优，存在问题时要提出）
  • 挂自己身上的需求，哪些需求排不下，要主动群里告知沟通

• 甘特图任务自检

  • 是否存在延期任务，及时刷新，如果存在延期任务，要指出原因（例如是有问题插入，需求交付要风险要明确指出）
  • 测试明确提测节点，如果发现开发还没有提测，要及时反馈
  • 是否存在未排期的时间（如果不是请假），需要提前告知迭代管理者

8、迭代回顾

在每个迭代快要结束的时候，管理者应该再开一个全员会，会议的主要内容如下：

• 需求质量回顾
  分析本次迭代中缺陷的个数和缺陷的原型，避免类似问题重复发生

• 迭代问题回顾
  在迭代过程中各成员遇到的问题，并在会议中讨论解决方案

• 事故复盘（如果有）
  迭代中哪些需求出现了线上事故，需要有明确的复盘文档，并告知整个团队

• 敏捷流程调整
  脱离团队实际讲敏捷，就是耍流氓，因此在不同团队的，对敏捷迭代的执行方式会有一些差别，其他团队合适的我们团队不一定适合，因此，在此会议中，大家可以畅所欲言，认为哪些流程可以优化，SM 会根据大家讨论的结果，结合公司的要求，重新调整迭代节奏

回顾会是不是要每个迭代都要开呢。这个是不一定的，如果你发现团队的迭代回顾会的内容不多，也可以两个迭代开一次，这样也可以减少大家的会议时间。（肯定有很多人讨厌开会的）

在搞迭代回顾的时候，也不一定要SM来组织，为了提高团队成员的积极性，我们可以让团队成员轮流来组织，但是SM需要建立基本的会议要求，比如这样：

1、会议开始前，应该提前准备好会议内容
2、会议时间要严格把控，预计花多少时间，每个模块多少时间，自己要心里有底
3、会议过程中要边听边记，会议主持人同时也是会议记录人，要收集每个人的说法，打草稿，会后梳理总结
4、会议过程中要及时把控会议进度，不该扩散的及时打回
5、开会前要提前一天通知所有人，让参加人员提前预留时间
6、会后要出一份报告，发邮件给全员和相关领导

写了很多。我们简单总结一下整个周期的重要节点吧。

需求规划（开始） -> 需求预评审 -> 需求宣讲- > 需求排期（计划会）-> 方案评审 -> 用例评审 -> 发布前checklist -> 迭代回顾（结束）

六、TAPD的使用规范

通过上面的内容，你基本上已经知道大厂的敏捷迭代是怎么玩的了。
接下来我补充一个内容。当你使用TAPD时。每个需求在整个生命周期中都有相应的状态节点。我们也必须制定一定的规范，才可以更好的使用TAPD。

1、 需求创建

• 用户故事必填（主要是产品&各个需求的创建人）
• 产品需求或者开发上的技术需求，验收标准必填（否则不好权衡需求是否完成，是否达标）
• 需求开始时间不应该是迭代的开始时间，而是需求真正投入工作的时间（由主责人跟进填写）
• 需求结束时间一般为全量发布时间，或者是任务全部完成的时间（需要测试参与的由测试跟进填写，不需要的主责人进行维护）

2、需求评审

• 需求评审前有交互设计的需要先完成原型图（产品）
• 需求评审时，要确定各个需求的主责人
• 需求评审后，各需求主责任开始设计技术方案，并完成技术方案的评审，此时参与方应该花一些时间了解本迭代呈接的需求
• 需求评审后，在排期会前需要完成排期。识别风险需求，并主动提出。

3、需求流转

（以下由各个需求主责人进行流转）

• 待规划：指评审会暂时规划到本迭代，但是各个主责人还没有开始投入
• 已规划待评审：已进行方案设计的排期，但是技术方案仍然未评审
• 已评审待开发：技术方案通过，但是还未进入开发阶段
• 开发中：编码实现中

（以下是测试进行流转）

• 待测试：已提测，但是测试还未介入
• 已测试：测试已在测试环境验证完成，但是未进行生产环境的发布
• 已发布G0/G1 ： 发布到了G0/G1 的环境，还未全量
• 已发布G2：已经全量发布了，即需求【已完成】

所谓的主责人，我也同时建立了对应的规范标准。

七、主责人制度

主责人：负责该需求的整体进度，作为需求的负责人，需要及时反馈风险和最新的进度

在不同场景会有不同的主责人身份：

需求类型	前端资源	后端资源	测试资源	主责人身份
产品需求	是	是	是	后端
产品需求	是	否	是	前端
产品需求	否	是	是	后端
产品方案调研	X	X	X	产品
技术方案调研	是	是	X	后端
技术方案调研	是	否	X	前端
纯后端需求	否	是	是	后端
纯前端需求	是	否	X	前端
测试需求（自动化）	X	X	是	测试

• 在需求评审会后，先确定对应需求的处理人身份。
• 然后在计划会开始之前，确定每个需求的主责人（和处理人可能不同，如需要前后端的需求，但是后端是非关键的节点，那么就是前端主责）
• 主责人在计划会结束前，要提前预支相关的资源（如产品、测试，开发），然后确定好预计提测时间，如果晚于这个时间提测，主责人负责（非正常情况延期需要在迭代回顾会总结，说明原因和具体后续措施，主要是为了后续工作改进）
• 需求进入测试阶段，主责人统一变为测试，开发在约定时间前进行提测，但测试、发布仍延期，由测试负责（非正常情况延期需要在迭代回顾会总结，说明原因和具体后续措施，主要是为了后续工作改进）

八、经验总结

常有人说一百个读者就有一百个哈姆雷特，Scrum 对于不同的公司有着不同的执行过程，甚至相同公司不同团队执行的过程也有所差别，在这里我还是要重点强调一句，适合其他团队的敏捷节奏并不一定适合你的团队，在我刚接触团队管理的时候，我参考了很多组的管理方式，和他们聊应该怎么做，然后模仿他们进行组内尝试，再通过团队成员的磨合，经过很长的时间才找到了我们自己团队的节奏。

但是 Scrum 还是有很多方法论的，主要是要不断的实践和一定的理论知识支撑，再通过大家的不懈努力，才能真正找到一个合适的节奏。

因此，如果你是一个管理者，而且你们团队也打算使用敏捷迭代，那么我希望你不要照搬我的这一套，只能做一定的参考，你必须找到你自己的方式自己的节奏，才能带好你自己的团队。

这几年的管理，我看了很多管理相关的书籍和课程，也基本研究了公司大多数团队的管理方式，从宏观的角度去分析其他团队做的好的地方，好的我们尝试去学习实践，而看着其他团队不好的地方，我们也会自省，避免和他们犯一样的错误。

好的，最后希望你可以成为一名优秀的管理者，一名优秀的 scrum master