究竟什麼樣的開發流程是規範的?

新亮筆記發表於2020-03-02

概述

有讀者反饋,讀了文章 一線技術管理者究竟在管什麼事? 收穫滿滿,但還有點不過癮,還想了解更細的東西...

這篇文章分享開發流程規範,目的是提高產品質量,優化開發流程,供大家參考。

規範是死的,人是活的,希望自己定的規範,不要被打臉。

究竟什麼樣的開發流程是規範的?

接下來從以上六個階段進行逐一拆解。

1 需求評審

作為技術人員肯定都參加過需求評審會,不知道有沒有遇到這樣的情況?

  • 產品經理按照 PRD 文件讀一遍,參會人員無動於衷。
  • 產品經理剛講了一個需求點,參會人員就產生了激烈的討論,都在證明自己是對的。
  • 參會人員對需求的目標不明確,對需求點進行發散思維討論,最終偏離方向。

遇到以上問題,肯定是在參加需求評審之前未做充分準備,那麼問題來了,需要提前準備什麼?

評審前

不要聽產品同學說,該需求是大老闆跟進的、非常重要、非常緊急之類的,就問產品三個問題:

  1. 解決了什麼問題?
  2. 提升了什麼指標?
  3. 有什麼商業價值?

這三個問題搞清楚了,再進行評審。

產品經理髮出 原型PRD 初稿後,開發人員要有 1-2 天時間(具體時間根據專案大小而定),熟悉文件,有任何疑問可以反饋給開發經理,由開發經理統一收集再反饋給產品經理,產品經理逐一進行答疑。

熟悉完文件後,開發人員和開發經理需要一起確定:

  • 技術選型(前端/後端框架、日誌中介軟體、訊息中介軟體、資料庫...)
  • 技術架構(元件與元件之間如何協同工作,如何部署)
  • 技術難點預知(明確存在的技術難點,並確定解決方案)
  • 效能瓶頸預知(明確可能存在效能瓶頸的地方,並確定應對措施)
  • 上下游系統互動(明確在流程中的哪個位置,約定介面文件提供時間、介面聯調時間)
  • 功能模組劃分(任務拆分和分配)

技術方案確定後,需要輸出技術設計文件,包括:總體設計概要設計詳細設計介面設計 等。

評審中

開發人員必須參加,有需求不明確的地方當場提出,同時開發人員也需要思考產品需求是否合理,可適當提出自己的產品意見。

一般評審至少有兩次(初稿和終稿)。

評審後

評審後,如有需更新技術文件的請及時進行更新。

開發經理首先需要考慮團隊現有的資源及專案的優先順序,然後根據技術設計文件進行評估排期。

排期模板如下:

究竟什麼樣的開發流程是規範的?

2 技術評審

評審前

開發人員一定要重視技術設計!

開發人員一定要重視技術設計!

開發人員一定要重視技術設計!

重要事情說三遍!

技術評審主要評審什麼?

  • 系統關係圖模組關係圖流程圖的設計,畫圖工具根據自己愛好即可。
  • 介面設計,需要考慮介面的 相容性、擴充套件性、引數命名遵守 引數命名規範 等。
  • 資料庫設計,需要遵守 資料庫設計規範,並記錄 資料表變更文件
  • 詳細設計,需要考慮公共類、公共方法、方法定義 遵守 專案框架目錄規範

評審中

開發人員和開發經理必須參加,涉及到總體設計和概要設計時,需要邀請 架構師 參與,涉及到資料庫調整時,需要邀請 DBA 參與。

一般評審至少有兩次(初稿和終稿)。

評審後

評審後,如有需更新排期文件的請及時進行更新。

排期確定後,通過郵件方式進行回覆排期,使用標準化的 回覆排期郵件模板

按部就班,按計劃行事。

3 需求開發

編碼

開發人員編碼過程中,需要遵守團隊的 編碼規範,同時嚴格按照設計文件中的技術方案執行,除了保證程式碼邏輯的正確性外,還需要考慮程式碼封裝性可維護性可擴充套件性,當編碼階段發現技術方案需要調整時,需要及時通知開發經理,經過同意後才能實施,涉及到引入新框架和新技術,也需要提前通知開發經理。

程式碼審查

開發人員需要控制程式碼提交的頻次和粒度,每次程式碼提交之後 24 小時內,需要主動聯絡程式碼審查人完成檢查,開發經理負責檢查是否執行到位。

程式碼審查主要審查什麼?

  • 規範性檢查(是否符合程式碼規範、提交備註規範等)
  • 健壯性檢查(是否陷入死迴圈、資源未釋放等)
  • 安全性檢查(是否存在SQL隱碼攻擊、XSS、SSRF、CSRF、越權、檔案上傳等)
  • 效能檢查(是否存在未加快取頻繁連線DB,是否需要連線池)

聯調

開發人員積極主動地推動聯調工作,如果遇到阻礙及時通知技術經理進行協調。

自測

聯調完畢後,開發人員需要同時完成自測,並將標準化的 自測報告 發給測試團隊。

對於有效能要求的專案,需要開發人員進行效能測試,並出具標準化的 效能測試報告

提測

自測完畢後,通過郵件方式進行提測申請,使用標準化的 申請提測郵件模板

開發人員根據公司運維提供的釋出方式,進行部署到測試環境。

4 跟進測試

測試用例評審

開發人員必須參加,避免出現測試與開發對需求理解不一致的情況。

Bug 修復

開發人員及時關注 Bug 列表,快速修復迭代釋出,如果測試進度存在延期風險,需要及時通知開發經理。

5 跟進上線

開發人員首先確認 Bug 全部關閉,同時產品人員在測試環境驗收通過,然後需要主動推動相關團隊理清上線依賴和上線順序,同時確定回滾預案,最後根據公司運維提供的釋出方式,進行部署到線上環境。

線上環境部署完成後,通過郵件方式進行通知產品人員和測試人員,使用標準化的 上線完畢郵件模板,同時積極推動測試人員和產品人員完成線上驗證,線上出現問題後第一時間通知開發經理。

6 線上問題覆盤

需求在測試環境和正式環境,均未測試出 Bug,上線一段時候後出現 Bug,這種問題用什麼制度約束?

出現問題後開發人員及時修復,修復完了就完事了。僅僅做到這些還遠遠不夠。

建議使用如下模板進行復盤。

究竟什麼樣的開發流程是規範的?

小結

大家可以數一數上面使用到了多少規範,這時有朋友會說了,這規範也太多了吧,這和工廠工人有什麼區別,我們程式設計師是有創造性的,我們喜歡前沿性、挑戰性的工作,我們放蕩不羈愛自由...

針對這個問題,首先我不否認開發人員是有創造性的,但並不是所有的程式設計師都有創造性,在現實工作場景中大部分程式設計師不是做創造性工作的,也沒必要做創造性工作,所以必須按照規範流程執行。

團隊管理和團隊之間合作,必須要有規範,並嚴格執行。

就到這吧,以上供參考。

推薦閱讀

歡迎關注一起交流學習

究竟什麼樣的開發流程是規範的?

相關文章