開發流程規範

開發流程規範

流程

1. **需求整理：**和業務、開發 深入 溝通之後做產品設計，以產品原型、產品文檔方式整理出詳細產品方案
2. **需求評審：**產品文檔、產品原型完善之後邀請設計師、測試、開發（如有必要建議加上業務方）參加需求評審會；會議開始前要求所有參會人員已經認真地看過產品經理提供的產品原型、產品文檔；在該會議上所有參會人員對產品細節提出疑問，力求所有人對所有細節都有清晰明確和一致的理解，如果有異議，討論之後由產品/業務方修改需求後重復該環節。會議最終結果要求所有人對產品需求描述（原型、文檔）清晰明確無異議。
3. **準備階段：**需求評審會之後各崗位並行啓動，測試開始寫測試用例，設計師設計初稿，接口設計接口方案，開發設計開發方案
4. **測試用例評審：**所有人蔘與測試用例評審，通過對測試用例的評審加深對需求的邏輯細節理解，進一步完善開發方案和接口方案、產品和設計師一起完善交互設計
5. **設計方案評審：**評審設計方案，對於開發來說主要是避免出現某些特殊情況下的設計方案缺失，例如橫向/縱向元素較多時在小屏幕下的設計是否缺失，元素內容彈性較大時（文本長度）不同內容的設計方案是否合理完善，動態表現是否合理等
6. **接口方案評審：**開發和測試、產品（可無）評審接口方案，最後以文檔形式交付
7. **開發方案評審：**產品、測試一起評審開發方案，避免開發方案設計缺陷、前後端對相同業務理解不一致
8. **開發階段：**開發開始嚴格按照開發方案分模塊進行迭代開發，測試開始按照測試用例和接口文檔編寫接口測試代碼、測試腳本
9. **測試階段：**開發分模塊提交給測試進行測試，開發配合測試Debug
10. **上線：**所有模塊測試完畢，gitlab 上打 tag，打出各渠道包，提交上線
11. **需求更改：**開發、測試過程中若有需求更改（包括但不限於產品邏輯、文案描述、UI 設計），重複執行以上步驟。嚴禁直接找開發私下調整，務必保證所有改動都會通知到所有人。注：不需要步驟的可以跳過，例如 UI 改動，不需要“接口方案評審”，接口改動不需要“設計方案評審”。

各環節及崗位交付要求

1. 產品交付要求：
   1. 文檔完整、無歧義、簡潔、通俗易懂，產品原型請保證“基本交互”，最好是高保真；
   2. 若有判斷邏輯的，請在產品原型上註明某項操作導致的後續流程所需要執行的判斷邏輯。
2. 接口交付要求：
   1. 以接口文檔形式交付（推薦代碼生成）
   2. 註明都有哪些接口；
   3. 註明每個接口的業務說明；
   4. 註明每個接口的數據結構；
   5. 註明每個接口的各字段是否可以爲空；
   6. 各接口中相同含義的字段名稱和數據類型要保持相同；
   7. 如果存在枚舉字段，需要詳細給出各狀態的枚舉值以及對應的說明；
   8. 接口請求頭、請求格式的詳細規定；
   9. 接口非正常響應狀態的詳細規定；
   10. 接口評審完成後要儘快先給出“假數據接口”；
3. UI 交付要求：
   1. 文件夾路徑按照產品原型邏輯組織，每個對應模塊的文件夾下應包含所有頁面對應的標註圖，不應將類似標註圖放到其他文件夾下
   2. 提供全局適用的設計規範定義，以及適用說明：包括但不限於全局用到的顏色，字體大小，按鈕在各種狀態下的背景色、前景色、寬高，文本間行間距，文內折行時的行間距，分割線顏色，內邊距等等
   3. 需要提供不同尺寸的屏幕下設計差異性，例如橫向/縱向元素較多的情況下，需要提供小尺寸屏幕的設計標註圖；橫向/縱向元素較少時，需要提供大尺寸屏幕的設計標註圖；若元素內容多少彈性較大時，請提供不同情況下（內容較多和內容較少）時的設計標註圖
   4. 切圖要壓縮
4. 測試方案交付要求：
   1. 完善的測試用例文檔
   2. 接口測試方案（最好有測試腳本能夠批量測試所有接口）
   3. 上線必備流程/條件
5. 開發方案交付要求：
   1. 技術選型調研結論報告（優劣比較、踩坑方案）
   2. 複雜的業務流程要給出流程圖、時序圖（圖可以很簡單，但是要能精準地詮釋方案）
   3. 複雜需求更改及代碼重構要有架構設計方案，需要經過內部評審
6. 開發階段執行要求：
   1. 嚴格按照**4個參考（開發方案、需求文檔、產品原型、設計圖）**開發/Debug，代碼提交前務必執行單元測試
   2. 若開發過程中發現設計標註或產品需求描述不夠清晰、邏輯錯誤等問題，需郵件知會項目組內所有人，重複執行流程步驟解決問題。嚴謹私下溝通私自解決，防止其他人不知情導致工作出錯
   3. 開發過程中若需要修訂技術方案，需要開會討論，知會相關同事