這會做兩件事情：
從代碼被集成（進代碼庫）到小組意識到存在問題之間的時間間隔會被減到最小。
構建顯示器將信息傳達給整個小組——不論是集成成功完成——還是需要引起注意——這讓小組可以立即作出相應的反應。
像這樣頻繁的集成意味著軟件的構建是不停進行的，任何人在任何時候都可以參與構建過程。構建過程需要被自動化，以便使集成盡可能地容易，這是十分重要的。下面就是3Q公司的構建監視器的向小組傳達信息的一個例子。
就如上面圖畫所顯示的，構建服務器能夠向小組提供額外的信息。
重要的成功因素
自動化——這需要成為一個自動化的過程。否則你將不得不專門找一個開發人員來維持構建過程——這可不是一個有意思的工作。首先就要營造環境，取得設備和實現自動化。
TCR和配對編程——對于這一層次的集成工作，小組必須按照測試－編碼－重整循環來進行，這樣他們才有信心保證所有的問題只會發生在集成過程里。如果沒有TCR循環，這一部分的過程將會非常困難。
按部就班——就像這個小標題說的，不慌不忙地從簡單的地方開始，然后隨著時間的推移來逐步改進——尤其是在代碼編寫標準這一塊。
保持高效率——第三步
就如我們在《上篇》里說的，敏捷開發過程是一項工作強度很大的編程方式。除此之外，軟件開發本身就壓力重重，而小組累垮的可能性非常高。
可持續的步伐意味著開發小組現在和未來的工作都將非常艱苦。加班不是我們希望鼓勵的事情，盡管有的時候需要如此。如果小組不得不加班工作，那么我們想要嘗試將可持續步伐里的加班時間控制在一到兩周而不是一到兩個月。再強調一遍，敏捷開發是一項強度很大的工作；配對編程要求很多交互和重視，測試－編碼－重整循環也是如此。盡管敏捷開發會引發我們小組的最大潛能，但是我們需要清楚很多時候的大量加班會累垮整個小組的風險。
重要的成功因素
這是管理者必須十分清楚的一個領域。確保小組在整個項目里保持合理的步伐是其主要職責。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
