上接：scrum節外生枝（四）
5.bug！bug！bug！
理想中的scrum世界，不需要驗收測試階段，因為每個sprint結束，都會交付乙個可發布的版本。但是，現實中每個sprint結束後都會不斷湧現新的bug。所以《硝煙中的scrum和xp》說：「你大概沒法取消驗收測試階段」。但正是這sprints之外的驗收測試階段，把我們拖入了萬劫不復的境地。產品原本計畫1年release，但1年半時我們仍在修復不斷湧現的bug。我們的目標是修復所有priority 0和1的bug，並使bug修復率達到至少80%，才能宣布到達beta 這個milestone。但每輪full test發現的bug總是與修復的bug不相上下，bug數始終沒有呈現收斂的跡象。最終vp engineering辭職，大家對於這種狀態也是非常沮喪。
到了這種程度，再想回到乙個良性迴圈的狀態，談和容易。這個教訓告訴我們，如果驗收測試無法避免，我們也要努力使其縮到最短。而要實現這一點，一要保證在每個sprint中開發人員交付的**質量，二要提高每個sprint中測試工作的效率。只有這樣，在每個sprint結束後，bug才會盡可能的少。
按照以前的做法，其實每個sprint是個微觀的順序開發過程，開發人員先寫**，完成功能，快到sprint的結束的時候，測試人員才開始測試，必然地，發現的bug沒時間修復。不是影響下乙個sprint，就是累積到最後的驗收測試階段。後來，我們把開發人員和測試人員按backlog分組，每個sprint，從第一天起，開發人員和測試人員都開始忙碌的工作，開發人員只要有新**提交，測試人員就立即測試，有bug馬上反饋；沒有新**提交，測試人員也會準備測試環境、編寫測試用例等。另外，增加單元測試覆蓋率、建立自動化測試團隊以開發自動化測試框架、增加exhaust test等手段從另乙個方面提高**質量。而且，將發布新版本的週期從一年左右，減為半年左右，每個版本增加較少的功能，但使交付更頻繁。這樣的變化，使情況有了較大改觀。
所以要盡可能地讓bug消滅在每個sprint中，不要等到最後驗收測試階段，那時bug們會形成合力，你只有招架之功，無還手之力了。
結束語本文只記述了幾個我們在實踐scrum中遇到的問題，像這樣的問題還有很多，有些得以解決，有些則還沒有。但是無論怎樣，scrum所描繪的完美世界有著巨大的吸引力，激勵著越來越多的實踐者不斷前行。
SCRUM節外生枝（四）
上接 scrum節外生枝 三 4.太多的外界干擾 很多公司，都面臨乙個問題，在研發新產品的同時，還要應付對舊產品的維護任務。另外，來自市場 客戶服務 人力資源等部門的事情不斷地打斷專注於研發的scrum團隊。比如 市場部門需要技術人員參加展覽展示會做技術後備，客戶服務部門要請技術人員到現場解決在客戶...
SCRUM節外生枝（三）
上接 scrum節外生枝 二 3.乙個程式設計師卡殼了 有了一些工作經驗的程式設計師 也許可以擴充套件到所有的技術人員 都遇到過這樣的情況 在乙個本以為容易的技術實現上遇到未能 到的難關，長時間無法逾越。本來乙個小時能完成的feature，可能因為乙個severe 0 的bug，折騰得一天下來也無法...
SCRUM節外生枝（一）
每個接觸 scrum 的人，可能很快被 scrum 框架所描繪出的美好景象所吸引，scrum 所運用的方法和流程不難被理解，很容易被擁戴者拿來試驗或實施。但當到達某個微觀步驟時，一些節外生枝的事情總會發生，scrum 的聖經裡沒有藥到病除的良方，有的只是過來人親身體驗的痛苦和有關成敗的感慨。1.牴觸...