Hello! Big Agile! - 哈啰的大规模敏捷实践 (下)
前面我们花了两篇文章的篇幅，跟大家详细分析了哈啰在大规模敏捷组织中所面临的4大挑战，究其核心是需要解决以下两个问题：
挑战1~3是需要在大型组织中建立一个高效的沟通及决策机制；
挑战4是需要建立一个合理的评价体系。
在中篇中我们介绍了，挑战1~3是通过运用敏捷模式本身的特点做了补强来处理，那么很自然的“X”就是应对挑战4的办法。
我们今天单独来聊聊这个“X”。
其实答案也并没有那么神秘。这个“X”就是哈啰的研发效能度量体系。
为什么需要度量
一位管理学泰斗曾经说过：
你如果无法度量它，就无法管理它。
- 彼得.德鲁克
笔者认为，流程是因应“更大范围的协作”而产生的。一个好的流程不应该是一个静态的“项目”的概念：流程设计好了，宣讲完了，开始执行就算“结项”，万事大吉了；而应该是一个动态的“运营”的概念。流程在落地的过程中，流程制定者应该要能够判断流程执行的是否有效，是否需要进行微调......
所以，并非大型组织都希望用一堆条条框框来限制团队的行为，这是大规模团队协同的必然内在要求。而度量体系的建立，是保持和优化相关流程的必然选择。
在研发团队同样如此，不管你是用传统的开发方式，还是敏捷方式。在大规模团队中，你不可能单凭感觉来判断团队是否高效，是否在持续优化，必须要建立研发效能的度量体系。
研发效能为什么难度量
为什么笔者前文一直遮遮掩掩，用“X”来代指研发效能度量体系？因为研发效能确实非常难以度量，弄不好对于团队协同不是“+X”，反而起到“-X”的反效果。
为什么难？
首先，研发是一项非常复杂的创造性活动。研发人员其实并不是在“Devlop”（开发），而是在“Invent”（发明）：产出物无法像流水线上生产的零件那样标准化，往往是独一无二的，所以难以定量的评价其优劣。
其次，影响研发效率的因素非常多。研发的全流程涉及到的环节和角色非常多，不同阶段的产出物又大都非常抽象，容易发生变化和理解偏差。即便是开发同样的产品，因为项目组规模、项目时间、项目成员等的不同，其实施结果可能会完全不同。
最后，如果度量的使用场景不对，往往造成更大的灾难。在业界，研发度量指标“翻车”的例子比比皆是：
是不是看着特别傻？这也是“程序猿们”对于“度量”这件事比较抵触的原因之一--太扯了。
我们再举一个具体例子来帮助大家理解。
比如“千行代码BUG率”（= 发现的BUG数量/代码总行数），这应该是一个业内比较认同和普遍使用的一个软件质量度量指标。即便如此，这个指标本身的“质量”并不高：
把简洁的代码写复杂，用扩大分母的办法降低指标数值，“提升”软件质量......
来了一个测试小白，对于产品逻辑不熟悉，愣没发现作为“分子”的BUG：于是“霹雳一声震天响，给零缺陷代码鼓鼓掌”......
超越公式之外：代码上线后确实工作的很完美，但稍微有个小的需求调整就狂出BUG，让后面维护的人战战兢兢，如履薄冰......你好意思说这是高质量软件？
正是因为上述原因，虽然我们都知道要做“研发效能度量”，却往往还是“过不好自己的人生”。
笔者认为，要做好研发效能度量，首先必须要明确一些基本原则，才能够有的放矢，事半功倍。
研发效能度量的基本原则
- 原则一：度量注重团队输出而不是个人输出
因为研发是一个多角色长链路的工作，往往一个环节的工作质量会直接影响下一个环节，甚至最终结果，且每个环节的输出往往无法马上检验其质量好坏，这与流水线上的工序有着天差地别，我们无法应用工业化思维来做软件研发的度量。
所以，我们做研发效能度量的时候，应该系统性而非局部性的去思考问题。单一度量某个角色或者个人的输出往往意义不大，应该从团队的维度来设计相关指标。
- 原则二：度量指标解读注重趋势而非绝对数值
在大型研发团队中，因为团队的多样性，指标的绝对数值代表的意义往往很难做到“一刀切”的精确定义。如果我们无法“精确”，就不要强求，基本准确就好，没有必要为了“0.5”的差别究竟是多少大伤脑筋。
相应的，如果我们不对“绝对数值”过份纠结，而更多的对度量指标去做趋势的解读，往往相对更容易被接受，使团队的焦点始终放在如何进一步改善上，而不是度量指标本身的合理性上。
- 原则三：度量结果不直接应用于个人绩效
最后一点，笔者个人认为也是最重要的一点。
许多“翻车事件”都是因为将某些度量指标与研发人员个人绩效直接挂钩，导致度量变成了笑话。
参考原则一，因为研发人员的工作结果衡量有难度，所以类似流水线上的工人或者销售人员那种以KPI的方式，简单将度量指标与绩效挂钩的方式非常不适合研发人员。“墙裂”建议不要这么干。
哈啰是如何做的？
另一位管理学“太逗”曾经说过：
大型组织都需要度量，使用敏捷的方式相对更容易一点。
- 尼古拉斯.大鼻子
为什么这么说？我们具体来看：
传统项目方式，项目团队是临时的：项目消失，项目团队解散。同时，项目的时间跨度又不相同，所以持续衡量团队输出比较困难。
敏捷团队就不一样。团队人员基本固定，迭代周期也规定。除非团队成员突然“跌落山崖，碰到世外高人将毕生绝学倾囊相授”，否则团队的整体输出应该是稳定的。敏捷的工作方式的特点，排除了团队组成和周期等干扰因素，更容易定量的去做团队度量以及趋势的判断。
另外，敏捷的一些特殊“发明”体现了敏捷团队度量重趋势而轻绝对值的特点。比如故事点，不同团队的故事点的绝对数值代表的工作量可能不尽相同，在不同团队之间比较绝对数值值没有太大意义，但故事点的趋势变化则可以反应同样一只团队的表现是否有起伏。
以上这些默认设定都完美匹配了研发效能度量的“原则一”和“原则二”。
另外，敏捷框架贯穿始终的理念是强调“团队绩效”：比如，跨职能团队和鼓励团队成员自主挑选任务等。
如果推崇的是个人绩效，团队成员不会主动去承担自己不熟悉或者从未尝试的工作内容，因为“不安全”，“多一事不如少一事”。这又与“原则三”比较契合。
因为......所以......尼古拉斯.大鼻子没有骗人啦。^_^
哈啰具体是怎么做的呢？我们从以下两个方面分别介绍：
Sprint报告：以定量评价为主，注重事“干”的怎么样
在每个Sprint结束之后，每个Team的Scrum Master会跟团队一起输出一个Sprint报告。在报告中，将Sprint进行中的一些过程和结果性度量指标做呈现，用为作团队Retro的输出物之一，帮助团队更好的分析下一步需要提升的方向。
以下挑选几个比较有代表性的内容跟大家示例一下。
- 问：敏捷团队人员都是固定的，为什么要记录人员配比？
答：理想是美好的，现实是骨感的。哪有不缺资源的研发团队？哈啰也不例外。在某些资源紧张的时候，虽然我们也鼓励团队成员去承担一些其他角色的任务，比如研发交叉测试对方的功能等，但部分业务线的Scrum团队中的资源就是没办法固定（尤其是前端和测试这两个角色），无法避免的出现资源跨Team的情况。
在这种现实面前，我们可以暂时的妥协，来点“Scrum But”。但是作为敏捷教练，你一定要清楚这是一种“非正常”状态，所以我们会记录一下不同角色的人员组成，对照团队的在Sprint实际表现分析这种配比情况是否正常，是否需要改善。
- 问：什么是Brake？
答：Brake是我们发明的一个指标，是指Sprint Kickoff以后因为产品或者业务需求变更导致的额外的工作量。这下你终于明白我为什么一定要求Team发这封“垃圾邮件”的原因了吧？
Brake的中文意思是“刹车”，这其实是一个中性的描述。有驾驶经验的同学应该都清楚，如果车子就要撞墙了，踩刹车是一个非常必要的选择；但是如果没有紧急情况，车子行进过程中频繁踩刹车会比较耗油，带来额外的成本。
我们是通过记录这个指标来对Srpint进行中的需求变更做一个记录。变更其实应该是一个“中性”的词，碰到紧急情况变化其实是有益的，不能说Sprint是受保护的，需求绝对不能变。
也就是说，我们不期望每个Sprint的Brake都是0。但是如果这个值太高，必然影响团队的交付速度，团队肯定是要找产品和业务“讨个说法”的。
- 问：为什么统计需求池的情况？
答：作为研发团队，你一定确定以及肯定会听到业务方这样的吐槽：“需求太多了，研发速度太慢跟不上，要加资源”。其实这种吐槽多半是缺少数据支撑的“观点”而并非事实。
在敏捷模式下，研发团队的需求是有初步估算并放入需求池的，而研发团队一个Sprint可以做多少个“故事点”可以参考历史经验，基本是可以估计。
加上敏捷迭代周期固定，这样就能够很方便的估算出，目前“积压”的需求需要多少个Sprint可以完成。
我们的实践经验说明，需求池中放至2~4个Sprint的需求（1~2个月）都属于正常范围，无需增加研发资源。
如果小于2，无论业务侧有多少想法，数据说明，这些想法并未成为研发可以开始实施的需求（表中的团队对应的这个值是0.23），说明业务和产品需要加速需求输出啦；
如果大于4，一种可能是研发资源确实不够，需要补充；二则有可能在需求池里的部分需求“待得太久”，一直优先级不够高，可能已经“过期”无需再让研发实现了，需要及时清理。
我们就是通过“需求池大小”这个指标来量化需求积压的实际情况，同时可以过滤一些过了很久都排不上优先级、实际上已经没有实现价值的需求。
图中另外两个指标分别是Velocity和投入度，这个就是Scrum里面的含义，这里就不解释啦。图中的团队，这两个指标是稳中有升棒棒哒！
速度指标和质量指标的结合，才能说明“效能”如何。所以一定要有与质量相关的指标体现。
第一个图表是不同环境中发现Bug的情况。我们都清楚，越晚发现Bug，解决成本越高，通过这个指标鼓励团队成员在正式提测之前充分做好自测，减少在测试阶段的Bug数量。
需要特别说明一下的是第三个图表，是问题解决速率。有一个明显的大提升，这个是因为引入JIRA后，同学们还不太习惯及时在JIRA里面修改Bug状态，导致统计数字有些失真。
在做了一些引导和通过一些技术手段（比如不填JIRA里的Bug号就无法提交）之后，团队基本养成了习惯，所以后面的数据反映的是较为实际的情况。
这个例子说明，我们也可以通过数据的统计来推动团队的行为规范的达成(报告就从JIRA里拉数据，不做修正)，毕竟有哪个程序猿愿意被人说修Bug慢呢？
Sprint报告中相关指标的整理是为了团队Sprint Retro的输入，在报告中当然少不了Retro Meeting开过之后的总结。Scrum Master 会跟团队一起完成这部分的内容，对于下个Sprint的改进方向有个明确的结论。
需要特别说明的是，在报告指标基本稳定后，我们专门开发了一个小工具来从JIRA里提取数据来自动生成上述图表，Scrum Master可以根据图表和实际的工作情况来在线填写总结的内容，最终生成一个完整的网页版报告。
以此来节约Scrum Master的时间，也方便团队和其他相关的人员查阅。
注：以上仅为日常Sprint报告中经常使用的较为重要的度量指标，并非完整的哈啰研发效能度量体系。
在敏捷模式下，工作的最小单元是敏捷团队。当每个团队的相关指标度量完毕后，就非常容易的叠加出某个产品，某个业务线，乃至于整个研发团队的效能情况和变化趋势了。
敏捷模式是一个更注重团队成长的模式，除了关注事情做的如何，我们更需要关注“人”，关注团队有没有持续成长。
如果说"Sprint报告“ 是对于单个团队“定量”的Retro，那么“敏捷成熟度”就是对于团队和组织“定性”的Retro。
敏捷成熟度：以定性评价为辅，注重“人”“过”的好不好
哈啰敏捷成熟度模型是我们参考业内成熟度考量标准，结合哈啰本身的特点，从五个基本维度（敏捷活动、团队建设、工程实践、敏捷文化和交付价值）出发，形成的一套衡量敏捷团队成熟度的工具。
简单来说，我们会以季度为单位对于所有Scrum团队做一个简短的调查问卷。并根据团队成员的回答结合Scrum Master的判断来最终形成一个敏捷成熟度的报告，定性的说明团队处于哪一个敏捷成熟度。
我们希望通过这种方式，能让团队有不断成长的目标，大家一起朝着“敏捷梦之队“的方向迈进。
其中L4表示团队基本可以达到自组织状态，是一只比较成熟的敏捷研发团队。
我们同时可以分析不同级别队伍数量在产品、业务线、整个组织的比例及变化情况，定性的来掌握组织变化的趋势，并根据不同团队的特点，有的放矢的制定调整方案。
综上，哈啰就是通过“Sprint报告”和“敏捷成熟度”来对组织做定量以及定性的分析，通过长期观察和分析累积的数据，来识别组织在协作当中的瓶颈和掌握组织的效能变化，从而及时有效的优化和干预。
通过过往的数据来决定下一步的行动，我想这也是敏捷这种“经验型”的管理模式较为科学的一面吧。
写在最后
我们用三篇小短文的篇幅，跟大家一起详细探讨了哈啰研发团队在发展中遇到的挑战，以及因应这些挑战的一些具体实践，希望能对各位有些借鉴作用，也欢迎各位“大佬”斧正。
文末，想跳开主题，聊点别的。
作为大型组织流程的制定者和执行者，PMO的责任重大。有两点是格外需要留意的：
不“迷”信，不“盲”从，适合的才是最好的
笔者在担任Scrum Master的时候经常提醒自己的一句话就是：“每个团队都是不同的”，在大规模组织中更是如此：不同的组织有不同的特点，甚至同一组织在发展的不同阶段亦有不一样的诉求。
这就要求我们在制定相关流程的时候更加谨慎，选择真正适合团队当下情况的协同模式。
拿大规模敏捷来说，千万不能“言必及LeSS，不提SAFe就显low，只有沾上Spotify才显得高大上”。
当然，不“迷”信，不“盲”从，并非完全“不信，不从”。博采众家之长，为我所用，才是正道。
拿哈啰的模式来说，我个人感觉是整体比较像"LeSS‘’，从SAFe借来了“拉毛线”，与Spotify的团队组织雷同，同时借鉴了Spotify系统架构优化包括团队文化建设的思路。
此外，依我判断，目前暂不具备朝SAFe过渡的条件；另，因为企业产品特性的问题，可能永远也无法完全长成Spotify.....但不妨碍我们按照目前的思路一步一步往前走，Check and Balance。
再啰嗦一句，在大型组织中，如果想走敏捷的路，说一千道一万，先把单个团队的敏捷基础做牢，这是一切大规模敏捷框架的基础。接着可以用“LeSS起步，SAFe挂挡，始终瞄着Sptify”，“四不像”没什么要紧。
流程需要运营，要有“随时知道我们在哪里”的方法
犹为关键的是，PMO一定要意识到流程的建设是一个运营的概念。
仅仅引入一种框架是不够的，随着情况的变化，团队的变化，原有的流程可能会逐渐不适合新的形式，甚至事实上走向“消亡”。
我们一定要具备“随时知道我们在哪里的”方法：运用度量的手段，通过数据驱动的方式来掌握现状，决定下一步的行动方向。流程建设也可以“敏捷”起来，用迭代的方式去进行，不是么？
最后，我想说，无论你使用的是LeSS，SAFe，还是打算跟Spotify学，亦或者压根使用的不是敏捷模式，都需要有成体系的研发效能度量的方法去支撑整个“系统”的运转。
这才是这个系列主题，笔者希望传递给大家最最重要的观点，没有之一。
诚然，在实际工作中，任何变革都不会一帆风顺，或许我们会遭遇到不理解、挑战甚至阻挠；或许我们也不可避免的受到“企业重力”的影响：一夕之间因为某个变故，以前的心血全部付之东流。
但作为PMO，我们一定要比团队成员更坚定，比项目经理更皮实，要始终保护好自己内心的那一束光：我们的价值就是让团队更有效率的协同，更有成就感的工作；进而通过成就他人，来成就自己。
与各位PMO同仁共勉。
