專案委員會：這是乙個很虛的角色，即能確定專案是否要做的那幫人，有時候可能就是乙個高階經理就能拍板確定。和我們實際開發沒啥關係，不用去關心他。
在說幾點注意事項：這個流程是站在前端開發角度來分析的，因此好多步驟的發起人都是 fe。（ps：在此我也希望大家在工作中都要做到積極熱情，主動承擔一些事情，你會得到收穫的。）
這個流程看著非常複雜冗長，你可能會擔心執行起來的效率。其實，我只是把所有的細節都畫出來了而已，實際執行起來不會太麻煩，有些事情很快就能做完，例如聯調。
圖右側列出了每個步驟的交付物，即該步驟做完需要產出的文件或者其他內容。交付物是專案管理中非常重要的概念，有了交付物才有能證明你真正做了執行並完成了這個步驟，而且萬一後面出了問題，也可以回溯（甩鍋）。例如評審會結束之後，一定**郵件寫出會議結論和評審人。
上述流程有些可能會被大家忽略，或者覺得多餘、浪費時間，例如技術方案設計和評審，再例如自測。其實只要你有點開發經驗或者專案管理經驗，都應該知道這不是浪費時間。拿技術方案設計來說，如果你接下來開發程式很順利，寫乙個技術方案並不是難事兒，你不會因此而延期；但如果你技術方案寫了兩天都沒寫出來，那你開發的時候估計也磕磕絆絆不順利，延期風險很大。
這個過程我們作為 fe 很可能是參與不到，或者壓根就不知道的。因為在需求評審之前，所有的事情都是 pm 來主導的，只有專案立項之後，並且 pm 把需求編寫完成，才能流轉到 fe 這裡。總之，這個過程你不用關心，只需要知道有了這個過程，pm 才能編寫需求，並發起需求評審。
編寫需求是 pm 的工作，我們不用關心。接下來 pm 會拉各個角色（ue ui rd crd fe qa）開會，進行需求評審。
會議的主要步驟：
第二，各個角色的與會者提出自己的問題，pm 來解答；
第三，如果問題全部被解答，則評審通過，否則評審不通過。
fe 參見需求評審和其他 rd crd 類似，最重要的是關心這些功能的技術實現：是否可實現，或者實現成本高不高。例如，pm 要在使用者長按點贊按鈕時顯示絢麗的動畫，這一點使用 h5 來成本太高，你就可以建議 pm 在 h5 端換成簡單動畫。另外，開發人員也可以對 pm 的功能邏輯提出質疑，不一定非得是技術問題。
評審結束之後，pm 一般就會向各個開發人員要排期。注意，這時候不能立刻答應，最好的回覆方式是：我們回去討論一下，明天下班之前（或者某個未來不太久的時間點，都行）給你答覆。這樣，你可以和其他 fe 或者架構師來討論技術方案，一起評估乙個比較靠譜的排期。
（ps：如果你的專案有拍死的 deadline ，那沒招了，你就安排加班吧。）
這一步容易被大家忽略，人類好像是本能的眼高手低，感覺看似比較簡單的事情就很樂觀。越是這種心態，越要謹慎行事，在這裡我建議所有的公司或者團隊，都把編寫技術方案作為乙個必要的步驟，即開啟開發前必須編寫技術方案，並完成評審。
技術方案編寫完成之後，需要拉內部的經理、架構師（或者技術負責人）、其他對接的角色（rd crd）來評審技術方案。內部人員注意評審這個方案是不是符合設計原則，有擴充套件性，以及是否有其他坑（如效能問題，安全漏洞等）。外部對接的角色主要評審介面是否全面，輸入輸出設計是否合理。
技術方案評審通過之後，就得給 pm 反饋排期了。注意，估算工期一定要留有 buffer ，給自己留好餘地。有工作經驗的人都知道，乙個人在乙個公司裡，一般會同時擔任很多的工作，你不能保證接下來不會有其他功能耽誤你的時間。例如，這個專案你本來預估是 10 人/天工作量，那你最好反饋 12-13 人/天。
（ps：評審之前反饋排期也可以，只是評審之後反饋，更加靠譜一些。）
補充一句：這裡我們僅僅提到了 fe 的技術方案評審，其實 crd 和 rd 也會有他們的技術方案評審，評審時也需要拉著 fe 。其實大家的關係都是相互的，彼此相互把關，出來的設計方案就不會有太大問題。
互動和視覺的設計，是 ue 和 ui 要做的事情，我們不管他們怎麼做。他們做完之後會拉著 pm fe crd qa 進行設計稿的評審，即看看這個頁面最終是什麼樣子。
fe 去參加主要看看視覺的實現是否有難度，特別是對一些透明、漸變、毛玻璃、陰影等特效，要慎重對待，還有比較常見的例如 1px 邊框的問題。這些如果你遇到了，但是不確定是否可以實現，那最好回去查查再回覆他們。
評審通過之後，ui 將產出設計稿給 fe 。按照慣例，ui 應該給 750 畫素的圖，即以 iphone 6 兩倍屏為標準的圖，並且設計稿中標出所有的顏色色值和間距、字型的大小。他們有專門的工具來匯出這些，例如用 sketch 就可以輕鬆匯出。注意，此時如果你已經給了排期，但是設計稿比較複雜的話，必須及時和 pm 溝通修改排期，有問題早發現早處理。
有了前端的技術方案，有了客戶端、後端的介面，有了視覺設計稿，這時候就可以進行開發了。一般需要從 git 裡新拉乙個分支，使用 mock 資料（此時後端還沒有介面）。如有客戶端的對接，還需要用到一些模擬 native 能力的外掛程式，如果你們沒有那就只能等到和客戶端聯調時再看了。開發產出的不僅僅是**，還應該有開發文件（也可以是比較豐富的注釋）和測試用例。
我們作為技術人員，往往以為乙個軟體專案最關鍵的就是**開發，而傳統的專案管理流程說，**開發只佔軟體生命週期的 1/6 。根據本文相信你能體會到，**開發真的只佔軟體專案的很少一部分。所以，作為程式設計師你要想自己值錢、有不可替代性，就要從整個軟體專案的階段入手，而不僅僅是提高開發能力。
**開發完成之後，所有介面都做完了，你要告訴 ui 進行視覺聯調。雖然你自己是按照 ui 給的設計稿做的，但是你不一定每乙個細節都做的正確，需要 ui 確認。另外，各個手機螢幕的響應式做的怎樣，也需要 ui 拿不同手機測試。他如何測試你不用管，只需要配合他就行了，遇到問題你就改。
這一步的產出是「聯調報告」，不要被這個詞給嚇著，以為要寫乙個正規的文件。現實不是這樣的，待 ui 聯調完了之後，讓他在專案群裡 @ pm 回覆一下說「視覺聯調通過」，這樣就行了，這就是聯調報告，有這個記錄即可。包括圖中所有的「報告」，最常見的形式就是郵件和群資訊。但是，哪怕就是一封郵件或者群資訊，短短的一句話，這個步驟也不能省略。否則誰知道視覺聯調已經成功了？
fe 開發 h5 頁，crd 開發客戶端，rd 開發後端介面，待大家都開發完成之後，也需要把**放在一起聯調一下。將 h5 和後端**打包到同乙個測試機上，既可以聯調 h5 和後端介面。將客戶端的訪問位址指向這個測試機，就可以聯調客戶端和後端介面，也可以聯調客戶端和 h5 。聯調成功之後，最好再給 pm 看一眼，讓他確定這就是做出來的效果。
這一步我是自己加的，也是我自己的做事風格。但這一步不是我自創的，在傳統軟體專案管流程裡，就有「冒煙測試」這一步驟，也就是自測。但是，我在所有帶過的團隊中，都沒有發現規定必須自測且產出自測記錄。但是，我還是堅持自己的觀點，我負責的專案必須要有自測步驟，而且我呼籲大家也要堅持自測。
自測並不是把所有功能全部詳細測試，而是把核心功能都測試一遍，並記錄測試結果，保證主流程是能跑通的。我相信每個有工作經驗的同學都遇到過這種情況，程式設計師**寫完就提測給 qa 了，qa 一執行立馬報錯，無法繼續測試，打回來找程式設計師重新修改。這種事情極大影響效率，誰都不樂意看到。如何避免呢？答案就是提測前，先自測。
自測依據需求的核心功能，可以是人肉手動測試，有可以是自動化單元測試，這個不要求。但是最後要產出乙個自測記錄，即用乙個**，列出所有核心功能，並記錄每個功能你的測試結果。為何要有這個產出，就是為了證明你真的測試過每個功能了，而不是眼高手低看兩眼就通過了。一般需要產出交付物時，大家都會認真對待，沒有交付物大家就可能敷衍了事。
自測完成，並產出自測記錄，即可以提測了。提測需要 fe crd rd 和 pm 一起，將需求文件、**、自測記錄提交給 qa ，併發正式的提測郵件，告知所有專案角色該專案提測了。qa 收到之後，確認分析完成，需要回覆計畫的測試完成時間。然後 qa 開始測試。
qa 測試過程中肯定會不斷的產出 bug 列表，此時 fe 應該要求 qa 把所有 bug 的描述都寫清楚，即能讓個自己傻瓜式的復現這個 bug ，以便快速修改。遇到復現不了的問題，一定要第一時間找 qa 來復現，有些問題復現了一次再也復現不了，那你就先別管它，先去改別的問題。qa 測試完成之後，要發準出郵件，告訴所有專案角色該專案測試通過，可以準備上線了。
qa 測試完之後不一定能立馬上線，因為一般產品的上線都是例行的。頻率比較快的產品，可能規定每週一到周四下午的某個時間點可以上線，晚上一般不上線，周五一般不上線，除非緊急修復 bug 。因為，上線之後就有可能帶來一些 bug ，可能晚些才能發現，如果晚上或者周五上線，一旦發現 bug 大家已經回家睡覺或者過週末了，不容易集中人力修改。
上線的步驟一般是先合併**到 dev 或者 master 分支，每次上線可能是多個功能一起上線，因此合併**時還可能會出現衝突，得先解決衝突。然後開始發起上線審批，生成上線單，需要 pm qa 和各個技術經理審批確認，op 才能將這個上線單解鎖，這樣就可以發起上線。
上線的機器一般也分好幾步，每一步都需要 qa 參與回歸測試：
第一步是預覽機，預覽機只對內有效，外網看不到，但是載入線上的真實資料。
第二步是單台機器，即線上機的一台機器。
第三步是單機房，即線上機的乙個機房。第四部是全量，即線上機的所有機房。這些步驟全部操作完成，並且 qa 全部回歸測試完成，才算真正的結束。
如果其中乙個步驟遇到問題，就需要啟動快速回滾。回滾就是用 git 的上一條記錄重新上線，覆蓋目前的**，步驟也是先預覽機、單機器、單機房、全量，每一步也需要 qa 回歸測試。如果 bug 影響嚴重，還需要專案的主要角色寫檢討，做覆盤匯報，總結教訓。
專案總結是可選的，而且我發現大部分的團隊都不會去做總結，覺得上線完了就大功告成，該啟動下乙個專案了。但我覺得，無論是不是做專案，做完一件事（如看完一本書）就應該自己總結一下。回顧一下經過，總結一下得失，積累一點經驗，這樣才能慢慢成長。
關於研發流程
關於研發流程，每個公司因為團隊規模大小而不一樣。團隊規模較小 需求，研發，測試都是由乙個人跟你提供，始終只有乙個人和你對接 正常團隊規模 產品出需求，技術主管和研發人員評審確定方法，研發開發和自測，測試工程測試，產品驗收。整個過程你需要合產品，研發主管，測試打交道 利弊 團隊規模小比較靈活，因為你每...
軟體專案研發流程
前一點段時間參與了乙個公司的新專案，最近有時間開始總結一下專案的研發流程 研發流程大概分 為 6個部分可研性分析，需求分析，概要設計，詳細設計，程式編碼，測試，發布，下面就分別說一說這個幾個環節具體都幹什麼.可研性分析之後，確定產品，研發 技術leader和主程 測試同學，質量同學，需求方對接人進行...
研發管理流程（一）
公司的一切流程都是為了提公升交付質量，提高市場競爭力，形成核心競爭力。目前的研發管理流程，分為4部分 描述 是否跟進專案，組建專案團隊，一般是銷售 方案 專案經理。思路 判斷客戶想做這個事情的確定性，評估贏下專案的可能性和所需的預先投入，從而決定是否繼續跟進 內容 1 商機預覽 2 我們為什麼要參加...