需求的实践.docx
《需求的实践.docx》由会员分享，可在线阅读，更多相关《需求的实践.docx（22页珍藏版）》请在冰豆网上搜索。
需求的实践
需求的实践
细节需求时期（上）
IBMDW中国站点
林星（iamlinx@）
2002年1月
从这一篇开始，我们开始进入细节需求时期。
和业务建模时期注重于软件概貌不同的是，细节需求时期讲究充分挖掘涉众的需求，并作为其它的活动的输入。
细节需求时期和业务建模时期有着不同的做法，迭代、小版本发布的思想是非常重要的。
1、细节需求时期和业务建模时期是不同的。
前面的章节谈了很多业务建模的知识，可以看到整个过程基本上是串在一起的，严格按照软件生命周期模型来说是属于瀑布模型。
这里就有问题了，我们在讨论瀑布模型的时候已经用了很多的篇幅来鞭笞它了，这里我们又用回了这个模型，这是不是有点…。
这样做的一个很大的原因是业务建模有它的特性。
在一些小的项目中，业务建模在软件生命周期中所占比例一般不大，多半是为了了解业务环境的，其中BPA的成分会多一些，BPR的部分通常很少。
所以其中如果发生了一些失误的地方，可以在需求阶段弥补。
如果是那些诸如ERP的项目，那么业务建模和BPR会有很重要的位置，这个时候，一般要根据具体的情况来制定战略，很难说是采用何种周期模型。
而且业务建模一般需要的人手不多，也会安排在项目的早期。
所以只要有审查，业务建模采用何种生命周期模型并不是特别重要的。
不过这是对于那些特定的项目而言的，对于市场化的产品来说，应该有另外的过程，但这并不在我们的讨论范围内，以后有机会的话再和大家讨论。
再说需求，需求的生命周期绝对不能按照瀑布模型的来。
对程序员来说，最痛恨的一件事情就是需求改变。
所以呢，大家想出一种需求凝固的办法，在分析完了需求后，就把它固定起来，写成文档，让客户签字。
以后再有需求的增加或改变的话，就拿出这张纸说，"看吧，当时的要求可没有这一项啊。
"这种做法的恶果是显而易见的。
不过，有些企业则会反驳说，"没有啊，我向来都是视客户为上帝，这种事情我是不会做的，我会让程序员增加这个功能。
"可惜的是，这种纵容顾客，伤害程序员的做法更糟。
还记得我在听管理学课程的时候的一句话：
"员工是最重要的，客户次之。
"这是很有道理的，如果你的员工不满意，那么员工直接服务的客户又怎会满意？
所以无论是哪一种做法，都只能暂时解决问题，对未来造成的危害却更大。
需求改变的危害很大，可是不变的需求从来就没有存在过。
如果说，过去的社会中，企业的需求能够在一段相对长的时间内保持不变。
那么，在现在这个全球化趋势愈来愈明显的社会中，一个不会变化的企业就只有死路一条。
曾经是大陆霸主的恐龙为什么会灭亡，而当时弱小的哺乳动物却能够存活下来，最大的原因就是面对着瞬息万变的自然环境，恐龙没有办法改变自身来适应环境，而哺乳动物则可以。
现在的社会也是一样的。
如果你的软件企业所服务的客户一家家歇菜，那你的下场也就可想而知了。
所以，很明显的，需求和变化几乎就是同义词。
2、迭代
一方面是要求不变，一方面是要求改变。
在这种矛盾的环境下，如何才能达到一个平衡点呢。
在已往的软件开发过程中，多半都要求对未来作出预测。
例如，需求要有前瞻性，设计要有可延展性。
可是这种做法往往难以实现。
现实中的变化何止千万种，你都能做到算无遗策吗？
如果你说你在做计划书的时候，可以估算到9月11号可能会发生灾难，那我就没话可说了。
一个中型以上的项目往往都需要数十人的团队工作半年以上才可能完成。
这时候的计划还要加进人这个最不确定的因素。
这样，正确的估计简直就是比登天还难。
有很多自称考虑周详的计划书，在进度安排时连假期都没有考虑在内。
这种计划，定与不定又有什么差别呢？
我最早接触迭代这个词是从一个朋友那里。
他对我说：
"自然界中的物体从来就没有以直线形式存在的，螺旋状的物体才是符合规律的，例如DNA。
"他这话虽然听起来很玄。
但是却很适合放在需求过程中。
直线条的需求过程显得干涩，孤立，易断。
而有螺旋的（迭代的，增量的）需求过程不论从那一个切面去看，都能够形成比较稳定的形状。
其实这个道理是很简单的。
在我还是个写程序的菜鸟的时候，为了不至于编译时出现一大堆的Error，于是就采用稳扎稳打的方法，写一小段程序除一次bug。
而迭代也是这样，是把以前需要一年才能看到结果的过程分成多个小过程，每隔一小段时间就可以看到一定的改进。
体现在需求上，以前要一口气做完的需求往往会划分为多个的阶段，每个阶段完成一些功能。
这样做有什么好处呢？
人们对较长的未来比较难以估计，但是却可以大致估计出短时间内的未来。
这就好比我说不出两年后我是什么样，可如果是两个星期，我就有把握得多。
把一个大目标分割为多个小目标，这样人们能够不断的看到一个个目标被实现，这比长时间的等待大目标的实现要好的多。
客户总是说，我想看看软件才能提出更多的需求。
这符合人的本性，应该予以满足。
不断的改进有利与开发人员和客户的合作程度的提高。
迭代的过程可以一定程度上消除原来品保人员等开发人员，开发人员等品保人员的瓶颈现象。
3、需求迭代的特殊性
迭代式的需求开发并不是意味着需求开发平均分到各个迭代周期来进行。
在理论上，应该是先做完需求分析（还有构架设计），再着手进行各阶段的开发工作。
可是实际情况中，需求要保持不变可太难了。
根据自身的经验，一个项目，在一开始往往可以完成的需求开发可以占全部需求开发任务的80%（估算的数字）。
但是在随后的软件开发中浮现出来的需求（新增或改动）又会有20%。
可是这20%的需求是极不稳定的，可能分布在项目中期，也可能分布在项目晚期，甚至可能会在项目在部署阶段才会呈现出来，这些都取决于团队的能力。
这样的项目的风险其实是很高的，有些较晚才浮现出来的需求可能会花费大量的资源来实现，如果这需求又对软件架构有影响的话，那后果更是灾难性的。
在XP中，一个迭代周期会包括多张素材卡片（StoryCard），一张素材卡片都代表了系统的一项功能（functionality），这些素材卡片由项目负责人和客户、领域专家按照一定的规则，共同从需求集中抽取，决定在本次迭代中实现。
一次迭代经过计划、准备素材卡片、分析、编码实现、测试、构建等步骤，呈现在用户面前的将是一个可以运行（canwork）的软件。
用户可以清晰的看到软件的界面，软件的使用手册，软件的输出结果。
一切都是一览无遗的，不需要任何的叙述性的语句来描述软件，因为用户会自己去感受。
接下来，用户的反馈意见被收集，分析，处理，必要的需求改变被安排在随后的某个迭代周期中实现。
单独的迭代可能是线性的，但是从整体上来看，多个迭代周期形成了一个流水线般的生产方式：
所以呢，需求迭代的特殊性在于需求的出现并非是迭代的，但是需求的分析和实现则是迭代的。
4、迭代的代价
就和计算机中任何的算法都必须寻求空间和时间的平衡一样，迭代方法虽然有其优势，但是同样需要付出代价。
由于要不断的对软件进行调整，所以软件的架构（Architecture）需要比较稳定，经得起变动。
这一点可能在过去比较难，现在的软件架构都相当成熟，都能胜任这种工作。
例如J2EE就是一个非常出色的架构。
除了架构，系统的框架（Framework）也是非常的重要，框架要足够"软"，这个方面虽然没有现成的框架可以利用，但是业界有很多关于这方面的资料，例如设计模式、分析模式。
这些都是告诉你一些经验之谈。
都是可以参考和采用的。
多个的发布版本要求开发团队有控制版本的能力。
多个的开发版本如果不加控制到最后必然如同洪水猛兽一般可怕，开发人员的时间都浪费在各个版本的统一上。
关于版本控制，有很多的软件都能够完成这一工作。
对于比较小的团队来说，简单的目录控制可能就足够了。
上面画出的迭代示意图虽然好看，要实现可没有那么简单，如果功力不足，画虎不成反似犬，原来安排的迭代计划没有严格执行，结果是更加混乱。
这时候就要求团队的项目经理有足够的计划能力，以及团队的配合。
需求变更，并不是所有的需求都一概接受。
对于时间所剩无几的项目，一个简单的需求变更都可能是骆驼身上的最后一根稻草。
这就要求团队能够有需求变更的管理能力。
5、和其它阶段的关系
在进入细节需求之前，千万要先确定系统的架构。
国内的程序员很少会专门去思考这个问题，但是会自发的去做这件事情。
比如，你是选用微软的DNA，还是J2EE。
这就是架构决策的一种。
但是我们并没有重视架构的设计。
架构方面的欠考虑，会使得架构的涉众蒙受重大的损失。
想想看，一家企业想要改变原有的架构，那是需要多大的成本啊。
由于我们文章的主题是需求，所以架构方面的问题并不在讨论范围之内。
但是，请记住，先决定架构，再进入细节需求阶段。
当然，这并不是说，进入细节需求阶段就不能改变原先的架构了。
原因很简单，亡羊补牢嘛！
由于细节需求是迭代进行的，所以每一次迭代就像是一个小型的瀑布模型，要经历需求、分析、设计、编码、接受测试、交付等阶段。
这样，细节需求实际上是和软件开发过程中的其它阶段紧密相连，其中可能并没有很明显的界限。
在下一章中，我们其实可以发现，探究需求活动和其它的活动都是同步进行的。
有话要说 打印 保存 关闭
需求的实践
细节需求时期（下）
IBMDW中国站点
林星（iamlinx@）
2002年1月
和业务建模时期不同的是，我不再花费笔墨讨论需求要如何做，因为做法、注意点和业务建模时期并没有什么太大的区别。
而在完整的流程上，像RUP、XP之类的方法学可比我讲的要好的多。
因此，我会把焦点集中在我在实际工作中的一些困惑，以及一些思考。
1、"和其它阶段的关系"的再思考。
上一篇的末尾我们简单的讨论了细节需求阶段和其它阶段的关系。
对于软件过程的各个阶段，不同之处只是注重的焦点不同而已。
在业务建模阶段，我们关注于系统的整体需求；在细节需求阶段，我们更关注于需求的细节部分。
其它的阶段也是一样，架构阶段，所关注的当然是如何设计出一个合适的架构；到了设计阶段，注意力就转移到了如何设计方面。
当然，焦点的不同，导致了各个阶段所需要的技能和工具也不尽相同。
业务建模阶段需要你有整体的把握能力，你可以使用简单的用例图，基本的用户素材等工具。
细节需求阶段则要求你能够充分的挖掘需求和进行良好的沟通。
相应的，在架构、分析、设计等阶段，也会有不同的需要。
各个阶段的实质就是注重点的不同，这对于大多数的软件开发而言都是一样的。
不论你采用的过程是传统的，还是迭代的。
2、架构
MartinFowler在他的ISA中写到：
I'musingarchitecturetomeantheimportantdesigndecisions,theonesthatshapemostaspectsofasoftwaresystem.Theseareoftentheharderdecisionstochangelateronintheproject（althoughoftennotashardaspeoplethink）.Asaresulttheseareoneswhereit'susefultostartintherightdirection,andthusknowingaboutarchitectureisavaluableskillforanysoftwaredeveloper.
架构并不神秘，无非是一个决策而已，只是这项决策对软件特别重要就是了。
软件开发人员可能根本没有主动的进行架构设计，但是他的行为，已经潜移默化的进行了；而还有一些人，总在谈论着架构，但是并不了解这个词的含义。
春运就要到了，学生也要赶着回家。
如何选择回家的交通工具就是一个重要的决策。
路程的远近、不同交通工具的价格都是显式的，比较容易知道的。
而以往的经验也告诉你，火车票比较便宜，但是比较紧张，花费时间较长，整个过程也不舒服；飞机票比较贵，但是容易买到，花费时间少，整个过程很舒服。
这时候你就要做出正确的决策，为回家选择一个正确的架构。
你可能考虑的因素有哪一些？
以下就列出了一些可能的因素：
拥挤程度，大家都知道春运时那种情况；
购买票的难易程度，火车票需要很早就要预定了；
是否有额外的渠道，比如你能够买到飞机的学生票；
经济实力，经过了一个学期的花销之后，现在还剩多少生活费；
根据这些因素，以及这些因素对你的影响程度，即优先级，你可以自己估算出一个或几个可能的架构方案。
而这种架构的选择，直接影响到你之后的行为，也影响到行为的结果。
开发软件和买票回家又能有什么区别呢？
一样要考虑成本、结果、时间。
所不同的只是复杂了：
需要专业技能，有很多不确定的因素。
那么我这里谈论架构的问题，和需求有什么关系呢？
在上面的例子中，大家可以看到架构是根据什么决定的？
是因素。
因素的本质是什么？
就是需求。
因素，就是需求。
所以，需求决定架构。
上一篇中，我谈到说，在进行细节需求之前，一定要定出架构。
当然，这时的架构可能只是一张草图。
为什么？
因为我们已经进行了业务建模，对项目有了一定的认识，对用户的需求也有一定的把握，成本、范围、时间等要素也都清楚了（如果你还不了解这些，请你回到业务建模阶段，你的工作还没有结束）。
这个时候，决定架构的因素已经形成了，可以进行架构的设计了。
需求能够决定架构，架构反过来也能够影响需求。
最明显的一个例子就是用户界面的设计。
虽然用户界面主要来自于需求，但是不同的架构对用户界面也会有影响，例如基于浏览器的客户端，和基于Windows界面客户端能够提供的界面就不同。
在XP中，这种的架构设计，被称为ArchitectureSpike。
为什么叫做Spike呢？
就是说你需要专研，解决一些主要的问题，但你并不是提供一个完整的解决方案。
例如，在项目的初期，如果你对新近的服务器和操作系统不了解，你肯定会花时间去了解，去试用，去测试；如果对数据库不了解，你也肯定会试着使用看看。
这种行为，就是Spike。
所以呢，架构的设计只是很初步的设计，而不是一个完善、定型了的设计。
这一点要注意。
架构的选择和开发人员的经验和能力非常有关系。
一般来说，它需要开发人员具有相关的经验。
提供架构的厂商多如牛毛，如何选择，也是一项学问。
比如，数据仓库的平台，选择的品种就很多；而WebServer的选择也是五花八门；操作系统也是一样。
这些又都是和架构息息相关的。
3、模式
武功有招式，下棋有棋谱。
不论是招式，还是棋谱，都是针对某一种问题的特定解决方案。
在软件开发领域，这种解决方案就被称为模式。
"每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心，这样，你就能一次又一次的使用该方案而不必做重复的劳动"[AIS，77]
这句话源自模式的鼻祖――ChristopherAlexander。
而在软件开发领域，最值得一提的著作，就是GoF写的『设计模式』一书。
在该书中，作者描述了23种的设计模式，可以说，这些模式奠定了面向对象设计的基础。
而另一本值得阅读的著作，就是MartinFowler所著的『分析模式』。
在软件设计中，我们遇到各种各样的问题，我们可能缺乏经验，或能力有限。
这非常的正常。
但是现实是，我们生产出的代码由于设计方面的缺陷，往往不够清晰，容易出错，难以扩展。
相信只要是开发过软件的人，都遇到过这种问题。
于是，我们就希望能够看看其他人，是如何处理这种问题的。
这里的"其他人"指的可能是技术专家，也可能是经历过同种问题的人，他们对你遇到的问题有能力，有经验来解决。
他们提出的解决方案往往是非常成熟的，能够解决你目前遇到的问题，也能够解决你目前尚未遇到的问题。
这对你的吸引力是很大的。
那么，我们谈论模式，模式来源于何处呢。
注意，模式是针对某一类的问题的解。
这里的问题，所指的就是需求。
比如说，客户希望能够在软件中实现不同的税率计算方法，那么，我们很自然的就可以想到Strategy模式；当客户的产品有一个很复杂的单位换算机制的之后，我们也能够很自然的想到Quantity模式。
使用模式，能够使我们迅速的把握需求的解决方法。
另一方面，模式往往告诉我们比目前的问题更多的方面，因为模式都是大家的经验沉淀。
如上所说，它还可以解决你目前没有遇到的问题。
因此，我们还可以从模式中发现出更深的需求。
另外一点也很重要，虽然它和需求的关系不大。
模式往往都有一个模式名称。
这就形成了一种沟通的语言。
比如我们在下象棋的时候，只要说"马后炮"，谁都知道这是什么意思，绝对不需要呢详细的解说每一步棋子的走法。
对于软件开发也是一样的。
我和我的同伴会心的一笑，说：
"FactoryMethod。
"两个人都能够理解这是什么意思，因为这是一种共通的语言，它代表了背后隐藏的各种类的关系和代码实现。
这在软件开发中非常的重要。
当然，这有个前提，大家都对模式有一个通透的了解。
4、简单设计
模式属于设计的一环，所以前面我们讨论的其实就是设计和需求的关系。
这一小节我们还是讨论这个话题。
但是侧重点有所不同。
XP中有一个原则：
KISS。
不是kiss哦。
它是Keepitsimpleandstupid的缩写。
除了XP，其它的敏捷方法都提倡简单设计，反对过分设计（overbuild）。
也就是说，针对目前的需求，设计目前的软件。
很多的软件人员都是完美主义者，他们喜欢完美的设计，然后把这种设计提供给用户。
这种思想就是过分设计的开始。
不必要的功能浪费了客户的投资。
我们在做需求的时候，很经常发现开发人员随意的向客户推销一些新功能，或是在设计时，过多的考虑未来可能出现的需求变动。
所以，简单设计的意思，就是要针对目前客户提出的需求进行设计，不要过多的考虑目前没有提到的功能。
5、如何统一
细心的读者看到这里可能已经是疑窦丛生了。
一边是鼓励使用、设计最完美的方案；另一方面，又强调简单。
似乎是自我矛盾。
不错这其中是由矛盾的地方，但也有一致的地方。
因此，在使用先进的模式和保持设计的简单性之间，我们需要权衡。
一次，我们看到了一个关于权限设置的模式，我们觉得这个模式非常的好，它提供了类似于UNIX操作系统那样的权限控制，可以很随意的增加组、用户，并能够在文件级别上设置权限。
我们如获至宝，觉得这是一个非常有用的模式。
于是，我们花了一些时间将之实现，并打算应用于新的软件中。
在实际中，我们发现没有一个用户需要如此强大的功能，他们所需要的可能仅是密码控制，或是简单的用户管理。
如此复杂的功能对他们来说没有任何的意义。
完美的模式在现实中遭到了冷遇。
实际上，用户目前不需要这项功能，并不意味着他以后不需要这项功能。
用户的计算机程度提高的很快，我们估计，再过那么一两年，用户可能就非常需要这项功能来管理他那日益庞大的员工队伍了。
但是目前，这项功能对用户来说，设置复杂，所以他们并不愿意接受这个"有价值"的功能。
最后，我们想到了一个解决的办法，我们为这一项功能定义了一个通用的接口。
通过这个接口，你可以实现复杂的功能，也可以实现简单的功能。
总之，你只要是实现了接口的方法就行了。
接口的方法很多，但是在目前的简单的实现中，可能就仅仅是一个返回语句，并没有很多的实现。
相应的，用户的也仅仅需要使用简单的方法，诸如addUser（），updatePasswd（）等。
界面也做了简化的处理。
通过这种方法，我们可以在用户需要的时候，替换掉权限模块，对其它的应用并不影响。
当然，其中有很多的细节需要注意。
在完成之后，我们还发现了另一个副产品：
整个的权限控制模块是高内聚，低耦合的。
模式，就好比螺帽的设计图纸，它规定了螺帽的技术规格，但是没有规定具体的尺寸。
对应于不同的需要，我们可以设计出不同大小的螺帽以供使用。
图纸只需要一份就可以了，并不需要为每一种尺寸的螺帽画一张图纸。
因此呢，一个经历了实践检验的模式，往往功能强大。
但是它可以有多种不同的实现。
有哪一条法律规定你必须完全的实现一种模式呢。
在实际使用中，你需要权衡模式使用的成本和效益。
你会发现，在很多情况下，你还是实现了模式，但只是模式的一个框架，或一部分，但是这在目前就够用了。
而当需求变动，或新的需求出现的时候，你可以很方便的在原有搭起的框架上添砖加瓦。
一切都是那么的自然。
比如，在一个进销存的软件中，存在一个运输选择算法，目前的运输途径就一种，但是很有可能会增加新的途径。
这时候，你就决定采用Strategy模式。
但是你只是实现了一个简单的框架，只有一个具体子类，来实现目前的算法。
当新的运输途径出现时，你需要增加一个算法，你就可以再增加一个子类，只要实现的接口相同，改动是不会影响到系统其它的部分的。
6、测试
测试是非常重要的，是软件成败的关键。
但是目前国内对测试并不关注，或是假装关注。
这样就无法保证软件的质量。
测试有很多种，我们这里要说的是和需求息息相关的测试，就是接收测试（AcceptanceTest）（关于这个词，可能不同的文章会有不同的译法）。
Surelyyouaren'tgoingtoassumeyou'regettingwhatyouneed.Provethatitworks!
Acceptancetestsallowthecustomertoknowwhenthesystemworks,andtelltheprogrammerswhatneedstobedone.
上面这段话摘自『XPInstalled』。
接收测试有两个作用：
首先是让客户明白系统能够做什么，然后是让程序员明白该让系统做些什么。
有一种测试的方法是把测试留到最后才做，让客户去发现错误。
千万别这么做。
原先花费1块钱就可以改正的错误，到了这个时候，可能需要花费1000块钱才能解决。
这是软件开发的放大效应。
因为很多的工作已经基于这个错误建立了，开发人员也已经对这个错误没有映像了。
XP中有一个很重要的价值，叫做反馈（Feedback）。
KentBeck在ExtremeProgrammingExplained中有句话讲得非常好：
"乐观是编程的职业病，反馈则是其处方。
"从需求的识别，到根据需求构建的系统交付给客户，客户提出意见。
这就是一个反馈过程。
反馈过程所花费的时间越少越好。
接受测试就是解决客户反馈的一个有效的手段。
客户编写可重复的测试脚本，开发人员开发出的软件要经受这个测试脚本的考验。
这种的反馈速度是很高的，能够有效的解决反馈的问题。
因此，客户在要求实现需求时，同时也有义务提供相关的接收测试：
ifit'sworthhavingtheprogrammersbuildit,it'sworthknowingthattheygotitright.
一个有价值的功能一定是可测试的，如果不是，那么这个功能要么是没有价值，要么是尚未描述清楚。
要注意，这个测试必须是可重复的。
这是因为需求的易变性。
需求在不断变化，这就意味着代码在不断的变化。
因此，原先已经用接收测试证明过了的代码还需要再次证明。
这就要求测试是可以重复的。
大量的测试，甚至重复的测试引出了一个新的问题：
全凭手工进行测试会浪费大量的时间。
因此，易变的需求对测试提出了一个新的要求：
自动化测试。
只有自动化的进行测试，才可以完成如此大量的测试工作。
目前，最好的自动化测试工具，应该就是Xunit系列。
关于这方面的问题，大家可以参考相关的资料，这里我们不作深入的讨论。
接收测试最可能的一种形式就是自然语言的说明，外带一组的测试数据。
需要强调的一点是，这个测试数据一定要包括输入和输出。
这样才可以做出比较。
如果只有输入没有输出。
测试很可能就是白费劲。
所以，计
升级会员 