Facilitating change is more effective than attempting to prevent it. Learn to trust in your ability to respond to unpredictable events. It’s more important than trusting in your ability to plan for disaster. Martin Fowler and Jim Highsmith
諺語提供：黃為德教授
這樣聽起來好像跟要作風險控管有點相反方向呢。風險控管不是說要plan for the possible problems，但上面說的好像是：『讓他發生吧..我有辦法處理好』
回覆刪除Prevent 不是應該比發生後處理要好嗎？
需求變更變數難以預防，實務上不就是計畫趕不上變化，變化趕不上老闆的一句話~
回覆刪除I think the point is all about cost: Can you afford preventive design? If so, prevent but keep in mind that there's no design that is absolutely future-proof. Otherwise, keep adaptive and respond to change.
回覆刪除我想這則諺語主要在談敏捷宣言中的"repond to change"，這一點將另貼意見來談。
回覆刪除至於Max Huang所說的「趕不上老闆的一句話」，老闆會受客戶與費用的壓力，這是很自然的事，不過為何負責發展的人不採用諸如設計原則之類方法，減低老闆一句話的壓力，例如因此省錢省時，這可能是老闆最在意的。
避免走夜路很重要，但是訓練一個好身手也很重要...
回覆刪除2001年2月有17位方法學專家聚集在Utah州Snowbird鎮，討論發展軟體的較佳方法，本諺語的作者Fowler與Highsmith是其中的兩位，討論會最後大家同意，以"agile"一字做為專案期間對需求改變的反應能力，並且提出『敏捷宣言』，成立所謂『敏捷聯盟』(Agile Alliance)(要了解這個聯盟可參照http://www.agileallicance.org網站)。這個宣言的價值有4項，簡言之包括：
回覆刪除People over process
Software over documentation
Customer over contract
Change over plan
由這4項宣言引申12項敏捷方法的作業原則，也發展出一些發展軟體的敏捷方法，諸如XP、Scrum、DSDM、FDD等，個人認為Q34諺語與第4項宣言有關(全文：Responding to change over following a plac)，諺語中「預期事故的反應能力」以及「處理災難的能力」應該就是指對變更的反應能力，因為需求的不斷變更是目前軟體工程的問題之一(說災難也可)，17位專家採用"agile"一詞而非"lighweight"，是要能敏捷反應需求變更，至於計畫也是很重要，至少有計畫才能有預算以及時程，不過光「死抱計畫」，不見得專案能成功，因此反應任何變更的能力更行重要，甚至於也有助計畫的成功。
補充說明：發展軟體有所謂predictive approach與adaptive approach，敏捷方法屬於後者，敏捷宣言告訴我們必須適應環境的改變，如何適應環境的改變，也許遵守一些設計原則，如OCP或DIP之類，或者採用敏捷方法，如Scrum或XP，或可見效。要了解敏捷方法不仿進入本部落格陳振炎教授的『台灣敏捷方法苗圃』看看。
作者已經移除這則留言。
回覆刪除筆誤："Responding ... a plac"應為"Responding ... a plan"，又"lighweight"應為"lightweight"，用特修正。
回覆刪除