4）可持续性

　　功能点的实现选择，要考虑的还有可持续性的问题，是功能点是可以不断去叠加来完善的，而不是说不断的推翻后重新实现一把，这个是差别很大的。比如说内容创建功能，现在对于异常的处理我们暂时不实现，这个是没有问题的；但是如果下次要实现异常处理的时候，要把现在内容创建的流程的功能描述推翻重来，这个可持续性有问题了，因为这个意味着以前的功能全部都会被推翻，很可能是以前的实现都白费了，这是功能点设计的的不可持续性了。功能点设计一定要有持续性，如果是这样子，系统的功能能够越做越强。

　　所以我们可以把每一个的User Story的各个功能点想的更加完善，这个是很好的，剩下的只是如何取舍的了，所谓取舍，只是阶段性的舍弃和选择罢了。所以在讨论过程中，不要因为功能的增强，范围的扩大而让我们感到害怕和困惑，把他们记录下来，是很好的逐步改进系统的武器，我们只要运用上面的一些原则，能够让我们做的更好。

　　下来再谈谈设计的问题

　　在Head First Object-Oriented Design的书中，定义Good Design是Flexible Design。而The Art of Agile Software Development一书中，定义Good Design为“A good software design minimizes the time required to create， modify and maintain the software while achieving acceptable runtime performance.”是软件的可维护性。所以Agile Design强调的功能，基本上都是从如何不断改进软件的可维护性和可扩展性而努力的，只有软件具备了良好的可维护性和可扩展性，那么软件能够很好的不断叠加功能，软件才具有旺盛的生命力。

　　我们实际中面向的问题呢？其实还是很简单，是好的设计和项目时间的冲突，好的设计是需要时间考虑的，也是需要时间来实现的（虽然不是，有时候好的设计会节省更多的工作量）。

　　对于第一个问题，于项目时间的冲突，这个可以回到前面开始谈的内部质量和外部质量的问题，前面对于功能（外部质量）的问题，我们已经谈了取舍的方法，那么，内部质量（设计），是不是也可以取舍呢？在“Scrum and XP from the Trenches”书里面，作者自己是这么认为的：

　　Internal quality， however， is not up for discussion. It is the team’s responsibility to maintain the system’s quality under all circumstances and this is simply not negotiable. Ever.

　　在这上面我是持一样的观点的。

　　然而我们的问题依然存在。和项目时间的冲突如何平衡呢？我想可以考虑两个原则：

　　● 足够好（First Right）

　　● 分阶段实现/可持续性

　　1）足够好（First Right & Good Enough）

　　所谓First Right & Good Enough是让我们看看我们所作的设计是不是足够清晰的架构我们的系统，而不是太过的复杂导致项目时间不足，往往好的设计并不是要花更多的时间实现的，通常只有Over Design才让我们感到力不从心。所以我们发现设计导致实现的时间过长的时候，我们需要看看，是不是我们想的太复杂了？