5.確定第一個改進方案

英英帶著幾套方案來找老劉和曉川討論。方案一是，曉川收到提交后，先在其任務分支上進行構建，沒有問題了，再把改動合并到集成分支。老劉提醒，這樣曉川要額外費很多時間在任務分支的構建上，因此總的集成時間可能反而會延長。英英問，那能不能讓別人代替曉川進行這樣的檢查。老劉說，可以考慮，先往下看看其他的方案。

方案二是，在提交前，由曉川檢查，程序員是否進行了構建并且通過了構建。曉川說，在技術上，這很難查。無法保證程序員向曉川出示的構建結果，就是其任務分支末端的代碼編譯出來的。事實上，之所以程序員提交了會構建失敗的代碼，多半是在構建成功后，又改了些內容，以為肯定沒問題了，所以沒有重新構建就提交了。

方案三是，由程序員所在開發組的領導提交。也就是說，程序員先給領導發信，領導核實后，再給曉川轉發。沒等曉川說他覺得讓領導們給他寫信不太合適，英英自己就把這個方案否決了，因為既然方案之二曉川很難查，那方案之三領導也很難查。

方案四是，程序員在申請提交的信里寫上“已通過構建”五個字，否則曉川不集成這個提交，打回去重新提交。老劉問，如果程序員說是構建通過了，其實構建沒通過，那怎么辦？英英說，如果曉川事后分析出這樣的事情，她就負責通報批評。

接下來，在項目例會上，英英跟各個小組的領導們重點介紹了第四個方案，大家覺得盡管這個方案不完美，但是相對來說是比較好的，于是討論通過了這個方案。

會后，英英寫了封信給項目全體成員，詳細說明了情況，并強調了如果出現了言行不一的情況，要通報批評。信的落款是英英和曉川。

執行的情況是這樣的。在下一輪集成里，有兩三成的提交沒有標明“已通過構建”。曉川逐個給相應的程序員打電話，讓他們在保證構建通過后，重新寫提交申請。經這么一折騰，星期一晚上到11點才完成了所有提交的合并。那些不得不重新寫提交申請的程序員，成了加班到最后的程序員。曉川也有點累。不過這是值得的。因為在周四中午，而不是周末加班，這一版基線就出來了。