秉承敏捷宣言的精神（個體與交付重于過程和工具；可用的軟件重于完備的文檔；客戶協作重于合同談判；響應變化重于遵循計劃），我認為，敏捷開發大致應該體現如下的思想：擁抱變化、自我組織、簡單最好、客戶至上、有效溝通、精益求精。

1、擁抱變化

Kent Beck和Martin Fowler在介紹極限編程（eXtreme Programming）時，最先提到的就是要擁抱變化。這基本上代表了敏捷陣營對于變化的一種態度，那就是不拒絕，而且還要主動求變。有一句經典的論斷 說得好：“在軟件開發領域中，唯一的不變就是變化。”其實，不僅僅是軟件開發領域，世間萬事萬物都處在永恒的變化之中，這是宇宙的基本規律。奧巴馬在競選 美國總統的時候，提出的口號就是“變化”。變化才是真正的常態。

傳統的軟件開發過程由于過分強調文檔的完整，重視與客戶的談判與簽訂合同。 所以，開發團隊最希望的一件事情是凍結需求規格說明書。只要雙方簽字，需求就確定下來，不可更改。若要更改，必須經過需求變更委員會，走非常嚴格的需求變 更流程。如果軟件開發真能如此，倒也算是我們開發人員的幸事。但現實總是殘酷的，需求總是會變化。變化的原因有以下幾種：
1）業務發生了變化；
2）客戶對業務的理解發生了變化；
3）需求分析人員對需求的理解出現了偏差，需要修正。

對于第一點，或許我們還能夠根據合同與客戶討價還價，而對于后兩點，尤其是第三點，我們顯然是不可拒絕的。而敏捷方法則要求團隊隨時響應客戶的需求，針對變化給出相應的解決方案。

如何擁抱變化呢？我想可以通過如下方式來實現： 

1）現場客戶

很多開發團隊并不喜歡客戶對他們指手畫腳，甚至認為他們不停提出的需求變化讓他們疲于應對。但現場客戶給團隊開發帶來的益處還是要遠遠超過他帶來的壞處。無論團隊中聚集了多么權威的領域專家，但真正了解客戶需求的還是客戶自己。也許他們很難用語言來表述自己的想法，但有了和現場客戶的及時溝通，我們才能夠在 發生變化的初始就能夠獲得第一手的資訊。如果事情總要發生，早解決絕對比晚解決要好，而且要好得多。

如果在開發中，沒有辦法讓客戶成為團隊的一員，那么我們也應該指定一位客戶代表，退而求其次，也應該在團隊中指定一位業務專家負責業務事宜，也就是Scrum中Product Owner的角色。總之，我們需要在項目開發中，能夠讓開發人員在對需求理解發生困惑時，能夠明確地知道由誰來負責。而一旦需求發生變化，也必須有專門的 角色負責向整個團隊或者相關人士傳達。至于業務功能的優先級和重要程度排定，也必須由這個角色指定。

2）定期迭代和小版本交付

不僅要定期迭代，而且要盡可能地讓迭代周期短，并及時交付可以工作的小版本發布。XP的迭代周期通常為一周，而發布一個小版本大約是一個月。而Scrum則將迭代稱之為Sprint，持續時間推薦為一個月。Sprint結束就需要向客戶展示當前迭代完成的版本。

敏捷方法絕對不可閉門造車，因為需求總是可能存在二義性，且需求總是處于不斷的變化中。若能定期交付一個可以工作的小版本，一方面可以給與開發團隊和客戶以 信心，另一方面也有助于我們及時獲得客戶的反饋。而衍生帶來的還有一個好處是我們可以免費找到最優秀的測試人員了，那就是我們的客戶。如果沒有現場客戶， 則小版本的交付則顯得尤為重要，因為它給了我們及早修訂錯誤的機會。

3）持續改進

開發過程總是會出現錯誤，無論是開發方法、技能，還是團隊管理與團隊合作。持續地改進我們的開發方法、管理方法與開發過程，才能夠及時而有效地解決錯誤，避免重蹈覆轍。一個能夠持續改進的團隊是一個成長的團隊，同時必然會是一個擁抱變化的團隊。

在 Scrum中，每個Sprint完成并結束了評審會議之后，都會召開一個回顧會議，即使總結優秀經驗，檢討錯誤與教訓，團隊方能夠從錯誤中成長起來。此 外，回顧會議還能夠幫助團隊正確地認識自己，幫助團隊成員進行交流與溝通。作為“雞”角色的客戶若能參加回顧會議，可以讓客戶更直觀地了解團隊，比提出自 己的看法，有助于在后面的開發過程改善合作的質量。