解决需求建模中的常见难题
为了能以灵巧的方式进行需求建模，需要具备一定的条件。但不幸的是，很多项目组并不具备。需求建模工作常常被你所处的环境所影响和破坏，一般是组织所奉行的文化不利于有效的软件开发或者项目甲方不清楚他们的决定所带来的影响。在这一节中，我列出了一些在需求建模中多数项目组经常碰到的问题，并讨论了可能的解决方案。这些常见的难题如下：
难于接近项目甲方 （Limited access to project stakeholders）
项目甲方分散在各处 （Geographically dispersed project stakeholders）
项目甲方不知道他们想要得到的是什么（Project stakeholders do not know what they want）
项目甲方改变主意（Project stakeholders change their minds）
优先级冲突（Conflicting priorities）
过多的项目甲方想参与进来（Too many project stakeholders want to participate）
项目甲方指定了技术方案（Project stakeholders prescribe technology solutions）
项目甲方墨守成规（Project stakeholders are unable to see beyond the current
situation）
项目甲方含糊其词（Project stakeholders are afraid to be pinned down）
项目甲方不懂建模artifacts（Project stakeholders don’t understand modeling
artifacts）
开发人员不懂业务（Developers don’t understand the problem domain）
项目甲方过于集中于某一类需求（Project stakeholders are overly focused on one type
of requirement）
项目甲方对于需求的确定有许多繁文缛节（Project stakeholders require significant
formality regarding requirements）
开发人员不懂需求（Developers don’t understand the requirement）
难题 #1 难于接近项目甲方
这是一个经常发生的问题。由于某些原因，高层管理部门有时愿意投资数百万美金进行一项系统的开发，但却不愿意或不能指派一些合适的人选来告诉你这个系统需要干什么。“为了项目的成功，开发人员需要得到项目甲方的积极支持”，项目甲方常常严重缺乏对这一点的认识，他们不清楚软件是如何开发的；或者他们一直以来都是以这种方式工作（译者：即不委派人员协助开发），而不知道有更好的方法。
要解决这个问题，首先你需要与项目甲方进行沟通，告诉他们你需要同他们紧密地协作，他们必须投入宝贵的时间与你一起工作。有时可能没有可以确认的用户，这种情况通常是当你在开发一个零售产品或一个供你（潜在）客户使用的基于web的新系统时出现，在这种情况下你需要找一些人来代替。一个较好的方法是选择你的市场人员或销售人员，因为他们熟悉客户，他们脑中对你的系统会有一个大致的轮廓。或者直接找一些可能的用户（你可以自己从用户的角度去想这个系统应该提供什么；或者从外面聘请一些人，他们应该是你的产品所面向的用户）。根据我的经验你肯定可以找到能为你的系统提供需求的人，曾经有好几次我都被告之不可能提供人员与我一起工作（但最终都找到了[译注]）。记住你的项目甲方不仅仅是系统的直接使用者，你应该认识到你是在冒风险如果没有任何直接使用者参与到你的软件开发中。
难题 #2 项目甲方分散在各处
对于上一个问题，还有一个原因就是你的项目甲方与你的开发组不在同一个地点，使得你没办法与他们很好协作。这种情况常发生在比较大的组织内，一些项目外包给其他组织；或者在一个由多个组织合作开发的项目也会出现这个问题。解决的办法有几种。一是，想办法将开发小组和项目甲方集中到一个地方。正如我在《交流》一文中所提到的，面对面的交流是最直接有效的方式。如果做不到这一点，下一个最好的做法就是让项目甲方和开发人员在一段时间内在一起，另外的时间通过其它手段进行交流（在《交流》一文中，我提出了几种可选择的方式，如电子邮件，视频会议，和一些支持协作建模的工具）。我曾经参加一个由300人组成的项目组，项目甲方在每三个星期中用一个星期同我们的开发人员一起工作，而其它两个星期通过电子邮件和电话联系，这种方式运行得相当好。如果上两种方法都不适用，那下一种较好的方法就是让开发人员到项目甲方所在的地，与之共同工作。我在好几个项目中成功地使用了这种方法。但要注意这对那些出差的人来说非常艰苦的（我就经常出差，幸运的是我喜欢旅行）。还有一种方式就是让业务分析师先到项目甲方那里去了解他们的需求，然后再让他们回来与开发人员定义需求。当然，你可以根据你的情况组合使用这几种方法。
难题 #3 项目甲方不知道他们想要得到的是什么
这就是你什么要花时间进行建模的原因。通过建模来探寻他们想得到什么以及哪些对他们而言是重要的。现今的商业非常复杂，甲方经常意识到有问题需要解决或存在着改进的机会，但他们不知道如何去做。这是十分正常的。你曾经重新装修过房间，或者重新布置过家具吗？你知道你想有一个更好的居住环境，但却常常措手无策。可能你会去查阅一下杂志上的图片，参观一个家具店，或者去朋友家看看他们是如何摆设的。如果你对构想一个居室的布置感到困难，可想而知，你的项目甲方要确定一个什么样系统是多么的不容易。
这是一个正常的现象，我们从接受这个观点开始。如果你的用户不能确切地告诉你他们想得到的是一个什么样的东西，告诉他们这没有关系。他们现在所需要做的仅是告诉你他们想让你干什么。同重新装修房间类似，可能你现在还没有一个整体的布局构想，但你可以从着重于安装一个书架开始。着眼于他们对系统中有最清楚想法的一个方面，对这个小部分建模，然后实现一个可运作的系统（遵循用代码进行验证这一做法）。他们就可以实地操作，向你提供反馈。如果他们甚至连一小点的需求都提不出来，就好像你完全不确定是否会有书在房间中，那么就从调查他们现在的工作方式开始。通过对现有工作流程的建模，你会进一步了解他们的工作，从中看到他们可能需要的改进以及最差的环节在哪，由此就可以向他们建议。
难题 #4 项目甲方改变主意
项目甲方也是人，是人就会改变主意。你把家具按想象中的位置摆好，但当你回过头来端详一番，可能觉得这样并没有达到想象中的效果。象布置家具这样简单的事你都会改变主意，何况那复杂的系统呢。项目甲方百分之百会改变主意。
要解决这个问题，你首先得接受这个事实，拥抱变化。不管发生了什么变化，都是与建模有关的，因为你会发现要么是他们开始时不清楚他们自己的需求（参见上一个讨论），要么就是你没有弄明白他们所想要的。当你同项目甲方一同讨论时，你应该从他们的角度以他们的语言达成一致的认识，这会确保你没有作出另外的假设，而且会提高谈话的质量。我曾经参加过为一个电子商务系统开发管理系统的项目，在这个项目中我们得出了一个公正而准确的需求。第一个星期，我们提供了两个网页：一个是主页，上面包含了关键功能的菜单项；另一个实现了一个高优先级的功能。我们完全按照他们所要求的来做。当我们想他们演示以后，他们意识到最初的想法不好，然后要求我们重新构造。变化来了。最后，当用户对系统中某一部分的想法发生改变时，你会发现实际上是由于他们没有弄清楚需要解决的问题，这意味着需要同他们开一个关于构想的会议（参见需求建模会议的相关内容）；或者是由于某个有不同构想的甲方的意见没有被正确处理。
难题 #5 优先级冲突
你所建造的系统必须反映多方面的需要，包括直接使用者，高级管理层，你的实施人员，支持人员，以及维护人员。各方面都有不同的优先级要求和目标，即使是同一类中的不同个体也是如此。这就会出现冲突，有冲突就必须进行处理。
再一次，首先是接受这种现象。系统的优先级需要协商而定。注意到我所说的吗？你需要定义你系统的优先级。每个项目甲方心目中都有一个自己的优先级，这很好，但你的目的是要决定整个系统的优先级，这往往不同于他们个人的想法。一种方法是实行代表制：指定一些代表，他们每人都能代表某一大组的项目甲方，让他们来协商作出决定。你可能想自己来支持这个协商工作，但这项工作非常耗费时间，而且有可能其结果会导致项目甲方与你和你的项目组之间形成敌意（费力不讨好）。我建议尽可能地让别的人来做这个苦差事。如果协商没有结果，你最后一招只有寻求金牌业主（就是付钱的人）的帮助，要求他们进行仲裁。在我曾经参与的一个面向国际的电子商务系统的开发中，有些甲方设想该系统一开始就能够支持多种语言（美国英语、英国英语、西班牙语、德语、日语和粤语）。这样，唯有我们能服务于每个主要的市场。另外一些甲方想让这个系统运行迅速，而仅愿意支持美国英语，因为他们觉得这对于客户来说是可以接受的（你的项目甲方也有笨的时候）。我们不能对此达成一致，于是我将这个问题向上反应。最后的决定是第一个版本仅支持美国英语，然后在确实需要其它语种时再进行需求评估。
难题 #6 过多的项目甲方想参与进来
有时你会发现想参与的人太多了。这种情况通常发生在项目的初期，大家都抱有浓厚的兴趣，或者你的项目与个人的业绩相关，很多人都想沾光。最好的办法就是感谢每个人的热情，让他们明白你现在得到的帮助已经足够了，而且你已经挑选了一部分人，告诉他们以后当你需要他们的帮助时会同他们联系。当我处于这种境地时，我会尽量挑选最合适的人选，那些能提供最好的见解而且愿意花时间同我的开发组共同工作的人。同时，我不会疏远那些现在没有加入进来的人，有可能在某个时候他们某方面特殊的专长正是我们所需要的，或者可以通过他们来宣传我们的工作。一般来说，一个积极参与的项目甲方会对这个系统越来越熟悉，但同时盲点也在增加，而越来越难发觉一些潜在的问题。因此保持对合格的外部人员的联系是颇有价值的。
难题 #7 项目甲方指定了技术方案
我曾经遇到过这样的情形，一个项目甲方人员说我们需要使用某种技术，比如某个版本的Oracle。而此时我真正需要的是从他们那里得到行为类型的需求，比如“客户能够将钱存入一个账号中”。确实，技术方面的约束是肯定存在，也是开发组应该知道的，但此时有可能他们只是想告诉你Oracle是他们组织的数据库标准这样一个事实。很多时候，真正的问题在于你的项目甲方难于区分系统的需求和系统架构的选择，有可能这个人是技术出身而喜欢讨论技术方面的问题，或者只是由于他们刚好从最近
一期的商业周刊上读到一则成功使用Oracle数据库的文章。
最好的解决办法是定义好项目甲方的权责，制定一个适当的工作框架，以使他们能将注意力集中在定义系统需要做什么这个问题上，而开发人员则集中精力在系统如何做这个问题上。另外一种策略就是问他们“如果你已经有了适当的技术，哪它还那么重要吗？”或者“你想如何使用这项技术”这类问题来识别实际的需求。
难题 #8 项目甲方墨守成规
许多组织中，人们多年来使用同样的工具以同样的方式工作着。他们可能从来没见过另外的方式或从来也没想过。他们对改变怀有恐惧感，可能是他们害怕没有所需的技能来适应新的系统，也可能是担心会被新系统取代。出于这些担忧，他们会按照适合他们的方式给出需求。
解决这个问题最好的办法是同他们讨论目前的情形，辨别哪种方式运作良好而哪种方式不好，以及向他们讲明当前形势正在如何地发生着变化。假设在SWA
Online这个项目中，某个甲方人员在确定需求时告诉你任何一个定单最多只能订购十样物品。什么？明显是因循守旧。如果你就此详细地询问，很快就会得知他们目前的运作流程是客户邮寄或传真他们的定单到公司，再由客户服务代表进行定单信息的输入。每张定单表格只有十行，而且得知以前的绿屏幕（译注：即单显）系统也被设计为每屏仅允许输入十条信息。
其实不必问这么多，你应该指出填写纸张表格的定单是造成这个限制的真正原因，因为纸张的大小是有限的，然后向他演示你可以很轻易地实现在一条定单订购多于十样物品。一会儿之后，他就会认识到这完全是可能的，特别是当你向他展示其竞争对手没有这项限制时，就更会消除他的疑虑。
难题 #9 项目甲方含糊其词
有时因为项目甲方不愿意做出具体的答复，给出的需求非常含糊。这主要是由于他们害怕犯错误。他们以前的经验告诉他们重新实现一个改变的需求要付出昂贵的代价，需求事先都必须得弄正确。这基本上是做不到的，由此他们就选择了含糊其词，在某些问题上不表态。
“你已经做好准备迎接变化；你的开发方式是迭代式的、递增式的，这样能降低变化所带来的开销；你的目标是为他们提供最好的解决方案，而这意味着有些需求会随时间的过去而演化的”，要解决这个问题你就应该给项目甲方留下这样的印象。言行一致，在实施过程中能够接受和支持变化。日久见人心，随着时间的推移，你项目的甲方就会认识到他们可以现在做出决定，日后如果需要可以安全地改变。当你在每个迭代过程完后交付软件，你的甲方看见软件随着他们对系统理解的不断发展而发展时，害怕表态的疑虑很快就会消去。
难题 #10 项目甲方不懂建模artifacts
绝大多数的项目甲方，可能还有绝大多数的开发人员，都没有正式地学习过建模。很有可能他们不知道如何去看一个UML活动图、或一个数据模型、或一个UML使用案例，因为这不是他们的日常工作所需的技能。问题在于他们需要懂得你所作的这些artifacts，这样才能明白你所表达的意思，才能积极地加入到建模得工作中来。
首先是确定你的项目甲方需要懂得哪些artifacts，这样才能知道你应该集中精力在哪。对此使用最简单的工具这个做法可以帮助你。如果你争取采用诸如索引卡片、纸张和白板这类简单的工具建模，你就降低了甲方的学习曲线。第二步就是教给他们这些技术，我倾向于Just
In
Time（JIT）这种方式。即当我们在一个建模会议中第一次需要某项技术时，我会先大致地讲解一下，然后就我们所讨论的问题深入讨论如何应用该项技术。在一个项目的开始，我会概括地讲一下一些常用的建模技术，使他们对将要进行得工作有个感觉。同时也会给他们提供一些读物，一般是The
Object Primer 2/e (Ambler,
2001a)，其中详细地讲述了这些技术（译注：随时不忘作广告J）。使用这种方法，我教过那些从来没有建过模的甲方，象CRC和基本用户界面原型这两种简单工具，每个都用了不到十五分钟。对于那些复杂一点的技术，如流程图或类模型，需要一段时间来慢慢学习。第三步是尽可能快地基于模型生成可运行的软件并得到具体的反馈。当这些模型变为现实时，你的项目甲方一下就能看到他们写在粘贴纸上的基本用户界面模型变为了一个HTML页面，CRC卡片上描写客户的概念反应在软件的功能中。
难题 #11 开发人员不懂业务
一个普遍的问题是在项目的开始阶段开发人员不懂甲方的业务，使得与甲方人员交流起来比较困难。这是自然的，就像建模不是甲方人员的日常工作一样，开发人员也不是一个熟悉甲方业务的专家。这就是为什么需要两组的人都积极地参与需求建模工作，就如三人行必有我师这条原则指出的，每个人都能为之做出贡献。开发人员需要花时间去学习相应的业务，虽然他们随着项目的进展最终能学会，但我们常常发现这样太慢，必须要通过某种方式来加快这个进程。多年以前，我工作过的一家公司，他们确实地理解到开发人员学懂业务的重要性。在前三天中，我和另外一个新来的员工都是由甲方的副总裁进行培训。这是一个数十亿美元的金融机构，他们向我们描述了他们各部门的基本情况。每个副总裁每次都要花几个小时对两个（是的，两个）开发人员进行培训。如果你的组织不是这样的，你可以找几本与该业务相关的书籍看一下，介绍性的大专院校的教程比较理想。我认为开发人员应该广泛地阅读。我经常阅读财富杂志、经济家、Utne
Reader和国家地理杂志，而不仅仅局限于The Communications of The ACM和IEEE
Software这类有关软件开发的刊物。这使得我有广阔的知识背景，对我在进入一个新的环境时帮助很大。
难题 #12 项目甲方过于集中于某一类需求
有时你会发现甲方虽然提供了一大堆的需求给你，可能以使用案例或使用情景的形式，但对于非行为类型（或行为类型）的需求来说还不足够。这个迹象就说明没有找对人，或者你遗漏了某个方面的人比如操作人员和支持人员。因此，需要重新考虑需求建模中甲方人员的组合。
难题 #13 项目甲方对于需求有许多繁文缛节
许多甲方认为正式（计划好的会议、需要他们审查和签字的正式需求文档和正式的讲演）就是职业化的表现。我认为这是我们的软件产业在过去的两个时代中所形成的软件流程理念，我们的甲方不知道有另一条路可走。这同样也是由于信息界与商业界间的紧张关系所造成的。我们的甲方不信任我们，他们坚持要履行这许多的繁文缛节，以此获得对他们并不熟悉的开发流程的更多控制。
你需要同他们进行沟通，向他们讲解有另外一种更灵巧的方式，让他们明白现在这种方式所带来的问题（开发进度缓慢、没有足够的机会去理解需求、超支的费用…
…）。问问甲方，他们真正的目的是什么。是开发一个可运行的系统呢，还是开会和制造文档？如果是前者，肯定是它，然后问他们为什么要坚持这些手续。不要接受他们的第一个回答，应该刨根问底，找出真正的原因。如我在Agile
Documentation
一问所指出的，他们不相信我们，这是他们拴住我们手脚的一种方式。接下来就是要他们相信你，一般来说比较困难，这主要看他们在以前的软件开发中经历了什么样痛苦。以及要求他们去掉一些手续。然后你就要以事实证明（即交付软件），向他们展示没有很多的手续一样可以取得成功。通过循环的迭代过程减少手续，直到你的软件能够有效地工作时交付给用户。
难题 #14 开发人员不懂需求
“开发人员弄不懂由业务分析师和用户建立的需求artifacts”，在没有采用灵巧建模的项目组中，时常听到这样抱怨。幸运的是，在采用了灵巧建模的项目组中你不会碰到这个问题。首先，熟悉你的模型和熟悉你的工具这两条原则告诉你，开发人员应该对所使用的artifacts和常用的工具受过足够的培训和有足够的经验。如果没有，那么他们就必须接受培训和指导。第二，增量改变这条原则建议你将一个系统分为许多小部分，每次针对一小块，一个一个地建立，这也反映在小增量建模这个做法中。这避免了开发人员一次需要理解太多的需求，陷入一个大的需求文档之中。第三，项目甲方的积极参与这一做法和三人行必有我师这一原则保证了你的项目甲方能够向开发人员解释他们的需求，而开发人员愿意这样做。第四，创建简单内容和简单地建模这两条原则确保了你的需求模型做到尽可能的易于理解。
技巧
以下所列出的技巧能够帮助你提高为系统的需求建模的效率，它们也遵循灵巧建模的做法：
需求的收集贯穿于整个项目过程中。大部分项目均是如此。虽然大部分的需求工作是在项目的开始阶段，但很有可能你仍需要回到需求上来，直到代码完全冻结时。记住拥抱变化这条原则。
解释技术。每个参与的人员，包括项目甲方，都应该对建模的技术有个基本的理解。如果他们从来没听说过CRC卡片？花几分钟解释一下它们是什么，你为什么要用这项技术，以及建立它。如果你的项目甲方不能够使用正确的建模技术，那么甲方的积极参与也就无从说起。
使用用户的术语。不要强迫项目甲方使用你的软件开发方面的术语。这个系统是为他们而建造的，因此应该是你使用他们的术语来为系统建模。
乐在其中。建模可以不是一项艰涩的工作。事实上，你完全可以寓模于乐。讲些笑话，轻松一下。人处于轻快的环境中，可以更加有效率。
取得管理层的支持。为需求模型投入时间，特别是本文所讲的以使用为中心的设计技术，对于许多组织来说是一个新的概念。项目甲方积极地参与建模工作，这也许对大多数的组织来说是根本文化的改变。任何涉及到文化改变的事情，没有高级管理层的支持是不可能取得成功的。你需要取得你的信息部门以及用户那边管理层的支持。
采取宽度优先的方法。我的经验是最好在开始时勾勒出系统的轮廓，尽可能大地了解系统的面貌，然后再集中在某一个小的方面。这样做，你很快会对系统的整体有个了解，选择好切入点。
已有的文档是需求的很好来源。象政策手册、政府法律、甚至于学校的教科书这些已有的文档都是很好的需求来源。在我曾经参与的一个电子商务系统中，我第一件事就是找到一本关于电子商务方面的书来确定一些基本的需求（比如支持信用卡的交易）。记住复用已有的资源这一做法。
记住今天的用户就是明天的分析者和以后的开发者。三人行必有我师这条原则其实也就意味着你的项目甲方在参与软件项目的同时也在学习软件开发的基本技能。常常会看见一个用户先成为一个业务分析者，而后通过学习更多的开发技能而成为一个真正的开发者。因为灵巧软件开发比以往的软件开发方法更加强调项目甲方的参与，这种现象会更经常地发生。注视这些愿意进行这种转变的人，给予他们帮助。有可能以后有人帮助你建立业务方面的技能，而帮助你跳出技术的世界。
参考资料及推荐读物
参见http://www.agilemodeling.com/essays/references.htm.
脚注
[1]
这个例子揭示了使用案例的常见问题。对于单一的一个迭代过程，它们通常过粗。你可以让一个使用案例在多个迭代过程中完成，从项目管理的角度来说这不是很好；或者你可以将其重构为更小的一组使用案例，这从建模的角度来说不好。
译注
Artifact -- 在一个软件项目中制造或使用的最终或中间产品。
它用于记录或传达项目的信息。它可以是文档、模型
或者模型元素。
本文翻译征得原作者Scott W.Ambler先生的同意，在此表示感谢。
|
|