工具在 software inspection 所扮演的角色

在Chui-Wen Chiu’s Note: 〈程式碼檢驗〉看到：

基本上我蠻認同程式碼檢驗這個步驟，不過這個步驟不應該是由人來作，更不應該全部交由一個人來作，而是交由一套工具來處理，如此可以省去不必要的人力支出，而且也可以將 Knowledge 分享給 Team 的每一個人。

站在節省人力支出的立場，用工具幫我們檢驗程式碼的想法看起來好像不錯，如果這樣做可以維持程式碼品質而降低人力的花費，當然是最好的選擇，但程式開發的價值首重創意性思考，但工具卻只能預先設好檢驗的規則，在已設定的規則範圍之外，還是有很多 defect 是會被工具忽略掉，但這些 defect 是不應該被忽略的，因為等到讓它們擴散就麻煩大了。因此把程式碼檢驗的工作，交由一套工具來處理，對於改善軟體品質而言，其實是不夠的。

亦即在檢驗程式碼的工作，工具並不能取代人力的，工具最多只能站在輔助的地位，因為審查程式碼並不是 routine job，這個工作需要的是程式實作的專業知識與技巧，要用人的肉眼直接來逐行檢驗，不能由工具代勞。

專案團隊的設計，其實是為了發揮團隊的綜效，讓專案的績效大幅增加。軟體專案團隊要成功，是專注於專業分工與整合團隊綜效相互配合。雖然電腦輔助軟體工程可以簡化設計及開發的過程，讓我們用更有效率的方式來設計程式，但如果太強調效率而缺少整合，效率只是讓無法創造價值的軟體在製品（in-process inventory）不斷地增加而已，徒然增加品質成本。

整合需要團隊有效的互動，也正如敏捷軟體開發宣言所強調的「人本與互動勝過流程與工具」。Software inspection 不是只有檢驗而已，它更重視學習及互動的過程，團隊的學習除了個人知識與技術的單方面獲取外，更重視團隊成員的互動並重視學習的回饋環路。在 software inspection 會議中，團隊成員可以提出個人看法，以積極及開發性的討論來促進集體反思，讓團隊以更有創造力的方式來工作。就像〈反思技術打破”集團性弱智”〉一文所提到的：

一個有學習力的企業要有集體反思的能力。在行動之後，能集體停下來反思的能力，「反思」不同於「檢討」，強調的是調整看事情的「角度」，團隊探究的重點是行動背後的假設，而不是行動本身，當交談的層次進入到假設及認知的層面時，團隊才有可能進入所謂的「雙迴圈學習」，也就是一群人「共同思考」的境界，而唯有在這樣的氛圍下大家才不會相互指責抱怨、不會計較誰的貢獻比較多、不會被認為提出了愚蠢的看法，真正創新才有可能出現！（白國際管理顧問公司總經理，沈沂採訪整理，《21世紀商業評論》2005年11期）

所以，團隊合作重視每一個團隊成員與其互動的過程。在參與 software inspection 的過程中，除了可以達到知識分享的目的外，還會讓成員感到受他有受到重視，無形之間增加團隊向心力及凝聚力。當我們用工具檢驗程式碼時，並沒有辦法享受到這些好處，如同我在〈軟體開發能力的自我組織〉中曾經提到的：

公司缺少了像 Inspection 這樣的機制，任何的抽象思考、建模及各種提昇設計能力的技巧最多只能「孤芳自賞」，對組織開發能力的助益其實是有限的。「獨樂樂不如與眾樂樂」，當專案實施 Inspection 時，成員的設計能力及 software asset 變得與日俱增，而且在團隊溝通上助益也很大，可說是好處多多。

Software inspection 可以用來 QA ，更可以做到 team building，這些都不是用了 CASE 工具就可以勝任的呀！

Powered by ScribeFire.

Please follow and like us: