难题 #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 -- 在一个软件项目中制造或使用的最终或中间产品。
它用于记录或传达项目的信息。它可以是文档、模型
或者模型元素。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
