開發工作中使用的敏捷開發模式
敏捷開發的定義及解釋說明這里就略過了，想要詳細了解的朋友可以猛點這里（敏捷開發詳解）。
談敏捷開發先從流程講起吧。首先，每天早上我們會有一個晨會( 站立會議 )，主要匯報昨天自己所做的工作及自己在工作的過程中所遇到的問題，然后敘述今天計劃的工作，組內成員依次匯報組長做好筆錄。如果組內成員有遇到自己不能解決的問題，晨會上提出來大家共同探討，但如果估計討論時間會比較長的時候就會安排會下協調處理，畢竟每個人的時間是寶貴的。這是一個高效的會議意在了解組內各成員的工作進度及狀態。
會議結束后大家就得忙各自的Story去了，說到Stroy可能有朋友會問了，什么是Story？下面我們就一起來了解下,說白了敏捷里面Story就是項目啟動前你的項目經理或組長將項目劃分出來的一個獨立的功能模塊。然后根據組內成員的特長安排的開發任務，在迭代中（通常兩個星期為一個迭代周期）開發完成。一般測試人員會在開發人員開發Story的期間完成測試用例的編寫，便于開發完成Stroy后showCase(開發人員在本地環境運行story供測試人員測試)時進行驗收。showCase通過后Story算是初步通過，因為迭代模式中的每個模塊交付時都必須是獨立可運行的也是集成可測試的，所以，功能代碼在測試環境集成測試無誤后該Story才算驗收通過。
開發人員完成編碼工作后并不意味著任務就結束了，這只是剛剛開始。是的，沒說錯，剛剛開始！測試人員會在測試環境對各個模塊進行測試，如果發現問題會及時的在bug反饋系統中(用于跟蹤問題的解決進度及完成情況)提出問題單進行跟蹤，開發人員編碼完成后最主要的工作估計就是和這個系統打交道了，需要及時的查看解決bug系統上面的問題單然后對問題單的狀態進行變更，便于測試人員回歸測試。
當然，讓測試人員發現并反饋了很多的問題也是讓我們開發人員比較苦惱的一件事情，畢竟不是什么好事兒。誰都希望自己交付的代碼能夠經得起考驗，少出現或不出現問題(當然我們知道這是不可能的)，那么怎么辦呢？敏捷里面針對類似的情況也有合理的應對流程，確保高效、高質、高產按時的交付。那就是我們常說的結對編程，通俗的說就是A和B兩個人劃分為一個編程小組，有問題及時溝通反饋。甚至A看著B或B盯著A寫代碼也是一件比較常見的情況。A在提交自己的Stroy時必須先讓B檢視Review一下自己的代碼，發現了問題應修復完成后才能讓測試人員去測試。這樣可以避免一些不必要的錯誤和疏忽出現，提高開發效率的同時提高編碼質量。
還有一種防范問題發生的措施，那就是集體檢視代碼。
迭代開發中一個星期后，團隊成員的編碼工作基本上完成了或完成了大半。這時候頭兒會組織一個開發人員會議，就是開發人員坐到一個會議室里面瞪著大眼在投影儀上找bug或編碼規范問題。團隊的力量還是巨大的，一會兒功夫一個功能模塊可能就給你揪出了十幾個bug，大家一起發現的問題會議結束后會形成一個bug列表，按責任人給依次分配下去解決。相當于集體重構了一次代碼，讓系統更加的健壯、穩定。
經過九九八十一難般的兩個星期就這樣循環反復中一閃而過，這時候我們可以暫時的小憩一會兒了。
這一會兒是多久呢，大概也就是一天左右的時間吧。因為一個迭代周期結束后，項目組成員會再次的坐在一起開一個即重要又輕松的會議--迭代回顧會議。大家吃著零食邊談論總結這個迭代中做的好的部分及需要改進的部分，“嘿，那個誰上次那個地方我說應該XX做樣吧！”、"這個迭代中XX同學給予了我很大的幫助，感謝"，大家你一言我一語就這樣展開討論開來...
回顧會議的第二天，開始了上面工作的第二次循環，直到整個項目交付......
原文鏈接：http://www.cnblogs.com/zzxbest/archive/2012/10/29/2745639.html
【編輯推薦】
