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

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

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

      

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

準備階段

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

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

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

        開發習慣的問題，開發節奏較快，要求你們儘可能保持良好的習慣，好的註釋，變量命名，日誌輸出，面對面交流等等，一切提升效率的作法都應該被提倡。

        迭代按兩週一個週期。

迭代

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

        週二至下週三週四，是實質開發階段，開發前不着急編碼，須要有必定的設計識別過程，較複雜的狀況，須要評審事後再開工。

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

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

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

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

        週五

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

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

        集成測試，所有迭代結束後，安排一段時間作系統性測試，測試，產品，用戶都可參與進來。

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

    

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