文章整理自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，回复【敏捷开发】即可获取

QCon演讲| 从团伙到团队，PingCode研发团队敏捷实践血泪史相关推荐

Qcon演讲实录|手机淘宝客户端的攻防演练实践
混沌工程是一个业界比较流行的防范系统性风险的方法论, 其核心思想是通过不断地失败来避免失败,以主动制造故障的方法来宏观地验证业务的容灾和恢复能力.这一概念在服务端存在大量的实践和落地, 在客户端还是属 ...
一个研发团队是如何坚持7年技术分享的？
--"所有分享都是有意义的" --"在PingCode,人人都可以成为分享者" 这是PingCode研发团队的分享精神,而这样的精神,在过去7年中已经闪耀了10 ...
中小型研发团队架构实践三要点--转
来自微信公众号聊聊架构作者|张辉清编辑|雨多田光如果你正好处在中小型研发团队-- 中小型研发团队很多,而社区在中小型研发团队架构实践方面的探讨却很少.中小型研发团队特别是 50 至 200 人的 ...
中小型研发团队架构实践三要点(转自原携程架构师张辉清)
如果你正好处在中小型研发团队-- 中小型研发团队很多,而社区在中小型研发团队架构实践方面的探讨却很少.中小型研发团队特别是 50 至 200 人的研发团队,在早期的业务探索阶段,更多关注业务逻辑,快速 ...
打造高效研发团队 (1) —— 组织架构篇
原文:https://my.oschina.net/huangyong/blog/1812037 2015 年,我加入特赞,带领了一支小规模研发团队.那时公司还在天使轮,团队最大的目标是能让产品上线, ...
中小型研发团队架构实践三要点
如果你正好处在中小型研发团队-- 中小型研发团队很多,而社区在中小型研发团队架构实践方面的探讨却很少.中小型研发团队特别是 50 至 200 人的研发团队,在早期的业务探索阶段,更多关注业务逻辑,快速 ...
携程千人规模团队研发效能提升实践
来源:携程技术作者简介 Mia ,携程高级项目经理,负责酒店Devops实践,关注Devops/敏捷等领域. YY,携程敏捷教练,负责团队敏捷转型,研发效能提升实践,关注Agile.Devops.研 ...
PingCode与Jira 敏捷开发管理能力的对比
敏捷开发是一种以拥抱用户需求为核心.采用不断迭代的方式进行的软件开发模式,依靠自组织的跨职能小团队,在短周期内通过快速.频繁的迭代,迅速的获取反馈,进而不断的完善产品,给用户带来更大的价值. 虽然敏捷 ...
阿里内贸团队敏捷实践
2019独角兽企业重金招聘Python工程师标准>>> 一.阿里内贸团队敏捷实践 -- 开篇本实践是原阿里巴巴ITU内贸团队打造出的一系列适合团队不断精进的敏捷实践.阿里内贸团队是 ...

QCon演讲| 从团伙到团队，PingCode研发团队敏捷实践血泪史