3.9 把现有的做法运用到情境驱动设计之中
上面几节分别谈了迭代、品质以及测试和检验等，其实对于这些内容来说，有人比笔者谈得更为广博，也更为深入。我们可以用一句话来概括前几节的内容，那就是：“要采用最佳的做法。”
笔者首先拿实现阶段做例子，来讲述我们所应该采用的做法：
- 以用户界面的设计方案为指导，把工作分成多个单元，并计算每个单元含有多少个功能点。这些单元要尽量划分得小一些，使得每个单元能够在2～4周内完成。
- 程序员必须把能够运行的代码放在系统测试环境之中顺利演示出来，然后才算完成了这个工作单元。代码通过演示之后，系统测试组的成员要设法暴露出程序之中的错误，把所有bug都呈现出来。
- 先在团队内部做代码检查，然后再将其放入系统测试之中，等到把代码放入系统测试之后，请外部人员再做一次代码检查。
- 把程序员完成其工作单元所花的时长记录下来，并且把完工之后所发现的错误数量也记录下来。我们必须要从这些统计数据之中有所体会，否则记录这些数据就没有意义了。每隔几个月，就应该对这些统计结果进行讨论，并据此改进员工与团队的做法。
上述做法与Scrum[13]及Kanban[21]等开发方法所提倡的最佳做法相当接近，其区别在于，我们的做法是先设计用户界面，然后再划分工作单元，这要比先划分工作单元然后再设计用户界面简单得多。
不过，上述做法只适用于实现阶段，而对于项目管理的早期阶段、情境设计阶段以及详细设计阶段来说，则需要用明显不同的办法加以应对。只有那种自我导向、自我激励式的团队，才能较为务实地完成情境设计。他们的工作量不太容易分割成明确的工作单元，而且其工作时长，也特别依赖于他们是否能及时联系到利益相关者，以及大家是否能够形成较为广泛的赞同或反对意见。对于集成设计、用户界面设计与数据库设计来说，也是如此。但是，这并不意味着设计项目不应该经常进行评审。实际上，设计团队应该欢迎有人来做评审，因为这比较容易确保设计方案能够满足利益相关者的要求。
把需求设计与编程实现交织起来，会产生一些问题，其中的一个问题是：它迫使我们必须按照相同的办法来管理整个项目，于是，我们就无法在不影响产品交付的前提下，灵活地针对设计方案之中的某一个方面进行争辩。
技术设计比前面几种设计更难办。如果项目比较急，那么技术设计的探索部分，完全可以放在情境设计还没完工的时候就开始做，因为我们只是想对应用程序的规模与性质有一个了解。虽说细节问题要等到集成设计完工之后才能敲定，不过情境设计很有可能会给集成设计提供大量信息，因而能够较早地知道其内容。技术设计与系统软件的设计较为接近，但是它与典型商用软件的编程工作之间，毕竟还是有一些区别的：
- 它的利益相关者是程序员、安全专家、营运经理、网络管理者及情境设计者。这些人并不是一般意义上的业务经理，他们都具备某些专业技术知识。
- 想把工作量清晰地划分成那种可以在2～4周内完成的工作单元，是特别困难的。
即便对于采用敏捷式开发方法的小型团队来说，笔者也依然建议定期地举行协调会议，就算要做的项目非常大，我们也还是应该如此。团队中的每一位成员，都应该拿出一定的时间，来检查其他团队成员所写的代码。