「瀑布法」的壞處，大家都知道，不用我再多介紹，基於ＱＢＱ的精神，我們要問一個問題：為什麼時至２１世紀的今日，我們還在使用這一套很扯的方法？

書中沒有對此進行研究，我只能根據我的經驗與判斷來說明這整件事情。

關鍵其實在企業最上層。

最上層離實際開發層次已遠，甚至沒有開發經驗，或者有，但是拋棄他們草莽時期敏捷的開發方法，走入了一個所謂制式／標準化的迷思。未來我會提很多這方面的事，但我們先理解一件事，這檔事不是發生在特定公司身上，其實正發生在你我身邊。

書中提了聰明人組成愚蠹組織，專幹一些瘋狂的事。不是嗎？我們看「呆伯特」漫畫，會發出心有戚戚焉的笑聲，為什麼？

其實也不用笑，即使今天我們知道這個道理，當我們到那個位置，到了那個情境，我們可能還是會幹同樣的笨事。

這道理，我還不能構成一個完整的論述，我暫時不深入解析，基本上和經濟原則有關，特別是博奕理論有很大的關係。（這裡的經濟原則指的是人類在有限的資源情況下作出選擇的方式，而不是說有什麼整體性的經濟效益。其實，不光是這裡，社會各種難以用理性去解釋的問題，如：藍綠爭鬥，其實也能夠用相同的理論來理解。）

既與經濟行為相關，你要改變它是很難的，除非有一套經濟導向，才能促進它到你想要的平衡。

值得注意的是，SCRUM架構本身無法提供這種平衡，所以，如果你誤以為把這套架構搬回公司套用，然後期待發生兩倍的效率，是不現實的。你可能必須把許多石頭搬開才行。雖不用上下完全打通關節，但至少你要像我一樣，有一個完全信服於SCRUM的團隊才行。

以下是【敏捷宣言背後的原則】，看了你就知道，這一切不是自動發生的，而是要遵守原則的，萬一有人基於其經濟意識，違反了原則，即便是小小角色，就會發生污染，往往就會破壞了整個行事步調，乃至於完全崩壞。

紅色部份，是我想講的，企業通常不會自動給你，相反的，基於不信任的原則，它要你完成許多不必要的文件的關鍵。雖然那些文件不能給你任何好處，但有了白紙黑字，你好像有了什麼安心感一樣 －－ 雖然那是騙人的（我甚至不想用比較委婉的形容詞：「虛幻」一詞來形容它）。

其實，也不能完全怪高層，你願意把你的官位與前程完全寄託在相信底下人的善意與積極上嗎？相信沒有太多人能做得到，特別是出社會已久的人。要是你可以的話，你可以改變企業內這一切很扯的事。

我們遵守這些原則:

我們最優先的任務，

是透過及早並持績地交付有價值的軟體

來滿足客戶需求。

竭誠歡迎改變需求，甚至已處開發後期亦然。

敏捷流程掌控變更，以維護客戶的競爭優勢。

經常交付可用的軟體，

頻率可以從數週到數個月，

以較短時間間隔為佳。

業務人員與開發者

必須在專案全程中天天一起工作。

以積極的個人來建構專案，

給予他們所需的環境與支援，

並信任他們可以完成工作。

面對面的溝通

是傳遞資訊給開發團隊及團隊成員之間

效率最高且效果最佳的方法。

可用的軟體是最主要的進度量測方法。

敏捷程序提倡可持續的開發。

贊助者、開發者及使用者應當能不斷地維持穩定的步調。

持續追求優越的技術與優良的設計，

以強化敏捷性。

精簡──或最大化未完成工作量之技藝──是不可或缺的。

最佳的架構、需求與設計皆來自於

能自我組織的團隊。

團隊定期自省如何更有效率，

並據之適當地調整與修正自己的行為。