项目那点儿事(十六) ---项目的基石[文档管理]之没有设计文档的团队

趁现在程序员们在开发，我们来说一下关于设计文档的问题。
很多人说，我的项目团队没有设计文档，认为这个不妥。无设计的团队怎么能行。
记得有一句话讲“建帝国大厦和狗屋的区别在于，狗屋不需要设计”。
其实我的团队是有设计的，不过展现设计的方式不同。

我们来看看传统的设计是怎么做的——详细设计是如何练成的

大家明白需求调研，完成后做设计。设计又分为概要设计和详细设计（这可是国家标准规定的）。记得以前公司的老板，拿着一套国标模板（中华人民共和国软件工程标准），像宝贝一样，跟我说：“羽之，以后我们项目都按这个做。你不说我们项目管理不规范，这下就要规范化了。”

领导的想法是不错，可惜用错了力气。因为国标模板有局限性。现在所有的官方标准，像软件工程、项目管理组织（PMI）等推出的流程都是瀑布式的。而瀑布式是个直肠子，一条路走到黑，不会脑筋急转弯。其实这个是项目的鼻祖——建筑业的管理方法。

我们看看建筑业的项目，首先说要盖个10层的大楼，这个大楼要做什么用，有多少个房间，可以容纳多少人等等，需求可是相当的精细。之后由专业的建筑设计公司来做设计。设计还要求必须有70%的重用，就是说，你设计中的70%必须在别的地方实施成功的（建筑设计公司的设计70%是可以抄袭的）。再交给施工队施工。

如果在施工时，需求方就是甲方了，要提出变更：我现在想盖个20层的大楼。这时乙方经理就会说：对不起，您这个地基只能盖10层的，想盖20啊，重新打地基，现有的东西都拆掉，而且要重新进行设计。这些工料、机器、人时、设计费，您费心，给补上吧。

所以建筑行业的项目需求变动是非常小，而罕见的。

瀑布式的管理方式，要求必须在前期冻结需求，甲方必须对需求非常明确，并且在整个项目周期内不会改动。很显然现在大部分的软件项目并不符合这个要求，除了军工航天项目外。

为了完成详细设计必须完成概要设计，因为详细设计就是袜子，概要设计是鞋，你必须先脱鞋才能脱袜子。

我们来看看概要设计都要干些啥。

概要设计中包括了总体设计、接口设计、运行设计、数据结构设计、系统出错设计

重点在总体设计上，总体设计就是用文字、表格或图形为项目的整体框架做个照片。比如项目的工作流程（基础流程图），功能与程序的关系（描述系统功能与需求的对照关系），系统的结构（分几个类、几个目录）等等。

就是说你看到你家小狗要拉屎了（需求出来了），你要想办法解决，你想啊想啊，最后想出来，带他去公园解决拉屎问题（概要设计）。

带狗到公园，找个地儿，拉完，把狗屎收到袋子中（咱可要环保啊），回家。这就是基本流程，拉屎需求与公园内拉的动作之间是对照关系，功能分为到公园，找地儿，拉屎几个类来处理。至于出错，那就是拉屎失败了怎么办（具体失败在详细设计中）。

有了概要设计，开始详细设计吧

详细设计必须要说明每个类的方法是如何处理的，这个可是个力气活，说力气活，是因其实设计并不太复杂，复杂部分在概要设计就做完了，这边和写伪代码差不多。主要包括程序描述，功能，性能，输入输出，算法，流程等。

这下知道了吧，按照国标做法，小狗要憋死了，可怜的小狗，憋死也不肯拉在家里。

费力还是次要的，如果客户说某某需求变更了，这下可热闹了，先看看概要设计吧，挺好，基本全改了，再看看详细设计，基本上没用了。这就是传统的设计方式。也是瀑布式项目管理方式的基本生活。好像这种方式缺点比较明显，但实际上是有优点的。

最大的优点就是开发实现时，不会出现无用功，并且对于开发的工作比较容易估算。

但是WEB技术的出现，让这个唯一的优势也不存在了。原因是技术复杂程度不同了。以前大家做个应用程序开发，单机也好，C/S架构也好，无非几种技术。以VB为例，一个系统涉及的技术，基本上就是VB和SQL，复杂点的用C++开发个插件。但WEB不同了，我们来看看现在主流的WEB技术，HTML、CSS、JS、XML、SESSION、AJAX等等再加上动态页面，业务层和数据层的技术。这个要用详细设计来做的话，估计做设计的人要吐血了，而且不止两三口。

这下清楚了吧，概要设计里面的要求基本上就是我们在做框架时完成的东西。那既然我找一个人做出了框架还要概要设计做什么啊？在WEB技术下，实现详细设计如此困难为什么我还要做详细设计呢？我采用技术规范（样例代码）来代替详细设计。

不过现在还有项目使用概要设计和详细设计，这种项目一般是军工航天项目，需求明确不会变更的，而且不会是WEB技术。

所以我的项目组是没有设计文档的，设计都存在于代码中。

以前我给别人讲到这里时，很多人问我，用的是不是XP（极限编程）。我可以负责任的说，我用的不是极限编程。原因是我的流程不符合极限的要求。

极限编程中第一个要求，测试先行。就是说在没有开发前，就要进行测试。这时你得到的是一个失败的结果（废话），得到了一大堆任务。之后程序员只要关于测试结果就行了，什么文档都不用了。换言之就是测试驱动开发，测试驱动其实就是问题驱动。是把想到的写成测试，然后开发，把遇到的问题再写成测试，再开发。如此反复。（感谢文野）
这个好像是不错，按XP思想，这个测试可以由测试人员来做或开发人员来做。非常遗憾，我至今没见过能达到这种程度的测试人员和开发人员。如果哪位大侠有这方面的经验可以讨论一下啊。

极限中的第二个要求，结对编程。就是两个程序员在一台电脑前工作。像飞机驾驶员一样，一个开飞机，一个导航。因为XP上说，两个人一起工作，实际效率大于两个人分别工作，原因是出错率低，还能通过高手来带新人(感谢文野的补充)，减少了上网聊天的时间（可能老外都挺爱面子的，不好意思当着别人面不干活）。我以前（天真的时候）向老板推荐过，老板说：“一个人的活，两个人干，我付一份工资行不？”。结果就是没戏，还被老板骂了一通，说整天不干活，想这个蠢办法。郁闷啊。

极限中的第三个要求，超人。就是团队不大，但人员都是牛人。每个人都强得一塌糊涂。但是我们看看现在手里的团队，基本上有一两个高手就不错了，大部分都是项目经理带几个实习生在那硬抠。

所以极限编程在我的项目管理经验中是零。不过我现在是尽可能的接近极限的思想。

篇后话:

今天聊了些文档的内容。不是因为我没啥可说的，而是因为文档在项目中很重要，你没见到合同上交付物里写着各种各样的文档吗，这些文档不用时上厕所都嫌硬，要用时真得很重要。没文档就别想验收了。

但问题是一个项目到底要有多少文档啊？这个和项目管理流程有关。本文我说了瀑布式和迭代式（我当前项目的）两者相差的重点，在于设计。当然需求和测试也是不同的。没有设计文档不等于没有设计，其实最完整的设计就是代码，最有价值的文档也是代码。