实现策略

    动态评估过程有一些基本的实现思路，第一个基本思路是尽可能早的发现所有的问题，如何发现呢？进行一次探险式的过程。这个过程周期不能够太长，太长的周期容易失控，而且项目初期人员未必能够全部到位；但这个周期也不能够太短，太短的周期无法发现足够数量的风险，无法为后续的过程提供丰富的数据。

    有时候，我们运用原型法来实现这个Mini过程。原型法包括了需求原型和技术原型，分别用于解决业务风险和技术风险。一个典型的需求原型是建立一个界面原型，来帮助客户理解未来的软件，避免抽象的思考。我看过很多界面原型的做法，有使用HTML的，有使用画图软件的，有使用规范的XML的。但是不管如何，界面原型能够帮助用户直观的理解需求。技术原型的主要目标是解决技术风险，任何一个项目都可能存在这样或那样的技术风险。对待风险的基本态度是尽早的评估风险并制定解决方案，而不是束之高阁。技术风险的解决方案视具体情况而定，但是，值得注意的是，一个项目中，技术风险不能够过多。如果确实存在这种情况，想办法找到有经验的导师或培训师，这要比自己摸索节省许多的成本。

    XP对探险式过程的评估主要包括两个方面，spike solution和迭代。spike solution其实就是我们在上面提到了的技术原型。它的目的是让不明确的评估成为明确的评估（参见XP的过程图中的Spike）。只有评估准确了，计划才能够准确。因此它是计划和迭代的输入项。

    至于迭代，它是XP中的重要概念。迭代选取了用户需要的功能（称为用户故事），并进行设计、开发、测试，迭代不断重复，并解决各种各样的问题。在通过用户的测试和认可之后，最终产生了一个可以运行的版本。这个版本的产生，标志着一组迭代周期的完成。第一个小版本正是我们所强调的探险式的过程。它的成功和教训，足以让你了解项目的各种知识，包括客户的复杂组织关系，投资方的准确意图，找出所有的涉众，发现用例，令团队成员和客户达成初步的共识，验证技术方案，建立一个初步的软件架构，或是针对现有的架构进行初步的映射，程序员需要额外的培训，测试力量似乎不足够，部署环境的风险需要提前解决。只有你按照完整的生命周期真正的去做这项工作，这些问题才会在一开始都暴露出来，否则，其中的很多问题会在后续的阶段中给你制造大麻烦。

    第二个基本思路是增量开发。增量和迭代有什么区别呢？Alistair Cockburn在Surviving Object-Oriented Projects一书中将增量描述为修正或改进开发过程，形象的说法是逐步的完成软件开发。注意到，XP的过程图中的小版本正是一个增量。XP认为，一个增量应该是可以发布的。做到这一点固然很好，但是并不是所有的项目都能够达成这一目标。例如，第一次的增量目标可能主要是定义一个架构，这个架构并不包含用户需要的功能，但是它是项目开发的基础。架构中可能包括业务实体基础结构、数据操纵基础架构等一系列的框架。但是对于XP来说，在用户无法发现价值的框架上花费大量的时间是不值得的，XP提倡的做法是根据需求的发展来逐步完善架构，而不是在项目一开始就花费精力开发架构。很难评价哪一种说法正确，我比较倾向于前期花费时间进行架构设计，但是实践中确实发生过设计过于复杂导致高昂成本的情况。在花费了大量的时间开发了一个属性处理框架之后，我发现其实简单属性就能够处理大部分的情况，毫无疑问，前期的设计投入打了漂。因此，重要的是权衡前期的投入时间。理想的情况是，你已经拥有了一个可重用的框架（或是架构），这样，你可以将项目的需求映射到框架上，而不是在项目一开始的时候花时间来开发框架。如果你没有框架，在项目一开始的时候，花费一定的时间来开发架构，但是这个时间不宜过长，你完全可以在后续的增量中对架构进行改进，所以不用急于一时。而且，单纯的框架（架构）开发是没有办法进行用户接受测试的，你的测试不得不推迟到第二次增量。这个理由也促使我们尽可能的缩短框架设计的周期。

    而迭代则是改进或修正软件质量。这也是第三个基本思路。我们注意看XP过程图中的迭代，多次的迭代才构成一次的增量（小版本），每一次的迭代都是对上一次迭代的改进，其中可能是修正了设计错误，或是需求缺陷。值得注意的是，迭代中可能会出现新的需求变更（新需求或需求改变），并令项目人员对项目的进展速度更加的了解（Project Velocity），这些将会反过来影响计划的修正。这体现了我们在上一章所讲述的XP对待计划的态度。

    并没有法律规定迭代需要和增量一起使用，但很明显，结合这两种方式是一种有效的做法。增量的目标是让项目得以向前推进（这就像是修路的时候，路的长度变长了），而迭代的目标是令软件的质量更优（就像是在一段路上架设路基、铺上水泥，建设路面设施）。这让我们想起了什么，不错，重构的两顶帽子。一顶帽子是为软件增加新功能，一顶帽子是改进软件的质量。非常的相似，只不过一个是过程级别的，一个是程序级别的。这里有一个基本的假设，不要同时增加功能和改进质量。团队也好，个人也好，一次只完成一个目标效率是最高的。

    思考

    和传统的先定义问题，然后再解决问题的做法不同，XP偏重于逐步的精化问题。软件开发中的问题定义和数学中不同，它往往是模糊的，动态的，需要在解决问题的过程中不断的调整解题的思路。对XP来说，这种解题思路，体现了其反馈的价值观－尽快获得客户对软件的反馈。