软件工程实践者的思想(PDF格式)-第7部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
接下来咨询公司会与我们的客户一起做业务建模，然
后再做业务到需求的映射，再抽取需求并完成需求建模。
他们做业务建模的时候，可能使用一些客户业务范畴内的
符号和标识；而在做需求建模时，则需要使用一些软件行
…45
…………………………………………………………Page 50……………………………………………………………
第 4 章 流于形式的沟通
业中（ 的设计和分析人员） 习惯的符号和标识。
这些符号和标识也有个专用名称，“En。。。 这个叫模型
语言（ML） 。”他们无时无刻不在向你展现他们的专业（这已
经是他们还存在的唯一原因了） 。
如果他们更加专业，他们会告诉你他们用的是 UML 。
向你介绍这个名词的时候，他们的眼镜或者眼睛里通常将
大放异彩。
①
UML 是模型世界里的世界语 。
到现在为止，你应该看到，咨询公司除了把问题搞得
更加复杂之外，他们仍然需要面对最直接的问题：与客户
如何交流？
他们的解决之道是模型语言。
有什么差别吗？
程序员不能要求客户会 C Language ，难道需求分析师
们就能要求客户会 Modeling Language 吗？！
2。 项目文档真的可以用甲骨文来写
独 孤 木 （http：//javaworld。。tw/） 曾 经 在 一 篇
《UML； OOAD and RUP 》中讨论到 UML 实际应用中的问
题。其中的两个问题是：
① 现实的情况未必如此。但UML 这个名词起码显示了它本源性的
期望：Unified Modeling Language（ 统一模型语言） 。
…46
…………………………………………………………Page 51……………………………………………………………
『大道至简』
） “大部分的使用者，以及客户的信息人员，其实
并没有足够的能力，来确认这些文件（User Case）
的正确性与完整性。”
） “除了客户不了解UML ，OOAD 跟 RUP 以外，
另外一个更糟糕的现象就是 project team 里面
的人也不懂。”
这实在是很有趣的事。
看来在一些情况下，在项目中使用 UML 只是完全不
懂的老板，以及什么都懂的博士的主意，而真实的场景中
去做事的那些客户与项目成员，其实是未见得就能用好
UML 的。
仅以 UML 的 User Case 来说，由“用例图”和“用
例规约”组成。规约跟我们写的需求说明书差不多，不过
更加细节罢了，而且还有一套相应的方法论来阐述如果去
实作。图则很简单，就是几个图形符号来描述系统边界和
角色关系。
显然甲骨文也能描述范围与关系。例如甲骨文中的
① ，这个边界就定义
“家”这个字，就是上有房子下有猪
得很好；在古文中，“三”通常是泛指，跟UML 图中的线
条上标注的那个“* ”是同义的，而甲骨文中“众”这个
① 至于是“内有猪”还是“下有猪”的问题，不是我们要争论的。
有些考古学家根据甲骨文的象形来认为古人与家猪是杂居的，但
我想那时的猪可能还比较野性，因此这种可能性还是小些。
…47
…………………………………………………………Page 52……………………………………………………………
第 4 章 流于形式的沟通
字，就是日字下立有三个人，也就是在同一个日头下做事
的很多人即为“众”，这个关系也描述得很确切。
所以只要你运用得法，甲骨文一样可以用来画用例图
和写用例规约。同样的，只要约定一套“语法”，你同样
可以用甲骨文来做活动图、类图、构件图……以及这些图
相关的规约。相比来说，古巴比伦人使用的楔形文字“象
形性”差一些，因此我不建议用它来画用例图。
既然甲骨文可以用来做为一种模型语言（ 同时它也是
一种文字和口头的语言） ，那么，如果你的项目中面对的
对象是商周文化的考古学家，以及你的项目组都由精通这
种语言的成员构成，这时你就可以用甲骨文来做项目文
档，以及画各种模型图例。
你要明白，要让考古学家看懂用例图，难度远大于看
懂甲骨文。与其要求他们学一种语言，不如使用他们那个
世界的通用语（ 当然，前提你的项目组也懂得这种语言） 。
在韩愈的《答陈生书》中，他因自己不会“速化之术”，
所以说陈生是“求道于盲”。然而他用了一个不恰当的比
喻：要知道盲人并非不知道路如何走，只是他不能象常人
一样描述他所知道的路。因此“问道于盲”是没有错误的，
真正错误的是你睁着眼睛问。
我们需要在正常人与盲人之间建立一种沟通的方式，
既然盲人不能睁开眼睛，那么你就闭上眼睛好了。
…48
…………………………………………………………Page 53……………………………………………………………
『大道至简』
UML 图在一些客户眼里无异于盲人的世界，如果需
要向他们做需求调研，你只能使用一种这些客户能够理解
和接受的方式，例如表格、流程图以及……更深入的交谈。
你要确认你的沟通方式是否有效，而不是去追求这种
方式是不是 UML ，以及用 UML 表达得是否正确。——客
户是因为他认为你理解了他们的需求，而在“需求确认书”
上签字，而不是因为你的 UML 画得是否精准。
现在来思考：为什么非要让客户看UML 图呢？如果
有能够满足“极限编程（XP） ”所要求的“现场客户① ”，那
当然可以不画用例图；相反，如果客户雇了一个专家组来
评审需求，那么你就老老实实地画用例图好了。
需要留意的是，专家组还要一种方式与客户沟通，这
有可能不是 UML 。——当然，客户愿意增加沟通成本，
那是他们的事。
一旦源头确定，你就可以接下来约定在项目组中要使
用的沟通方式。愚公——这个伟大的项目经理——所使用
的“聚室而谋曰”，就是很好的沟通方式。当然，如果客
户精通 UML ，那么我想愚公采用的项目沟通方式将会是
“聚室而论UML ”。我想一定会这样，因为愚公是很懂得
沟通的、伟大的项目经理。
① 这是极限编程的特征之一，指的是要求客户可以在程序员开发
的第一现场，随时可以向程序员确认完成功能的有效性，以及修
正需求或者先前的需求描述。
…49
…………………………………………………………Page 54……………………………………………………………
第 4 章 流于形式的沟通
3。 最简沟通
在 D 项目中，我向我的项目组员提出在需求阶段与
客户的沟通计划。这个计划只有三条：
） 在一个月中，只能跟客户作三次联系；
） 三次联系中，最多只能有一次面谈的机会；
） 一个月后，提交全部的需求调研报告、需求分析
和关于该项目的远景规划。
D 项目并不大，所以从主观上来讲，客户（代表） 并不
会为这个项目投入太多的精力。重要的是，我们在前期交
涉中已经发现：这个客户代表为大量其它的项目和工作所
困扰，他不会有时间来处理我们的问题。因此，减少沟通
和保障沟通质量的问题就显得非常突出。
在大多数的项目中，这样的问题都是存在的。真正能
满足极限编程（XP）所提出的“现场客户”的情形并不经常
出现。即使能将程序员送到客户现场中去，沟通问题仍然
是不可避免的。
因此在 D 项目中我提出了“最简沟通”。
我们开始在网络上查看相关的软件系统的特征以抽
取客户所关注的内容；了解该客户的公司、经营理念、组
织结构形式以及工作模式；了解同类公司的成功经验和优
秀的管理模式，以及客户的竞争对手在做什么和在关心什
么……
最后，我们开始综合以下两个方面的因素：
…50
…………………………………………………………Page 55……………………………………………………………
『大道至简』
） 客户在公司层面的外在表现、内部机制和运营管
理手段。
） 客户在项目中既已明确的需求和可能发生的需
求，以及客户围绕其公司行为（和方向）所提出的
需求。
这样我们就了解了客户项目中所有会产生需求的信
息点。
我们开始设计提问，每一个提问涵盖尽可能多的信息
点，尽可能的具有发散性以便形成更多的推论和假设。
我们把这些做成项目概要用 mail 提交给客户，并在
第二天电话回访他。他以口头的形式回复了这封 mail ，这
让我们尽可能地得到了项目在方向上修正。
我们确定了项目的实际目标，以及远期的方向。接下
来就是设计需求条目。
客户已经先期提供了一些关于项目的文档、报表和工
作数据。因此基于这些数据的需求分析，将是下一个沟通
前所进行的最坚苦的工作。项目组员被要求：
） 分析用户的每一个表格，以构建基础数据库；
） 分析每一条数据的含义以确定它的上下限，以及
数据间的相关性；
） 从工作文档中去了解客户的组织机构及其相互
关系，同时确定了每一类使用该系统的角色；
） 从报表中去了解客户关注的数据信息，以及被他
们所忽略掉的数据信息。
我们从数百条的需求条目中，整理出系统结构和模
…51
…………………………………………………………Page 56……………………………………………………………
第 4 章 流于形式的沟通
块，需求条目被映射到各个模块。我们很快画出了模块间
的相互关系图，并通过这个图分析了数据交叉关系，设计
了相应的数据索引并增加了一些新的关系性数据。
我们对用户角色、原始数据和系统结构进行了梳理之
后，我们花了很短的时间实现了第一个系统模型。当然，
很多的功能项目，我们都只是简单 show a dialog 。但我们
优化了每一个操作流程，以保证不同的用户（角色）在使用
时都尽可能流畅。
这一次的沟通我们使用了面对面的模式。我们很庆幸
的得到了与这个系统的每一类用户（角色）接触的机会，而
正好我们有一个模型，我们便让他们来操作并提出意见。
这一次我们终于有了一份详尽的的调研报告。
接下来的分析设计是顺理成章的事。我们在一个月后
完成了这个项目的需求分析报告，以及在这个分析上的一
些框架型的设计。还有，一个被用户所接受的原始模型。
——尽管，第三次的沟通中还发现了一些问题。但我
们终于有了一个好的开端。
应该清楚的是，保障每一次沟通的有效性都是最重要
的事。沟通不是打电话或者请客户吃饭那么简单的事。你
得到的每一次沟通机会，都是向客户了解更深层次的需求
的机会，因此最好在见到客户之前，你就已经设计了所有
的问题和提问方式。
吃饭并不是有效的沟通。大多数时候，那将以酒醉收
…52
…………………………
