Schedule 是用來 delay 的。
出處: 工作時有感而發
作者: 曾暘展
感想: 計畫永遠趕不上變化，Schedule永遠都是變動的，參加過的專案沒有一個不DELAY，衛星發射會DELAY，系統安裝會DELAY，連參加過的國外專案進度也DELAY，
DELAY輕則半年，重則二年以上，已經到了 Schedule 是參考用的，如果客戶再來個需求變更，那真的只有DELAY到天荒地老。
Schedule 是用來 delay 的。
出處: 工作時有感而發
作者: 曾暘展
感想: 計畫永遠趕不上變化，Schedule永遠都是變動的，參加過的專案沒有一個不DELAY，衛星發射會DELAY，系統安裝會DELAY，連參加過的國外專案進度也DELAY，
DELAY輕則半年，重則二年以上，已經到了 Schedule 是參考用的，如果客戶再來個需求變更，那真的只有DELAY到天荒地老。
Schedule是否用來"delay"，我不敢確定，但的確是許多軟體發展人士的痛苦經驗，不過"schedule"仍然是管理的指引之一，軟體發展因常常嚴重延宕致產生一些危機，最近才有一些「另類」或說「非傳統」的軟體發展方法出現，諸如MDA，Agile Methods等等，這些方法的「信仰者」現在吵的很熱，只不知效果如何，不過未聞沒有成效，識者不妨提供一些資料，以便印證一下。
回覆刪除Schedule通常是放在計畫裡面，Agile Methods有一則「座右銘」(motto)："embrace change"，不知是否可參考？我看，發展軟體的人可能需要有一點「反骨」，不要死抱著「文件」或「計畫」不放(Agile Manifesto第2及4項)，或許會舒服一點，雖然是 「書生之見」，但值得討論。
「計畫永遠趕不上變化，變化永遠趕不上客戶的一通電話」 XD
回覆刪除我想了好幾天，一直無法了解Q39諺語有何邏輯，也許是我的實務經驗不多有關，不過這則諺語雖然「無奈」，但可能會讓從事軟工相關工作的人或學習的學生洩氣，因此希望再表示一點意見。
回覆刪除從曾先生與日落先生的說法，"change"不論是來自於客戶的一句話或需求改變的要求或其他原因，它好像是"delay"的「禍首」，本人有不同看法，不要說發展軟體，在世界上的種種事與物，那件不是常有改變？所謂："The only constant in this world is change."(Henry Parmer)，問題在於你如何面對處理，在軟體發展的領域中，有許多具實務經驗的軟體發展學專家，竭盡心力創造許多發展軟體的原則與方法，難道都不管用嗎？。記得2009軟工教師研習會開會前，我曾經email給主持人一點意見，是說：我們是否應該調整或改變軟工教學方式，因為從軟工部落格看到許多抱怨，我總覺得，這些抱怨可能是因從業人士並未真正斟酌應用這些原則與方法所致，可惜未有當事人的任何正或反的回應。
不過，如果你相信「Schedule是用來delay用的」，我勸你改行，如果這則諺語是為「真」，我想我應該封嘴回家吃自己不必多言。但是在發現"silver bullet"之前，這則諺語仍然顯示軟體工程很嚴肅的問題，值得辯論，只可惜軟工的"silver bullet"尚未產生，可能永遠不會產生，只好認命。
個人認為一個專案時程的Delay，關鍵因素在於專案經理沒有正確掌握和確實的傳達整個專案內所有參予人員(包含利害關係人；顧客等)的一致性想法與開發現況所導致。如果確實做好管理，即便是客戶的一句話也應該是變更管理，視開發團隊情況去修改原有的專案時程，且專案的時程應該是每周(視情況)檢討審視。我認為會使用到Delay這樣的字語即表示原訂給顧客的規格和時間點都沒有達到，當然許多專案會因顧客強迫下又陸續追加超出原定計畫的功能，致使專案無法如期完成，我認為這樣的情況還是需要回到管理面來克服。
回覆刪除