第一步：
專案/系統開發，確定專案邊界和業務，當然是通過需求文件來確定，有明確**/標準最好
實際生產是逐步明確，那要有個框架體系，在框架中逐步明確。
使用寫書來模擬，就是先確定這本書的涵蓋範圍/傳授知識點；寫出對應目錄；然後對應目錄填充內容。
這就是框架，內容最容易變化。
使用什麼表達方式（推薦是**，成本低+傳達意思明確）
第二步：
整理輸出完需求文件後，開發人員清楚要做什麼後（ps：清楚的程度就要看需求文件的質量和開發人員的理解能力和雙方的溝通能力），就可以進行評估，然後設計開發了
技術選型
架構設計（架構文件）
資料庫設計（資料庫設計文件）
介面設計（介面文件）
目錄規劃
**注釋（這也算文件）
這個時候該理解清楚的理解清楚，該輸出開發文件的輸出開發文件，該算工作量的算工作量，該寫**的去寫**
第三步：
開發後進行測試，測試人員要理解清楚需求
第四步：
測試完成後部署
部署後完事，等下一步迭代
這個下一步迭代，如果還是同套人馬，那理解起來快（畢竟設計是自己寫的，**是自己寫的）。如果換人接手，那以上提供的資訊量足夠接手開發者理解清楚（花些時間）
以上說的是個大概，給個具體示例更好的展現說明（不然看了上面=》哦，哦，然後呢？）
建個git庫，**文件都放在git上，也好追述歷史（當然一般都不看歷史）
git目錄規劃
/doc/ =》 放各種文件，建子目錄更好區分文件或指令碼
/src/ =》 源**，這裡後端選型是springboot，就按springboot的目錄規劃
/readme.md =》 readme
基本文件型別，畫圖我就使用visio，**用markdown，mysql資料庫指令碼用sql
現在要開發個電子檔案系統，目的是將檔案數位化，方便查詢，檢索，複製，傳遞，閱讀
需求文件，**，用axure還能畫圖互動效果，放到/doc/ 目錄下
根據需求文件，上面給的需求文件後詳細了吧，有**說明，互動效果，該問明白的問明白
清晰需求後，就可以技術選型了，選擇springboot完事
架構設計，這要根據非功能性的要求設計（使用者量，併發量，響應時間。。。） ，架構文件放到/doc/ 目錄下
資料庫設計，根據需求文件的各個細節，表注釋，字段注釋，能寫詳細就寫詳細，資料庫設計文件放到/doc/ 目錄下
介面設計，介面文件放到/doc/ 目錄下
源**目錄規劃，因為採用微服務思想，源**的目錄規劃很簡單的，不會巢狀目錄的，也不會過多目錄
搭建環境（使用docker搭建環境），寫**實現，單元測試
開發後進行測試，測試人員要理解需求後進行測試
測試完成後部署（我使用docker部署）
下一輪開發，因為上面有充足的文件（資訊量足），所以你能理解和繼續開發
需求文件更新
資料庫設計更新
介面文件更新
源**編寫更新
測試開發後進行測試，測試人員要理解需求後進行測試
測試完成後部署（我使用docker部署）
反覆迴圈
等利益驅動做下一次技術公升級，架構公升級，重新設計，重構等等
軟體流程 開發流程規範
1 prd 介面文件 資料庫文件等按sprint分開整理並同步到confluence 2 前後端分離開發模式下，後端設計介面開發文件，同步到confluence，同時提供mock介面 3 後端功能初步拆分後，由各開發自主評估工期，再由專案leader評審 前端開發人員根據原型圖評估工期 測試人員根據...
app開發流程規範
描繪遠景，設定目標 產品的遠景是什麼？計畫需要做什麼實現這個遠景？明確各個階段的產品目標，為什麼設定這樣的目標？市場調研，競品分析 通過針對性的市場調研和充分的競品分析，測算產品市場前景和風險成本。收集需求，排優先順序 收集各業務市場部門反饋的需求意見，做典型使用者的深度訪談，組相開發設計運營人員頭...
專案開發流程規範文件
本文件為xx公司的開發規範文件，給開發團隊提供開發標準和規範。在開發規範中包含了兩個部分，第一部分是專案開發流程規範，主要闡述在專案開發過程中的各個階段的規範。第二部分為coding開發規範，coding開發規範闡述了在乙個框架中的各個層的開發規範 注 在第一版中不包含對工作流開發的規範制定 1.專...