jim yeh on 三月 22nd, 2007

關於 software review,在看了喲哪桑學長對我的文章所寫的回應後,發現學長對我想要表達的意思有些誤解。學長提到:

我個人不是很同意依照形式的多寡來分類review, technical review, peer review, etc. 雖然我對那種分類法的感覺不好, 我也建議少這樣說, 但的確有些人是這樣用的.

而我的原文是這麼說的:

對於一個開發流程未慣例化的組織而言(即未達 CMMI ML2),推行 review 可能會遭受極大的反彈;而對於一個開發流程未針對現況做回饋控制的組織而言(即未達 CMMI ML3),review 的推行可能比較徧向形式審查而較少的技術審查或 peer review

其實我要討論的重點並不在於 software review 形式的多寡,事實上,我文中提到的形式和學長所說的形式並不是同一件事。徧向形式審查的意思是審查的要點在於看工作產出有沒有遵照開發組織規章或專案計劃所規定的文件規範及慣例,對於工作的內容卻無法做到實質上的審查;而所謂的技術審查或 peer review 則是除了工作產出的形式是否符合規定外,審查的重點更會擺在工作產出的實質內容,我常稱這種審查叫做實質審查,用來和形式審查區隔開來。

所以我文中的形式與否並不是指 formal 或 informal,而是指開發團隊如何訂立工作產出審查的準則與流程。如果開發組織的軟體品質文化[1]只在於掌握軟體開發慣例,亦即所重視的是表單或標準流程的話,能做到形式審查就很了不起了,但慣例化的問題在於對變化反應的能力較差,要解決這個問題,必須用工程管理的角度,亦即讓軟體品質文化朝向較有效的回饋控制以掌握更複雜的專案,要做到回饋控制,工作產出的實質審查則是不可或缺的。

我認為工作產出的審查的形式化多寡並不是重點,因為不管我們採用那一種審查,關鍵會在於專案要解決的問題有多複雜,客戶的了求有多高[2],這些因素決定了我們所適用的軟體品質文化模式。要先了解開發團隊的軟體品質文化,才知道該不該 review 及如何來 review,至於工作產出的審查種類該怎麼分,其實並不是我想訴求的重點,通常我只會用實質審查或形式審查兩種審查來區分不同的軟體品質文化模式。

Powered by ScribeFire.



附註  
  1. 《溫伯格的軟體管理學》一書中所指的「軟體次文化」[]
  2. 這是溫伯格所建立的軟體次文化模型,請參考文獻 1 []
     

3 Responses to “Software review 與軟體品質文化”

  1. 喲哪桑 說道:

    可以請問一下,實質審查或形式審查的英文嗎?剛才google了一下實質審查或形式審查,發覺各行各業使用真普遍哪!我的中文實在太差了…

  2. 哈米尼斯 說道:

    看完後有點混亂~ 以您看法來說,審核會分為2種,一種是形式上的,主要在於公司已經有一定的專案或軟體開發流程,它處理的問題類似於工作有沒有按時產出,是否有依照公司的規範,像是品質的規範等等。

    而實質的審查則是針對工作產出物的內涵,例如解決這一個問題是否有更好的方法。

    所以2種不同的審查基本上是可以同時發生的?不知道這樣子有沒有誤解您的意思?

  3. jim yeh 說道:

    Hi 喲哪桑學長,

    形式審查或實質(內容)審查,是我在實務中用的的本土用語,所以沒為它們取英文術語。也因為如此,所以上一篇文章沒直接明說,而以一些類似概念的術語取代,不過也因為這樣才讓學長有著正名的動機吧。^^

    Hi 哈米尼斯,

    原則上沒有錯,不過實質審查的內涵應該是包括內容審查的。工作產出的形式應該是實質審查的一個項目,但對一個「個人與成員互動勝過流程與工具」的軟體品質文化而言,形式不會著墨太多,這時形式的審查就會重視 lessons learned 及有助於成員相互溝通。

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">