軟體品質管理之困境與對策思考

相信在不少與軟體開發相關的企業內，品質管理部門與軟體開發部門在日常運作中形成了如所示的“啞鈴形”組織圖。
  開發部門執行品質管理部門所制定的流程，通過提供證據的形式將各種流程執行後的資料反饋給品質管理部門（包括缺陷率和各種流程記錄），品質管理部門根據這些資料監督流程的執行效果，並適時修訂流程。聯絡兩大獨立部門的，是單薄的兩條線和一些部門間的會議。理想情況下，在品質管理部門與軟體開發部門間形成的是一個逆時針的良性品質管理環，理應獲得良好的效果。但在我看來，事實卻並非如此！

啞鈴形組織圖所存在的前提假設有兩個。其一，度量資料能真實地反映軟體品質。顯然，在軟體危機仍四伏的今天，業內並沒有找到完全能用於度量軟體品質的指標，這一假設對於現實多少顯得很是渺茫。其二，軟體開發部門能誠實地提供度量資料。對於目前國內職業化程度不高的狀態，這一假設也很難成立。

因此，啞鈴形組織圖所帶來的第一個困境是：將兩個部門分別變成了“看資料的”和“造資料的”兩大陣營。軟體開發部門為了達到品質管理部門所制定的“品質目標”，不時需要考慮如何將資料“造”好，哪怕“造”的手法有點低劣；而品質管理部門由於只是通過資料去瞭解軟體產品的品質狀況，除了不能理解有些指標為何忽上忽下外，更無法督促開發部門就品質問題的根源進行根治。

克服這一困境的對策我認為需要從打破組織圖開始。真正掌握軟體真實品質狀況的並不是來自品質管理部門的人，因為他們根本沒有觸及軟體原始碼，而是來自開發部門的軟體工程師。為此，兩部門的人員應當存在交集才更有可能做好品質管理工作，或許的組織圖更有助於達到這一目的。 
在新的組織圖中，兩部門交集中的人應來自開發部門的、對軟體品質管理有很好認識的技術專家，這些人來自“能力金字塔”（參見《軟體開發：個人與團隊是永遠的核心》）的上面兩層。他們除了協助品質管理部門瞭解軟體品質的真實狀況外，還應協助開發部門理解品質問題的根源和尋求技術解決方案。交集中的人可以考慮採用虛擬團隊的形式進行組織與管理。

品質管理容易出現的另一大困境是：太強調流程與資料，而忽視品質管理很重要的內容是協助工程師改善工作習慣（比如編程習慣）和提高開發環境的工作效率（比如項目的編譯效率、單元測試的實施效率）。在這種困境之中，品質管理活動更多地表現為“鋼性” — 達到設定指標或沒有達到，而缺乏應有的“柔性”理解。雖然“產品品質源於過程式控制制”這一思想被業界廣泛認同，但卻仍容易忽視將工程師的工作習慣和開發環境的效率納入到品質管理的範疇之中，這也是造成不少品質困境的關鍵因素。對於這兩方面內容的重要性，無論如何強調也不為過。
最後，我認為品質管理應更多關注於實踐，而非度量。由於軟體開發的特殊性本質，我們難以尋找到有效度量手段，與其在這方面毫無建樹，不如花更多的時間去建立適合自己的實踐方法，並將這些實踐融入到工程師的工作習慣和開發環境中去。

本文出自李雲的部落格，請務必保留此出處：http://blog.csdn.net/hzliyun/article/details/8184538。