它是敏捷開發的最重要的部分。在ThoughtWorks，我們實現任何一個功能都是從測試開始，首先對業務需求進行分析，分解為一個一個的Story，記錄在Story Card上。然後兩個人同時坐在電腦前面，一個人依照Story，從業務需求的角度來編寫測試程式碼，另一個人看著他並且進行思考，如果有不同的意見就會提出來進行討論，直到達成共識，這樣寫出來的測試程式碼就真實反映了業務功能需求。接著由另一個人控制鍵盤，編寫該測試程式碼的實現。如果沒有測試程式碼，就不能編寫功能的實現程式碼。先寫測試程式碼，能夠讓開發人員明確目標，就是讓測試通過。

　　Continuous Integration，持續整合。---------使用Jenkins來實現，能夠帶來很多的便利。

　　在以往的軟體開發過程中，整合是一件很痛苦的事情，通常很長時間才會做一次整合，這樣的話，會引發很多問題，比如 build未通過或者單元測試失敗。敏捷開發中提倡持續整合，一天之內整合十幾次甚至幾十次，如此頻繁的整合能儘量減少衝突，由於整合很頻繁，每一次整合的改變也很少，即使整合失敗也容易定位錯誤。一次整合要做哪些事情呢？它至少包括：獲得所有原始碼、編譯原始碼、執行所有測試，包括單元測試、功能測試等；確認編譯和測試是否通過，最後傳送報告。當然也會做一些其它的任務，比如說程式碼分析、測試覆蓋率分析等等。在我們公司裡，開發人員的桌上有一個火山燈用來標誌整合的狀態，如果是黃燈，表示正在整合；如果是綠燈，表示上一次整合通過，開發人員在這時候獲得的程式碼是可用而可靠的；如果顯示為紅燈，就要小心了，上一次整合未通過，需要儘快定位失敗原因從而讓燈變綠。在持續整合上，我們公司使用的是自己開發的產品CruiseControl。

　　Refactoring，重構。-------有風險，有程式碼。一般在一次大的版本釋出的時候，做這件事。但是，主要是針對比較混亂的程式碼來做。一般的細小問題，由開發自己修改。

　　相信大家對它都很熟悉了，有很多很多的書用來介紹重構，最著名的是Martin的《重構》，Joshua的《從重構到模式》等。重構是在不改變系統外部行為下，對內部結構進行整理優化，使得程式碼儘量簡單、優美、可擴充套件。在以往開發中，通常是在有需求過來，現在的系統架構不容易實現，從而對原有系統進行重構；或者在開發過程中有剩餘時間了，對現在程式碼進行重構整理。但是在敏捷開發中，重構貫穿於整個開發流程，每一次開發者check in程式碼之前，都要對所寫程式碼進行重構，讓程式碼達到clean code that works。值得注意的是，在重構時，每一次改變要儘可能小，用單元測試來保證重構是否引起衝突，並且不只是對實現程式碼進行重構，如果測試程式碼中有重複，也要對它進行重構。

　　Pair-Programming，結對程式設計。 ----- 這個方式很好。但是，需要團隊中的人，能夠有好的溝通能力，和工作經驗。帶領初級的人員來做。讓他們進步更快。而高階能力的人，可以互相學習。

　　在敏捷開發中，做任何事情都是Pair的，包括分析、寫測試、寫實現程式碼或者重構。Pair做事有很多好處，兩個人在一起探討很容易產生思想的火花，也不容易走上偏路。在我們公司，還有很多事都是Pair來做，比如Pair學習，Pair翻譯，Pair做PPT，關於這個話題，錢錢同學有一篇很有名的文章對它進行介紹，名為Pair Programming (結對程式設計)。

　　Stand up，站立會議。---- 很好，堅持做就會有效果。讓工作的進度可控。問題可控。

　　每天早上，專案組的所有成員都會站立進行一次會議，由於是站立的，所以時間不會很長，一般來說是15-20分鐘。會議的內容並不是需求分析、任務分配等，而是每個人都回答三個問題：1. 你昨天做了什麼？2. 你今天要做什麼？ 3. 你遇到了哪些困難？站立會議讓團隊進行交流，彼此相互熟悉工作內容，如果有人曾經遇到過和你類似的問題，那麼在站立會議後，他就會和你進行討論。

　　Frequent Releases，小版本釋出。------需要定義釋出時間。將產品釋出給相關人員，比如產品經理，及早的發現問題，是小版本釋出的核心。減少返工，和需求遺漏和誤解。

　　在敏捷開發中，不會出現這種情況，拿到需求以後就閉門造車，直到最後才將產品交付給客戶，而是儘量多的產品釋出，一般以周、月為單位。這樣，客戶每隔一段時間就會拿到釋出的產品進行試用，而我們可以從客戶那得到更多的反饋來改進產品。正因為釋出頻繁，每一個版本新增的功能簡單，不需要複雜的設計，這樣文件和設計就在很大程度上簡化了。又因為簡單設計，沒有複雜的架構，所以客戶有新的需求或者需求進行變動，也能很快的適應。

　　Minimal Documentation，較少的文件。 ---- 並不是沒有文件。而是核心是有架構的文件。程式碼自己會說話。

　　其實敏捷開發中並不是沒有文件，而是有大量的文件，即測試。這些測試程式碼真實的反應了客戶的需求以及系統API 的用法，如果有新人加入團隊，最快的熟悉專案的方法就是給他看測試程式碼，而比一邊看著文件一邊進行debug要高效。如果用書面文件或者註釋，某天程式碼變化了，需要對這些文件進行更新。一旦忘記更新文件，就會出現程式碼和文件不匹配的情況，這更加會讓人迷惑。而在敏捷中並不會出現，因為只有測試變化了，程式碼才會變化，測試是真實反應程式碼的。這時有人會問：程式碼不寫註釋行嗎？一般來說好的程式碼不是需要大量的註釋嗎？其實簡單可讀的程式碼才是好的程式碼，既然簡單可讀了，別人一看就能夠看懂，這時候根本不需要對程式碼進行任何註釋。若你覺得這段程式碼不加註釋的話別人可能看不懂，就表示設計還不夠簡單，需要對它進行重構。

　　Collaborative Focus，以合作為中心，表現為程式碼共享。 ------這個在團隊中，需要推行。因為人都喜歡守著自己的東西，不管別人的程式碼。而程式碼共享，不僅是讓程式碼可以互相修改，而且，激發開發人員的責任心。對整個產品負責，而不是對自己的功能負責。

　　在敏捷開發中，程式碼是歸團隊所有而不是哪些模組的程式碼屬於哪些人，每個人都有權利獲得系統任何一部分的程式碼然後修改它，如果有人看到某些程式碼不爽的話，那他能夠對這部分程式碼重構而不需要徵求程式碼作者的同意，很可能也不知道是誰寫的這部分程式碼。這樣每個人都能熟悉系統的程式碼，即使團隊的人員變動，也沒有風險。

　　Customer Engagement ，現場客戶。------這裡的客戶，可能是真正的客戶，也可能是產品經理。

　　敏捷開發中，客戶是與開發團隊一起工作的，團隊到客戶現場進行開發或者邀請客戶到團隊公司裡來開發。如果開發過程中有什麼問題或者產品經過一個迭代後，能夠以最快速度得到客戶的反饋。

　　Automated Testing ，自動化測試。-----難，主要是人力缺少。

　　為了減小人力或者重複勞動，所有的測試包括單元測試、功能測試或整合測試等都是自動化的，這對QA人員提出了更高的要求。他們要熟悉開發語言、自動化測試工具，能夠編寫自動化測試指令碼或者用工具錄製。我們公司在自動化測試上做了大量的工作，包括Selenium開源專案。

　　Adaptive Planning，可調整計劃。-----

　　敏捷開發中計劃是可調整的，並不是像以往的開發過程中，需求分析->概要設計->詳細設計->開發 ->測試->交付，每一個階段都是有計劃的進行，一個階段結束便開始下一個階段。而敏捷開發中只有一次一次的迭代，小版本的釋出，根據客戶反饋隨時作出相應的調整和變化。

　　敏捷開發過程與傳統的開發過程有很大不同，在這過程中，團隊是有激情有活力的，能夠適應更大的變化，做出更高質量的軟體。