Dom4j操作XML

我们总是要先接触客户的，是的，如果不这样，我们将无法确知要做什么。作为开发人员，可能更希望客户能学习或者精通C语言，这样客户就知道开发人员正在做什么，以及有多么地勤劳。或者，这样的客户还能以C语言的方式告诉开发人员他们究竟想要什么。然而要求客户学习C语言明显是自杀式的行为。没有客户会笨到愿意用C语言来描述他们的需求。C语言是程序员与计算机交流的语言，而不是他与客户交流的语言。程序员面对的是计算机，但计算机不是客户。因此在前面所提到的R模型中，开发人员最好不要直接面对客户。项目经理有这样的一种优势：他可以不用了解C语言，也可以用一种非C的语言来与客户交流(比如说汉语)。要深入项目的需求阶段的项目经理或者调研人员，被要求深谙项目所涉的业务。但这往往我们所做不到的，因为我们是软件公司，而不是做这些(客户的)业务的公司。这时惯常的做法是聘请行业咨询公司(或者个人)来介入需求阶段，协助了解和分析需求。

到现在为止，你应该看到，咨询公司除了把问题搞得更加复杂之外，他们仍然需要面对最直接的问题：与客户如何交流？他们的解决之道是模型语言。UML是模型世界里的世界语。

 

UML图在一些客户眼里无异于盲人的世界，如果需要向他们做需求调研，你只能使用一种这些客户能够理解和接受的方式，例如表格、流程图以及⋯⋯更深入的交谈。你要确认你的沟通方式是否有效，而不是去追求这种方式是不是UML，以及用UML表达得是否正确。——客户是因为他认为你理解了他们的需求，而在“需求确认书”上签字，而不是因为你的UML画得是否精准。

现在来思考：为什么非要让客户看UML图呢？如果有能够满足“极限编程(XP)”所要求的“现场客户①”，那当然可以不画用例图；相反，如果客户雇了一个专家组来评审需求，那么你就老老实实地画用例图好了。

 

一旦源头确定，你就可以接下来约定在项目组中要使用的沟通方式。愚公——这个伟大的项目经理——所使用的“聚室而谋曰”，就是很好的沟通方式。当然，如果客户精通UML，那么我想愚公采用的项目沟通方式将会是“聚室而论UML”。我想一定会这样，因为愚公是很懂得沟通的、伟大的项目经理。

 

我向我的项目组员提出在需求阶段与客户的三条沟通计划。

1)在一个月中，只能跟客户作三次联系；

2)三次联系中，最多只能有一次面谈的机会；

3)一个月后，提交全部的需求调研报告、需求分析和关于该项目的远景规划。

我们开始在网络上查看相关的软件系统的特征以抽取客户所关注的内容；了解该客户的公司、经营理念、组织结构形式以及工作模式；了解同类公司的成功经验和优秀的管理模式，以及客户的竞争对手在做什么和在关心什么⋯⋯最后，我们开始综合以下两个方面的因素：

1)客户在公司层面的外在表现、内部机制和运营管理手段。

2)客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为(和方向)所提出的需求。

这样我们就了解了客户项目中所有会产生需求的信息点。

我们开始设计提问，每一个提问涵盖尽可能多的信息点，尽可能的具有发散性以便形成更多的推论和假设。

我们把这些做成项目概要用mail提交给客户，并在第二天电话回访他。他以口头的形式回复了这封mail，这让我们尽可能地得到了项目在方向上修正。

我们确定了项目的实际目标，以及远期的方向。接下来就是设计需求条目。

客户已经先期提供了一些关于项目的文档、报表和工作数据。因此基于这些数据的需求分析，将是下一个沟通前所进行的最坚苦的工作。项目组员被要求：

1)分析用户的每一个表格，以构建基础数据库；

2)分析每一条数据的含义以确定它的上下限，以及数据间的相关性；

3)从工作文档中去了解客户的组织机构及其相互关系，同时确定了每一类使用该系统的角色；

4)从报表中去了解客户关注的数据信息，以及被他们所忽略掉的数据信息。

我们从数百条的需求条目中，整理出系统结构和模块，需求条目被映射到各个模块。我们很快画出了模块间的相互关系图，并通过这个图分析了数据交叉关系，设计了相应的数据索引并增加了一些新的关系性数据。

我们对用户角色、原始数据和系统结构进行了梳理之后，我们花了很短的时间实现了第一个系统模型。当然，很多的功能项目，我们都只是简单show a dialog。但我们优化了每一个操作流程，以保证不同的用户(角色)在使用时都尽可能流畅。这一次的沟通我们使用了面对面的模式。我们很庆幸的得到了与这个系统的每一类用户(角色)接触的机会，而正好我们有一个模型，我们便让他们来操作并提出意见。这一次我们终于有了一份详尽的的调研报告。接下来的分析设计是顺理成章的事。我们在一个月后完成了这个项目的需求分析报告，以及在这个分析上的一些框架型的设计。还有，一个被用户所接受的原始模型。尽管，第三次的沟通中还发现了一些问题。但我们终于有了一个好的开端。应该清楚的是，保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单的事。你得到的每一次沟通机会，都是向客户了解更深层次的需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。吃饭并不是有效的沟通。大多数时候，那将以酒醉收场。

 

 

History的丰富和准确为项目的后继开发、维护提供了可能。

 

在很多的时候，我所听到的沟通，都是一种形式。例如与客户吃饭或者打回访电话。其实沟通是具有目的性的，如果在没有明确目的的情况下与客户沟通，那将是浪费客户和自己的时间。这种目的，可以是了解项目的讯息、挖掘潜在的项目⋯⋯最末了，才是交流感情。然而大多数的情况下，它仅仅被看着交流感情。这便成了形式。且往往是客户所讨厌的一种形式。

沟通问题不仅仅存在与客户交流之中。还存在于与项目的各个角色之间。项目的分析报告为设计人员所看不懂，设计人员的方案为开发人员所看不懂，而开发的结果以为测试人员所看不通。等等都是沟通问题。

UML的确是解决沟通问题的最佳手段之一。然而如果项目一开始就不能用它，那么强求的结果必然是痛苦的。——要让UML在一个没有经过相关培训的团队及其各个角色之间用起来，几乎是不可能的事。即使用得起来，也存在经验问题。千万不要指望仅仅一个项目，就能让你的组员深刻的理解UML的思想。

也不要指望在每个项目中都能用它，如果你的客户能理解并支持使用UML，那以这个项目就会有一个良好的UML使用环境。否则，开发环节中资料的不一致性，将会使得项目难以收场。

使用与不使用UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。在每一次回顾项目时都应该注意：流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。