迭代流程
開發人員：週一到週五
產品設計：週一到週五
測試人員：週六
收集需求：週一週二週三
週四需求梳理
週五用戶意見
週六第二次需求梳理
需求階段
第一次需求梳理會議
開發人員和測試人員通過此會議瞭解下一次迭代的需求點
對需求有任何問題需要在此會議及時反饋給產品（技術層面，實現難度，實現方式的建議等）
產品人員收集反饋並修改需求
開發人員需在會後自發討論會涉及到的開發工作
第二次需求梳理會議
產品提供修改後的需求點以及細節
開發和測試需要通過此會議理解需求
需求不在此會議上做任何修改了（除非一些實現細節方面）
迭代計劃會議
結合第二次需求梳理會議
產品人員根據優先級排序Backlog
根據評估的工作量，開發人員按照優先級承諾這個迭代能夠實現的Backlog
承諾的Backlog必須這個迭代按時完成
其餘Backlog放到下一個迭代
開發人員儘可能多的拆分Task
開發階段
在此階段出現的新需求一律放到下個迭代實現
需求不做任何更改（除非產品和開發在不影響時間的前提下都同意改動）
根據項目開發情況，測試人員可以及時測試已完成的功能點，並把問題報到禪道上.爲確保開發可以順利完成，測試人員在此期間不能幹撈開發人員（除非特殊原因）
週五開發結束後，產品人員會拿到一個內測版本，主要用來總結和收集反饋
如果反饋是BUG，在測試階段修復，如果是新需求，就放到下一個迭代
特別強調:
在開發過程中遇到需求不理解或是不清楚等情況，一定要先和產品確認需求，確保實現是正確的，如果最後
發現由於溝通不及時導致實現有誤，開發迭代週期不會因此延長，開發人員只能加班完成
測試階段
測試後的版本應該是一個沒有大BUG功能完整實現的BETA版