敏捷開發的定義及解釋說明這裏就略過了，想要詳細瞭解的朋友可以猛點這裏（敏捷開發詳解）。
談敏捷開發先從流程講起吧。首先，每天早上我們會有一個晨會( 站立會議 )，主要彙報昨天自己所做的工作及自己在工作的過程中所遇到的問題，然後敘述今天計劃的工作，組內成員依次彙報組長做好筆錄。如果組內成員有遇到自己不能解決的問題，晨會上提出來大家共同探討，但如果估計討論時間會比較長的時候就會安排會下協調處理，畢竟每個人的時間是寶貴的。這是一個高效的會議意在瞭解組內各成員的工作進度及狀態。
會議結束後大家就得忙各自的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.cyzone.cn/a/20130624/242777.html