我们公司的一款PC软件，是对各种波形数据文件进行解析、显示。最近的一次开发，采用敏捷的方法进行，每次迭代验收都严格执行单体测试的全面性确认。本次开发的内容是追加一种新的波形数据文件解析，因此这个项目的主要输出是文件解析的DLL，但是针对新文件数据的显示，也是项目内容之一，只是因为显示功能已比较完善，预想不会占有太多的时间。

但最后问题就出在这个预想上。最终结果，6K的程序中共出现了9件Bug（第三方确认测试中发现的），而这些Bug几乎全部出现在显示和显示后的文件保存上。

为什么会出现这样的问题？我的反省如下：

1. 客户价值是最终目标。
   项目开始时工作目标存在严重偏差。显然，客户价值不是一个无错误的文件解析DLL，而是正确的波形显示。文件解析0 Bug的目标虽然达到了，却没能保证最终软件的质量。
2. 尽早结合，迭代验收标准是可以工作的软件。
   如果项目开始时，就坚持以工作的软件为迭代验收标准，就不会出现上述问题。而我们的验收标准是单体测试的全面性和全部通过。以可工作的软件为验收标准，就可以持续集成，尽快确认各种显示的结果。

最近一个项目的一点反省：客户价值才是关注的焦点