匿名所提的確是常有的現象，至於鄭教授的說法我只贊成前半句，後半句我的詮釋是：「浪費時間做過頭」之意(不管如何翻譯)，因為要把系統重新做過，表示發展專案已算失敗必須取消，依照Standish Group的統計，美國每年約有175,000專案，有30%未完成就得取消，原因是客戶"disapointed"，重新做過大慨很少或不可能，問題是這種問題如何解決，也許可以想想，結合agility與MDA(就是Agile MDA)是否是一貼藥方！Agility表示"doing the right thing"也就是"effectiveness"，MDA表示"doing things right"也就是"efficiency"，結合兩者可產生「活化需求」(live-requirements)現象，這種現象是因客戶可以在最早期就參與，正符合敏捷方法的精神，只不過在台灣很少能要求客戶從頭到尾參與發展，所以大部分軟體發展只不過是OEM的型態。
特別是在MIS 單位，user 今天想到什麼就教我們做什麼，而且都非常的急。等到做好了，他們又不用。所以別怪我們老是開發一些不中用的東西。
回覆刪除hmmm... 翻譯的很有趣，也是一個常見的現象，而且樓上的意見也的確是常見的經驗。
回覆刪除不過文句的原義可能較接近「為何我們沒有時間把系統做對，卻有時間把系統重新做過？」指的範疇很廣，例如需求沒弄對、需求弄對了但開發團隊卻誤解真正的需求、需求正確了解了但設計卻沒弄對，等等。
匿名所提的確是常有的現象，至於鄭教授的說法我只贊成前半句，後半句我的詮釋是：「浪費時間做過頭」之意(不管如何翻譯)，因為要把系統重新做過，表示發展專案已算失敗必須取消，依照Standish Group的統計，美國每年約有175,000專案，有30%未完成就得取消，原因是客戶"disapointed"，重新做過大慨很少或不可能，問題是這種問題如何解決，也許可以想想，結合agility與MDA(就是Agile MDA)是否是一貼藥方！Agility表示"doing the right thing"也就是"effectiveness"，MDA表示"doing things right"也就是"efficiency"，結合兩者可產生「活化需求」(live-requirements)現象，這種現象是因客戶可以在最早期就參與，正符合敏捷方法的精神，只不過在台灣很少能要求客戶從頭到尾參與發展，所以大部分軟體發展只不過是OEM的型態。
回覆刪除因為可以賣更多錢。或是工程師才有所謂的"貢獻"
回覆刪除不曉得在此發表意見的學者們有無實際參與台灣政府的軟體標案？有無長時間跟台灣政府的承辦人打交道？
回覆刪除[承前面的tread]一個軟體專案結束後怎樣才叫做成功？對出錢的甲方而言，可以跟他的長官邀功或幫助他升官，甚至是登上媒體報導才叫成功。對於受託的乙方而言，能有下次標案的機會，就代表成功。對於當初參與專案的團隊而言，不論用了何種軟體工法、不論用了何等先進的技術，沒有下一次標案的機會，沒有得到甲方的肯定，這個軟體專案就是失敗的。很可悲，但這就是學界永遠無法理解和接受的現實。學界搞軟工的學者幾乎都沒有體驗過台灣的軟體產業(尤其是政府標案)的惡質。
回覆刪除台灣的資訊教育只教出一群能力很強的pg，打架很強，但是沒有能力打仗，因為打仗是需要團隊、戰術和戰略的(業界中很強的軟體顧問都是在業界中打滾後才有能力打仗)，為什麼？因為學校的師長並沒有親身參與業界專案(別提那些業界科專、國科會那種沒有真正甲方的計畫)，教軟工的老師沒有真正在軟體工程中失敗、成功、失敗、再成功，怎麼教出有｢工程觀念｣的資訊科系學生？打仗的將軍若不是從最基層軍官做起，不曾經面臨部屬的挑戰、不曾經嘗過領導危機、不曾經折損兵源，怎能擔此大任？
軟體工程並非只有MDA, RUP, Agile, design pattern等，我反倒很少看到台灣有人在談軟體專案管理，專案管理最難搞的就是人，不論是團隊或是sponsor，我不知道在這裡發表的老師們對此的想法為何？但是一旦扯到人，就不是工程，而是藝術，因為處理人這件事，無法每次重複實驗都得到相同的結果。然而，軟體專案成功與否都是人決定的。
其實我很佩服在台灣做軟工的學者，因為這是超冷門的領域，但這卻是軟體產業的基本功，｢人｣也不會看到軟體工程的價值。各位學者除了發表學術論文，參與業界科專、國科會計畫外，建議各位老師去做做政府軟體專案，親自當專案經理帶領您的學生來一趟軟體工程體驗，把您的學生分成架構師、分析師、設計師、pg、tester來run一個Model，您一定會發現，台灣的軟體環境怎麼跟各位的認知差這麼遠？
也只有大教授放下身段去經驗如此惡質的台灣軟體環境，軟體工程在台灣也才有可能慢慢健全。
歡迎討論。
9/15匿名對於Q28諺語的意見，本人實有同感，我嘗試將此意見摘要如下，如有不妥請匿名指正：
回覆刪除1. 台灣軟工環境不佳，甚至惡質。
2. 學界似乎都沒有體會過台灣軟體產業(尤其政府標案)的惡質。
3. 軟體管理專案未被重視。
4. 教授們應放下身段去體會惡質的軟體環境，台灣的軟工才有可能慢慢健全。
我不能確定教授們是否都缺乏實戰經驗，至少本人多少參與過一些實際工作，不過是在良好的環境之下，依照我的體會，台灣的軟工環境不佳是事實，但是否不佳到惡質，不敢確定，或許是一些個案，原因可能是有權的人觀念官僚，甚至於外行領導內行所致，如果光靠教授放下身段(我不知教授有什麼身段)，大慨台灣的軟工不見得就會慢慢健全，因為教授們的主要專長在發展軟體的技術提升，以及培養優良的軟工人才，要改善軟工環境主要還是要靠主事者觀念的改善，一些財團法人機構如資策會，應負起一些責任，可惜至今未見成效，而且也看不出將來有何希望，我曾經主張，像資策會這種機構，應該減少技術人員，增加有經驗的政策推動人員，而不必一天到晚想發展技術，技術發展工作應該交給學術界或公民營研究機構，可惜未備認同。