秉承敏捷宣言的精神（個體與交付重於過程和工具；可用的軟體重於完備的文件；客戶協作重於合同談判；響應變化重於遵循計畫），我認為，敏捷開發大致應該體現如下的思想：擁抱變化、自我組織、簡單最好、客戶至上、有效溝通、精益求精。
1、擁抱變化
kent beck和martin fowler在介紹極限程式設計（extreme programming）時，最先提到的就是要擁抱變化。這基本上代表了敏捷陣營對於變化的一種態度，那就是不拒絕，而且還要主動求變。有一句經典的論斷說得好：「在軟體開發領域中，唯一的不變就是變化。」其實，不僅僅是軟體開發領域，世間萬事萬物都處在永恆的變化之中，這是宇宙的基本規律。歐巴馬在競選美國**的時候，提出的口號就是「變化」。變化才是真正的常態。
傳統的軟體開發過程由於過分強調文件的完整，重視與客戶的談判與簽訂合同。所以，開發團隊最希望的一件事情是凍結需求規格說明書。只要雙方簽字，需求就確定下來，不可更改。若要更改，必須經過需求變更委員會，走非常嚴格的需求變更流程。如果軟體開發真能如此，倒也算是我們開發人員的幸事。但現實總是殘酷的，需求總是會變化。變化的原因有以下幾種：
1）業務發生了變化；
2）客戶對業務的理解發生了變化；
3）需求分析人員對需求的理解出現了偏差，需要修正。
對於第一點，或許我們還能夠根據合同與客戶討價還價，而對於後兩點，尤其是第三點，我們顯然是不可拒絕的。而敏捷方法則要求團隊隨時響應客戶的需求，針對變化給出相應的解決方案。
如何擁抱變化呢？我想可以通過如下方式來實現：
1）現場客戶
很多開發團隊並不喜歡客戶對他們指手畫腳，甚至認為他們不停提出的需求變化讓他們疲於應對。但現場客戶給團隊開發帶來的益處還是要遠遠超過他帶來的壞處。無論團隊中聚集了多麼權威的領域專家，但真正了解客戶需求的還是客戶自己。也許他們很難用語言來表述自己的想法，但有了和現場客戶的及時溝通，我們才能夠在發生變化的初始就能夠獲得第一手的資訊。如果事情總要發生，早解決絕對比晚解決要好，而且要好得多。
如果在開發中，沒有辦法讓客戶成為團隊的一員，那麼我們也應該指定一位客戶代表，退而求其次，也應該在團隊中指定一位業務專家負責業務事宜，也就是scrum中product owner的角色。總之，我們需要在專案開發中，能夠讓開發人員在對需求理解發生困惑時，能夠明確地知道由誰來負責。而一旦需求發生變化，也必須有專門的角色負責向整個團隊或者相關人士傳達。至於業務功能的優先順序和重要程度排定，也必須由這個角色指定。
2）定期迭代和小版本交付
不僅要定期迭代，而且要盡可能地讓迭代周期短，並及時交付可以工作的小版本發布。xp的迭代週期通常為一周，而發布乙個小版本大約是乙個月。而scrum則將迭代稱之為sprint，持續時間推薦為乙個月。sprint結束就需要向客戶展示當前迭代完成的版本。
敏捷方法絕對不可閉門造車，因為需求總是可能存在二義性，且需求總是處於不斷的變化中。若能定期交付乙個可以工作的小版本，一方面可以給與開發團隊和客戶以信心，另一方面也有助於我們及時獲得客戶的反饋。而衍生帶來的還有乙個好處是我們可以免費找到最優秀的測試人員了，那就是我們的客戶。如果沒有現場客戶，則小版本的交付則顯得尤為重要，因為它給了我們及早修訂錯誤的機會。
3）持續改進
開發過程總是會出現錯誤，無論是開發方法、技能，還是團隊管理與團隊合作。持續地改進我們的開發方法、管理方法與開發過程，才能夠及時而有效地解決錯誤，避免重蹈覆轍。乙個能夠持續改進的團隊是乙個成長的團隊，同時必然會是乙個擁抱變化的團隊。
在scrum中，每個sprint完成並結束了評審會議之後，都會召開乙個回顧會議，即使總結優秀經驗，檢討錯誤與教訓，團隊方能夠從錯誤中成長起來。此外，回顧會議還能夠幫助團隊正確地認識自己，幫助團隊成員進行交流與溝通。作為「雞」角色的客戶若能參加回顧會議，可以讓客戶更直觀地了解團隊，比提出自己的看法，有助於在後面的開發過程改善合作的質量。
敬請期待第二篇《敏捷開發思想之自我組織》
敏捷開發思想
敏捷的原則敏捷開發其實並沒有標準型的流程。scrum也只是眾多衍生體中的乙個。實際上就算是scrum的實際使用也情況千差萬別。所以首先，請大家有這麼個概念 敏捷開發絕對不是一套一成不變的標準化流程。而更多的是一種自適應，自我優化的流程優化理念。並沒有一定的流程，而是需要大家有對任何自己覺得不對的，不...
本土化敏捷 大易管理與擁抱變化
剛看了曾仕強老先生的 大易管理 確實令我佩服。原本我也讀過易經，但和曾老先生比起來就是小巫見大巫了。大易管理，是指合乎 易經 所揭示道理的管理。目的在使現代化的管理，在中國人的組織中行之有效，然後再通過全球化，以求管理的世界大同。姑且不論大易管理是否能世界大同，但從中是有很多東西值得我們學習的。擁抱...
敏捷開發基本思想
敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟體開發團隊具有快速工作 響應變化能力的價值觀和原則，並於2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，他們認為 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 ...