優先改進哪個點：捏軟柿子還是啃硬骨頭？

如果能發現“要害點”，作爲優先改進的點，且有方法來“啃硬骨頭”，那麼就能讓持續改進切中要害，成效更大。

實踐敏捷、精益或 DevOps 的團隊，都在進行“持續改進”。但在持續改進中，會面臨兩個痛點：

找不到起始點 ：不知道該優先改進哪個點，感覺沒有方向；
啃不下硬骨頭 ：優先選的點改進成本太高，讓人望而卻步。

如果發現改進起始點這塊“骨頭”太硬，你是不是想換一個“軟一點的柿子”，作爲改進的第一步？

如果按這個思路進行改進，那麼成本高的改進點是不是就一直沒有機會被改進？這就解釋了爲什麼很多團隊只做低成本的代碼層面的重構，但很少進行軟件系統架構和基礎設施這些成本高的改進。

如果能發現“要害點”，作爲優先改進的點，且有方法來“啃硬骨頭”，那麼就能讓持續改進切中要害，成效更大。

要想達到這個目的，首先要解決“找不到起始點，啃不下硬骨頭”這兩個問題。

找到起始點，啃下硬骨頭

先說解決方案，可以用“優先改進象限”來識別改進的起始點，用“敏捷階梯模型”來啃下硬骨頭。

優先改進象限，有兩個座標軸，橫軸越往右，表示質量越差；縱軸越往上，表示價值越大。改進的起始點，應該是價值最大，質量最差的那個待改進點。

敏捷階梯模型，表示團隊在互信的基礎上，以消除“價值最大、質量最差”這個最大瓶頸爲願景，“儘早、頻繁、小批”地進行 PDCA（Plan/Do/Check/Adjust）迭代，一個迭代進步一點地進行改進。

我創造“優先改進象限”，是受了技術債牆的啓發。償還技術債也是在做持續改進，所以道理是相通的，但技術債牆很容易被團隊誤用。

在這個技術債牆四象限中，右下角“投入少、見效多（止痛多）”的技術債優先償還，而左上角“投入多、見效少（止痛少）“的技術債就不值得償還。

人人都願意做“投入少，見效多”的事情。但就如同繪製該圖的博客作者所說，在他們回顧技術債時，發現“投入少、見效多（止痛多）”的技術債很少。作者的解釋是他們在日常工作中，已經順手把這類技術債給償還了，所以這是個好現象。

但好現象後面隱藏着危機：對於右上角“投入多、見效多（止痛多）”的技術債，該如何處理？那篇博客沒有提及。

這就是技術債牆四象限容易被誤用的地方：團隊往往只關注“投入少、見效多”的技術債，而對“投入多、見效多”的則視而不見。

如何償還“投入多、見效多”的債？

比較好的做法，是將右上角“投入多、見效多”的大技術債，拆分成“投入少，見效多”的小技術債，並移至右下角的象限，參考“敏捷階梯模型“，儘早、頻繁、小批地償還。

比如，一個團隊在維護一個有 10 餘年歷史的遺留系統。該系統 80% 的業務邏輯都寫在了難以維護的 PL/SQL 裏面，不僅很難閱讀、重構和編寫單元測試，其中還有大量的重複代碼。將 PL/SQL 中的業務邏輯，改造成易於閱讀、重構和編寫單元測試，就應該屬於償還“投入多，見效多”的技術債。

由於該遺留系統 80% 的業務邏輯，都寫在 PL/SQL 裏面了。要想在短期內治理全部 PL/SQL 的業務邏輯難以維護的問題，是不可能的。但可以使用“優先改進象限”，先識別出價值最大的幾個業務邏輯，再從中識別出質量最差（多次出現生產事故）的一個業務邏輯，做爲改進的第一步。然後就可以集中優勢資源，集中治理這一個業務邏輯的維護性差的問題。比如可以考慮使用 PL/SQL 轉 Java 的工具，將業務邏輯轉移 Java 中，並編寫單元測試並重構。如果能解決這個 PL/SQL 的業務邏輯難以維護的問題，那麼就能讓這個曾經多次出現生產事故的“髒亂差”，變成易於維護且高價值的“首善之區”。這樣還能增強團隊士氣，促使大家識別下一個“價值最大、質量最差”的改進點，從而形成正反饋循環。

除了技術債牆的啓發，Jim Highsmith 的敏捷三角，也啓發了我創造出“優先改進象限”。

既然敏捷三角告訴我們，敏捷團隊工作的主要目標，應該是價值和質量，而不僅僅是“範圍、時間、成本”，那麼當進行持續改進時，首先要改進的點，也自然是價值最大，且質量最差的。因爲只有這樣，才能更有效地達成追求”價值和質量“的目標。

除技術債牆之外，另一個常用的識別優先改進點的思路，是使用約束理論。即先繪製價值流圖，標上各道工序的增值時間、等待時間和返工時間，並據此識別系統中最大的瓶頸。之後優先將這個最大的瓶頸“擴容”。等“擴容”後，再識別下一個最大的瓶頸，循環往復。但在軟件開發相關的持續改進中，尤其是當要治理一個大泥球系統時，經常會面臨深陷“泥潭”的局面，哪裏都有問題，難以找到最大的瓶頸。另外，如果團隊使用大批量交付的瀑布式開發方式，那麼就難以蒐集和度量增值時間、等待時間和返工時間這些識別瓶頸的數據，讓瓶頸識別難上加難。

此時如果使用”優先改進象限“，那麼識別出來的”價值最大、質量最差“的改進點，在大概率上是系統的最大瓶頸。這是因爲，”價值最大“，意味着改進點位於價值流的主幹上；”質量最差“，意味着返工最多（價值往回流，浪費很驚人），可以視作價值流動最大的瓶頸。所以，使用”優先改進象限“，可以快速地找到系統的返工的巨大瓶頸，有”投資少、見效快“的好處。

“優先改進象限”該如何落地？

可以召集團隊所有成員，召開“優先改進工作坊“，一起繪製“優先改進象限”。

團隊成員全員參與“優先改進工作坊“，一方面能提高優先改進點的識別準確率，另一方面能增強團隊成員改進的主動性，有助於改進的落地。

工作坊主持人可以參照下面的方法，來主持“優先改進工作坊”：

召集團隊所有成員；
每人把痛點寫在便利貼上，每個便利貼只寫一個痛點，貼到白板上，合併相同的點，然後分類；
先按價值大小，上下排序（可以衆人排隊，每人一次只能移動一個改進點的上下順序，輪流進行，直到不再有改進點的移動）；
再按質量優劣，左右排序（可以衆人排隊，每人一次只能移動一個改進點的左右順序，輪流進行，直到不再有改進點的移動）；
右上角的痛點，就是優先改進點；
大家討論，如何用敏捷階梯模型，儘早、頻繁、小批地改進剛剛識別出的“優先改進點”；
定期舉辦優先改進工作坊，重複上述過程。

總結

團隊在進行持續改進時，往往有兩個痛點：找不到起始點，啃不下硬骨頭。約束理論在團隊進行瀑布式大批量交付的情況下，難以識別最大的瓶頸，這樣就難以找到最佳的優先改進點。技術債牆雖然能識別“投入少、見效多”的優先改進點，但很容易被誤用，因爲大家往往只”捏軟柿子“，不”啃硬骨頭“。

團隊在進行持續改進時，往往有兩個痛點：找不到起始點，啃不下硬骨頭。約束理論在團隊進行瀑布式大批量交付的情況下，難以識別最大的瓶頸，這樣就難以找到最佳的優先改進點。技術債牆雖然能識別“投入少、見效多”的優先改進點，但很容易被誤用，因爲大家往往只“捏軟柿子”，不“啃硬骨頭”。此時，團隊可以在“優先改進工作坊”中，一起繪製“優先改進象限”，識別“價值最大、質量最差”的改進點作爲起始點，然後參考敏捷階梯模型，“儘早、頻繁、小批”地“啃下這塊硬骨頭”，並循環往復，形成正反饋循環，最終讓每個迭代的持續改進，都切中要害，並收穫更大成效。

作者簡介：

伍斌 _Ben，ThoughtWorks 軟件開發諮詢師。潛心進行軟件開發技術的操練與悟道。因經常辦技術操練道場，人稱“道長”。著有《馴服爛代碼》。自 1993 年大學畢業以來，先後做過程序員、測試工程師、項目經理和軟件開發諮詢師。2013 年 4 月創辦全棧開發者的編程操練社區“bjdp.org 北京設計模式學習組”。微信公衆號 bjdp_org。