對敏捷管理模式核心價值的解讀
敏捷核心價值的解讀
1、個體與互動 高於 過程與工具
一個團隊如果過於依賴公司的流程系統和過程管理工具那是死板的，沒有優秀的團隊，再好的工具也不起作用。優秀的團隊管理應該聚焦於團隊中的人。一個具有自組織特性的團隊，具有合作精神並且能夠協同工作的團隊比依賴於管理工具的更好。優秀的團隊擁有不同職能的成員，但是能夠共同計劃、緊密交流、協作互助並且具有共同的使命感。要成為一個優秀的團隊，主要在團隊溝通、團隊協作、團隊變化、團隊動力這幾個方面。
注意：敏捷不是杜絕使用工具，敏捷本身就有自己的流程和工具，但是敏捷更注重團隊的人和人與人之間的協作精神，而工具只是用來協助人工作的輔助品。2、可以工作的軟體 高於 面面俱到的文件
無論多麼完備的文件也不能代替可用的產品，最終可交付的也必須是可用的產品而非一堆文件。大量的、複雜的、詳細的文件書寫和維護對開發團隊造成大量的工作壓力，會讓成員陷入大量的文件中不能解脫，然而大量的文件在團隊中起到的資訊傳遞作用非常有限，沒有人願意去寫和去看上百頁的文件。敏捷將人從繁雜的文件工程中解脫出來。
敏捷提倡自組織團隊與客戶緊密的合作和互相交流代替複雜的需求文件；
敏捷提倡用可用提供可用產品代替文件；
敏捷提倡用自動化測試工具來代替大量的測試文件。
注意：敏捷完全不要文件，團隊內仍需要少量文件來記錄和交流，但是這些文件只要團隊內部認為足夠即可，而不再需要寫大篇幅的詳細文件。3、客戶協作 高於 合同談判
軟體開發的最終目標是要提供給客戶滿意的可用產品，但是隻怎麼樣才滿意只有客戶才知道。一紙合同並不能完全指明客戶的需求、進度以及專案成本，軟體不能像訂購日用品一樣來訂購，不能僅僅寫下一份需求描述後就想得到滿意的產品。好的合同談判應該為開發團隊和客戶的協同工作方式提供指導。
敏捷提倡自組織團隊與客戶緊密的合作交流，不斷理解客戶的需求，相應客戶的變化，並挖掘客戶潛在的需求。
注意：合同談判是保障各方利益的基礎，敏捷提倡客戶協作，但仍然需要合同談判。4、響應變化 高於 遵循計劃
常言計劃趕不上變化。任何軟體，都很難再需求分析階段分析和挖掘出使用者所有的需求。有些需求就註定是在需求實現階段或使用者使用階段才能逐漸顯現的，要承認的這種不確定性。團隊要做出最終能讓客戶滿意的產品，就需要不斷響應客戶的變化。
敏捷提倡不制定時間很長的複雜計劃，通過短週期的持續迭代不斷收集使用者的反饋和變化，然後不斷消除軟體中的不確定性問題。
敏捷提倡的開發方法是：“規劃 — 執行 — 調整 — 規劃”迴圈。
注意：敏捷不是不做計劃，而是不斷調整規劃。敏捷要避免兩種極端，一種是根本不做計劃，一種是花大量時間計劃的很細。
敏捷模式與瀑布模式的優劣比較
1、核心價值觀
瀑布開發是計劃驅動的，在專案合同談判後，專案組制定計劃並且遵循計劃執行，執行過程中團隊在過程與工具的支援下管理著專案，專案組通過書寫並維護面面俱到的文件來定義需求和傳遞資訊。
敏捷開發是價值驅動的，在專案成立後，通過自組織團隊和與客戶緊密合作，根據需求的價值評估一起制定迭代週期計劃，在開發過程中團隊內緊密合作，共同保證向客戶按計劃持續交付可用並且用後有用的迭代產品，然後不斷收集客戶的反饋和變化，在後續的迭代中響應客戶的變化使得客戶滿意，直到最終完成客戶滿意的產品。
2、響應變化
瀑布模式是在前期經過長期的需求分析、方案設計、功能開發後，在最後的測試或使用者使用階段才發現使用者的變化，這極大的增加了使用者的變更成本和軟體的返工成本。
敏捷模式是通過持續的短週期迭代，不斷的向用戶交付可使用的不完整版本，使使用者在軟體的開發過程中一直都能參與和體驗軟體的迭代成果，這樣就可以使使用者提早發現需求的變化，同時就可以在相應的迭代版本中滿足使用者的需求變化，還能不斷激發使用者新的需求。
3、風險管控
一個功能的完成是指開發完成並且必須經過驗證和測試了。
敏捷模式對專案的風險更可控，它通過持續交付的可用版本，能夠直觀的看到當前專案的進展和風險，而且因為過程中與客戶的緊密合作和不斷交付的可用版本，使得最終產品的使用者滿意度更有保障。
瀑布模式只能在經過長時間的需求收集、方案設計、功能開發之後的測試階段才能看到專案的實際完成進度，對管理者來說專案的實際交付風險不可控，而且最終交付的產品的使用者滿意度不可控。
4、團隊協作
敏捷模式促使團隊的各個部分包括客戶、開發、測試都能緊密的合作，大大促進了專案內相關干係人的情感交流。研發團隊與客戶都是在朝著共同的目標“完成客戶滿意的產品”而努力。
瀑布模式中，客戶只在前期需求收集參與了，而在長期的方案設計和功能開發過程中都不能參與其中，對已經完成的部分不可見或無法及時反饋。研發團隊為了在計劃時間內完成工作，可能導致不顧客戶滿意度完全遵循初始計劃執行。導致研發團隊與客戶矛盾加深。