開發流程規範

流程

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. 開發過程中若需要修訂技術方案，需要開會讨論，知會相關同僚