1. 敏捷是「乙個」過程
敏捷不是乙個過程，是一類過程的統稱，它們有乙個共性，就是符合敏捷價值觀，遵循敏捷的原則。
敏捷的價值觀如下：
個體和互動 勝過 過程和工具
可以工作的軟體 勝過 面面俱到的文件
客戶合作 勝過 合同談判
響應變化 勝過 遵循計畫
由價值觀引出的12條敏捷原則：
我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。
即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。
工作的軟體是首要的進度度量標準。
敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度。
不斷地關注優秀的技能和好的設計會增強敏捷能力。
簡單——使未完成的工作最大化的藝術——是根本的。
最好的構架、需求和設計出自於自組織的團隊。
每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。
建立敏捷聯盟的17位大師所創立的敏捷方法包括：極限程式設計，scrum，特徵驅動開發，動態系統開發方法，自適應軟體開發，水晶方法，實用程式設計方法。這些方法統稱為敏捷方法。
其實每個人都可以從敏捷宣言和原則出發，明確問題，找出一些解決方法，形成自己的過程。我覺得國內的軟體環境這麼複雜，程式設計師的自主精神又這麼強，敏捷方法應該是在中國首先提出才對，只是國人都有唯標準唯規範至上的心理定式，即使找出好辦法，也覺得不規範，沒有深入形成理論，無法提公升高度，始終是跟著鬼子屁股後面走，我想這也是國外軟體行業不成熟的表現之一吧。
2. 敏捷僅僅是乙個軟體過程
如果僅僅從軟體過程的角度去認識敏捷實施敏捷，效果不會太好。敏捷相對以前的軟體工程最大的革新之處在於把人的作用提高到了過程至上，正如敏捷宣言的第一條「個體和互動勝過過程和工具」所說的。
涉及到人的問題，就已經不再是過程所能覆蓋的了，就到了企業管理的層面上了，包括企業的價值觀和文化。這也是敏捷在國內實施的最大障礙：
把客戶當作合作夥伴而不是對手，從客戶角度出發去想問題，充分的跟客戶溝通，而不是出了問題推諉責任。目標是讓軟體實現客戶的價值，而不是收錢就完事兒。
把人的能動性調動起來，給動力而不是給壓力。
要實用而不是要規範。讓開發人員理解並實施，體驗到敏捷的好處，而不是盲目機械地實施規範。
沒有絕對的權威，每個人都有可取之處。
3. 迭代就是敏捷，up屬於敏捷。
看到這麼多人都把up歸入敏捷，我都開始懷疑是不是自己搞錯了。但是在我的印象中：
up 是重型的過程，雖然引入了迭代，但是其原則和價值觀與敏捷是不同的。敏捷注重的是反饋，迭代週期盡量的短，重在客戶的參與，通過客戶的參與，獲取持續的反饋，不斷調整使整個專案走在正確的方向上。同時也給客戶乙個感受和思考的機會，因為對於大多數客戶而言，目標是明確的（不排除有些客戶目標也不明確），但是具體怎麼做，開始時是沒有想法的，只有看到具體的東西的時候，才知道「噢，原來可以這樣，那我想把這裡調整一下」。
4. 敏捷是徹底革命的。
敏捷，特別是xp，讓人有耳目一新的感覺，覺得以前的所有軟體工程理論，設計方法都可以拋棄掉了，推翻一切，從頭再來。抱著這種想法實施敏捷，那就錯了，敏捷不是「石頭裡蹦出個孫大聖」，以前的軟體過程中也有敏捷的影子，只是沒有像敏捷一樣上公升到價值觀和原則的高度，比如快速原型法。敏捷是在對已有的軟體過程方法的改進，拋棄的是傳統軟體工程低效的外表，以往的軟體過程中很多技巧都是很實用的。實施敏捷應該以現有的軟體過程為基礎，從敏捷宣言和原則出發，利用敏捷的方法來改善過程。
5. 敏捷是反文件的。
文件只是為了達成目標的一種手段，如果這種手段是低效的，那就換一種手段。可是完全拋棄了文件，怎樣解決溝通的問題？難道你想每次溝通都完全用手比劃，用嘴說，跟不同的人重複表述同樣的想法，那樣更是低效的。
應該清楚文件的本質是把知識顯性化。在乙個專案中存在很多需要溝通的知識，知識具備兩種形態，顯性的和隱性的，傳統的觀念是盡量把隱性知識顯性化，即文件化，而忽略了這其中的代價（特別是更新同步文件的代價）。
因此，在實施敏捷的時候，需要在團隊內明確哪些知識是必須顯性的，這些知識可以通過文件交流。哪些知識是可以隱性的，這些知識則完全可以通過口頭的方式進行交流，以達到溝通的最佳效率。
文件不是目的，有效溝通才是目的。
6. 為了敏捷而敏捷
「嗯，敏捷這麼好，我們也敏捷吧」，可能很多人會有這種想法。忘了以前是在哪兒看的大師採訪錄：
q：「我們現有的過程很好，不知道怎麼用敏捷改進？」
a：「既然很好，那就不要用敏捷」。
做什麼事情都要有明確目標的，敏捷雖好，得看你需不需要，能不能解決你現在頭疼的問題，如果不是，那就不要給自己找麻煩了。
7. 敏捷是cmm的反義詞
在桂林會議的討論中，很多人把cmm作為敏捷的反義詞，我覺得這不是很合適。cmm只是一種衡量軟體成熟度的標準，並非過程，和敏捷不是一類概念。如果要給敏捷找乙個反義詞，我覺得傳統的瀑布式開發應該更合適一些。
並且，我認為，如果cmm還能繼續流行下去的話，應該會有公司可以用敏捷改善的過程通過cmm認證。
8. 敏捷是自由的，無約束的。
敏捷強調的是自組織團隊，發揮人的能動性，以動力代替壓力，讓人有絕對自由的錯覺。但是應該清楚，凡是都是要講究乙個平衡，人也是兩面的，消極的一面和積極的一面同時並存，絕對的自由會放縱人消極的一面。敏捷並非是絕對自由，無約束的。作為管理者，有乙個職責，就是引導團隊成員用自己積極的一面去壓制消極的一面，不能放任團隊中出現搭便車的現象，否則將打擊整個團隊的士氣。如果實在無效，那就只能將其排除出團隊了，這個懲罰夠有約束力吧？
9. 重做就是重構
重做不等於重構，很多場合這兩個概念是混淆的。但是在敏捷中，重構的乙個特徵是必須可控的。當對系統結構進行大的調整時，如果沒有測試驅動輔助的話，那麼可控性就會很差，這不能叫做重構。
開發方法 深入理解敏捷開發的常見誤區
1.敏捷是 乙個 過程 敏捷不是乙個過程，是一類過程的統稱，它們有乙個共性，就是符合敏捷價值觀，遵循敏捷的原則。敏捷的價值觀如下 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過 遵循計畫 由價值觀引出的12條敏捷原則 我們最優先要做的是通...
開發方法 深入理解敏捷開發的常見誤區
1.敏捷是 乙個 過程 敏捷不是乙個過程，是一類過程的統稱，它們有乙個共性，就是符合敏捷價值觀，遵循敏捷的原則。敏捷的價值觀如下 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過 遵循計畫 由價值觀引出的12條敏捷原則 我們最優先要做的是通...
深入理解敏捷開發的常見九大誤區
任人 開發者和使用者應該能夠保持乙個長期的 恆定的開發速度。敏捷相對以前的軟體工程最大的革新之處在於把人的作用提高到了過程至上，正如敏捷宣言的第一條 個體和互動勝過過程和工具 所說的。1 敏捷是 乙個 過程 敏捷不是乙個過程，是一類過程的統稱，它們有乙個共性，就是符合敏捷價值觀，遵循敏捷的原則。敏捷...