软件工程中我们必须更像心理学家

　　摘要：在软件开发中，爱因斯坦的意见，是多花时间理解问题，这意味着理解业务目标，正确地识别利益相关者，提出正确的问题以探讨问题，并使用合适的技术来描述系统应该做什么和为什么要创建它。但作者认为，即使软件工程师理解需要这样做，但在问题上花时间，这本身就是一个问题。她提出为什么发生这种情况，以及如何克服投入时间的阻力。

　　爱因斯坦曾经说过，如果他有一小时来拯救世界，他会花 55 分钟来定义问题，只花 5 分钟去寻找解决方案。除了在问题和解决方案上所花费的时间比例之外，我完全同意他对于在设法解决问题之前先理解问题的重视程度。

　　没有充分理解问题的后果

　　在软件工程中，理解问题是在系统需求定义阶段早期必须完成的工作。一个没有被充分理解的问题，将导致定义不清和不完整的需求，并最终导致不成功的项目。多年来，有关失败的项目和相关费用的统计数字一直令人失望。仅举其中几个作为示例：

　　根据 Standish Group 的数据：

　　41% 的项目无法增加价值和产生足够的投资回报 (ROI)

　　49% 的项目超出最初的成本估计

　　只有 28% 的项目在预算范围内按时完成

　　Standish Group 还将缺乏成功的原因归结为以下因素：

　　缺乏用户参与

　　业务目标不明确

　　无法捕获基本需求

　　缺乏对项目范围的控制

　　缺乏高管的支持

　　IDC (International Data Corporation) 甚至更具体地指出了失败的原因。他们发现，在软件开发中超过 80% 的失败由需求发现、管理或分析中的问题直接导致的。

　　并且根据 IAG Consulting 的数据，超过 40% 的 IT 预算将用于对较差的需求规范上。

　　这些数字证明爱因斯坦是正确的。

　　为什么不愿意投入时间

　　就软件开发而言，投入时间去理解问题，意味着要理解业务目标，正确识别利益相关者，提出正确的问题以探讨问题，并使用合适的技术来描述系统应该做什么，以及为什么要创建这个系统。虽然这看起来很明显，软件行业的人都明白必须要这样做，但为什么花时间去理解问题却很困难呢?

　　我认为困难源自以下原因：

　　急于针对所需要的某件事情找到一个快速的解决方案，这是人性的特点。一个没有经验的分析师会觉得没有详细理解需求就去解决问题是一个特别大的挑战。通常情况下，他考虑是否使用在以前的项目中创建的组件，即使用户不断解释自己的困难也是徒劳。这种对解决方案的焦虑出现在许多层面。项目经理和区域协调员都只有在他们看到像代码行这样实实在在的东西时才会感觉到进步。只要他们不会在忽略理解业务问题的重要性时鼓励开始实施，这就不是一个问题。

　　系统分析师和工程师不愿意冒险进入他们通常不熟悉的知识领域，例如，业务流程和行业专业知识。谈论表格、报告、函数和数据总是更容易一些的。

　　IT 专业人士在大多数大专院校中并没有接受此学科领域的相应培训。我们在计算机科学和工程方面受到了良好的培训。我们了解操作系统、统计、微积分、物理、编译器和编程语言等。但没有关注人文学科或心理学，所以我们可以学着与缺乏这些技术知识的人沟通。

　　在项目过程中，较低的用户参与程度往往涉及到级联开发流程(又称为瀑布 开发)所强加的文化，该流程在巴西仍被广泛使用，仅在项目开始定义需求的时候以及项目结束验收系统的时候，才需要用户参与。

　　改变文化的三种方式

　　好消息是，我们有办法克服这些困难。要实现在软件工程学科中实现或提高成熟度所需的文化转变，则需要在以下三大支柱的建设方面进行投资：流程、工具和人员。

　　投资于流程

　　在流程方面，在最近几年已经有巨大的发展。一些值得注意的示例包括，传统的 Rational Unified Process、Agile Unified Process 或 XP (eXtreme Programming) 等敏捷流程，或 Scrum 项目管理方法。每个方法都有自己的特点，并且不同程度地强调要维护与需求相关的基本要点，如：

　　用户和利益相关者的持续参与

　　并非在项目开始时指定所有需求，而是以迭代方式指定需求。

　　使用适当的技术来促进流程

　　在名为 Agile Modeling: Effective Practices for ExtremeProgramming and the Unified Process 的这本书中，Scott W. Ambler 解释了建模和文档在任何软件项目中的重要性，包括使用敏捷方法的项目。他强调，如联合应用程序开发 (JAD)、用例、访谈和观察等传统的技术，可以适应敏捷流程，而利益相关者的持续参与则是成功的关键。取决于不同的流程，发生变化的是，使用该技术的正式程度，以及花在该活动上的时间。

　　投资于工具

　　至于工具，一些极端的敏捷开发只捍卫纸张的使用。另一些则使用多种技术和工具。考虑到该系统将在组织中保留几年或几十年，并且将接受维护，我们必须利用资源使其记录和修改更容易。除了地理分布的开发变得习以为常这个事实外，对协作开发支持工具的需求已非常紧迫。

　　在这方面，对于正式程度要求较低的项目中的敏捷开发以及往往要接受监管和审计的传统项目来说，IBM® Rational® Requirements Composer 都是一个非常好的选择。它构建于 IBM® Rational® Jazz™ 技术之上，这是一个协作式平台，并且它包括支持问题理解、需求发现和需求定义阶段的特性。

　　投资于人员

　　至于人员，我们首先需要选择有适当经验的分析师，并提供培训和指导。有些技术和最佳实践可以改善团队合作。Donald Gause 和 Gerald Weinberg (见 参考资料)将 问题 定义为在 感知的 当前状态 和 期望状态之间的现有 差距。从这个意义上讲，问题有不同的解决方式。

　　提供期望的状态并非总是最好的解决方案。改变对当前状态的看法，可能会改变对问题的定义。例如，Microsoft 所收到的大部分关于产品(如 Word)的改进请求，都要求增加该产品已经具备的特性。

　　更好的解决办法应当是改变目前的看法，也许通过培训可以实现。解释在解决方案中所涉及的成本和其他方面，这可能会改变客户对期望状态的看法。有时，客户要求的特性并不会解决他们的问题，所以他们不会使用这些特性，这是因为他们对期望状态的感知可能是扭曲的。这方面的证据有 Standish Group 所公布的一个数字：“通常，系统中有 20-40% 的代码行从未被使用”。

原文转自：http://www.ltesting.net