jim yeh on 三月 22nd, 2007

哈米尼斯對我在〈對專案假設的看法〉回應說: 我文中所提的這一個假設「專案執行的過程中,兩方所簽屬的任何文件,皆屬有效文件」,這樣的說法並不是說客戶不能改變Scope(事實上我做過的案子很少有驗收時的規格會和合約完全一樣的),而是為改變提供一個正式的法源,至少不要在驗收時落人口實說變更Scope的程序是有問題而被卡來卡去。 其實我並不反對用合約或其它經雙方簽署相關文件來提供變更的正式法源,但合約或其它經雙方簽署的相關文件並不能算是專案假設,它們是一種會對專案成果發生影響的約束。所以用專案管理的專業術語來說,應該稱它們為專案限制而非專案假設。雖然合約條款或經雙方簽署的文件內容,這些限制其背後都會有相對的假設,但真正要有效地解決專案問題,應該是去識別問題背後的假設,並進一步地去管理它們;而非一味地運用根據假設所發展出來的限制來約束專案成果。因為後者的做法會讓人看不見問題背後的問題,以致於對失去問題焦點。 哈米尼斯隨後在他的網誌發表了〈專案管理:再論「專案假設」〉來闡述他對專案假設的看法,他認為: 如果把做專案當做是我們寫證明題,而證明的過程就好像是專案執行和驗證,在被驗證之前,其實我們甚至都可以說這一個題目(專案)都不是真的。當用這樣的角度在看時,把專案假設當做是一種專案的限制,我是認為並無不可。 但我認為,可不可以「用做專案來比擬解證明題」,其實是取決於專案所要處理的問題而定。如果專案的決策是屬於結構化(structured decision)的,亦即對問題有良好的定義、變動性很小、不確定性很低、過去有處理過類似問題的經驗及問題困難度不高,那麼做專案就相當於解證明題一樣:一切可以照著預先所規畫的來做,專案的假設就像證明題的已知不會改變,當然可以把做專案來比擬解證明題一樣;但往往軟體專案的決策多半都屬於半結構化(semi-structured decision)甚至是非結構化(unstructured decision)的,它們沒辦法像解證明題一樣那麼簡單,在過程中我們會發現原先建立的專案假設會隨著專案的變動而變得不再成立,將會對專案的成果造成某些影響。因此,在整個專案生命週期中,我們必須要注意假設所衍生出來的不確定因素,以防止或減輕它們對專案所造成的衝擊,否則對於專案要解決的問題就很有可能會發生此題無解的窘境。

Continue reading about 評論「專案假設」的相關討論

     
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 則是除了工作產出的形式是否符合規定外,審查的重點更會擺在工作產出的實質內容,我常稱這種審查叫做實質審查,用來和形式審查區隔開來。

Continue reading about Software review 與軟體品質文化

     

喲哪桑學長在〈Review vs. Inspection — 亂談軟體工程的正名運動〉中對〈創造 software review 的需求〉有所回應,他提道: 沒有壞就不要修,本是西洋古老的諺語。只不過,我還是會擔心,等到壞了,修也來不及囉! 我可以理解學長的 concern,但以 problem-solving 的角度來看問題,第一步一定要先弄清楚問題是什麼。再來問這是誰的問題,在問題擁有者並不想解決問題時,貿然要對方改變只會招致埋怨而對問題沒有任何的助益。

Continue reading about 評論喲哪桑對〈創造 software review 的需求〉的回應