每到專案接近尾聲的時候，專案經理往往是心裡最沒數的時候。專案經理最頭痛的問題是，越到專案後期，程式設計師交付的模組越來越多，聯調測試起來bug也越來越多，什麼時候能交付？說不清楚。
下面的問答是幾乎每個專案都會出現的：
老闆：按進度的計畫，我們能否按時發布產品？
經理：沒法評估，這一輪測試完成的時間我和測試主管可以估算完，但發現了那麼多bug，要多少時間修改，要評估過才能知道，就算改完了，後面還要做多少輪測試，我心裡也沒數。
老闆：那看起來，這次專案的測試時間留得很不充分了。
經理：是呀，一方面原來預留的測試時間被開發時間擠占了，另一方面，開發的時間也很難估算。新來的那幾個工程師提交的模組質量很差，要來回幾次測試才能達到整合的水平。這都是原先沒有遇見到的。
老闆：開發計畫中，模組是分階段提交的，對已提交模組的測試也並行開展了，為什麼到後期的整合測試還有那麼多的問題呢？
經理：初期提交的模組，由於整合度較低，測試工程師測試得不夠充分，即使測試過了，隨著專案的開展，已經測試過的模組也會有修改，修改過後，原來測試過的功能仍然要測試一遍才放心，越到專案後期，越不可能將原來所做過的測試再測一遍，因此，心裡越來越沒底。
老闆：那怎麼辦？加人手，趕緊調人，這個專案不容有失，必須如期完工。
經理：這個時候加人已經來不及了，新來的人還要老人培訓，反而添亂。況且，所有團隊都忙，能調誰來啊？
老闆：那怎麼辦？
經理：沒辦法，只好趕兄弟們加班了，到了這個時候，死也要死出來啊。但只能保證東西基本能用，bug是免不了的了。使用者投訴有多嚴重，只能等發布後才知道了。
在我經歷的十多年的軟體開發專案中，類似的情形或多或少都會出現，只是拼命的程度高低不同而已。跟很多同行交流，這也是行業通病。據調查，軟體開發工程師最不滿意的就是長期的加班。但這種加班總是難以避免，我們之前也學習和應用了不少軟體開發過程管理的方法，試圖優化開發組織方式、提公升開發計畫估算精確度、規範開發流程，提高開發質量，但效果總是不夠好，有個長期從事海外專案外包開發管理的朋友甚至跟我說，他嘗試了十多種軟體規模估算模型，也應用了cmmi等組織方**，還是沒法改變這種專案後期混亂忙碌的局面，很灰心，真想轉行了事。
作為一家軟體公司，必須將追求卓越作為企業發展的宗旨，而這一點要獲得客戶和員工的認同，必須生產出優秀的高質量產品，與此同時，快速到達市場的能力又是競爭制勝的關鍵。因此，為了做到開發過程又快又好，今年，我的公司整個技術部門進行了敏捷轉型，全面擁抱敏捷開發scrum模式。
經過了半年多實踐，團隊已經建立起了像模像樣的scrum運作機制：
(1) 追求sprint成功已經成為團隊共識
(2) 每日站會溝通機制
(3) 成員積極自願領取任務
(4) 約定成俗的sprint計畫和總結會議
我們敏捷了嗎？好像是的。但實際上，上述機制除了促進了團隊成員之間的交流，提公升開發效率和融合工作氛圍起到一定的作用外，對產品的質量提公升和縮短開發周期並沒有很明顯的變化，文章開頭提到的問答仍然出現。
道理很簡單，要真正做到產品質量提高和縮短開發周期，僅僅在價值觀和行為方式上下功夫是不夠的，歸根結底還是要提高團隊的工程實踐能力。而突破口就在於推行持續整合技術。
（待續）
持續整合工具是怎樣煉成的？持續整合工具實戰
它可以統計整個專案的覆蓋率 各包的覆蓋率 各類的覆蓋率，最後展示哪些 被覆蓋，哪些 沒有被覆蓋。持續整合報告 當乙個軟體專案使用了持續整合工具以後，許多的管理工作由不可靠的人為操作變為了機械自動化操作。作為專案開發成員，特別是專案經理，最關心的就是持續整合報告。進入持續整合控制台，可以看到所有在用的...
持續整合之路 Mock物件引起的測試失敗
今天遇到了乙個很奇怪的問題，糾結了好久。在和同事念叨這個問題時，突然想到了問題所在。問題現象 在乙個service的單元測試類中有八個測試用例，單獨執行時都可以正常通過。可是一旦一起執行時，總是會有固定的兩個測試失敗。問題原因 有乙個測試用例mock了service依賴的乙個dao物件，之後的用例再...
全面分析持續整合優缺點 1
描述持續整合最大的難點在於 它從根本上改變了整個開發模式。如果沒有在持續整合的實踐環境中工作過，你很難理解它的開發模式。實際上，在單獨工作的時候，絕大多數人都能感覺到這種氣氛 因為他們只需要與自己的系統相整合。對於許多人來說，團隊開發 這個詞總讓他們想起軟體工程領域中的一些難題。持續整合減少了這些難...