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

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

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

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

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

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

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

這有5種可能的原因：

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

B 迭代一和迭代二中新缺陷的高發現率是因為測試范圍的擴大

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

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

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

2. 關閉周期圖表中缺陷關閉周期在第一輪測試周期顯現穩步向上的趨勢。

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

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

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

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

迭代二的狀態：測試團隊做得很好，他們加快了測試完成的速率以及每輪通過中的總體測試完成數量，但是我們仍然看到有大量的測試失敗。在最后一輪中這個問題顯得尤為尖銳，在最后一輪中大部分測試都失敗了。當然，這和迭代二累積/解決的缺陷報告圖中所顯示的結果是一致的。

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

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

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

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

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