流程可以說是非常惹人討厭的東西了，四代見過太多的公司實行的繁冗的流程了。
為了辦一件事，要走太多的步驟，效率低下不說，最終還會形成一種叫“官僚作風”的習氣。這種如同癌症一樣的頑疾不斷毀滅着一個又一個的團隊。那么沒有流程不就行了！大多數創業團隊如是說。
創業團隊也需要流程嗎？
從四代的經歷看來，不是創業初期沒有流程，沒有流程大家怎么合作呢？
創業初期有的是流程，只不過沒有書面化而已！僅僅是沒有書面化而已！比如，什么時候規划，什么時候測試，什么時候發布，怎么解決問題，怎么響應反饋，哪一個不需要一套對應的流程？
只不過創業初期人比較少，當面交流就可以了，不需要一套書面化的流程。而書面化的流程應該在團隊磨合到能正常產出的時刻起，就應該書面化作為正式的團隊文檔，這樣由於有了個正式的開始，當創業團隊逐漸壯大，人數越來越多的時候，就可以不斷的充實和調整這個流程，讓它隨着團隊的成長而成長。
這就是即使PC團隊目前只有兩個人，四代仍然堅持要創建團隊工作流程的初衷。
版本發布流程
研發團隊最主要的流程應該就是版本發布流程了，也就是常說的Release流程，她真正的描述了每個版本完成的基本工作，包括完成的內容，完成的時間，完成的標准，對緊急情況的處理等等。
在經過數次的修正和調整后，四代的團隊目前試着實行的版本發布流程如下：
需求收集
流程的起點是收集本次版本需要完成的需求列表。收集需求可以說是軟件工程中最難搞的一部分了，偏偏它們還是軟件研發后面各個步驟的基礎，俗話說的好“不滿足客戶需求的軟件都是耍流氓！”。
不過對PC團隊現狀來說，這件事又不是什么困難的事，因為PC軟件的研發停滯了一個階段，客戶對軟件的需求早就堆成了小山。
四代需要做的就是將這些需求整理一下，結合軟件的現狀，給它們設定好優先級和順序。不過為了應對一些緊急的需求，四代還是增加了一個環節：需求收集階段。
在需求收集階段，四代會面向全公司成員，包括研發人員，測試人員，設計人員，客服和市場，發布征集軟件本次研發功能的建議，也就是從所有人那里收集一些客戶緊急需要的功能。
這個階段不是必走的步驟，當四代覺的這個版本的功能研發任務已經足夠緊急的時候，就不會發布這個公告。不過四代還是覺得，正常情況下每個版本計划的第一件事就是發布這個公告，這樣能保證研發不會偏離客戶太遠，這個太重要了！
當然了，這種做法也有個不好的地方，那就是需要各團隊所有人配合，坦誠的發表自己的想法。
這個似乎有一些難度，因為溝通幾乎是每個團隊最難的事了，何況還是跨團隊，人家理不理你還是個問題呢，那還談得上配合。所以實際操作的時候，四代都是拜托各個團隊的直屬經理，讓他們幫忙收集，效果還是會好一點點，不過大部分時候，也可以忽略不計。
上面這個環節主要是對外的需求收集，緊接着就是對內需求收集的環節。結合目標管理的理論，這一部分需求的收集包括三個部分：產品經理的需求，他代表公司，項目經理的需求，他代表團隊，團隊成員的需求，他們代表自己。
需求篩選
收集到需求后，接下來就是需求篩選了。
這個不用多說，四代自然是需要先按照優先級排好序，再根據規划的Release的時間的長短選擇合適的需求。
經過多次的試驗，四代覺得一個Release在10個周左右對PC團隊比較合適。在這個時間中，真正用於編碼的時間是4周，其中還包括1周專門用於修復比較嚴重的Bug。其余的6周包括測試，發布，緊急情況處理，小版本處理等。正常情況下，需求篩選就可以按照這個時間來。
編碼開始
需求篩選好以后，就是團隊成員自行領取任務了。
接着，四代會和團隊成員一起把自己手上的需要設計的任務設計一下，並組織項目所有相關人員舉行幾次會議，把這些設計過一遍，需要的調整的就調整，達到大家對所有這些的需求的理解是一致的。
雖然事先大家不可能想清楚所有的細節，不過認真的思考總是會為大家帶來一個好的開端。在開發的過程中，還會發現很多新的細節，不過沒關系，設計從來不是死的，設計從來都需要一個良好的起點，然后在此基礎上不斷演化。
在編碼的開始階段，四代會和團隊每個人把他們的任務細分到可以每1-2天都能提交的程度，這樣可以很方便的控制任務的進度和時間分配。
在編碼的過程中，四代唯一強調的就是代碼規范，這是四代的底線。做不到的人，四代會試着了解做不到的原因，並提供適當的方法幫助其做到。在四代幫助下仍然做不到的人，四代也絕不姑息，四代應該會馬上進行勸退，不過到目前為止還沒有發生。
進入內測
編碼完成以后，就是PC團隊內測了。
這一部分測試全部是圍繞新功能和修復的Bug展開，畢竟把一個漏洞百出的軟件交給測試人員測試實在是丟人的一件事，所以四代會帶領所有開發人員全身心投入到內測中。
由於開發人員對代碼十分了解，一般經過一定時間內測和修復后，除了一些不易修復或者不是很嚴重的缺陷，大部分主要流程中的缺陷都會被修復。
當然了，這是理想情況，在后面實行的過程中，還是出現了在開發時間很緊的情況下，內測做不好的情況，這是四代需要思考和調整的，四代需要頂住來自各個方面的壓力。
集成測試
再接下來就是開發人員和測試人員共同參與的集成測試了。
集成測試是最重量級的測試，目前都是手動執行的。
集成測試的第一階段和開發內測的目標是一致的，就是保證新功能和修復的Bug工作正常，發現問題就評估，然后根據重要程度修復。
第一階段測試結束后，第二階段就是全面的測試了，說白了，就是軟件所有功能的測試，非常辛苦而且枯燥，但是又不得不做。
這一階段測試內容非常多，包括軟件所有功能的測試，各種版本的測試，各個平台的測試，用戶真實數據的測試，大數據量的測試。這些固定的測試內容很多也是后面自動化的目標。
第三階段是探索型測試，說白了，就是無限制測試，也就是脫離測試文檔和常見的套路，完全不按常理出牌，執行一些不合理的操作，測試軟件的穩定性。
這個測試三板斧非常重要，它們結合起來基本做到了對軟件全方位的覆蓋，所以也是非常耗時的過程。經過幾次的試驗，這些測試的時間平均都在3周左右，和編碼時間也差不了多少了。
四代相信，只要成本允許，測試多花點時間，收益總是正的。
發布標准
為了便於划分測試的優先級和重點，四代把軟件的所有功能分成兩類：核心功能和輔助功能。核心功能指的是最為核心的資源管理模塊，輔助功能指的是登錄，注冊，人員管理等模塊。
四代和團隊決定是否發布軟件的標准：就是在當前版本中，核心功能沒有1級的Bug，輔助功能沒有0級的Bug。
所謂0級Bug指的就是不修復軟件就不能使用，或者用戶強烈要求修復的Bug。而1級的Bug指的是不修復該Bug的話，軟件用起來不方便，但是有方案可以替代的Bug。所以PC軟甲發布的標准簡單來說就是當前版本沒有0級Bug，核心功能還不能有1級Bug。
無奈的審核和收錄
測試以后發布就比較固定了，就是加密打包，然后拿到各大流氓的軟件管理中心進行審核和收錄。為啥叫“流氓”呢？大家都懂的，卸載又卸不干凈，不認識的軟件就報可疑，或者是直接殺掉。針對這件事，四代與鼬已經不記得與他們交涉過多少次，費了多少唾沫星了！
收錄成功后就發布升級包，客戶端軟件檢查到升級包就進行升級。
發布后的事
發布以后，如果有一些緊急的問題，然后就是2周左右研發小版本的時間。
小版本的測試比較簡單，基本都是根據代碼的修改范圍，划定測試的功能范圍，有重點的測試一下，然后再測試一下核心流程就可以發布了。
發布成功后，接着就是團隊面對反饋和進行反思的時間了。
這個部分怎么強調都不過分。因為不接受反饋，不進行反思的團隊就像一潭死水一樣，永遠無法成長為成熟的團隊，所以四代無論多么忙，多么沒時間，在發布后都會找時間完成反饋反思會議。
團隊功能的細化
在后面的實踐中，隨着專業的產品團隊和設計團隊的成立，產品的研發細節也在不斷的調整中，很多需求方面的事情不再由開發團隊完整的負責，而是有了專門的團隊去主導。這樣有了專門的分工，產品更加專業了，但是總體上說，這一套流程基本還是沒有太大的變化。
好吧，整個過程和大部分的敏捷過程都差不多，確實也沒有什么太多的奧秘在里面。如果非要說奧秘的話，那就是參與度，四代不斷嘗試在各個環節中增加團隊成員的參與度。
當然不僅僅是在研發流程中，四代還有一整套的方案來在各個方面提高大家的參與度，所以，即使是流程，也是和團隊的其他方面息息相關的，並不是孤立的存在，比如說與產品質量，就是密不可分的。
說起質量，很多人都會立即表示無語，甚至激進的測試團隊會當開發人員的面，大聲罵娘。唉，測試的那幫妹子也不容易哈，四代想。