概述
有讀者反饋,讀了文章 一線技術管理者究竟在管什麼事? 收穫滿滿,但還有點不過癮,還想了解更細的東西...
這篇文章分享開發流程規範,目的是提高產品質量,優化開發流程,供大家參考。
規範是死的,人是活的,希望自己定的規範,不要被打臉。
接下來從以上六個階段進行逐一拆解。
1 需求評審
作為技術人員肯定都參加過需求評審會,不知道有沒有遇到這樣的情況?
- 產品經理按照 PRD 文件讀一遍,參會人員無動於衷。
- 產品經理剛講了一個需求點,參會人員就產生了激烈的討論,都在證明自己是對的。
- 參會人員對需求的目標不明確,對需求點進行發散思維討論,最終偏離方向。
遇到以上問題,肯定是在參加需求評審之前未做充分準備,那麼問題來了,需要提前準備什麼?
評審前
不要聽產品同學說,該需求是大老闆跟進的、非常重要、非常緊急之類的,就問產品三個問題:
- 解決了什麼問題?
- 提升了什麼指標?
- 有什麼商業價值?
這三個問題搞清楚了,再進行評審。
產品經理髮出 原型
和 PRD
初稿後,開發人員要有 1-2
天時間(具體時間根據專案大小而定),熟悉文件,有任何疑問可以反饋給開發經理,由開發經理統一收集再反饋給產品經理,產品經理逐一進行答疑。
熟悉完文件後,開發人員和開發經理需要一起確定:
- 技術選型(前端/後端框架、日誌中介軟體、訊息中介軟體、資料庫...)
- 技術架構(元件與元件之間如何協同工作,如何部署)
- 技術難點預知(明確存在的技術難點,並確定解決方案)
- 效能瓶頸預知(明確可能存在效能瓶頸的地方,並確定應對措施)
- 上下游系統互動(明確在流程中的哪個位置,約定介面文件提供時間、介面聯調時間)
- 功能模組劃分(任務拆分和分配)
技術方案確定後,需要輸出技術設計文件,包括:總體設計
、概要設計
、詳細設計
、介面設計
等。
評審中
開發人員必須參加,有需求不明確的地方當場提出,同時開發人員也需要思考產品需求是否合理,可適當提出自己的產品意見。
一般評審至少有兩次(初稿和終稿)。
評審後
評審後,如有需更新技術文件的請及時進行更新。
開發經理首先需要考慮團隊現有的資源及專案的優先順序,然後根據技術設計文件進行評估排期。
排期模板如下:
2 技術評審
評審前
開發人員一定要重視技術設計!
開發人員一定要重視技術設計!
開發人員一定要重視技術設計!
重要事情說三遍!
技術評審主要評審什麼?
系統關係圖
、模組關係圖
、流程圖的設計
,畫圖工具根據自己愛好即可。介面設計
,需要考慮介面的 相容性、擴充套件性、引數命名遵守 引數命名規範 等。資料庫設計
,需要遵守 資料庫設計規範,並記錄 資料表變更文件。詳細設計
,需要考慮公共類、公共方法、方法定義 遵守 專案框架目錄規範。
評審中
開發人員和開發經理必須參加,涉及到總體設計和概要設計時,需要邀請 架構師 參與,涉及到資料庫調整時,需要邀請 DBA 參與。
一般評審至少有兩次(初稿和終稿)。
評審後
評審後,如有需更新排期文件的請及時進行更新。
排期確定後,通過郵件方式進行回覆排期,使用標準化的 回覆排期郵件模板。
按部就班,按計劃行事。
3 需求開發
編碼
開發人員編碼過程中,需要遵守團隊的 編碼規範,同時嚴格按照設計文件中的技術方案執行,除了保證程式碼邏輯的正確性外,還需要考慮程式碼封裝性
、可維護性
、可擴充套件性
,當編碼階段發現技術方案需要調整時,需要及時通知開發經理,經過同意後才能實施,涉及到引入新框架和新技術,也需要提前通知開發經理。
程式碼審查
開發人員需要控制程式碼提交的頻次和粒度,每次程式碼提交之後 24 小時內,需要主動聯絡程式碼審查人完成檢查,開發經理負責檢查是否執行到位。
程式碼審查主要審查什麼?
- 規範性檢查(是否符合程式碼規範、提交備註規範等)
- 健壯性檢查(是否陷入死迴圈、資源未釋放等)
- 安全性檢查(是否存在SQL隱碼攻擊、XSS、SSRF、CSRF、越權、檔案上傳等)
- 效能檢查(是否存在未加快取頻繁連線DB,是否需要連線池)
聯調
開發人員積極主動地推動聯調工作,如果遇到阻礙及時通知技術經理進行協調。
自測
聯調完畢後,開發人員需要同時完成自測,並將標準化的 自測報告 發給測試團隊。
對於有效能要求的專案,需要開發人員進行效能測試,並出具標準化的 效能測試報告。
提測
自測完畢後,通過郵件方式進行提測申請,使用標準化的 申請提測郵件模板。
開發人員根據公司運維提供的釋出方式,進行部署到測試環境。
4 跟進測試
測試用例評審
開發人員必須參加,避免出現測試與開發對需求理解不一致的情況。
Bug 修復
開發人員及時關注 Bug 列表,快速修復迭代釋出,如果測試進度存在延期風險,需要及時通知開發經理。
5 跟進上線
開發人員首先確認 Bug 全部關閉,同時產品人員在測試環境驗收通過,然後需要主動推動相關團隊理清上線依賴和上線順序,同時確定回滾預案,最後根據公司運維提供的釋出方式,進行部署到線上環境。
線上環境部署完成後,通過郵件方式進行通知產品人員和測試人員,使用標準化的 上線完畢郵件模板,同時積極推動測試人員和產品人員完成線上驗證,線上出現問題後第一時間通知開發經理。
6 線上問題覆盤
需求在測試環境和正式環境,均未測試出 Bug,上線一段時候後出現 Bug,這種問題用什麼制度約束?
出現問題後開發人員及時修復,修復完了就完事了。僅僅做到這些還遠遠不夠。
建議使用如下模板進行復盤。
小結
大家可以數一數上面使用到了多少規範,這時有朋友會說了,這規範也太多了吧,這和工廠工人有什麼區別,我們程式設計師是有創造性的,我們喜歡前沿性、挑戰性的工作,我們放蕩不羈愛自由...
針對這個問題,首先我不否認開發人員是有創造性的,但並不是所有的程式設計師都有創造性,在現實工作場景中大部分程式設計師不是做創造性工作的,也沒必要做創造性工作,所以必須按照規範流程執行。
團隊管理和團隊之間合作,必須要有規範,並嚴格執行。
就到這吧,以上供參考。