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