任務排期
-
優先級排期。按優先順序排列一個產品需求列表。
-
顆粒度。每個需求要盡量小，安排一個小需求在3天內完成。
-
工作量。技術管理者，要評估每個需求的工作量。評估工作量，除了開發時間，還要預留20%的時間處理bug，以及其他的雜事。
-
並行任務。任務並行能提高效率，串行會卡頓。
開發人員發成一個小需求后，可以提測，然后做其他的需求，這樣測試人員就不會被卡住了。 -
預留測試時間。除了定好開發人員的開發時間，還要留充足的時間給測試人員測試。
-
何時完成？何時發包？發出哪些內容？
晨會
-
站會。坐着的會議經常會開得太久，晨會沒必要太久。
-
簡要。每人花兩分鍾講一下昨天/今天做的事情。
-
白板。通過白板展示每個人的工作內容，進度，以及遇到的阻礙。
-
量化。統計工作量，完成了某個需求的百分之多少，比如50%之類的。
還可以寫上耗費的開發時間，2h。(統計開發時間的意義不大)
需求評審
-
需求文檔提前發布。文檔提前半小時發給其他團隊成員，給大家閱讀思考的時間。
-
反講解。程序員聽完需求后，反過來講給產品/需求人員聽，看程序員對需求的理解是否准確。
-
拒絕不合理的需求。不明確的需求不要做。
-
在開發的過程中，最好不要亂改需求。這樣會浪費開發時間，也影響交付的質量。
-
理解真正的需求。多溝通，開發人員理解了需求，再進行開發流程。
開發流程
代碼設計
- 代碼設計。包括接口設計，數據表設計等等。
時間允許，還可以給出時序圖，UML圖。
代碼開發
-
單元測試。單元測試的覆蓋率要達到要求;
-
功能自測。程序員寫完了代碼，最好多測幾遍，確保開發環境和測試環境都沒問題。不要浪費測試人員的時間。
Review
- 在提交代碼前，先讓高工幫忙Review一下，Review完修正了代碼再Commit。
代碼評審
- 代碼評審。復盤代碼的設計是否合理、邏輯是否正確。
測試流程
用例評審
- 用例評審。測試用例，要在測試之前就先寫好。
測試
- 正確地提bug。測試人員，最好能寫清楚bug，包括期望結果、重現步驟等，如果能給出具體的圖片更好。
將bug描述清楚，能夠節省開發和測試之間大量的溝通成本。
發布上線
-
發布說明：包括相關的服務，版本更新內容。sql腳本。
-
上線/發包必須經過運維。保證版本的可控性，避免泛濫，后續問題不可控。包盡量控制發的頻率，不然很多功能控制不住。
-
一周一迭代。或者兩周一迭代。
會議
- 會議總結文檔。開完會要有結論，並記錄文檔。