四個圖分別為：1）迭代二接近結(jié)束時累積解決的缺陷報告 2）迭代二接近結(jié)束時的關閉周期 3）迭代二接近結(jié)束時的測試完成情況 4）迭代二接近結(jié)束時的測試小時數(shù)

問題1）圖中是否有證據(jù)顯示你在練習1中所概述的改進已經(jīng)奏效？

問題2）你是否相信迭代二中HELLOCARMS的測試結(jié)果表明在迭代二結(jié)束的時候可以準時交付？

讓我們根據(jù)練習1中建議4項改進開始對進度進行評估。

1. 在測試階段剛結(jié)束時迭代一的累積/解決缺陷報告圖有一個大的跳動。

可能的改進：在迭代中更早地穩(wěn)定產(chǎn)品，本例大約在第3周左右。另外專注于修復在該迭代的后半段測試中發(fā)現(xiàn)的缺陷。

迭代二的狀態(tài)：雖然開發(fā)確實已經(jīng)在解決缺陷方面做得很好，在迭代二中已報告缺陷總數(shù)也幾次達到了收斂狀態(tài)，但是缺陷報告率在迭代二的整個測試執(zhí)行階段中都非常高。測試經(jīng)理和項目管理團隊應當一起進行進一步的調(diào)查來尋找這個問題的根本原因。

這有5種可能的原因：

A 迭代一中功能的高回歸率是因為迭代二中的高缺陷修復率

B 迭代一和迭代二中新缺陷的高發(fā)現(xiàn)率是因為測試范圍的擴大

C 迭代二中新功能增加率高

D 迭代二中增加的大量功能帶來了大量的缺陷

E 上游質(zhì)量控制活動不夠，例如需求和設計評審、代碼評審和靜態(tài)分析、單元測試

2. 關閉周期圖表中缺陷關閉周期在第一輪測試周期顯現(xiàn)穩(wěn)步向上的趨勢。

可能的改進：根據(jù)新的功能限制后續(xù)迭代的規(guī)模并且專注于快速消除缺陷。

迭代二的狀態(tài)：我們無法斷定迭代二的規(guī)模是否已經(jīng)受到限制，因為這是迭代二中缺陷發(fā)現(xiàn)率高的一種可能的解釋。但是，開發(fā)團隊確實已經(jīng)做得很好，他們扭轉(zhuǎn)了工作積壓和缺陷關閉周期延長的負面趨勢。換而言之，根據(jù)上面的描述可能開發(fā)團隊工作進行得太快且解決缺陷時對細節(jié)關注不足，這導致了高回歸率。

3. 測試用例完成情況圖中在迭代一的第二輪和第三輪（例如，最后兩輪）中增加了大量的測試，同時也使得最后一輪中有大量的測試失敗。

可能的改進：嘗試在第一輪中運行所喲的測試從而識別到盡可能多的問題；然后專注于缺陷的解決從而使迭代中最后一輪結(jié)束時大部分的測試可以通過。

迭代二的狀態(tài)：測試團隊做得很好，他們加快了測試完成的速率以及每輪通過中的總體測試完成數(shù)量，但是我們?nèi)匀豢吹接写罅康臏y試失敗。在最后一輪中這個問題顯得尤為尖銳，在最后一輪中大部分測試都失敗了。當然，這和迭代二累積/解決的缺陷報告圖中所顯示的結(jié)果是一致的。

4. 從迭代一的測試小時數(shù)圖中可以看出，在第一個測試中的測試牽引有限，造成在第三輪和最后一輪中測試壓力很大。

可能的改進：移除任何對有效測試和完成首輪測試有障礙的部分。

迭代二的狀態(tài)：測試團隊在確保完成牽引和在迭代二測試執(zhí)行一開始切入測試方面做得很好。迭代二的實際測試小時數(shù)比計劃的要多一些。這部分時間和迭代二測試用例完成情況和累積缺陷報告/解決圖中所展現(xiàn)結(jié)果是一致的，因為預料之外的高測試失敗率和高缺陷報告率會增加所需的測試工作量。

因此，根據(jù)這些分析，我們可以得出結(jié)論：HELLOCARMS在迭代二結(jié)束的時候部署并未進入正軌，累積/解決缺陷報告圖表明系統(tǒng)中還留有大量的潛在缺陷。測試完成情況圖則表明大量的功能存在問題。

因為不懂，所以抄書，抄著抄著就明白啦，這是個奇怪的事情。