迭代流程
開發人員：周一到周五
產品設計：周一到周五
測試人員：週六
收集需求：周一周二週三
周四需求梳理
周五使用者意見
週六第二次需求梳理
需求階段
第一次需求梳理會議
開發人員和測試人員通過此會議了解下一次迭代的需求點
對需求有任何問題需要在此會議及時反饋給產品（技術層面，實現難度，實現方式的建議等）
產品人員收集反饋並修改需求
開發人員需在會後自發討論會涉及到的開發工作
第二次需求梳理會議
產品提供修改後的需求點以及細節
開發和測試需要通過此會議理解需求
需求不在此會議上做任何修改了（除非一些實現細節方面）
迭代計畫會議
結合第二次需求梳理會議
產品人員根據優先順序排序backlog
根據評估的工作量，開發人員按照優先順序承諾這個迭代能夠實現的backlog
承諾的backlog必須這個迭代按時完成
其餘backlog放到下乙個迭代
開發人員盡可能多的拆分task
開發階段
在此階段出現的新需求一律放到下個迭代實現
需求不做任何更改（除非產品和開發在不影響時間的前提下都同意改動）
根據專案開發情況，測試人員可以及時測試已完成的功能點，並把問題報到禪道上.為確保開發可以順利完成，測試人員在此期間不能干撈開發人員（除非特殊原因）
周五開發結束後，產品人員會拿到乙個內測版本，主要用來總結和收集反饋
如果反饋是bug，在測試階段修復，如果是新需求，就放到下乙個迭代
特別強調:
在開發過程中遇到需求不理解或是不清楚等情況，一定要先和產品確認需求，確保實現是正確的，如果最後
發現由於溝通不及時導致實現有誤，開發迭代週期不會因此延長，開發人員只能加班完成
測試階段
測試後的版本應該是乙個沒有大bug功能完整實現的beta版
Linux 測試環境後台發版流程
1.首先獲取到後端開發的jar包和前端的zip包，可以跟開發直接要或者然後問一下位址 2.用xshell連線伺服器，進入專案所在資料夾下的lib目錄下，替換專案公升級jar包 cd 專案名稱 lib rm rf 專案名稱.jar，移除之前的jar包 上傳 專案名稱.jar，上傳新的jar包 3.進入...
YunTable開發日記（5） 發布0 01版
本文是 yuntable開發日記 的第五篇。在功能方面，0.01版的yuntable還遠算不上是乙個bigtable的轉殖，但基本實現了對資料的持久化儲存，而且底層儲存格式也是基於簡化版的google sstable格式，在介面方面，則提供了insert和show 也就是select 這兩個介面，而...
發版前提醒
1 發生產包or 測試包前請檢查新包配置檔案資訊正確性，2 資料庫連線池預設連線數配置注意更改，生產應用中頁面請求較多，預設配置不能滿足生產需求，將有可能出現頁面響應時間過長 3 持續更新中 mysql show variables like max connections oracle selec...