工具在 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:
分類: 品質文化, 專案團隊, 專案監控, 知識管理, 軟體審查, 開發工具。這篇內容的永久連結

在〈工具在 software inspection 所扮演的角色〉中有 6 則留言

  1. 自動引用通知: Software inspection 與衝突 at 同人的生活派對

  2. 自動引用通知: 同人的生活派對 » 善用工具為軟體品質加分

  3. 自動引用通知: 艾克索夫實驗室 » Defect Detection Tool 之不需要道聽途說

  4. 自動引用通知: 艾克索夫實驗室

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *