三、我们需要哪些文档，工具和努力

　　软件项目肯定离不了文档和管理工具，如果您的项目还没有它们，那么请从现在开始。那么文档是不是越多越好呢？老话说的好，合适的才是好的。小而精的文档和工具会让我们事半功倍，大而全的文档会让我们疲于奔命，后迷失在文档的海洋中。

　　我们写代码的都知道，错误的注释比没有注释更可怕；同样的，没有及时得到更新的文档比没有文档更可怕，因为文档是项目的注释。那么我们是否有必要去更新那些我们根本没有用到的文档呢？很显然，那是非常没有必要的，是对资源的浪费。文档说起来其实是一个工具，是一个让我们开发时有依据，可以追溯开发过程以及记录开发结果的工具。我们只有用到它，它才有存在的必要。

　　那么文档过于少或者干脆没有文档，不是更简洁？我想说：不写代码不是更简洁？玩笑归玩笑，没有文档或者文档太少会导致的问题大家可能也都遇到过：那是过程不可追溯，有些非常重要的逻辑没有记录，需要用到时团队成员各执一词，甚至需要重新找客户确认而是客户认为我们不够专业；有些非常重要的设计没有记录，导致代码维护困难，以至于维护人员破口大骂开发人员写的什么垃圾代码做的什么垃圾设计。有些设计非常的巧妙，非常的值得学习，然而是因为没有留下记录而被初学者如我一样的人骂了N次。在反省自己不够聪明时，是否也该让写代码的人反省一下为什么没能留下点儿记录？

　　有一种观点是好的设计是代码，意思是代码是设计，代码应该非常的，可读性特别好，让人一看明白，我完全同意。如果代码写到这种程度，那文档真的没用了。那么请自问，您是这样吗？如果是，没文档，没问题；如果不是，请把重要的东西写下来。那么，哪些是重要的呢？

　　哪些是必须的， 哪些是Optional的。对于哪些文档更重要些，应该由项目的具体情况而定，特别是项目的大小，逻辑的复杂程度，人员的情况等等很多因素。在我做过的项目中，我个人认为重要的一些文档和工具如下所述：

　　1、功能说明书（Functional Specification）------按独立功能划分优先级，每一条记录都是一个可交付物，都是一个功能。整个文档描述了整个项目的交付功能和优先级。项目中的所有人，都应该关注这个文档：测试用它来写测试用例；开发人员用它来决定先开发哪个功能；PM用它来查看功能的完成和验证状态。它通常不应该内容过多（由项目规模决定），我觉得多两行字可以描述一个独立工作的功能，至于对这个功能的理解，应该由负责它的程序员来完成。

　　2、核心流程图。这个流程图可能描述了用户使用该系统的过程；也可能描述系统中数据的流转；也可能描述表单的流转。总之，它描述一个过程，这个过程对用户来说非常重要。这个图有时候也会被其它的图，如顺序图代替。

　　3、部署文档。该文档描述了该系统应该如何部署，它不一定非要是一个word文档，也可能仅是一个bat文件而已。这个文档应该描述该项目如何部署，步骤是怎么样的，需要哪些文件，需要哪些硬件支持，以及需要注意什么。部署历来都不太被重视，大家觉得只要东西做出来了，部署不是放上去吗？其实不然。在经历了一定周期的开发后，开发过程中积累的配置，对环境的要求，在真正部署的时候很多忘了，所以部署可能会花费很多没必要的时间，我觉得这也是微软要做daily build的原因之一，每天都build一个可用的版本，当然部署没有问题了。我们刚开始可能不需要每天都build一个版本，但少要一周或者两周部署一个版本吧。每次部署都整理一个自动化的脚本或者文档，会让你后上线的时候非常的从容。

　　4、测试用例。我不是一个测试人员，测试也是我觉得一直没有做到位的地方。客观的说，我觉得用例应该花很大心思去编写，像用户真正的在使用软件一样。项目应该在设计和开发的时候以满足用例为目标，而不是开发完了才想起来用例，去测试，发现问题再修改，回头想想，这可能是测试驱动开发产生的原因吧。我们知道用户发现错误修改的成本高于我们自己发现的错误；同样的，设计和开发阶段解决的问题成本也远远小于测试阶段发现的。正是，问题发现的越早，解决起来越容易，成本越低。

　　5、Bug管理工具。这个管理工具可以是一个excel，当然，我并不推荐这么做，毕竟excel却是不那么自动化。但是，只要比excel自动化一点点儿的信息系统可以了，它需要可以记录问题，可以传截图，这够了。我推荐使用bug tracker，这是个dotnet开发的开源的bug管理工具，其实也可以管理需求，是非常实用的。