软件开发流程改进与经验教训
1. 前期困境
在软件开发的收尾阶段极具不可预测性，就像难以知晓冰山藏于水下的部分大小一样，我们无法确切知道在产品发布中究竟还有多少实际工作要做。在 2005 年的发布周期里，我们遭遇了严重的进度延迟问题，等到产品发布时，团队士气也十分低落。
2. 2005 年后的改进措施
为了改善状况，我们在后续的发布周期中做出了七项改变：
1.保持代码清洁
-设立质量里程碑（MQ）：在产品工作开始前，设立 MQ 以消除技术债务，并建立一个能防止未来技术债务积累的工程系统。主要处理的技术债务领域包括 bug 和测试。
-消除已知 bug：目标是在 MQ 结束时实现零已知 bug。之前推迟处理的 bug 要么被修复（并通过自动化回归测试验证），要么被永久关闭，避免在后续版本中反复考虑这些 bug。
-确保测试可靠：让所有测试都能可靠地通过。清除不可靠的测试，避免手动分析测试结果，尤其是构建验证测试（BVT）。消除测试债务需要对测试进行重构，使其更具弹性，并改进测试工具和基础设施。
2.采用更紧凑的时间盒
- 从三个月的里程碑计划转变为五周的冲刺计划，如今已进一步改进为三周的冲刺。每个冲刺中，团队有机会交付一个或多个功能（产品待办事项），前提是满足后续讨论的完成标准。每个冲刺结束时，目标是交付一个潜在可发布的软件增量，即客户技术预览版（CTP）。我们仅发布那些需要收集外部反馈的 CTP，但会在内部部署每个
