給一個團隊寫的敏捷實踐方案

剛接觸敏捷時，感覺挺好，當實際執行時，卻是半敏捷半傳統的路數，畢竟要實行真正的敏捷需要超強的隊員，對口的研發環境，以及普遍的認可度。敏捷在國內已推行多年，實施起來難度還是很大，應該說很多團隊都不算是真正的敏捷。既然不算，我給X團隊寫的一篇方案，自當書面文檔，當然據我所知也沒有實行推動起來，畢竟每個團隊都有自己的現狀。

內容大致如下，也算是對我之前的兩個團隊敏捷實施的總結吧，雖說實施效果有時候也走樣，畢竟也是個經歷。

大前提 : 要求全員整體參與產品的研發過程，從需求，設計，到開發測試等等。

準備階段

分析原始需求，整理大體流程，畫原型圖/為提高全員對需求的理解程度，可全員參與，初步分析出數據結構，搭建開發環境等開發過程中所必備的技能，各崗位角色安排到位。確定整體迭代過程，及第一迭代的內容。測試可確定測試計劃。

每日站會，內容只涉及昨日工作內容，今天準備做什麼，目前有什麼問題。切忌深入討論細節問題，佔用大家大量時間。

看板，工作完成後，主動更新看板，將工作進度時刻暴露在外，大家心中有數，一旦工作進度無法保證，可協調其他隊員幫助完成或移至下迭代開發。

開發習慣的問題，開發節奏較快，要求大家盡量保持良好的習慣，好的注釋，變數命名，日誌輸出，面對面交流等等，一切提高效率的做法都應該被提倡。

迭代按兩周一個周期。

迭代

迭代首日，開迭代計劃會，人員，全員參與，包括開發，測試，產品，業務等相關干係人。內容，由產品業務人員講解本迭代內容，全員討論需求存在的問題，記錄有歧義內容。全員評估本迭代需求任務複雜度，確定工作量。基於現有情況可確定本迭代能否完成。各開發人員認領需求，並複述需求內容，確保與產品要求一致，開發拆解需求為具體任務，並確定工作量。會後錄入系統中，統一管理。測試人員可離場編寫本迭代測試案例。

周二至下周三周四，是實質開發階段，開發前不著急編碼，需要有一定的設計識別過程，較複雜的情況，需要評審過後再開工。

開發完成做好單元測試，更新任務狀態並口頭通知測試、產品人員測試。驗證功能。

測試在此期間編寫完案例，開展測試，並與產品業務討論下迭代需求內容。

中間可穿插半天講解下迭代需求，提前熟悉內容。

周三周四可部署穩定版本，全面測試，並修復bug。若上迭代遺留bug影響關鍵流程的，馬上解決，其餘可按時間安排修復。

周五上午迭代驗收會，開發確保全部功能開發完成，不要遺漏功能。下午迭代回顧會，回顧本迭代流程中存在的問題及可改進的地方，再下迭代中完善。

迭代過程中若需求有變動，工作量不大的可動。大的需要評估，移到下迭代或某個周期內完成。

集成測試，全部迭代結束後，安排一段時間做系統性測試，測試，產品，用戶均可參與進來。

投產演練，為確保上線順利，上線周期及一旦上線失敗後的還原措施，都需要在此階段不斷嘗試，以防在正式投產時出現意外。

敏捷實施具體某一個迭代，還是傳統瀑布開發，從需求分析，概要設計，再到開發測試。兩種過程相輔相成，切不可割裂開來。

• Spring Boot + Elasticsearch 實現大批量數據集下中文的精確匹配
• Spring Boot + Elasticsearch 實現索引批量寫入
• Spring Boot + Elasticsearch 實現索引的日常維護
• 野蠻生長的前端，從雜牌軍到正規軍
• 微服務體系下如何快速構建一個服務
• 介紹幾款常用的在線API管理工具
• 你不得不知的幾個互聯網ID生成器方案
• 基於SpringCloud的Microservices架構實戰案例-序篇
• 程序員，保護你的好奇心和求知慾

推薦閱讀：