那個時候，build一次大概是15分鐘，因為Check In Gate環節是按照標準流程走的，所以build出錯的幾率也小。CC大多數時候是綠的。哪怕偶爾出問題紅了，也很快被修正了。

　　隨著項目的開發，代碼規模越來越龐大。功能測試越來越慢，比起自動執行腳本那種速度，開發人員更樂意手動點兩下，加之上面對工作進度的壓力。更改了一些工作方式：后臺的工作方式不變。

　　前臺，將功能測試腳本的工作交給幾個測試人員編寫。幾個測試人員也坐在附近，基本可以看作團隊成員(到后來編制也是我們團隊的成員了)。開發人員人肉測試一下保證沒有問題了再提交。

　　測試人員寫腳本的流程是拿到上一次build成功的war包，在本地寫腳本，本地測通過了再提交。

　　持續集成服務器上功能測試不通過的時候，由測試人員提交BUG，開發人員修改。持續集成的流程依舊。

　　這樣，從后來收集的數據看，工作效率是提升了，因為參照以前的統計，開發人員的工作一下減輕了1/3。以進度來衡量的速度自然很輕易就可以讓上級滿意了。

　　新的解決方案總會產生新的問題，測試人員在測試方面的專業性，使得他們寫出來的腳本測的更細。功能測試的時間占耗，增長的更快了，短短半個月，就增長到了1個小時。每當出現問題，作出反應之后，要在1個多小時以后才能知道結果。而且，持續集成方面并沒有做到，一旦出錯，誰也不能提交代碼這么嚴格。模塊化的設計所帶來的假想的安全感和進度的壓力，使得開發人員修正問題的激勵不高。于是修正問題的速度不如產生問題的速度快。持續集成服務器在那兩個個禮拜里只有兩頭是綠的，周一早晨和周五下午。