轉型與變革

今年有很多機會幫忙客戶處理軟體品質提升和測試執行效率的議題，每每檢閱各種資訊後總是感觸良深。 一般來說，軟體開發通常都會有測試，但多半會著眼在類驗收型的測試。這類測試通常是軟體開發的品質活動下限，畢竟你的交付對象不可能不驗貨。不過這類測試有個大家都知道的問題，那就是通常很晚期才會知道對錯，而且執行期會看起來很長，畢竟所有測試都在最後一刻統一驗收。一口氣驗出所有問題，然後解決問題，時間很難不長。如果再搭配窘迫的測試人員和資源，那問題就很驚人了。 通常想要改善這情況，有幾件事得思考： 降低最終測試案例數量。可以做的方式如只驗收影響的部分、等價類劃分、透過風險和覆蓋率因素來分散測項的執行或改良與刪除無效測項等。不過這些方式能否有效展開的前提在於對受測系統的功能與模組的掌握度和良善的測試案例管理。如果沒這兩個前提，那麼很難做好什麼減量的決策，畢竟沒有依據。 多樣的測試方式與早期測試，也就是我們常說的左移。在工程上，一個基礎的原則是 built in quality。簡單說就是在每個軟體開發階段都確保該階段交付物的品質，不讓瑕疵流到下個階段。話是這麼說，但想做好這件事卻很少有速解方案。以單元測試為例，或許會有一個單純的想法那就是從現在開始規定大家都要寫單元測試。通常很容易會觀察到兩種結果，那就是不了了之和施行效率不佳。接著就會開始常見的故事： 那麼到底是誰的錯呢？ 正解是整個開發系統的錯，或者非要說誰的錯的話，那大概就是全部參與者的錯。 為什麼是這樣的理由？如果組織在新產品或專案或團隊的一開始沒有左移測試的念頭或至少融入一些除了類驗收測試外的其他測試手段。通常亡羊補牢並不容易，因為組織內的工程人員和非工程人員早已經長期透過各種方式貼補或容忍品質議題，而這類慣性會成為引入所謂「正確」做法時的巨大阻礙。此外，從未考量類驗收型測試外測試的軟體系統要再為其撰寫其他類測試有可能是相當困難的事情，因為目前的軟體實作結構可能盤根錯節且沾黏嚴重(耦合度高)。面對這樣的軟體系統，一般做法都會從舊系統內的新實作開始落實。不過，這類施行方式會有幾個關鍵議題需要尋求所有該系統參與者的共識： 成效可能不容易立即彰顯，而且開發時間還變長了！畢竟既有系統的原有品質問題不會憑空消失，所以會產生一種雖然投資了品質活動，但怎還是有問題的現象。這類認知落差非常需要被重視和解決，否則可能加劇工程和非工程人員之間的摩擦。可能的解決方式不外乎事前溝通、對齊關注指標、或針對高度有問題的部分做一次性的改善等。 測試不只是學會工具就行。測試有時會需要軟體設計方面的知識，所以千萬別認為送人去學 xUnit 之類的工具，然後就要馬上雞犬升天。通常是會升天，但可能不是你想像的那種。因此，除了強化測試技術本身的學習之外，持續強化工程團隊在設計上的能力也是相當必要的。可能的進行方式除了培訓外，還可以考量組織內非正式研討活動和加深團隊對既有系統的理解等。 萬年不變的流程和政策造成的變革阻礙。此處的流程不只包含開發，還需要考量開發流程的上下游或分支流程。除非在意的只是有沒有某種測試技術活動，而成效次之，那麼的確還真不用想太多。若是希望這些活動能夠紮根並且持續發展和提升，那麼除了考慮工程相關流程外，最好也思考一下與該受測系統相關的業務流程或其他營運流程，同時重新審視這些流程所涉及範圍的政策，以便去除不必要的摩擦。

什麼是遺留系統？ 遺留系統指的是已經運行多時，具有一定商業價值，但隨著時間推移，逐漸面臨架構、技術、軟體版本等過時問題的系統。 為什麼需要面對遺留系統❓ 由於遺留系統在商業營運上仍然有其必要性，因此往往難以輕易汰換。隨著新的商業需求出現，系統在過時的基礎上變得越來越難以修改或擴充。在某些情況下，即使發展新的系統，甚至會因為系統間的高度耦合，使其無法如預期般的退場。 遺留系統除了面臨維護成本逐漸上升，穩定性往往也會開始下降，最終導致工程團隊疲於應對與維護。因此，我們必須誠實地面對遺留系統所帶來的風險，並尋求長遠的解決策略。 跨出改善的關鍵活動 在 CPHT 進行遺留系統評估與改善輔導案的過程中，除了探尋從過去到現在商業決策的脈絡，同時也包含了挖掘第一線工程人員的認知與想法。其中幾個關鍵的活動： 遺留系統與技術債的評估 團隊拓墣與服務邊界的梳理 日常工作流程的梳理 人員對於負責系統、職務等的掌握度與適應性 每個系統的形成與演變，必然有其歷史背景與脈絡，其中包含當時的商業需求、組織樣貌、技術趨勢等。而從商業到工程之間的分析活動也意味著推動任何的改變都必須彌合商業與工程的落差。否則，即使出發點是為了改善遺留系統，眼前所採取的方案仍可能成為潛在的技術債，並在未來反噬！ 由於輔導的企業涉及上百人團隊與上百個長達五年甚至十年以上的軟體系統，因此透過這些盤點作業來梳理現況也至關重要。在現況盤點後，我們更能針對架構發現與顯著技術債來尋求在商業需求層面、技術層面、治理層面的長遠處置策略，以及在下一階段聚焦關鍵的改善活動。值得一提的是－去年幫助企業進行遺留系統評估與改善規劃後，最近 CPHT 也和客戶一起動起來，努力把改善計畫變成實際行動！ – 如果你也正在思考如何組織內的資訊系統與流程內追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro

說到 DevOps 免不了會讓人直接聯想到各式各樣的工具，而這也是 DevOps 之所以能夠加速軟體生產力的方法之一。 工具的使用，如果只限於個人，那麼就只是個人的意願問題而已，但如果把工具引入團隊內，那麼這問題就會稍稍變得複雜！比方說： 團隊內的成員是否熟悉這類工具？ 工具要如何融入團隊目前的工作模式？ 如果是工具舊換新，那麼資料要如何遷移？ 團隊是否有空做出改變？ 工具使用的成本是否可以承擔？ 講到這裡是不是開始覺得一陣頭昏腦脹了呢？不過就用個工具嘛！ 可別在這邊危言聳聽~ 上述的問題，運氣好的話的確有可能經過一陣摩擦後順利落地。運氣好不好這得端看工具影響的範圍和深度而定，結局就又回到上述各個問題。筆者就曾經遇過團隊花了大價錢買了工具全年的訂閱也請了外部講師做了一套培訓，結局是工具從一開始的零星使用到最後無人使用。這樣的故事並不少見，而當工具導入擴及到全組織時，那問題就又顯得更加麻煩。當然講到這邊都還只是提到工具而已，而 DevOps 可不只有工具，還有許多工程上的最佳實務做法… 所以到底該怎辦比較好？ 掌握工具或實務做法的影響範圍是做出任何改變的重要第一步！ 流程說穿就是完成一件事情的一連串活動和做法。如果我們能夠了解導入目標所相關的流程的話，那不就可以順著流程知道哪些活動、人和工具會受到影響，從而掌握影響範圍。因此，筆者在協助企業進行各式 DevOps 導入時，第一件會做的事情就是進行流程對照(Process Mapping)的活動。流程對照名詞聽起來很厲害，但其實就是透過視覺化的方式來把做事過程塑模下來的活動。進行這類活動有以下幾個步驟：

在許多場合談到最後負責時刻的時候，總是很容易引來質疑和訕笑的回應。 說到底只不過不想決定；做了再說講這麼多 最後負責時刻（Last Responsible Moment, LRM）指的是延遲決策造成的代價高於決策成本的時間點。簡單說就是期望在擁有最多必要資訊且還有賺頭時來進行決策，以便讓決策最貼近解答。只不過這個時刻往往是答案呼之欲出的時間，再不做出決策，那就是被決策了！理論上來說，這的確是一個很甜蜜的決策點，然而回到了現實，最後負責時刻彷彿成了拖延病或衝動的理由。 最後負責時刻聽起來很簡單，但基於這個概念做出決策前，其實有兩個要件需要思考，分別是：決策情境和資訊取得方式。 當處在「繁雜（Complicated）」的決策情境時，決策者可以透過分析資訊來了解該採取何種行動，而且在此情境下，想要收集哪些資訊和如何收集是相對清楚的，這是因為因果關係仍然可以理解。因此，最後負責時刻在這樣的情境下有最大的效益和清楚的時機點。至於「明確（Clear）」的情境就更不用說了，相關的資訊可能在映入眼簾的當下就已經清楚明確，而手邊也早有應對之策。從得知到決策到採取行動或許順暢到連決策者都沒有感覺到做了決策。 當情境變得模糊不清且「複雜（Complex）」時，資訊取得的手段往往需要額外採取行動，而無法單純靠既有機制來收集足夠的資訊。比方說，需要透過 MVP 或 A/B 測試來了解真實情況，然後再依據結果來做出最後的決策。這個時候會出現一種先行動再決策的直觀感受。如果決策情境進一步複雜到「混亂（Chaos）」狀態時，打帶跑的現象就會更明顯，而且被推著跑的感受也會跟著明顯。在這些情境下，行動被提前至最終決策之前，甚至最終決策的樣貌都慢慢不易被描出框線。決策和行動之間的界線變得模糊，而使得決策就像是被拖著，然而這卻是情境使然。最終，決策者仍需做出決策，而且必須加緊速度在嘗試仍然有效前做出決斷。 尚不論 Cynefin 的中央區域，其四種情境也只有「繁雜」情境在感受上有較為清楚的決策時刻，其餘要不是過於明確要不就是需要多試試。這讓最後負責時刻感覺起來顯得就像是遲延決策、沒有決策或不用決策做了再說的代稱詞。 在當前的商業與科技進展下，VUCA 就像是一種常態。最後負責時刻其實是相當重要的概念和原則。它能夠降低決策風險，讓組織更容易適應變化。決策終究是要下的，只是有時它需要一些前期的準備。與其埋怨決策被拖延了或沒人要做決策，倒不如思考如何提出一些行動來獲得更多資訊，以便最終決策的進行。不過有時團隊成員對於決策者的不耐煩有可能來自於資訊落差，所以身為決策者應該讓成員了解事情的梗概並且保持必要資訊的透明，而不是忍著而最後成了團隊的瓶頸點，這不僅無法提升決策效率，也會傷了團隊的凝聚力。 – 如果你也正在思考如何導入 DevOps，並且追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro