文章整理自 PingCode 基础平台部总监 徐子岩 QCon 大会演讲；（大会视频及 PPT 文末获取）

当研发团队发展到新的规模或阶段，原有适应的开发管理模式都会面临新的瓶颈和问题，这个时候就需要去引入新的方式，就比如敏捷、规模化敏捷、OKR、DevOps 等来实现对研发管理的不断优化与改进。这些都是研发管理非常好的模式，但无论是敏捷、DevOps、自动化还是其他的方法，都必须要找到适应自身团队的模式。

本文将分享PingCode团队从 5 人发展到近百人，在发展的不同阶段引入敏捷、DevOps 和自动化等管理方法过程中，遇到的问题以及解决问题的方法，希望能给大家带来一定的启发和借鉴。

团伙时代：不规范 ≠ 不高效 

​

在几个人的团队规模下，开发模式可能是不规范的，但研发效率、进度、质量等一些问题和瓶颈，只有当团队规模扩大才会逐渐阻碍发展。

就比如：开发进度不可控；产品质量差，线上错误多；团队成员被动接收任务，主动性和自驱力差；团队沟通不及时，前后端接口不匹配，重复性工作......这些问题在几个人团队的时候可能根本就不存在，或者说影响很小。但随着团队扩展到几十个人，管理者就会发现，因为这些问题，团队的运转开始出现阻碍，研发效率开始变得低下。

为了解决团队规模不断扩大带来的问题，PingCode 团队在 2017 年开始引入敏捷开发，再后来是 OKR、规模化敏捷，通过不断的尝试与调整，逐渐建立起了从 Scrum 开始到研发线三级目标体系。

敏捷、规模化敏捷与 OKR：从 Scrum 开始到研发线三级目标体系的建立 

敏捷开发

敏捷开发正越来越多地渗透进各行各业，受到不少企业的追捧。但很多企业已经用实践经验向我们证明：落地敏捷会遇到非常多的坑。事实上我们自己也是如此。那么敏捷开发实施过程中有哪些需要注意的坑？又有哪些可行的实践经验呢？

明确 Scrum 当中的三个角色

Product Owner 必须是产品的唯一决策人。Product Owner 可以去听取研发团队的意见、客户的意见、公司高层的意见，但这些意见最终是否被采纳，以及他确定的产品优先级是什么样的，只有他能决定。因为公司高层去对产品规划做调整很可能会导致本次迭代计划的失败。而这时候 Product Owner 必须敢于站出来告诉高层调整将给本次开发带来的风险。

Scrum Master 要确保团队执行 Scrum 流程的正确合理，扫清团队执行 Scrum 遇到的一切障碍。因为 Scrum 流程能否良好运转最关键就在于 Scrum Master。所以，如果是刚开始引入敏捷，建立第一个 Scrum 团队，那么找有经验的人来担任是十分有必要的，比如具有敏捷认证证书或者找行业敏捷专家咨询。并且也不能把 Scrum Master 定义为项目经理，因为两者的职能和所负责的结果并不一样，两个角色的混淆极易造成 Scrum 流程的不正确。

敏捷四个会议

• Sprint Plan -故事点打分：

成员间对任务的熟悉程度不一致，导致打分偏差特别大。在理想的 Scrum 团队中，我们每个成员对功能、技术知识的了解应该都是一样的。但实际上任何团队的成员在技术和产品认知上都会存在差异，这就导致了估算的偏差过大。

那要怎样避免这种问题的发生呢？PingCode 团队提出的一个方法是“专家意见”：当 Product Owner 把一个需求讲解完，首先由对这个需求最了解的人提出一个打分的基准意见，然后大家再基于他的分来打自己的分。如果第一轮打分过后仍出现偏差较大的情况，打分偏差大的人就需要去讨论，自己为什么打这个分数。

但为了避免成员对各自的估算互不相让，陷入无休止的争论，我们又引入了另一种机制：讨论时间不能超过 5 分钟，无论讨论多激烈、是不是讨论完，5 分钟一到必须进行下一轮打分。这样就最大限度地避免了两个人无休无止的说，其他人在旁边无所事事。

如果第二轮打分差异还较大，那么又要开始新一轮讨论、打分，在这个过程中任何团队成员觉得讨论太细节了或者不想听了，都有权利举手打断，要求立即开始打分。基于这样的流程，直到最终达成一致意见。

• Sprint Plan -任务领取 vs 指派：

标准的 Scrum 是不能够去分配任务的，必须是成员自行领取任务，但我们按照标准规则运行一段时间之后，发现它带来了一个新的问题：

能力较弱的成员领取了关键任务，导致风险过大。因为团队成员能力有强有弱，如果一个能力比较弱的成员领了一个特别关键的任务，Product Owner 就会很担心任务完不成，但他又没办法，因为在标准的 Scrum 是不能去分配任务的。

并且，它还会造成另一种情况，就是成员可能长时间无法领取自己感兴趣的任务，积极性受挫。因为有一些成员是非常有技术上进心的，他可能非常想要领一些自己不熟悉的领域或一些自己技术的发展方向的任务。但是他运气不太好，每一次想领的任务都被别人领走了，两三次以后，他的积极性可能就大受打击。

实际上我们并不希望在 Scrum 团队中出现这两种情况。

那这个问题要怎么解决呢？

领取任务为主，适当的指派任务，但是任务指派的时候有非常严格的限制。就比如只有 Product Owner 才能指派任务，只有非常核心的任务或者是成员特别感兴趣的任务，才可酌情指派。并且，这里建议指派比例不要超过 50%；

• Daily Scrum -燃尽图

在 PingCode 服务过的众多 Scrum 团队中，如何让燃尽图变得好看是一个经常被提及的问题，但追求好看的燃尽图是否有意义呢？

燃尽图异常只能代表项目进展可能出现问题，但不一定真的出现问题了，因为燃尽图只是项目健康指标的多个指标之一。

当燃尽图出现不漂亮的情况，我们应该尽快去分析项目是否有风险。如果分析发现项目有问题，比如有些估算是不合理的，就要去重新估算。

但也有另一种情况：我们会发现这个燃尽图虽然不好看，但分析项目并没有任何风险，这个时候我们就没必要去做出调整。

• Sprint Retrospective

无论是敏捷还是 DevOps，我们非常关注的一点就是闭环，而在 Scrum 四个会议能够让流程达成闭环的就是 Sprint Retrospective，所以 Scrum 团队流程、团队运转的情况如何，关键就是看 Sprint Retrospective 开得好不好。而在 Sprint Retrospective 我们遇到过两个特别典型的问题：

回顾会变成批评或自我批评会议。Scrum 一个核心观点是重团队不重个人，如果一个功能没实现是整个团队的问题，而不是说功能负责人或者谁写的代码的问题。所以 Sprint Retrospective 要始终明确是反思团队的问题，而不能反思个人的问题。从另一个角度来看，就是我们的 Sprint Retrospective 要关注流程上的问题而不是结果上的问题。

回顾会变成没人说话的会议。出现这种情况很大一部分原因是性格使然，因为东亚人在这种场合就是不太容易去说话。这种情况下就需要采用一些方法让大家能够更多表述自己的想法，并且要确保提出问题后一定要讨论解决方案，讨论出解决方案后要有负责人，负责人要对这个解决方案进行回顾和检查。

如果遇到没有解决方案的问题，也一定要明确这点，因为没有解决方案也是一种解决方案，这样大家就都会意识到这个事实，并且从其他方面寻找可能的方法。比如有人提出测试人员不足，但此时部门的 HC 是冻结的，就属于这种类型的问题。

只有做到以上几点，才可能让团队成员在 Sprint Retrospective 不断提出项目的问题和看法。

​

PingCode 回顾会专门有个模块去记每一个迭代里面大家提了什么问题，怎么去解决的，负责人是谁。

规模化敏捷与 OKR



实施敏捷开发将近两年的时间，我们的团队规模不断扩大到 50-60 人，这时候我们团队可能不止一个领域的团队，有可能有多个领域的团队，这种情况下，又逐渐开始产生另一些问题：

• 如何协调多个团队的迭代周期

• 跨团队的支持与任务安排

• 研发目标如何统一并落地



为了解决这些问题，我们开始引入规模化敏捷、OKR，并且经过这几年的实践，我们逐渐找到了将规模化敏捷、OKR、敏捷结合的一种方式。当然这里面会涉及到非常多的内容，这里只进行简单的介绍。（欢迎大家通过下方链接与我们建立起联系，进行深入探讨）

我们的 OKR 分为年度目标和季度目标，年度目标是每半年制定一次，年初制定年度目标，然后在年中的时候会对它做一次比较大的修正。因为市场是瞬息万变的，我们不可能评估出一年的研发方向；

在年度目标制定后，我们会进一步拆分出季度目标。在季度目标产生的过程中，我们会产出季度的 OKR 和规模化敏捷中的产品增量数据。也就是在这个阶段。我们的 OKR 和敏捷建立起了关联。因为它会落到我们 PingCode Plan（项目集管理）中具体的史诗及特性。

然后在每个迭代，会通过季度目标产出的产品增量去准备每次迭代的内容，也就是具体的 Spring backlog。通过这一过程，我们把产品规划的史诗和特性，落到敏捷工作项，然后再把工作项不断落到每个迭代。

通过这样一种方式，我们 PingCode 团队整个产研线的目标，一步一步从 OKR 到规模化敏捷的增量再到 Scrum，最后落到我们每一个开发人员具体任务，从而实现从上到下目标一致性。

XP 与流水线：用工程化手段提升研发效能

敏捷、规模化敏捷和 OKR 解决的都是我们研发团队流程问题，但流程问题解决了，团队很大可能还会面临产品的交付质量不高，工程师的开发时间减少的问题。

这些问题又要如何解决呢？在PingCode的实践中发现工程化手段是不错的选择。但由于极限编程跟 DevOps 覆盖的面非常广，所以这里也只能例举几个比较重要的点。

测试驱动开发

打造适合团队的测试驱动开发流程。因为标准的测试开发流程虽然很好，但是对团队的要求过高，而且实际收益并没有理论上的那么大。

所以我们对测试驱动开发的流程做了一定调整。首先我们的业务流程必须得包含测试，就比如：单元测试、集成测试、性能测试、持久性测试这些一系列的测试，然后所有的缺陷修复也必须要包含测试。

另外我们对测试覆盖率也有非常硬性的指标，业务模块覆盖率要求 80%、基础模块要求 90%；

因为我们每一个子产品模块都必须要配置实际集成流水线，代码提交的时候要自动触发这些流水线，进行代码编译、质量分析、单元测试等等，当单元测试覆盖率达不到流水线配置的时候，工程师代码是合不进去的，这也是为什么我们能实现强制的人员测试覆盖率指标。

只有随着业务代码持续更新的测试代码才有意义。我们曾在 2017 年的时候曾经做过一次单元测试的普及，但随着业务代码持续演进、部署压力的增加、上线压力增加，就导致大家写了新功能或者改了旧功能没时间改测试代码，出现测试不过情况就注测试，最后就发展到大家都不测

在这种情况下测试是毫无意义的，但是如果你写了测试，哪怕只有一条测试，你让他随着业务代码持续的通过，都要比你写 100 条 1000 条测试不去维护所带来的团队收益都要大。

Code Review

全员强制要求所有 Commit 操作都必须经过 Code Review 会不会占用大家太多的时间，这是很多团队都比较顾虑的问题，我们在实施的时候也有这样的担忧，所以在全员引入前先用了两个团队试点。

但实践发现，这样做的收益是远远大于成本的，因为它所耗费的时间通常在 5 分钟左右，最长也不过半小时，但对工作质量、团队成员责任心的增长、团队成员对于技术的追求都有明显的帮助。

PingCode Code Review 要求：

• 全员强制的 Code Review

• 通过 GitHub Pull Request

• 持续集成流水线必须通过

• 必须至少一位成员通过 Review

• 提交者负责合并代码

​

PingCode 代码分支：代码试图合并入 devlope 或 master 分支时才必须要做 Code Review

研发自动化：让团队专注于高价值目标的产出

在引入诸多方法解决问题的同时，也随之产生很多的流程、规范以及成员之间的沟通，这也就意味着我们的团队实际上花了很多时间和精力在重复性任务和事务性任务上。

ITChronicles 的一项调查显示，当前的技术工作者一年有将近 69 天都在进行着事务性工作。也就是说，每年全球有将近 5 万亿美金被浪费在了这些重复性的工作中。同样的，在我们对 PingCode 的客户以及国内研发团队的调查中发现，83%的工程师都感到他们的日常工作缺乏效率。研发团队每周都要花费大约 10%的时间来人工处理那些重复性的工作。

因此我们看到，在敏捷开发、规模化敏捷、OKR 等基础上，让团队成员从那些重复性的、事务性的工作中解脱出来，成为了另一个可能提升研发效能的突破点。

在国外，已有不少产品来帮助团队实现研发自动化，如 Jira Automate、MS Power Automate 等，而国内，我们PingCode也在前不久发布了国内首款研发自动化产品。

它对于研发团队的作用与效果可以简单归纳为：

1、通过 Flow 的规则引擎和丰富的链接器，将那些烦闷的、重复性的和事务性的工作从手动操作变为自动触发执行，让团队专注于真正创造用户价值的任务中。

2、即使我们都是使用 Scrum 和 DevOps，不同企业、不同团队、不同部门都有着不尽相同的工作流程。Flow 能够在不破坏通用规则的前提下提供丰富的个性化流程控制，在不增加额外工作量的同时完成复杂各异的场景需求。

3、目前，Flow 能够与 PingCode 全线子产品如 Agile、Testhub 等进行关联，同时也能关联 PingCode 后台系统，服务于整个研发团队。

4、不久的将来，Flow 将突破 PingCode 的限制，连接 Github、Jenkins 等外部系统，让你的整个 DevOps 流程通过 Flow 自动流转。

并且，我们在产品内测的一个月时间里，也发现自动化给团队带来的时间节省是非常可观的。

​最后，总结来说，研发管理方式并没有好与不好，只有适合与不适合。

当大家在考虑自己团队管理方式的时候，一定要从团队出发去找适合的方式，并且一定要明确研发管理的目标：提高产量、提高质量、提高效率，只要能让这三个目标达成，就值得我们继续坚持。如果影响了这三个目标的达成，即便是所谓最标准的 Scrum，那也是没意义的。

欢迎注册体验——智能化研发管理工具PingCode

想获取本次演讲 PPT 及完整演讲视频？

关注公众号 PingCode，回复【敏捷开发】即可获取

​