這是鼎叔的第一百一十篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本公眾號《敏捷測試轉型》，星標收藏，大量原創思考文章陸續推出。本人新書《無測試組織 - 測試團隊的敏捷轉型》已出版（機械工業出版社），文末有連結。
上文 聊聊質量管理工程師的鬱悶https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484687&idx=1&sn=2dd34c5b84a9ced839bf9208ae274582&chksm=c24fb06df538397b8dd79c2462ef7d78f462ac8071301799e6acae874d9cb8bdaa7680001204&scene=21#wechat_redirect，
說到質量保障（QA）工程師的困惑。傳統研發質量的管理體系一直有比較大的侷限性，在敏捷團隊中推動度量常常缺乏成就感。質量管理如果作為獨立處罰型部門，難以產生推動質量內建的文化。兩種環境下的質量觀有哪些關鍵的差異？
一、強調規範文件 VS 弱化文件
傳統 QA 管控團隊的殺手鐧就是一切用書面記錄下來，強調規範化，帶來的文件處理成本很高。而敏捷質量模式則是重溝通、輕文件。文件也可以是輔助交流的生動工具，但不會使用過於死板的形式。團隊內部寫文件更多是為了知識沉澱，在測試方面確保理解場景即可。只有要交付外部客戶時才會對文件做規範處理。
二、嚴格約束角色的許可權 VS 高度信任的管理
因為質量管控的權力大，“以質量和安全為名” 會給日常操作流程的成本層層加碼，卻沒有人大膽做質量控制的減法。在傳統研發公司就會呈現出 “缺乏信任” 的氛圍，很多並非那麼保密的資料非要申請許可權，對合作方員工防範嚴格，進一步造成協同辦公的高成本，但少有人公開質疑這點。
敏捷團隊應該擁有高度信任的氛圍，設定規範的主要目的不是 “限制許可權”，而是鼓勵明智地授權，讓集體交付價值最大化，避免短期衝動衝破健康運營的 “護欄”。
三、各司其職 VS One Team
傳統的軟體度量，因為是建立在 “準確追責” 的基礎上，很容易導致各個角色只關注自己的份內之事，害怕被高管關注到 “短板”。個體的聚焦反而暴露了團隊缺乏互相補位的不足。遺漏到線上的事故，往往不是需求測試不充分，而是跨子領域的協同場景缺乏看護。
敏捷推崇的自組織形式就是 One Team，這並不是要求人人都是全棧高手。而是指每個人不但擅長自己的專業領域，而且能在關鍵時刻互相補位提醒風險。One Team 會帶給成員更好的安全感和更有勇氣的探索嘗試。
四、紅黑榜扣分 VS 團隊集體負責制
傳統質量管控因為要強調令行禁止的紀律，習慣性的建立懲罰型度量機制，比如紅黑榜，出現一次跟進不及時，則扣除績效分，多了會影響獎金回報。這種比較壓抑的氛圍在崇尚自主風格的新生代員工中不能起到提高效率的作用，反而會導致優秀人才的批次流失。
敏捷的 One team 追求集體共擔質量風險，形成內部共識的 “紀律”。就算需要提醒負面現象，通常也是透過有趣的方式去 “懲罰”，如站會遲到的處罰：俯臥撐，買下午茶，表演舞蹈等等。
在回報激勵上，One Team 首先是看一線團隊的整體交付價值大小來分配利益，輔以成員間和客戶的認可度評價，而對內部單一崗位的產出指標度量並不是給回報排序的決定因素。
五、 威權管理者 VS 僕從管理者
在傳統質量管控的導向下，研發團隊的經理會被強化威權，成為研發人員的法官。領導提出了技術意見或者不太合理的評價，員工通常不太敢反駁。這種氛圍會導致研發風險被滯後發現，員工也不敢提出對現狀的大膽變革，因為沒有人保證發起變革就一定會有正向資料，甚至度量變革的指標還會在一段時間內明顯下跌。
曾有一個部門負責人對我說，“你看，部門有幾百號人，如果我不能讓大家聚焦在最核心目標的達成率上，那對公司而言是多大的資源浪費啊！” 而我的回應則是，對於這麼龐大的團隊，如果以領導的意志為指揮棒，以死板的年初考核指標為準繩，那領導個人決策能力就會成為團隊發展的瓶頸，這才會形成真正的浪費。人才因為不敢認領新的挑戰而讓自己的才能被埋沒，從而大規模離職。
敏捷研發時代，誰能保證年初定的目標和考核指標到了年底還是最合理的？這本身就是違反敏捷價值觀的做法。
敏捷價值觀強調的是領導要麼成為明智的干係人，在團隊之外提供資源和建議，但領導的意見僅供團隊參考，團隊應該自主運作；要麼成為團隊的 “僕從領導”，關心團隊當前運作的主要困難，並第一時間尋求解決之道，為員工排憂解難。
這也是鼎叔在聊聊每日站會中認為的，Leader 應該把 “48 小時內發現並著手處理阻塞問題”，作為團隊管理者的敏捷要求。
六、質量至上 VS 有損釋出
在質量至上的 “理所應當” 之下，可能掩蓋研發行為上的低效短板，容忍自動化技術停滯不前。比如，有一個 VIP 客戶向手機測試大領導反饋了一個第三方遊戲的機型適配問題，後面公司制定的改進措施是增加三倍的人工測試員，並覆蓋五倍於目前適配測試覆蓋的第三方遊戲數量，“以降低客戶投訴率”。這就是典型的不計成本的 “提升質量”。但是平均每款遊戲的測試力度是下降了，總成本支出卻大漲了，這樣真的能給公司帶來質量團隊的價值麼？顯然不會，顧客不會為了手機適配測試買單，當市場經營形勢不利時甚至可能帶來 “測試大裁員”。
總之，提升質量卻不考慮成本，就是在 “耍流氓”。背後往往是決策者沒有認真分析遺漏到線上的質量問題的產生根源在哪裡。增加測試的範圍或顆粒度，不一定提高質量問題的攔截率。我們首先需要看看哪些質量提升活動是值得投資的。
那 “有損釋出” 又是什麼概念？
既然敏捷研發的目的是儘快交付使用者價值，我們就不能保證所有缺陷都消滅掉才能釋出，團隊應該集體決策，在釋出時間（價值變現時刻）和品質滿意度上取得平衡。
很多產品都會確立釋出質量標準及衡量指標，但是這些標準不一定是基於使用者價值視角，而是依賴一定的專家經驗。針對不同的產品發展階段，不同的需求優先順序，我們其實可以探索靈活的標準，在區域性場景降低測試力度，或者允許帶有一部分缺陷上線。如圖所示。比如創新型產品，我們允許其帶有更多的非核心體驗上線，試探市場的反應，迅速確定發力方向。
圖 產品特徵四象限
核心產品如果到了關鍵釋出期之前，仍然遺留了較多的缺陷，我們應該集中力量處理必須修復的關鍵缺陷，這部分的質量標準不應降低。但是非關鍵缺陷在後期可以只記錄不處理，以免在驗證不充分的情形下引入更危險的新缺陷。
另外，我們也可以從不同產品的業務特徵來看有損釋出，例如：
UGC 類產品，對於效能要求高，但是準確性要求不高，釋出質量的重點在於展示快，但是畫面顯示內容可以有一些問題（有損）。
電子商務產品，對頁面響應效能要求也高，最終交易結果要讓顧客滿意，但是處理中間過程可以有一定的等待時間（有損）。
金融產品，處理響應可以稍慢（有損），但是展示的金額資料要和預期絕對一致，不能有差錯。
七 對上級管理者負責 VS 對一線團隊負責
QA 作為人數很少的崗位，經常直接對管理層彙報，承接管理者的改進訴求，在傳統公司，QA 對管理者負責是必然的結果。然而在敏捷組織中，對一線團隊負責也是 QA 必須兼顧的價值觀。這兩者如何權衡是一種藝術，因此敏捷團隊中的 QA 需要具備更稀缺的綜合能力。
如何從上傳下達的傳聲筒，變成上下級之間資訊傳遞的橋樑和加速器？
拉通度量指標的共識，並把指標透明化展示，是第一步。多聊聊指標背後的理論、思考邏輯、參考案例、對未來的美好期待。切忌把老闆的質量管理觀點強壓到一線團隊身上。
透過訪談，識別團隊落地改進的幾個最大困難，並迅速確定措施跟進人和定期評估機制，是第二步。系統思考：關鍵指標做得不好，背後的根本原因是什麼？QA 的價值在於挖掘背後的增量資訊（包括主觀判斷），這個沒法依賴自動化平臺了，得點對點溝通。紙面上的資料差距下通常埋藏著更本質的理由。
階段性完成改進動作後的鼓勵、反省、規則化，是第三步。具體改進規則不應該是 “正確的廢話”（對所有團隊都通用），而是針對特定團隊在特定階段的主要風險。
八 強調合同的精準穩定 VS 強調合同的自適應性
這點很有意思，本質上還是傳統協作管理和敏捷協作管理在文件上的觀念差別。
如果我們把合同每個字都摳得非常精細，不準改動，會有什麼結果？
業務需求方一定會一次性把需求都加進去作為約束，不管是不是很需要，因為改合同的成本太高，頻率太低了。開發體量被增大，但是功能體驗感反而被稀釋了。
敏捷的產研合同應該約定的是功能的價值和驗收場景，鼓勵按透過驗收的故事點收費，或按迭代收費可變期限合同。只要有需求釋出就可以支付費用，什麼時候使用者需求滿足了就停止開發，可以提前完成合同。
研發管理規範也是同樣道理。再厲害的專家團隊也不可能一下子給出完善規範，它應該是和團隊充分互動的。
最後，小心——
有的 QA 團隊為了展示自己在質量管理上的專業度，熱衷於在管理層彙報專業報表，把質效指標機制設計得非常宏大複雜，這違背了基本的敏捷規律：
質效改進的工具和看板，應該是迭代演化出來的，像產品一樣簡潔明瞭，它應該適應一線團隊的階段性發展，而不是大幅增加一線團隊的認知負擔。
如何制訂出既完善又高效的敏捷度量指標體系，如何減少指標被濫用的機率，是本專輯後面的文章要詳細闡述的。