近期做了一個不算復雜的項目，第一版時bug數已經高達300個，才真正的警醒、反思。
一個項目的進行的是否順暢，肯定不是一人之力能夠推動的，有必要制定統一的規則，保持從產品到開發再到測試的步調一致，勁往一處使。
下面是此項目的心得，以此項目為戒：
- 1.需求階段：
目前如果是常規小發布的話，一般是產品發出來簡單的需求說明及上線時間點，在當面說一下，開發就開始coding了，這樣對於有經驗或者理解能力強的開發是OK的，但是，我們一般遇到的都不是這樣的開發[捂臉]
所以我們的解決方法是：
不論大小的需求，都要把產品、開發、測試約在一起，產品對新需求做說明，然后開發復述自己對於需求的理解風格給產品和測試聽，看是否理解正確
會議結束后，由產品將需求記入teambition
- 2.指定規划
徹底了解需求之后，開發評估這個需求的工作量，然后再說一下自己手頭的工作是什么，把手頭的工作和需求進行優先級排序，確定先做什么再做什么，給出具體提測時間點。
然后測試評估該提測時間是否合理
- 3.測試：
開發提交測試的代碼需求自測通過
提測時間點是從開發自測通過時間開始算，如果提測的內容到測試之后其他主流程block的話，測試打回提測內容，此刻不算做提測時間，直到主流程通過（冒煙測試通過）才算是提測，該時間點才算是【提測時間】
提測的內容在teambition上及時將狀態改為【測試中】（非測試中的問題將不列入測試范圍）
若此次提測有老代碼或者邏輯優化，但是在前端無感的話，需求同步到測試，測試同學會留意此部分功能