如何提高團隊項目的開發質量、開發效率。
程序員
- 完成大於完美。
- 不要埋頭苦干，獨立思考后仍不能解決問題，要及時把問題拋出，向其他同事請教。
- 開發進度緩慢，項目進度有風險時，要及時上報，讓上級協調資源，或者其他開發人員幫忙分擔。
有風險不可怕，可怕的是不及時暴露風險。 - 需求並不是做得越多越好，要做有價值的需求。
如果每個迭代要做的功能一大堆，沒有時間自測，做完出一大堆問題，那還不如少做點，做好點。 - 程序員一定要會砍需求。
做不完的需求，一定要跟產品協商，部分需求能否放到下一個版本。
有時，產品一句話，程序員就能少加幾天班。 - 程序員評估需求，最好是留一些緩沖時間Buffer。
風險和質量，往往是由於時間不夠而導致的。
比如半天的功能，評估為一天。因為工作中經常要開會，或者有些亂七八糟的事情，不留Buffer，會增加風險，降低質量。 - 需求澄清前，要提前閱讀需求，這樣需求澄清才有意義，才能提出有意義的問題。
- 先搞清楚需求，再進行開發，不然做完了又得重新做。
- 在開發過程中，遇到不清楚的，找產品經理確認清楚，再繼續開發。
- 開發功能之前，要進行技術評審，包括技術方案、接口設計等。
有時，資深程序員幫忙指點一下，能少走好多彎路，少浪費很多時間。 - 接口的字段及含義，要錄入接口文檔。
- 數據庫字段的增刪、數據結構的變化、業務邏輯的變化，都需要思考是否會影響歷史數據。
如果會影響歷史數據，要如何處理歷史數據。 - 做單元測試，保證單元測試覆蓋率。
- CodeReview，做代碼評審，保證代碼的質量。
- 修改別人的代碼之前，可以先跟原來的開發人員交流。
- 參加測試用例評審前，盡量提前查看測試用例。
- 程序員開發后，在轉測之前，可以對優先級高的測試用例進行冒煙測試，也就是對着測試用例進行自測。
- 上線之前，准備好版本相關的腳本，並評審。
- 記錄生產問題，並寫清楚問題原因以及解決方案。
- 如果開發人員充足，最好每個功能模塊都有一個第二負責人。這樣第一負責人休假/離職后也能接手。
- 測試完成以后，如果再次修改代碼，需要通知測試進行回歸測試。
產品經理
- 不要跟甲方、業務方盲目承諾，隨意定期。
- 需求要分優先級。緊急的需求先做。
- 需求要做拆分。不要一次迭代就做一大堆功能。
做了不一定有人用，先做一個簡易版的出來，聽取用戶反饋，再逐步迭代。 - 需求澄清，提前兩天通知。
- 需求澄清，邏輯比較復雜的功能、系統內沒有做過的功能，最好先和開發人員提前溝通，能不能做，怎么做。
- 需求澄清，提前將文檔發出來。這樣團隊成員有更多的時間去思考需求，提出問題。
- 需求澄清，要講清楚需求背景，為什么要做這個需求。梳理清楚需求的前因后果，從用戶的角度出來。
- 需求澄清后，跟對應研發確認是否能聽懂，並讓研發反過來講解給產品聽
- 需求文檔，最重要的是，寫清楚哪些是新增的功能，哪些是修改的功能，哪些是已有的功能。
- 需求文檔，術語必須清晰，與頁面文字一致，加上雙引號。比如 "一級菜單"--"二級菜單"--"標題"。
- 需求文檔，要寫清楚菜單/路徑。不然別人看了文檔，都不知道需求相關的功能是在系統的哪個地方。
- 需求文檔，關鍵的信息和細節必須加粗，標紅。
- 需求文檔，及時上傳服務器。
需求文檔不止給是當前的同事看的，團隊成員離職后接手的人也能更好地理解需求。 - 需求變更，盡量減少。
- 確定了一個版本的需求后，進行需求封鎖。
需求封鎖后，不得隨意在版本中新增/變更需求。非緊急需求放到下一個版本進行。 - 發版的前兩天，不要再進行需求變更。
- 需求變更，必須在群里同時通知研發和測試，不能只通知其中一個。
- 每個月或者每個季度，同步需求規划。
- 拒絕甲方/業務方的不合理需求。
提測
- 研發在冒煙測試之后，再提測。
- 提測可以showCase。當着測試的面，把整體的流程走一遍。
有些研發，做完的功能，連主流程都跑不通，測試根本沒法測。 - 提測后，冒煙不通過的，測試可以打回。
測試
- 測試同學，應該在開發階段就准備測試的腳本，這樣就不用擔心測試階段時間不夠。
- 測試用例，在開發轉測的前兩天進行評審。
- 測試用例，評審后要上傳到服務器上。
- 多注意邊界條件。
- 自動化測試。
- 提高測試用例覆蓋率。
- 生產問題要及時跟進。
倒排需求
- 倒排需求，本身就是有風險的。
- 倒排需求，對質量是一種極大的傷害。
- 倒排需求，風險應該由業務方自行承擔。
倒排需求，壓榨了研發和測試的時間，加班加點，最后風險反而要由研發和測試承擔，天理何在？
倒排需求，不管是需求延期、線上問題，都應該由業務方負責，如果業務方不負責，那誰答應倒排需求就由誰負責。
風險應該在倒排需求時，就跟業務方說清楚。
並行需求
- 盡可能減少並行需求。同時做兩件事情，往往會顧此失彼。
開會
- 開會不要開太久。
會議不要超過一小時。太長的會議不會有人聽的。
白天開會，晚上干活。最終會影響項目的質量。 - 開會要提前預約，咨詢同事是否有空，如果是線下會議，要提前訂好會議室。
- 開會只拉相關的負責人，不要拉所有人，不要浪費別人的時間。
- 開會時，主持人要檢查人員是否到齊，及時通知入會。
溝通
- 通知事項要通知到位，相關人員全部同步。開發、測試、產品、負責人，這幾個人都要通知。
- 溝通，要說重點。不相關的話別說。
- 溝通，直接找相關的負責人，不要間接傳達信息。
- 溝通，簡單扼要。能一句話說完的事，不要說兩句話。
- 溝通時，除了可以說話，還可以用肢體動作、寫字、畫圖等。
發版
- 發版當天，修改代碼要謹慎，需要截圖發到工作群，開發人員一起review。
- 發布評審checkList：包括相關的服務清單，服務的發版順序，版本更新內容，sql腳本。動態配置。接口權限、菜單權限、回滾sql、回滾tag等。
- 發版需要提供回滾策略：假如發版后出現問題，需要進行回滾。
提前准備好回滾的sql，包括各個sql腳本的回滾語句。
git需要打tag，一旦需要回滾，直接用tag回滾。