需求的实践（4）下

需求的实践（4）

http://www-900.ibm.com/developerWorks/i/c.gif

业务建模时期（下）

林星 (iamlinx@21cn.com)
2001 年 11 月

和上一篇的理论不同，这一篇文章更注重于实际，举出了在业务建模简短需要注意的一些原则和实践，每一条都来自于实践之中，也都有理论的支持。其中的很多内容更是经过多次的失败才总结出来的。相信大家如果能够理解这些原则和实践的某些方面，至少能够避免重蹈覆辙。

原则（Principle）
1. 谁才是"上帝"
<我们说客户是上帝，是因为客户的重要性，客户占有决定性的地位。可是在软件开发中，到底是谁有决定权呢？是出资方，还是项目经历，或是程序员？
职责不清，是业务建模失败的主要原因之一。我们可以很容易的看见客户把自己的要求用几句话高度浓缩之后扔给开发人员，或是开发人员按照自己的意思开发程序。难道说，客户和开发人员之间真的是"心有灵犀"，完全不用沟通的吗。
我在前文中已经提到过项目涉众和开发人员的权利和义务，我想这里还有必要再次强调。Scott W. Ambler说：
it is the role of project stakeholders to provide requirements, it is the role of developers to understand and implement them.
在我一次开发过程中，遇到过一个很有意思的涉众，他在他的需求分析中这样写："总之，要实现那种能够想到就能做到功能。"我想，这位涉众对我们的计算机工业有着非常远大的抱负。但我不得不客气的告诉他目前实现是不太现实的。
大家听了可能会觉得好笑，但是在我自己和客户打交道的生涯中，这种客户不在少数。现实就是这样，你要怎么做？是一笑之后，弃之不顾吗？我想大多数人会这样做。因为他的要求太荒唐了嘛。可是，你有没有花时间去了解一下，他这句荒唐的话背后代表了他的什么意思呢？我觉得，软件开发人员负有教育涉众的义务，你需要引导你的涉众，让他们说出自己的心声。我在看到这位涉众的这句话后，就花了一些时间去了解，其实呢，事情很简单，他就是想要一个能够定制报表模板的功能。而在项目结束后，我和这位涉众有幸再一次的合作，这时候，他已经成为了一个出色的客户方的项目领导者了。
这个例子说明了什么呢？涉众往往都是领域专家，对自己的工作有很深的认识，可是由于对软件开发的不了解，涉众往往表达不清，甚至表达不出自己的需求。这时候，就是体现你的功力的时候了。记住，象对待上帝一样对待你的客户。
2. 耐心是首要的
明白了谁是"上帝"，那就要耐心的对待上帝。学理工科的人，一般在逻辑思维上会比较好，可是对于涉众来说，可不一定是这样。我就遇到过一位做档案工作的涉众，在了解需求的时候，扯东扯西，含糊不清。明明一分钟前才否定的方法，下一分钟又提出来了。我觉得我的脾气应该是不错的，可到最后也几乎发飚。所幸，最后我终于撑了下来。我想，在经历过这件事情之后，我的耐心指数又会有一个很大的提高了吧。
我有一位同事的耐性是我所佩服的，在一个网站项目中，他负责系统分析。他整整花了三天的时间，和网站项目的负责人住在一起。最后系统分析出来之后，他的精神还不错，可是那位负责人已经快不行了。
当然，这只是个笑话，并不是去鼓励大家拼命。劳逸结合还是很重要的，身体是革命的本钱嘛。但是这告诉我们，如果缺少耐心，需求是很难成功的。例如在业务建模的讨论会上，你虽然规定了这次的会议讨论的是高阶需求，可是与会者总会时不时的争辩一些芝麻绿豆的小事儿。你怎么办？我相信这种情况是很普遍的。
耐心最后会仍会体现为沟通，只有耐心的沟通，你才能揭开需求的重重面纱。人的行为总是会受到思想的指导，如果你解不开涉众的心结，你就不可能了解他真正需要的。
我的一位项目涉众的表现很奇怪，她总是在不停的说一件事情："她要实现报表自动生成。"她的需求讲来讲去好像总脱不出这个范围，可是我从她那里几乎听不到别的东西了。这时候，我决定放弃了，我想从她哪里可能已经没有更多的资料了。但在我了解到她的工作中报表处理占用了她大量的时间之后，我改变了想法。在我花了一些时间帮她理清了报表处理的思路之后，她还在其他方面给了我很大的帮助。
3. 参与是重要的
XP方法的一个重要实践，就是提倡"现场客户"（on-site customer）。也就是说，客户应该随时和开发人员在一起，随时提供资料和做出决策。而这个客户，也必须领域专家，而且能够有权做出决策。
这种现场客户相信国内的软件组织多半还做不到。但是一定要往这方面努力。我认为，这种现场客户有两种人：一种是项目涉众，还有一种是行业专家。其实很多软件公司都会配备一些管理咨询人员，这些人就是行业专家。有数据统计说，目前广东省软件公司中的咨询人员和开发人员的比例达到了3：1。我觉得这是好事。项目涉众往往对自己的工作中的事务性部分有很深的认识，但是很难将之提升到一个理论的水平。这时候就需要一些行业专家来帮助了。让行业专家和项目涉众共同探讨，还能够激发项目涉众的灵感，想到原来他想不到的方面。这就是"潜在需求"的开发。
另一方面，参与还意味着需要项目涉众全身心的投入到业务建模的过程中来，要能够调动他们的积极性。因此呢，太复杂的流程会阻碍涉众的参与。所以，使用一些简单的、能够为客户所接受的工件（Artifact）来进行业务建模是很有必要的。我说过前面讨论的那些"主角"啊，"用例"啊，那是理论，是给开发人员看的，让开发人员心里有个底。你给涉众看这些，他们能懂吗？等他们了解了这套机制，恐怕黄花菜都凉了吧。
素材（User Story）、特性（Feature）、CRC卡片这些都是很不错的工件，既简单，又能够满足需要。
知识点：素材和特性都表述了用户的一个简单的要求，它能够在较短的时间内完成。素材是XP方法中的工件，特性是FDD方法中的工件。CRC是class、 responsibility、collaborator的缩写，它是一张分为三个部分的卡片，分别标记了类名，类的责任，以及类之间的合作关系。非常的贴近客户，甚至可以在做游戏的过程中完成卡片的填写，能带来很强的客户参与度。
4. 拥抱变化
我想这一点会遭到开发人员点一致指责。毕竟，需求变化是开发人员最讨厌的一件事了。不错，我也讨厌。可是，就像我们常说"哭不能解决问题"一样，讨厌能解决问题吗？拒绝客户的变更要求，要求客户在需求规格说明书上签字。这些做法只能是适得其反。没有任何正面的、积极的意义。
必要的需求变更管理是重要的。因为无休止、无控制的变化必然会造成资源的极大浪费。但从另一方面说，需求变更被接受的评判标准应该是"是否合理"，而不是"是否易于实现"。
需求变更要求我们的开发工作要迭代式进行，包括需求、设计、实现等阶段。这样才能将变更风险减到最小。这一点我们在讨论具体需求建模的时候会进一步讨论。
拥抱变化的更高一个层次是提前预估变化。制定一个可能的变化清单来记录可能出现的变化。最简单的例子就是一个企业在开发了进销存系统之后又希望能够开发财会系统与之相连。如果你能够预先留下伏笔，相信能够省不少力气。预估变化的另一种做法是通过使用模式。但是切记，模式的使用也不能过头。这些是题外话，如果有机会我会在其他的文章中集中讨论这方面的问题。
实践（Practice）
5. 建模会议
会议是业务建模最重要的手段。尽管会议在中国总是背负着一些骂名，但是只要组织得好，它是一种相当有效的沟通（Communication）手段。建模会议是一种大范围的会议，换句话说，所有的相关人员都应该参加会议。因为在业务建模时期，主要的目的就是建立对系统的高阶需求，这就要求众多项目涉众的共同参与，以保证需求的广泛性。所以呢，建模会议的规模是相当大的。出资方、高级经理、经理、直接用户、开发人员，各方各面的人都应该参加或是派代表参加建模会议。
如果大家有过参加大型会议的经验都知道，越是大型的会议，它的决策效率就越低。这是正常的。因为一个人的时候，不需要沟通，决策效率最高。等到两个人的时候，他们需要沟通的时间来进行决策。等到三个人的时候，这个沟通并达成一致的时间就更长。如果人数到了四个人、五个人甚至一二十个人，那么大部分的时间都会花在沟通上。更何况，人和人之间还有观念不同、利益之争。所以呢，为了保证会议的效率和效果，应该遵循一定的规则：
做好准备：如果你要开会，与会者连内容都不清楚，那你会怎么办。你必须首先花很多的时间来说明你开会的目的，是不是。要事先将会议的主题、议程连同会议通知发送给与会者，让他们先有个准备，会议开始时就能够迅速进入正题。
尽量邀请最多的人：我已经说过，如果建模会议不能够听取最广泛的意见，它就不是一个成功的会议。可是在现实中，这点往往难以做到。因为目标组织做为客户，往往都很"拽"，在没有充分认识会议的重要性之前，要做到全部到场简直就是不可能。而客观上也会有出差、休假、有要事等原因做不到这一点。这里，一方面你需要向目标组织的决策者阐明利害，让他们重视。另一方面，你也需要积极主动的邀请项目涉众参与。因为邀请所有的人是不可能的，所以就尽可能的多吧。
分出与会者的级别：我很喜欢那种有一个内圈、一个外圈的会议室。因为我邀请所有人是件无法做到的事情，所以我首先要保证核心人员能够全部到场，坐在内圈，然后才是次要的人员，坐在外圈。核心人员是和你的项目息息相关的那种人。比如，财务系统，财务主管就是核心人员。要保证核心人员全员到场，至于次要人员，越全越好。
从底层开始：中国人有个比较不好的习惯，就是老板说一的时候，他决不会说二。所以要先让底层先说话，然后才轮到中层，再到上层。开发人员是不说话的，他们要么听，要么引导大家说话。如果我们一开始就先让领导来训话一番，那底层的人也就不用再说什么了。
列举所有涉众的所有观点：首先要让大家能够对新的系统畅所欲言，然后把所有的观点都罗列在白板上。这里头可能会有一些观点会是非常荒唐的，但没有关系，尽管写上去。这是一个脑力激荡的过程，很容易产生出新的idea。主持的开发人员的主要工作就是引导和鼓励大家说出更多的想法，并记录下来。这里我们稍微离题一下，有人说中国人在会议上大都不愿意发表意见，我看在这种建模会议上不必过于担心此事。为什么呢，因为项目涉众不需要为他们的发言担任何的责任，说了，白说，白说谁不说。
将观点分类：想必你的项目涉众已经有些累了，创意也差不多了，你的白板估计也满了。但是你看看白板上的观点，有很多是重复的，有很多是类似的。所以你需要用逻辑的观念将这些观点归类整理。这个工作也可以由你引导大家去做。
确定优先级：对观点排出优先级也是非常重要的，它能够帮助你识别出重大的风险，并为你在制定迭代计划时提供指导。同样，这项工作也应该由项目涉众来确定。
调查主要业务逻辑：什么叫主要业务逻辑？包括了企业的主要业务流程、主要的业务规则、重大的算法。这些都是需要在一开始就十分明确的资料，需要在建模会议上了解清楚。当然，你不能对你的项目涉众说，"这个，接下来，大家谈一谈主要的业务逻辑吧。"下面的涉众一定摸不着头脑。你还是应该引导涉众，从涉众的话语中捕捉你需要的信息。
注意会议时间：人不是机器，是会累的。所以控制好会议的长度很关键。一般，这种会议会有四五个小时，根据统计，两个小时内的会议不会让人产生疲劳感。所以应该把会议分成几小段。另外，你还可以根据会议的进展来决定每小段会议参与的人数。因为，会议越往后，一些与会者就不太重要了。
避免细节：建模会议主要的目标是建立高阶需求。如果把过多的时间花在讨论鸡毛蒜皮的小事，那就会浪费大家的时间。而在此时调查需求细节是没有很大的意义的。因为你对很多的事情都还不了解，需要进一步的深入。这时候的细节对你并没有太多的帮助。
回避技术：我在一次建模会议的时候，遇到一位负责技术的涉众，他总是不停的询问系统的技术架构，推销他的设计理念。使得我不得不好几次重申，"技术问题我们会单独找时间谈。"我想，那位技术人员应该是有比较好的理念，也很希望能够表现一把，这点无可厚非。但是这个时候还不是讨论技术的时候，需求尚未明确，讨论技术实现不是本末倒置么？
做好记录：俗话说，好记性不如烂笔头。所以在会议上做好记录是非常关键的。因为这种会议的代价相当高昂，你的项目涉众不可能每天不干活，陪你开会的，就算他们肯，他们的老板也不肯。所以要充分利用好会议的成果，所以一个优秀的速记员绝对是必要的。另外，根据研究显示，如果使用录音机的话，会使得与会者心存芥蒂而不愿开口，所以，不要使用录音机。
6. 测试
在需求的初始阶段提到测试可能会觉得有些奇怪。凡是项目，总会有一个标准来考核是否成功。这里的测试指的是考核软件项目是否成功的一个"执行性目标"。
这个目标将会是软件开发最终要满足的条件，软件成功与否的判定标准。很多企业在信息化建设的时候没有一个比较明确的目标。所以在被问道这方面的问题时，他的答案往往是我的目标是建成企业的ERP系统，建设企业的信息化平台等空洞的话。这样的软件怎么开发？连结束的标准都没有。是费用用完结束呢，还是决策者说停就停了呢。目标应该有一个可以量化的标准。例如，开发物流系统的目的是为了缩短产品周转周期，降低库存；开发供应链系统是为了加强和供应商的联系，降低库存。这些和具体业务有关的指标都是可以通过细化，用多种分指标来度量的，所以是可以做到的。
我们把这种目标称为测试就是要提醒开发人员，要把满足这种目标当作最终的测试。你的软件做得再好，不是涉众想要的，又有什么用？这是很浅显的道理，可是在实际中，涉众方和开发方往往因为一些具体的因素看不到这一点。其实，这个目标在上一篇中我们也讲过，那时我们是把它叫做愿景、范围。在本质上是一样的。
这种"可执行性目标"可以使用一些因素来衡量：
7. 业务实体
业务实体（business entity）是企业中的一些起到关键作用的类别。客户、供应商、员工、订单、凭证，这种业务实体的例子可以举出很多很多。业务实体往往会成为一个很关键的因素，因为在系统中，角色操作业务实体的行为往往会分配给业务实体，例如"根据订单计算价格"会成为订单的一个行为。这样，工作流程的实现往往是多个业务实体相互合作完成的。所以业务实体设计的好坏会对系统有很大的影响作用。
业务实体设计的主要工作包括找出业务实体，确定业务实体的属性和行为。
要确定业务实体，首先必须确定角色，并从角色的行为找出业务实体。角色需要我们对目标组织进行讨论。以我个人的经验，寻找业务角色一般比较简单，但是要记住，一个人可能担任好几个的业务角色，这是经常发生的情况。从业务角色的行为，我们可以找出业务角色所处理的事物，这些就是我们所需要的业务实体。业务实体是一个单独的业务实体还是业务实体的一个属性是值得研究的。一个本该是属性的事物被判断成业务实体只是会带来一些开销，可是一个本该单独列出的业务实体却只是被判定为其它业务实体的一个属性就有可能会带来灾难性的后果，最大的可能是系统难以扩展。
在一个人力资源管理系统中，员工类可能是非常重要的一个业务实体，它可能有非常多的属性。而在其它的系统中，例如进销存，员工类只是起到一个记录、权限管理的作用罢了。再比如，在一些企业内部的自动化处理系统中，客户可能只是其它一些实体的属性，而以客户为中心的设计大行其道的现在，这种设计就有它的致命缺陷。
要确定业务实体的属性和行为，主要是要确定每个类（业务实体）要做的事情，属性则是为了能够更好的描述类和类要做的事情。利用CRC卡片是一个不错的办法。
CRC是"类"（class），"责任"（responsibility）及"辅助者"（collaborator）三者的简称，这些资料常呈现在一张卡片上。

类名称
责任1	责任1的辅助者1
责任2	责任2的辅助者2
…	…

通过制作这样的CRC卡片，可以比较容易的找出每个业务实体的行为（责任）和属性（辅助者）。您可能会问，为什么不直接找出属性和行为，而要多此一举呢。这个问题是我们一直在强调的。在建模阶段，我们面对的是可能对计算机技术完全不懂的涉众，所以，采用大家易于接受的方法，可以够保证需求的完整和正确。
8. 准备计划
目前在软件开发中，关于计划有两个极端的误解。
在有些软件组织中，一般不做计划，或是做一些笼统的、没什么用处的计划。一些开发人员认为，"做计划是虚的，还不如做些实际的事。"对于项目经理，或是对这种情况没有办法，或是发布的计划开发人员阳奉阴违，让计划成为一纸空文。项目执行中随意性极大，偏离方向的事情时有发生。
而在另外一些组织中，计划被视为重中之重，需要花费大量的时间、人力，做出来的计划可谓事无巨细，算无遗策。而写的出这种计划的项目经理也被视为高级人才。开发人员叹口气说，"写程序的不如写文档的。"可是在执行的时候，原来精密的计划往往漏洞百出，项目的进度一拖再拖。
我们所有人都知道那句明言：在软件开发中，要花90%的时间完成90%的项目，然后再用90%的时间完成剩下的10%的项目。为什么呢？计划不科学。
在管理学中，计划，也有叫规划的，定义是"为组织确定目标、实现目标的战略与手段、步骤、程序的过程。"打个比方说，我想要把一个箱子推倒一个地方，这个地方就是我的目的，我为了到达那里，我是不是要估计一下按什么路线推，要推多快。然后我就开始推，还要不时的和原先的计划比较比较，需不需要调整路线和速度。这个估计就是计划。
计划的目标不是消除错误，而是让所有错误变成一堆经过细心规划后的小错误。研究四种设计方式后，最终放弃三种，最多不过是三个小错误而已，但因没有做好设计而将程序重写三遍，却可能造成三个大错误。
然而为什么会出现上面提到的两个极端呢？第一种情况其实是软件行业最早期的一种形态，没有计划，资源分配混乱，软件的开发过程处于混沌、无序、自发的状态。项目的成功全凭运气和项目成员的个人能力。而第二种情况其实一个前进了的形态，最典型的代表就是我们之前提到过的瀑布模型。那这种考虑周密的计划为什么也容易失败呢？很简单，你认为你考虑周密，可是实际上却不一定。我就见过标榜自己考虑周详的计划中排出的时间表是一周7天的。看来他一开始就没打算让开发人员休息了。计划是对未来的一种估计，哪一个人能够准确的说出6个月后的情况，恐怕没人能行吧。9月11号之前，有几个人能料到那天会发生这么大的事情？那你凭什么推算出半年，甚至一年后的事情呢？另外，你是不是真的非常了解你的开发人员，以至于有信心代替他们制定计划呢？
有人说，计划没有变化快。这句话说得很对，它提醒我们，没有计划是不行的，不具备可执行性的计划也是不行的。计划不是拿来炫耀的，是要用来执行的。我们定计划的时候，可以没有华丽的词藻，美好的构想。但是我们不能没有一些要素：

什么(WHAT)：按顺序列出达到目标所需完成的工作；
何时(WHEN)：完成工作所需要的时间；
做到的程度(HOW-WELL)：要完成的工作以何标准来度量；
资源(RESOURCES)：完成工作需要的人员/资金等；
谁(WHO)：由谁负责完成任务。

但是我们仍然逃不开现实和计划的背离的问题。我们虽然对预计一年后的事情把握不大，对把握开发人员在想什么把握也不大。但是如果你自己想想自己两个星期后的事情应该还是能够猜的八九不离十吧。这就引出了迭代的概念。一个项目由几个甚至几十个的迭代周期组成，每个迭代周期都是比较容易估算并制定计划的。这就是迭代的思想，也是软件工程技术的一个大飞跃。说到这里，我又要吊大家的胃口了。关于具体制定迭代计划的讨论，我们会留到下一章节讨论细节需求建模的时候再谈。
9. 培训