本文分享一些技術改進類項目（以下簡稱“技改項目”）的質(zhì)量保障思路窗慎。
技改項目的質(zhì)量挑戰(zhàn)
何為技改項目？即目標是服務于技術改進或架構升級，而非服務于常規(guī)的業(yè)務功能更新。常見的技改項目有：大規(guī)模的前端重構或后端重構狸窘、技術架構升級、數(shù)據(jù)庫拆分坯认、數(shù)據(jù)遷移、系統(tǒng)上云和云遷移氓涣、非對客的支撐性項目等牛哺。（非對客：不直接面對前端用戶的功能，通常是系統(tǒng)的支撐性需求）
為什么這類項目的質(zhì)量保障思路值得單獨討論劳吠？區(qū)別于常見的業(yè)務功能更新引润，這類項目往往都是在保持原有業(yè)務的基礎上進行的底層支持或改造，與以往業(yè)務功能測試的角度不同痒玩，更多的是針對非功能需求的測試淳附。而團隊整體缺乏業(yè)務視角，或對非功能需求的質(zhì)量認知不足蠢古，可能會引發(fā)大量的質(zhì)量風險或缺陷奴曙，破壞已有功能的正常運轉。
另外草讶，技改項目面臨的情況往往比較復雜洽糟，缺失的大量業(yè)務上下文，難以償還的技術債遺產(chǎn)堕战，項目人員往往面臨著一邊做技改坤溃、一邊理業(yè)務的困境。難上加難的是嘱丢，還可能同步進行著現(xiàn)有業(yè)務的擴充或變更薪介，這就更為技術改進類項目的質(zhì)量保障過程雪上加霜。
因此越驻，這類項目的質(zhì)量保障任重而道遠汁政，需要特別對待，從長計議伐谈。
兵馬未動烂完，策略先行
風險驅動整個過程
技改項目好比暗潮涌動的平靜海面，平時不出事诵棵，一出就是大事抠蚣。因此，風險分析和干預應貫穿始終履澳。
常見的質(zhì)量風險盤點如下：
- 低估工作量或研發(fā)過程中的工作量膨脹嘶窄，不能如期上線
- 上線過程不可逆怀跛，有失敗風險
- 破壞既有穩(wěn)定功能
- 影響外部集成系統(tǒng)
- 不可抗力導致上線時間變動，提前或延后
- 質(zhì)量較差造成的大量返工
我們把這些風險放到風險狀態(tài)矩陣中柄冲，可針對不同等級的風險制定不同程度的干預或響應機制吻谋。
構建質(zhì)量防護網(wǎng)
按理來說技改類的代碼變動，類比重構现横，應保證原有功能不被破壞漓拾。但現(xiàn)實往往是“動一行、掛一片”戒祠，“動兩段骇两，修半年”。
在做大規(guī)模的技改前姜盈，構建質(zhì)量防護網(wǎng)尤為重要低千。設計良好的自動化測試能被頻繁執(zhí)行，這就構成了質(zhì)量保障的基礎馏颂。我們詬病于自動化測試的投資回報率低示血，通常是因為用錯了地方。自動化測試應用于需要大量回歸測試的場景救拉，如業(yè)務變量較少的技改類項目难审，會比應用于頻繁開發(fā)新功能的場景更見效也更經(jīng)濟。
除了自動化測試給代碼質(zhì)量的保障近上，還需要人工干預的流程保障剔宪。測試人員應堅守質(zhì)量門禁，即使是一張技術卡或任務卡壹无，也要像對待用戶故事一樣葱绒，堅持開結卡的流程，明確驗收標準和完成定義斗锭，確保已經(jīng)做了的事情都是有效且高質(zhì)量的地淀。
為“不可逆”而設計和預演
試想這樣的場景：常規(guī)的功能發(fā)布，經(jīng)過緊鑼密鼓的上線部署和驗證岖是，突然發(fā)現(xiàn)存在重大問題帮毁，來不及臨時修復，只能回滾豺撑。于是相關的服務回滾后烈疚，測試人員又進行了回歸驗證，確保服務回滾不會造成重大的影響聪轿。為了不影響業(yè)務運轉爷肝，往往只能在非工作時間進行部署，折騰完這一圈可能都是后半夜了，好在有驚無險灯抛。大家盯著轉危為安的軟件金赦，露出了欣慰的笑容。
如果是技改類項目呢对嚼？一樣的過程夹抗，上線→發(fā)現(xiàn)問題→回滾？無法回滾纵竖！若此時遇到問題漠烧，內(nèi)心只有兩個字：“絕望”。技改類項目的特點決定了上線過程基本都是不可逆的一錘子買賣磨确，很少具備有多套生產(chǎn)備份或災備的條件沽甥。因此，技改類項目的開發(fā)乏奥、測試、部署亥曹、基礎設施邓了、上線過程等等一系列研發(fā)活動，都需要為“不可逆”而設計媳瞪，并且應在類生產(chǎn)環(huán)境進行多輪具備多樣性的部署預演骗炉。不能事后補救，只能事前預防蛇受。
業(yè)務視角不能丟
技術改進句葵，并不只是技術范圍內(nèi)的事。除非這部分代碼完全不會在生產(chǎn)環(huán)境運行（當然這種情況也不需要上線）兢仰，否則都需要帶著業(yè)務視角來看待技術改進乍丈。在改進過程中，如何邊改邊保持業(yè)務的穩(wěn)定運行把将，如何確保遷移后的數(shù)據(jù)能在業(yè)務系統(tǒng)里順利流轉轻专，如何保證非對客項目的架構設計滿足業(yè)務系統(tǒng)的支撐性需求？這些問題的探討都不能獨立于技術范圍察蹲，而需要更多業(yè)務側的輸入请垛。
業(yè)務輸入與業(yè)務評審
業(yè)務人員天然具備業(yè)務視角，可以從保證業(yè)務連續(xù)性的角度給技改類項目兩類輸入洽议，一類是業(yè)務知識本身宗收，項目背后的業(yè)務沉淀和業(yè)務重點；另一類是為了保證業(yè)務連續(xù)性亚兄，需要提供的支撐性需求混稽，如可追蹤/留痕、容錯性、高可用需求等荚坞。
在技改過程中挑宠，識別到任何可能影響本系統(tǒng)業(yè)務或集成系統(tǒng)業(yè)務的改動內(nèi)容，都需要組織業(yè)務評審颓影，充分理解業(yè)務背景各淀，再評估改動范圍和風險。
基于風險的業(yè)務優(yōu)先級判斷
資源總是受限诡挂，以追求經(jīng)濟的投資角度來看碎浇，應基于風險來判斷業(yè)務優(yōu)先級，給不同風險等級的業(yè)務璃俗，投入與之匹配的質(zhì)量資源奴璃。如下圖，呈現(xiàn)了基于業(yè)務優(yōu)先級的自動化測試設計城豁。
業(yè)務集成要趁早
如有可能苟穆，盡早集成。應從設計時就進行思考唱星，驗收時依賴的內(nèi)部服務盡量不用mock雳旅。盤點改進點或遷移數(shù)據(jù)的業(yè)務含義；所需覆蓋的業(yè)務場景间聊，盡量以端到端的視角去做技改部分的驗證攒盈。如果早期不考慮集成相關的問題，后期可能面臨的就是大量返工哎榴，甚至推倒重來型豁。這個沉沒成本是不情愿也不應該付出的。
技術實現(xiàn)尚蝌，應知其所以然
深入技術細節(jié)
因技改類項目需維持業(yè)務連續(xù)性迎变，且通常底層變化難以從外部觀測，可測性不高驼壶，因此在做技改類項目的測試和質(zhì)量評估時氏豌，需要深入技術細節(jié)，對具體的實現(xiàn)過程刨根問底热凹。只有深入技術細節(jié)泵喘，才能有效避免“錯誤的輸入經(jīng)由處理后，陰差陽錯地返回了正確的般妙、或看上去正確的輸出”纪铺。
重視非功能需求
非功能需求，也稱跨功能需求或支撐性需求（Non/Cross-functional requirement）碟渺，是指按照一些條件判斷系統(tǒng)運作情形或其特性鲜锚，而不是針對系統(tǒng)特定業(yè)務行為的需求。——維基百科
測試非功能需求的兩大質(zhì)量目標：一是保證系統(tǒng)穩(wěn)定運行芜繁，二是保證系統(tǒng)可持續(xù)發(fā)展旺隙。
- 運行質(zhì)量：可在系統(tǒng)運行時觀察到的質(zhì)量，如安全骏令、性能蔬捷、可用性等
- 發(fā)展質(zhì)量：與軟件系統(tǒng)結構和開發(fā)過程有關的質(zhì)量，如可維護榔袋、可擴展等
技改類項目應更加重視非功能需求：整個改進過程是否破壞了系統(tǒng)原本支持的非功能需求周拐；干系人或用戶對改進后系統(tǒng)的非功能需求預期是否發(fā)生了變化；對已經(jīng)捕捉到的非功能需求凰兑，應能清晰描述驗收標準和期望的系統(tǒng)運行狀態(tài)妥粟。
一些經(jīng)驗教訓
1+1<2
由于技改類項目的特殊性吏够，承擔這類項目研發(fā)工作的大都是研發(fā)骨干勾给，這對項目經(jīng)理提出管理上的挑戰(zhàn)。需警惕“1+1<2”的陷阱锅知，避免頻繁陷入漫無邊際的無意義的技術討論中锦秒。同時兼顧技術決策的投資回報和改進效率，以及核心骨干人員的工作體驗喉镰。陷于類似困境的同事們都能深刻意識到團隊梯隊的重要性，全是資深同事并不利于工作的快速推進和高效管理惭笑。
全局視角
影響技改或被其影響的干系方很多侣姆，技改類項目需要更宏觀的全局視角。不只關注技術沉噩，更關心業(yè)務捺宗；不只關心自己的業(yè)務，也關心是否影響外部集成方的業(yè)務川蒙；不僅關注當下的運行質(zhì)量蚜厉，也關心未來的業(yè)務或架構演進。一句話總結畜眨，這個全局視角需要橫跨技術和業(yè)務昼牛、團隊和干系人，還有時間上的現(xiàn)在和未來康聂。
業(yè)務沉淀的必要性
具備高業(yè)務復雜度的項目一定要做好知識管理贰健，再忙也別忘了抽空做業(yè)務沉淀和知識傳遞。業(yè)務沉淀的必要性就好比人的軟實力恬汁，平時可能看不出差距伶椿，持續(xù)做也似乎成效甚微。但凡遇到復雜度上升或面臨艱難挑戰(zhàn)，管理人員就會發(fā)現(xiàn)脊另，在平時點點滴滴的實踐過程中导狡，業(yè)務上下文的構建和業(yè)務視角的賦能，已經(jīng)在團隊中悄無聲息的完成了偎痛。關鍵時刻方見奇效旱捧。
