敏捷開發簡介

前幾天和同事們去西交大作校園宣講，固然我是去幫忙加旁聽的。:-)  HR和同事們介紹了不少關於公司的狀況，包括文化，價值觀，敏捷開發等等，不少東西我都是第一次學習到，後來我對馬同窗說，你那富有激情的關於公司的敏捷介紹讓我收穫很大，他說我這句話給他很大的鼓舞，呵呵。

　　下面我將馬同窗的講解簡單介紹一下，首先看下面這個圖:

 

　　這兩個圓圈表示不一樣的視角上的敏捷實踐，包括開發者視角和項目管理的視角。接下來從裏向外進行介紹，由於有些實踐我瞭解得不清楚，若是下面有哪些說得不對的地方也請你們指出。

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

　　Continuous Integration，持續集成。在以往的軟件開發過程當中，集成是一件很痛苦的事情，一般很長時間纔會作一次集成，這樣的話，會引起不少問題，好比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，可調整計劃。敏捷開發中計劃是可調整的，並非像以往的開發過程當中，需求分析->概要設計->詳細設計->開發->測試->交付，每個階段都是有計劃的進行，一個階段結束便開始下一個階段。而敏捷開發中只有一次一次的迭代，小版本的發佈，根據客戶反饋隨時做出相應的調整和變化。

　　敏捷開發過程與傳統的開發過程有很大不一樣，在這過程當中，團隊是有激情有活力的，可以適應更大的變化，作出更高質量的軟件。