挨踢项目求生法则（4）——设计篇

摘要：

知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了避免让客户踢、不让老板踢、项目组成员之间不互相踢，俺为你们分享一些减小被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分团队建设篇、战略篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。

什么叫挨踢项目？

IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特色：
1.需求不肯定。
2.技术不肯定。
3.工期限死。
4.预算限死
两大不肯定和两大限死，你想不“挨踢”都难！

 

 

什么是“漂亮”的设计？

一些关于软件设计的资料提到，我们的设计须要高效、可靠、易用、安全、可扩展、兼容性强、移植性强……
每次看到这样的文字，个人第一反应就是头晕，这些基本就是废话嘛！
软件设计是为软件服务的，要服从项目的商业目标。一味追求所谓的优雅设计，项目可能会死的很惨。客户购买的是软件而不是你的设计。若是你在客户面前介绍你的设计如何精妙、如何OO、如何依赖注入？那客户只能当你是火星人看了，客户并不会由于你的设计如何精妙而原谅你的推迟交付和增长费用。若是为了节省时间，忽略设计或者粗略设计，项目一样极可能会死得很惨！没有想清楚就动手，就至关于冒着大雾往前走，可能走错方向，可能跌入悬崖……

我认为“漂亮”设计应该是这样的：
1.能命中需求。
2.符合项目的战略。
（什么是战略？请参考《挨踢项目求生法则-战略篇》：http://blog.csdn.net/u010825142/article/details/9026279）
3.作适度的设计。
固然以上内容可能仍然不够清楚，请继续阅读下文。

为何须要设计？

之前公司过ISO的时候，其中一个我以为比较厌烦的问题是：软件的实际设计已经和设计文档不符了，ISO内审员要求我去更新设计文档。为了不这些麻烦，我试图将设计文档写得比较粗和通用，这样就大大下降了须要更新文档的机会。若是将设计进一步抽象化，我彻底能够写出一个N层架构的设计出来，这样的设计能够复用到n多项目上，每一个项目的设计文档复制这个设计就能够了。但问题是：咱们的软件设计就是为了获得一个不用怎样修改的文档吗？何况这样粗的设计对项目实际工做有什么实用价值呢？
在某项目管理培训中我展现了某项目的某模块的详细设计文档，但有学员提出了质疑，从他的经历看来，没法让程序员写出相似这样的文档。写不出文档，是由于没有能想清楚？仍是由于不会中文呢？软件设计并非写文档，而是经过探索和思考，想出解决问题的方案，文档写不出了没有关系，关键是你有没有解决方案？哪怕这个方案存在与你的脑壳当中，你能不能清晰的表达出来？表达的方式不必定是文档，能够是口头表达，能够是经过Demo来展现等等。

如今能够来回答“为何须要设计？”这个问题了，个人观点以下：
1.需求解决作什么的问题，而设计是解决怎样作的问题。
2.如何更简单、更少工做量地解决怎样作的问题，是设计工做的重点。
3.需求工做决定了软件的价值，而设计决定了软件的成本。
4.写设计文档并不等同于软件设计，软件设计在于探索、思考、实践，摸索出有效的解决方案、具体作法等。
5.Word文档仅是软件设计的其中一种表现形式而已。
6.设计不是一次成型就不变的，而是须要持续优化和改进。

咱们须要作什么设计？

设计包括概要设计和详细设计，这是咱们惯常的认识，但我将设计分为如下几方面的内容：架构设计、模块设计、数据库设计、用户体验设计。
架构设计能够近似看做是概要设计，架构设计是通盘考虑了全部软件需求后的一个宏观设计，我一般会用UML的部署图、组件图和包图进行架构设计，设计的粒度会达到组件及模块级别。
模块设计是指在架构设计的基础上，在软件系统划分红n个模块，每一个模块进行详细设计。我一般会用UML的类图、顺序图来进行模块设计，设计的粒度会达到类、类的方法和属性、类之间的调用关系等。
数据库设计这个不用多解释，粒度要达到最终实现的程度，而用户体验设计可能须要多加解释了。
用户体验是指用户使用软件时的总体感受，用户体验设计须要考虑清楚软件的总体界面规划、界面前后关系、文字表达、软件与用户如何交互等等。说到用户体验设计，不少人直接反应就是美工的事情，这是不对的，美工仅是用户体验设计的一小部份内容而已。一个软件若是内部实现很烂，但用户体验设计作得很好，那么这个软件仍然会很受欢迎。相反，一个软件的用户体验设计很烂，哪怕软件的内部设计很精妙，客户也不会卖帐。从这个角度上看，用户体验设计是至关重要的，但用户体验设计每每是被忽略的。不少软件公司没有专门的用户体验设计职位，每每由程序员本身设计软件与用户的交互，作出来的软件很是不人性化。

我在之前的公司作项目，一个项目通常会有1份架构设计文档，1份或者多份模块设计文档，1份数据库设计文档和1份用户体验设计文档。我想说明的是，以上提到的四种设计并非非要对号入座，每种设计对应一份或多份文档，而是软件设计应该包含这四方面的内容，至于文档的数量和形式没有规定，你能够一个文档包含四个方面的内容。另外还要说明的是，并非软件全部的模块都须要写详细的设计文档的，若是该模块的实现方法已经很成熟，成为项目组的“常识”，这些内容没有必要额外再写文档。

法则1：需求驱动设计

之前曾经参加某项目的某设计文档的评审，你们围着一个局部的技术问题进行讨论，但争论的内容仅仅是一些软件设计上的大道理，每一个人对这些大道理诠释不一样而已。因而我问：你们知道这个项目的需求吗？能不能列出设计中须要重点考虑的需求是哪些？竟然没有人能答出来！
我去评审设计文档很简单，就是事先将需求搞清楚，列出设计中须要重点考虑的需求，而后看看设计文档是如何考虑这些需求的实现。设计就是用来知足需求的，用需求来检验设计文档，这是很基本的“常识”，但这个常识每每被咱们忽略。编写设计文档的为“节省”时间，不去全面深刻理解需求就去写设计文档，参加设计评审的为“节省”时间也不去了解需求，这样设计和设计评审就变成了走形式、浪费时间的事情。

前面提到设计决定了软件的工做量，在设计时间上“节省”时间，你的代价就是将会花数倍甚至数十倍以上的项目工做量。认真地需求驱动地作好设计工做，这是必须的。下面简单介绍一下什么需求驱动什么设计：
1.架构设计是通盘考虑所有需求后设计出来的，因此能够说：所有需求驱动架构设计。
2.模块设计是在架构设计的基础上，针对局部需求的具体实现设计出来的，也就是说：局部需求驱动某模块设计。
3.数据库设计是整理了所有需求当中的业务数据，思考这些业务数据如何在数据库中存取后设计出来的，也就是说：业务数据驱动数据库设计。
4.用户体验设计须要考虑业务流程、业务数据等，为知足客户的业务目标，咱们设计出来的系统与用户之间的交互细节等，也就是说：业务流程、业务数据、业务目标等驱动用户体验设计。
“需求驱动设计”这句话还不够具体，还要进一步细化，什么需求驱动什么设计！上述几点是我以往工做的简单总结。

关于需求，请参考《挨踢项目求生法则-需求篇》：
http://blog.csdn.net/u010825142/article/details/9042125

 

 

法则2：不要误解“简单设计”

极限编程中提到“简单设计”，有些朋友很兴奋，终于能够用“简单设计”做为不写设计文档的理由了！
什么是“简单设计”呢？如下状况是否是简单设计呢？
1.简单想一下，而后快速作一个设计。
2.没有设计文档的设计，就是简单设计。
3.不设计就是最简单的设计。
4.编码就是设计。
极限编程对“简单设计”的诠释能够总结为两点：
1.不要考虑太长远，仅考虑当前的需求。
2.用最简单的办法来实现。
我基本认同这个观点，但问题一些朋友的理解可能出现了误差。第2点“用最简单的办法”这是很难作到的，将事情简单化这是难度很高、很考验智慧的事情。“简单想一下”是很难想出“最简单的办法”的，随便想一下想出来的办法，每每是工做量巨大的办法！简单设计的意思是指要让项目工做变得简单，而不是将设计的思考过程简单化。软件设计是一种智力投资，多花一小时想清楚如何让项目工做变得更加简单，会节省你更多的项目时间。

法则3：作高性价比的设计

在符合项目战略的状况下，用尽可能少的工做量来实现需求，这基本上就是“高性价比”的意思。
实际上咱们不太可能作出一个“最好”的或者说“天衣无缝”的设计，由于有如下的条件限制：
1.有限的项目工期。
2.有限的项目预算。
3.项目成员的能力条件限制。

软件设计是高难度的技术活，须要你作出适当的取舍和平衡，作出一个合适的设计。
但高性价比的设计意味着：
1.公司项目的利润更加大，公司赚钱更多了，我们能分到的钱也就更多了。
2.项目工做更加简单，项目组不须要加班或少加班就能完成工做。
3.高性价比设计是挑战智力的工做，会让你的工做更加有愉悦感和成就感。
因此为了公司好、你好、你们好，向“高性价比设计”的目标进发吧！

法则4：人人都是软件设计师

有这样一种观点：由软件设计师设计出详细的设计，程序员按“图纸施工”即可。
我不喜欢将软件研发工做变成流水线的工做，将研发过程分割为需求、设计、编码、测试等几个环节，每一个环节有专职的人员，他们作好本职工做就能够了。这样的工做模式有如下几个问题：
1.人变成了机器，没有创造力可言。
2.每一个人对工做职责负责，而不是对项目成功负责。
3.这样的模式不可能产生创意，也意味着不可能完成复杂的、须要创造力的项目。

我认为项目组中每一个人均可以是软件设计师，不要剥夺程序员思考的机会，不要将他们变成按图纸施工的机械人。
在个人项目中，我是这样作的：
1.架构设计和数据库设计由富有经验的程序员负责，其余项目成员参与学习和评审该设计。
2.模块设计由未来负责该模块编码的程序员负责，架构设计师来评审该设计。
3.用户体验设计由测试工程师或实施工程师负责，程序员参与。

法则5：设计文档应该先己后人

一些QA一般用这样的理由来讲服项目组编写设计文档：
1.为了让未来接手项目的同事搞清楚情况，设计文档是必须的。
2.未来你本身也极可能须要改程序的，如今写下文档对你未来的工做有用。

以上的作法，就好象你对一个正在挨饥荒的人说：如今多存点粮食吧，对你未来有用。听你劝说的人确定气死了，巴不得吃掉你充饥！
因此以上的理由是不能驱动项目组写设计文档的，设计文档应该达到这样的效果：对项目当前的工做有用，能帮助我马上解决问题！若是设计文档不能达到这样的效果，就不能驱动项目组写好设计文档。

设计文档必须先保证对本身、对项目组自己的当前工做有用，在这前提下有条件才去考虑对本身的未来有用、对别人有用。也只有立足于这个出发点下，才可能写出有实际价值的文档，文档不是摆设，是要立马在工做中用上的。

法则6：设计文档不必定是Word文档

之前曾经遇到一个挺郁闷的事情：
某项目用SQL Server数据库，我直接在SQL上进行设计，也就是说数据库的设计与实现一块儿作了。在数据库上作设计的好处有：
1.设计立刻获得验证。
2.以利用数据库的特性作不少设计上的探索，让设计作得更好。
3.设计完成了，数据库也建成了，不须要再作一次，节省不少时间。
我很喜欢这样作，但QA认为我没有数据库设计文档，不符合ISO的要求。我以为很郁闷，数据库这个文档就是数据库设计文档，干吗非要写一个Word文档？后来迫于要ISO审核，我用复制粘贴大法写了这个数据库设计的Word文档。若是项目使用的数据库只有一种，我以为直接在该数据库上作设计没有什么不妥，固然若是你的项目须要支持多种数据库时，该作法可能不妥。

经过这个例子我想说明的是：设计的表现形式能够不少，不必定是Word文档，怎样的方式对当前项目工做最有效，就应该采用怎样的方式。固然有人会说，写下Word文档对未来的人有好处，但前面的法则说了，要“先己后人”而不是“先人后己”，若是我如今就饿死了，你让我如今存粮有啥意义？何况Word文档并不必定是全部软件设计的最佳表现形式。

法则7：不是全部地方都须要有设计文档

有这样一种观点：代码没有设计文档是不符合CMMI要求的。
你认为是否是全部代码都应该对应有详细设计文档呢？
数据库四轮马车的操做若是大家公司已经得心应手了，大家项目组闭着眼睛都能作了，你还会写一份详细的设计文档，而后对着该文档编码吗？
并非全部的地方都须要设计文档，仅在须要的地方才写设计文档，个人作法一般是这样的：
1.架构设计文档通常不可缺。
2.数据库设计文档通常也不可缺。
3.并非全部模块都要写设计文档的，通常在如下状况下才写该模块的详细设计文档：
1）算法比较复杂；
2）想法不太成熟；
3）负责该模块的程序员是新人等。
4.用户体验设计文档通常也不可缺，但文档的内容通常不会覆盖软件的所有内容，成为“常识”的内容不须要写。

法则8：“编码即设计”是合适的，但烂代码除外

“编码即设计”这个观点我支持，我要进一步修正，应该是“好的编码即设计”。架构设计文档、数据库设计文档或不可缺，但详细设计文档是能够直接经过编码来代替的，但前提条件是该程序员的编程素质足够好才行。
中国计算机教育培养出来的程序员，大多数是编程基本功不过关，在校没有写过多少代码。这是一大问题，而另一大问题是这些编程基本功很水的人士，大多不会认识到本身的问题所在，还自认为本身水平不错，编程是小菜一碟的事情。遇到不肯意写或者写不出设计文档，又自认为本身编程水平很行但实际不好的项目组成员，就须要项目管理者多花心思来引导了。
有时候遇到一些编程新手，死活写不出设计文档，我会让他直接经过编码来思考。文档可能没有办法让他理清思路，那么直接编码来理清思路吧，你能够经过他的代码来了解他的想法并给出针对性的指导，帮助他提高水平。

 

 

做者：张传波

创新工场创业课堂讲师
华为某团队高级顾问

《火球——UML大战需求分析》做者

www.umlonline.org 创办人