四个图分别为：1）迭代二接近结束时累积解决的缺陷报告 2）迭代二接近结束时的关闭周期 3）迭代二接近结束时的测试完成情况 4）迭代二接近结束时的测试小时数
问题1）图中是否有证据显示你在练习1中所概述的改进已经奏效？
问题2）你是否相信迭代二中HELLOCARMS的测试结果表明在迭代二结束的时候可以准时交付？
让我们根据练习1中建议4项改进开始对进度进行评估。
1. 在测试阶段刚结束时迭代一的累积/解决缺陷报告图有一个大的跳动。
可能的改进：在迭代中更早地稳定产品，本例大约在第3周左右。另外专注于修复在该迭代的后半段测试中发现的缺陷。
迭代二的状态：虽然开发确实已经在解决缺陷方面做得很好，在迭代二中已报告缺陷总数也几次达到了收敛状态，但是缺陷报告率在迭代二的整个测试执行阶段中都非常高。测试经理和项目管理团队应当一起进行进一步的调查来寻找这个问题的根本原因。
这有5种可能的原因：
A 迭代一中功能的高回归率是因为迭代二中的高缺陷修复率
B 迭代一和迭代二中新缺陷的高发现率是因为测试范围的扩大
C 迭代二中新功能增加率高
D 迭代二中增加的大量功能带来了大量的缺陷
E 上游质量控制活动不够，例如需求和设计评审、代码评审和静态分析、单元测试
2. 关闭周期图表中缺陷关闭周期在第一轮测试周期显现稳步向上的趋势。
可能的改进：根据新的功能限制后续迭代的规模并且专注于快速消除缺陷。
迭代二的状态：我们无法断定迭代二的规模是否已经受到限制，因为这是迭代二中缺陷发现率高的一种可能的解释。但是，开发团队确实已经做得很好，他们扭转了工作积压和缺陷关闭周期延长的负面趋势。换而言之，根据上面的描述可能开发团队工作进行得太快且解决缺陷时对细节关注不足，这导致了高回归率。
3. 测试用例完成情况图中在迭代一的第二轮和第三轮（例如，最后两轮）中增加了大量的测试，同时也使得最后一轮中有大量的测试失败。
可能的改进：尝试在第一轮中运行所哟的测试从而识别到尽可能多的问题；然后专注于缺陷的解决从而使迭代中最后一轮结束时大部分的测试可以通过。
迭代二的状态：测试团队做得很好，他们加快了测试完成的速率以及每轮通过中的总体测试完成数量，但是我们仍然看到有大量的测试失败。在最后一轮中这个问题显得尤为尖锐，在最后一轮中大部分测试都失败了。当然，这和迭代二累积/解决的缺陷报告图中所显示的结果是一致的。
4. 从迭代一的测试小时数图中可以看出，在第一个测试中的测试牵引有限，造成在第三轮和最后一轮中测试压力很大。
可能的改进：移除任何对有效测试和完成首轮测试有障碍的部分。
迭代二的状态：测试团队在确保完成牵引和在迭代二测试执行一开始切入测试方面做得很好。迭代二的实际测试小时数比计划的要多一些。这部分时间和迭代二测试用例完成情况和累积缺陷报告/解决图中所展现结果是一致的，因为预料之外的高测试失败率和高缺陷报告率会增加所需的测试工作量。
因此，根据这些分析，我们可以得出结论：HELLOCARMS在迭代二结束的时候部署并未进入正轨，累积/解决缺陷报告图表明系统中还留有大量的潜在缺陷。测试完成情况图则表明大量的功能存在问题。
因为不懂，所以抄书，抄着抄着就明白啦，这是个奇怪的事情。
