通常程序員給人留下的印象就是機械，內向，不善言談。
其實一個好的程序員最需要具備的能力就是溝通的能力。
只有良好的溝通才能知道客戶需要什么，也只有良好的溝通，才能與團隊成員合作無間
本次討論希望帶領大家進入一個以溝通為基本原則的軟件開發領域，它就是——敏捷開發

一、敏捷開發簡介
1、敏捷開發與傳統軟件工程的比較
傳統軟件工程：規范化的文檔，持續改進的軟件過程
敏捷開發：密切的交流與合作，逐步細化的開發過程
兩者的區別好比重型武裝部隊與特種部隊的區別
人員變更大，人數較多，成員分數，模塊通信量大，耦合性強，維護時間長，開發過程有長期性，社會性的項目不益采取敏捷開發方法
2、4條核心價值觀
（1）個體和交互勝過過程和工具
敏捷開發很強調個人能力
它以溝通和個人能力代替了定義死了的過程
（2）可以工作的軟件勝過面面俱到的文檔
它強調迭代式的開發，以開發的一個個版本形象的說明了需求，便于客戶聯想，也便于團隊溝通演示
（3）客戶合作勝過合同談判
這條有過項目經驗的人都能理解，與客戶成為朋友比固定死的合同有用得多
（4）響應變化勝過遵循計劃
它強調溝通，從而更積極的擁抱變化，并隨時調整
3、敏捷開發的基本原則
（1）盡早、持續交付有價值的中間軟件
（2）響應變化創造競爭優勢
（3）業務人員與開發人員一起工作
它的目的是強調大家建立頻繁密切的交流
這是一種幫助大家溝通的方法
這里的業務人員是指需求人員，開發的時候當然需要了
但是肯定不直接參與軟件編寫過程
（4）團隊內部面對面的溝通
（5）根據完成了的功能調整工作進度
這是一種幫助大家溝通的方法
這里的業務人員是指需求人員，開發的時候當然需要了
但是肯定不直接參與軟件編寫過程
業務人員指的是了解客戶需求的人員
熟悉業務的人
（6）重構代碼，保持代碼健壯
（7）盡快完成目前已知的需求
強調把不了解的需求放到以后，不考慮太多可能性
不考慮太多可能性是指不考慮變化的可能性
先做好已知的，定義好的，持續形成新版本，客戶可能會想到需要什么
很多客戶并不是一開始就知道自己要什么
你給他一個東西用用，他會覺得好，還需要什么
或者哪里不好，需要改動
很多時候客戶有很多需求，我們需要做的是幫他找到重點，理清流程，幫助客戶提高主要的工作的效率才是目的
大家要始終知道，敏捷開發是一種開發方法，遵照執行可以對你的工作提供效率，而不是必須遵守的。
4、主要的敏捷方法
（1）極限編程（XP）-后面介紹
（2）水晶方法（Crystal）-個人覺得是XP的復雜版
重點；一種方法學，根據不同類型的項目確定不同的開發方法
（3）動態系統開發方法（DSDM）
重點：迭代式開發，及時并持續獲得客戶反饋，并對主要功能不斷精化
敏捷開發是一種原則，實際的方法很多
是一種哲學的價值觀
（4）特征驅動的軟件開發（FDD）
自適應軟件開發（ASD）
SCRUM方法……

二、極限編程簡介
個人覺得極限編程是一系列方法的組合
1、特點：輕量、柔性、充滿樂趣
2、XP的價值觀
（1）溝通
（2）簡單
（3）反饋
（4）勇氣
其實前三點剛才敏捷開發方法已經講了，重點就是勇氣
不是重點，是我要講的重點
勇氣其實和擁抱變化是一個意思
勇氣還指不斷的重構代碼
勇氣就是甚至引導客戶去變化
使之成為一種競爭優勢
3、基本原則
（1）快速反饋
（2）簡單性假設
（3）逐步修改
（4）提倡更改
（5）優質工作
第（5）點是很多優秀的程序員容易犯的錯誤
很多優秀的程序員喜歡設計，覺得思路是最重要的，很多時候把思路理順了，不愿意把問題完全解決好，總是留些小尾巴。但是后面又更不愿意回有修補好
比如很多人寫TRY加個CATCH，然后就不寫出錯處理，想等最后一起寫，實際上再不會回頭看了

三、重要概念解釋
這里的概念實際上很多就是一些小方法，我重點講解一下，希望能引起大家的興趣，使大家更詳細的研究XP方法

用戶故事:
就是面對面的請用戶描敘自己工作的步驟，可以用UML，也可一用小卡片
也可以用最平實的語言描敘，當然你一定要記錄下來，這個是需求分析的依據
迭代式開發：
迭代方法有沒有人不懂？
迭代式開發就是不斷的交付新版本，但是不是修改性質的，而是不段精化的
隱喻：
我覺得就是對事物的約定俗成的叫法
比如很多人把DOTNET高手叫大內高手（DOTNET讀音和大內讀音很近似）
這里的約定俗成是為了更方便的交流，更愉快的溝通，大家把平時這些比喻收集起來，和客戶交流，和團隊成員交流的時候就可以這樣說
就象現在把女朋友叫老婆，難道你會不懂嗎？
簡單設計：
粗略的設計，不考慮各種可能情況，只設計主要類
測試先行：
測試先行是現在很提倡的開發方法，是很值得研究的
好比砌磚頭，先拉一個水平線，每砌一快磚都對比一下
如果你全部砌完了再看對得齊不齊是不是有點晚了
測試先行的方法之一就是寫每個模塊之前先寫測試代碼，并且在每次改動之前測試一次
這樣是很正確的思路，其實一點也不復雜，就象在學校寫程序的時候，要也MIAN（）方法測試一下結果，你寫好了以后，再測試就很方便了。而且不用進行很復雜的測試
重構：
我用三個詞解釋，就是重思考，重設計，重編碼。
不斷的找時間重構自己的代碼是提高自己能力的很重要的方式
結對編程：
結對編程不是結隊編程，是2個人，不是更多
有誰親自試過
我個人不喜歡結對編程，但是建議大家工作不忙的時候可以試試，至少可以提高大家的交流度
結對編程主要目的是讓大家更好的交流
敏捷開發的基本原則就是溝通
持續集成：
將所有模塊經常性的整合，以及時發現與系統有沖突的問題
典型的就是微軟團隊的：每日構造
微軟的每日構造甚至到了變態的地步，要求每天集成測試，發現問題，就算是凌晨也會找到你，要你立即修改
現場客戶：
這是一種夸張的說法，其實就是經常和客戶面對面的交流，演示，和現場開發差不多
編碼標準：
團隊采取統一的編碼標準，避免就個人習慣，個人愛好等細節問題產生爭論。

總之極限編程就是要求團隊與客戶密切的溝通，團隊最好是長期合作，和客戶交朋友。
希望本次討論能讓大家更加熱愛編程，更積極的于他人溝通，更熱情的擁抱變化。
并預祝大家能利用此方法更充分的發揮自己的潛力，在職業道路上一帆風順。
謝謝大家
轉自http://blog.chinaunix.net/u1/34831/showart_1668198.html