剛做完一個專案並且艱難得上線，對整個專案流程和gitlab規範 有了一些心得，給新來的同學普及一下。
最先產品會寫一篇需求文件，咱們要先看需求文件對專案有一個大致瞭解，然後產品喊後端、ui、前端 一起在討論-一下專案，對專案有一個明確的認知，如果討論過程中 有咱們沒有做過功能，咱們需要調研。 ui畫完圖 咱們先看圖 想想一下專案的整個互動流程 感覺哪地方邏輯不對 可以和ui、產品一起商量，商量的時候記得叫上後端，別你們商量好了有改動 人家後端還不知道怎麼回事那。 如果一些佈局 你看著難受彆扭，可以和ui商量 但是以ui為主，畢竟人家是 幹這個的，還有剛來咱們公司 肯定會遇到沒psd圖 你沒法量 但是還需要符合規範的情況，三種方式 你要求ui出psd圖 、 還有就是 自己看《web端互動規範》和讓ui 在圖上標識距離畫素。一般都是第三種，但是 由於咱們有元件庫 通常情況下 都是不用測量距離。
對專案有明確認知 就可以開始畫類圖，類關係用什麼標識連線點開這個連結有詳細說明 ，不會畫 或者 類關係不明白的 可以問各自師傅，類圖是重中之重 真正開始寫**的時候 是要跟根據類圖來做的。mock在這個時候 也可以與後臺制定了。
然後ui圖出完之後，咱們就可以開始畫互動時序圖了，互動時序圖要體現出 使用者的操作流程和互動效果，互動時序圖畫完要給ui看一下，哪地方的互動有問題 ui會和你說的。
圖畫完讓師傅或者組長檢查一下，然後就可以開始預演了，預演就是 你拿著這兩個圖，給團隊其他成員 去講解，尤其是 互動時序圖 需要和團隊成員達成思想一致，才算預演成功。預演通過後，需要在gitlab上自己所在專案拆分issue，
完成一個issue的流程 ：
把對應issue的分支合併到dev
我們開始開發功能是在dev上建立分支，功能分支 就是開發專案裡面還沒有的新功能的分支，以dev-feat開頭。功能開發完之後確定沒有問題，合併到dev，如果合併到dev之後發現有問題要修復，在dev分支上建bug修復分支，以dev-fix開頭，修復完之後合併回dev，功能全部開發完畢。
dev合併release之前 需要配置好webpack，向運維要你專案的測試地址（域名），向後端要後端的服務測試地址。
合併到release 並且專案 能執行了，就算是提測成功，在測試期間 如果測試給你找到bug 他會建立issue 並把issue 指派給你，如果你發現是後端問題 你在和測試說 讓他指派給後端，
在測試環境發現的問題，在release分支上建立分支，以fix開頭，修復完合併回release 指派給測試，測試合併後，然後關閉該issue。
專案線上沒有問題後，master合併到dev，專案負責人自己提合併請求，自己完成合並，然後將dev合併到release ，測試組同事完成合並。最後會開專案總結會要記住 開會的時候總結的幾點 ，最後會寫專案總結 寫到專案維基裡。
APP專案合作流程規範
整體流程說明 mrd評審 磨刀不誤砍柴工 1 mrd對於問題細節分支和細節描述希望能夠更多覆蓋，避免開發過程中的反覆確認和資訊不對稱。2 mrd評審，rd qa都要帶著問題去評審，這樣也可以更好幫助產品規避沒有想到的邊界問題。開發物料管理 清晰才能簡單可依賴 pm 負責上傳最新mrd文件 互動文件 ...
專案開發流程規範
1.專案啟動 1.需求文件 2.概要設計 3.詳細設 4.編碼 5.coderiew 7.自測 8.打包釋出測試版本 9.正式版本釋出交付 10.釋出後的維護 上面這些是自己一個非科班出身的人工作幾年後的總結，其實我想作為一個科班出身的軟體工程專業的人，肯定知道這些流程，但是我想學校老師也是大概的講...
專案流程規範之我見
今天早晨跟主管溝通了一個專案的流程問題，可能按照之前專案管理的經驗，該專案的流程並不符合標準的規範流程。經與協調溝通後中，也考慮該專案涉及到的人員 部門太多的實際情況，專案經理一時無法對資源做更為細化的排期。大家經過了一番激烈的爭辯後，感覺目前是有一些不太合理的地方，但是需要針對不同專案的實際情況去...