本节书摘来自华章计算机《需求设计：构建用户想要和需要的产品》一书中的第2章，第2.7节,作者： [英] 克里斯·布里顿（Chris Britton） 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.7 实现
正如早前所讲，实现（或者说编程）本身就是一项设计活动。它的输出物是可以运作的应用程序或服务。
由于编程是一项设计活动，而设计活动之中可能会出现反馈，因此，在编程的时候，我们总是有可能因为发现了错误或值得改进之处，而回过头来修改更为高层的设计。
有很多书籍都在详细讲述各种编程设计图，但笔者在写代码的时候基本上不用这种图，只是偶尔会使用对象图（object diagram）来确定某个复杂数据结构的样貌。
设计方面的图表与文档，其用途有三种。第一是帮助我们思考设计方案。假如这是唯一的用途，那么一旦把设计方案想明白之后，就可以立刻丢掉这些文件。实际上我们也确实应该把这些文件丢掉，因为设计方案后来有可能会发生变化，如果有人还是参照早前的图表来理解，那就会受到误导。第二项用途是促进我们与他人之间的沟通。之所以要绘制逻辑用户界面图，是为了把用户界面的设计方案讲给其他程序员听。第三项用途，是留给稍后的项目使用。与情境设计有关的文件应该保留下来，因为其他的开发项目，以后可能需要与我们当前设计的这款应用程序相集成。程序员是通过能够运行的应用程序，来与利益相关者沟通的，因此，与编程有关的设计图表，其唯一用途就是帮助我们理解复杂的编程问题。
笔者发现，对于编程工作来说，源代码是最好的技术文档，这个观点，与很多敏捷软件开发者的看法有相通之处。
前面讲过：我们最好是等到所有的宏观设计都完成之后，再去着手进行开发。给含有100个画面的用户界面撰写设计文档，或是给含有100张表格的数据库撰写schema文档，实际上花不了多长时间，这一类的任务，一个人用几星期时间就能完成。真正耗时的地方在于做决策，也就是要讨论设计方案，并根据反馈情况来进行修改。设计活动之中会有反馈，而且还会有其他一些因素，为此，我们显然应该等到设计方案敲定之后，再去进行实现。但是有一项例外：由于技术设计会渗入我们对系统测试环境以及通用例程所做的实现之中，因此，只要应用程序的性质、规模与非功能型的需求可以清晰地确定下来，那我们就应该尽快开始实现。
实现阶段完成之后，系统测试应用程序会持续增长。我们在任何一个时间点，都可以向利益相关者展示系统测试应用程序。笔者喜欢频繁地去展示，这是因为：
1.它可以使利益相关者感觉到项目正在推进。
2.我们可以尽早发现利益相关者是否改变了主意。
然而现实并非总是如此乐观。要想使重要的利益相关者对此表示关注，并安排出时间来观察我们的应用程序，是有一定难度的。
我们希望首次发布的软件产品能够给人留下好印象，然而这一版之中所包含的特性应该少一些，以便快速地进行交付。该版本一旦发布，就可能会受到某些用户的品评，这些用户通常并不是严格意义上的利益相关者，但我们还是应该对这样的反馈做出回应。这可以令利益相关者觉得我们愿意倾听其意见，也可以帮助应用程序在业务活动之中获得良好的信誉，这是开发工作的最终目标。
