“哇这么多人！”
和我领导第一次参加部门例会的感觉类似，我临时顶替版块经理的第一天，第一次发现组里还有同事可以商量事情时候，我有点理解他当时的感受。
2018年5月28日，我带着一个仅有两名实习生的项目，加入了业务测试部。这一天，我意外地收到了很多赞美和鼓励，但我内心是不安的。我明白，这是一个成熟运营的“体系”，我不曾想过会加入它，但在加入它之前，我确实做了很多准备，我获得了ISTQB TM和ScrumMaster的认证，有自信，我明白我要做的事情还很多，姿态必须是一名“追赶者”。
不断打磨的精益团队
一年的时间，我花了大量的心思在团队构建和过程改进上，包括：基础业务培训、敏捷知识宣贯，价值观的建立，质量提升和持续改进，回头来看，结果是欣慰的。现在团队6名外协公司同事，每期CQ单平均20单+，团队找到节奏，产能稳定，年度绩效指标在中心排名前三，过程和产出都按质量规定做好。
团队最大的改变是：建立质量至上的价值观，不作恶不刷绩效；更自律更自信，在交付上更有话语权；测试“驱动”了开发，（迫使）开发项目组改掉很多不良习惯，提升了项目质量。
这方面，我们积累了一些实践经验：
实物看板+数据共享+版本管理
宏观上，实物看板让团队能够轻易对整体目标和进度达成共识，白板+易事贴，轻量级的低成本方案；
微观上，自定义符合团队管理需要的《测试仪表盘》（起个高大上的名字，其实就是一张Excel表），数据来源是一体化平台/CQ/QC，Excel进行二次加工和计算，内容涵盖本期和近期纳入投产计划的CQ单及关键指标，如计划投UAT日期、计划完成日期、执行数、缺陷数、百案例缺陷数、受阻情况等。《测试仪表盘》每日在VSS上更新，内部共享，支持团队决策，站会不会“空对空”，弥补实物看板的不足。
团队协作上，版本管理是重要的技术支撑，如《测试仪表盘》更新，案例修订、风险评估和操作手册编写等。
开放自律的团队
测试任务自领取，测试员从看板和《测试仪表盘》了解组内全局的测试任务，自行领取CQ单，开展测试任务，一般不需要干预。
绩效指标公开，团队的每个测试员都能从《测试仪表盘》看到组内全局的绩效指标，包括每人领取的CQ单数量，编写案例数、执行案例数和缺陷数等。
测试资产整理，不定期将业务流程整理成表格或图，发布在VSS上，积累测试资产，方便业务学习和流程复盘，为测试员组内轮换和测试任务自领取打下基础。
项目回顾总结会
形式：“干货”+零食，重视回顾总结会，提前准备PPT，不官话不批斗，说重点说“干货”；准备零食和饮料，不邀请领导，放心交流和充分分析。
内容：分享成功的实践，指出待改进的不足，投票决定改进方案。
“啊还有这事儿？我要做什么？”
顶替版块经理的这段时间，虽然我做了心理建设，但还是接到了很多让我愕然和不备的电话，主要是我自身的问题，毕竟缺乏这方面的经验。焦头烂额后，我又在想，除了缺乏经（Tao）验（Lu），是不是还缺点什么？
小团队管理及组织治理
常规项目已经形成固定的“仪式”，例如案例审定和风险提示，应对越来越快的投产节奏，我以小见大说几点：
团队粗放，组织治理就是空谈
反馈链长，版块经理了解本期无法完成CQ单需要几步？先问项目经理，项目经理问小组长，小组长问测试员，再层层反馈汇总。
这些数据时效差质量参差，不足以支撑决策，过个半天又发生变化，需重新反馈；小组长也许了解情况，但版块经理或项目经理无法直接掌握，“神经末梢”太远，根本没有感觉，没有抓手。
组织精益，要从小团队精益开始
掌握“数据”，就是“仪表盘”，能够支撑决策的数据都应该纳入，并可视化，每天更新，具体的工程实践有很多，可以是白板或共享电子表格。
缩短反馈链，每天都做反馈，而不是每一期的某一天集中反馈；每个人都参与反馈，每个人都了解决策。
保持危机感，持续自我完善
多了解同行业界情况，不要躺在自己以为的“舒适区”，没有强的求生欲，放弃进步，在这个时代就等于放弃生存。
降低被替代率，传统纯手工的测试，在降本增效的大环境，将会面临巨大的挑战，搞不好就会被替代。
懂业务还要懂技术，拥抱新技术手段，自动化测试、简单小工具开发、数据库知识、数据分析、人工智能等，自我赋能。
“我们需要一辆汽车，但给你的可能是一匹跑得更快的马。”
大规模敏捷
大规模敏捷有很多方法和框架，DevOps是应用最广泛的，是一套为人熟知的实践方法集合和文化价值观，它可以帮助任何规模的组织缩短软件发布周期，提升软件质量、安全及快速获取产品开发反馈的能力。
行业的DevOps之路
互联网大佬们已经走过了持续交付1.0时代，也就是已经打通了交付流水线；现在发展到持续交付2.0时代，即“价值探索环”+“快速验证环”，支持业务快速试错，反馈调整，投入运营，产生商业价值。
DevOps在互联网行业得到了爆发式的发展，已经上升到精神层面，甚至“信仰”输出。
相比之下金融行业就“略显生涩”，银行大多处于DevOps的转型探索，以及工具的使用阶段，要走的路还很长，差距还很大。
我行DevOps的缺失
我行DevOps的起步在金融同业里算比较晚，目前技管部牵头立项的“DevOps提升项目”，主要是搭建我行的“DevOps流水线”。我们通过配合测试，发现问题还有很多，体验还很差。即使“流水线”搭建完成，那也只是DevOps推广中最简单的一步，“重量级”的组织机制和软件架构等方面才是真正要面临的考验：
- 软件架构，系统架构在设计之处并未考虑面向测试和部署。
- 基础设施，需求、开发和测试涉及的开发、构建、配置、部署按瀑布模型设计；需求以RMP承载，开发测试以CQ承载，投产按年初制定的投产窗口投产。
- 组织机制，人员架构和考核方案并未围绕DevOps单独进行设计。
- 核心工程实践，包括DevOps依赖的关键工程实践：配置管理、主干开发、单元测试、持续集成、测试驱动开发以及自动化，并未得到重视和践行。
测试有必要介入DevOps吗？
和许多银行相似，我行现在所有关于DevOps的试点，都称不上真正的DevOps，处于分散的、局部的小团队敏捷，有部分试点的开发团队或测试团队在实施敏捷方法，但并没有形成有组织的大规模敏捷。
即便如此，我依然觉得测试应该介入：
- “质量内建”和“测试驱动开发”是DevOps的核心文化和关键工程实践，测试决定了DevOps的成败，缺少测试还叫什么DevOps？
- DevOps是业界的选择，我行已经起步晚了，而现在是一个契机，一个举各方力量推进大规模敏捷的机会，一个让测试更好发挥作用、体现专业价值的机会。
- 不要因为现在还不是一辆“汽车”，就放弃拥有一匹“更快的马”，因为“测试前移”是任何软件测试项目都适用的工程实践，DevOps项目的先行，可以为常规项目带来成功的实践经验。
测试介入DevOps需要什么？
基本的认知
“DevOps是什么？”
DevOps是一种工作流程，通过调动组织成员的价值观和使命感，激发成员达成更高效能，促进广泛的组织变更。说人话，DevOps就是一个开发测试运维都遵守的“大套路”，它不是什么洪水猛兽。
“DevOps有什么好处？”
DevOps将提升团队和组织的效率，实现业务需求到功能上线的端到端快速交付，为我行业务发展赋能。说人话，研发团队（开发+测试）会变得更高效，测试前移并驱动开发，提升产品质量。
“有了DevOps我们会更轻松吗？”
一开始并不会。如果把常规项目比作篮球比赛里的阵地进攻打法，那么DevOps就像全场紧逼打法，后者对于观众来说，比赛节奏更快，对抗更激烈，观赏性更高，对于落后一方的球队，有更大的机会赢得比赛，但对于运动员，需要更好的配合，并付出更多的体能，对于教练员，需要更好的战术指导素养。
实施DevOps的目的，是把更多的企业价值，以更快的方式传递给客户，客户和企业自身是直接的受益方，而企业内部，需要让组织治理更规范，引导协作团队变得更自律。
“DevOps能推进测试进度和提高关单率吗？”
长期来说会，这是DevOps的目标，DevOps建设不会一蹴而就，需要一个持续改进过程。
道理都懂，可是当下常规项目的考核怎么办？这种顾虑本质上还是没有接受DevOps，觉得是“我要”试点，可以“配合”但有“底线”，常规项目才是“正业”，眼神里想说我就是来和常规项目“抢人”的吧？
培养专业的测试骨干
参与DevOps项目试点，积累敏捷测试项目的经验，培养中心的测试骨干。
- 面向业务方向，要求熟悉业务，从需求分析中正确拆分测试验收条件，指导测试案例编写；带领测试人员开展UAT测试，把控测试进度和风险预警；参加各种敏捷快速会议，反馈问题；从小组长中挑选，向测试团队长、业务专家方向培养。
- 面向团队方向，要求熟悉敏捷方法，构建可视化的精益看板，构建轻量可控的过程管理和质量管理；主持或参加各类敏捷快速会议，分析问题并做出决策，保持团队按敏捷的节奏协同工作；与业务及开发沟通协同工作；从项目经理中挑选，向敏捷教练方向培养。
基础理论培训及实践
- 技管部在试点前期会有集中的基础理论培训和沙盘演练，骨干成员应该重点参加。
- DevOps项目每期项目回顾会，重点总结经验和改进事项，积累实践经验，形成中心资产。
- 后续其他试点DevOps项目团队成员，通过其他成员传帮带，以及成功的实践，边干边学。
相匹配的考核与激励
- 为DevOps项目匹配相应的考核指标，例如：“测试前移”将增加测试团队的工作量，需增设相应指标；迭代周期未必与CQ平台的开发测试计划吻合，需放宽部分考核指标。
- 为DevOps项目设计相应的仪式及过程，例如：迭代规划会议、敏捷快速会议；一体化平台应与DevOps平台对接。
- 鼓励团队成员拥有大规模敏捷相关的资质认证，例如：统一组织培训及认证。
DevOps项目工作设想
构建敏捷测试团队
首先最关键的，是中心上下对敏捷、对DevOps有基本认知，不是为了配合谁来推广，没有不变的常态，即使常规项目也有测试前移的必要。
虽说不和常规项目组“抢人”，但真的需要人员来践行我们的想法，而且对配备的骨干人员有一定要求，对业务对产品要熟，测试前移时，要与业务和技术进行有效的沟通，对测试和质量提出专业意见，不是为了前移而前移。
开展有效测试前移（测试驱动开发）
从中心层面，让测试团队与DevOps试点项目对口的业务部门、开发项目组及需求分析部门对接。
形成固定的工作模式，从需求提交形成RMP，总工办拆分需求之前，必须让业务、开发和测试三方对需求拆分、投产（迭代）周期达成共识。
测试团队参与业务及开发的相关讨论或会议，包括需求澄清、需求变更等，并编写验收条件（测试大纲）及验证案例，“测试即需求”，三方确认，达成共识。
测试团队在开发项目组开发完成投UAT之前，完成正面及页面案例的编写，三方确认，达成共识。
测试团队参与开发项目组的敏捷快速会议，对UAT测试中存在的缺陷以及需要支持的问题，进行面对面沟通，对可能延期的功能进行当面提示。
高频回归自动化
（尽可能）将一切自动化，帮助测试团队减负，逐步积累和完善高频回归的自动化案例库。