【IT168 技术文章】

    在软件过程中，我们如何保证信息能够得到正确的传递呢？我们用什么方法来避免信息传递的失真呢？我们如何在这样一个过程中处理人与人之间的交互呢？在正确传递信息的情况下，我们又如何保证投入的最小化呢？

    意图

    软件开发过程是知识传递、知识转换的过程。注重知识转换中的完整性，保证知识经过各个阶段和活动，顺利的转换为软件是极为重要的。

    示例

    元朗公司是国内某银行的下属企业。从年初开始，公司就投入了大量的人力为银行开发新版本的国际收支系统。考虑到这是一个非常庞大的系统，因此公司把原先的软件开发团队扩大了一倍，补充的人员有些来自于其它的项目组，有些人员来自别的公司。为了保证开发的顺利进行，项目经理引入了软件过程。但是从一开始，麻烦的事情就出现了。项目组中的技术人员和银行的领域专家之间不断出现意见相左的情况。主要的问题是后加入的员工对目标领域不熟悉，难以配合领域专家的工作。最糟糕的是，某些领域专家身处异地，因此在需求分析的中期，开发团队邀请这些异地的领域专家来到开发所在地，进行了为期两天的讨论会。结果并不理想，讨论会上充满了对原先已定稿的需求的反对性意见，技术专家、领域专家吵成一团。需求分析阶段不得不在原先的基础上延长了50%的时间。在进入设计和编码阶段之后，问题少了许多。但在设计到编码的过程中仍是出了一些麻烦，原因是新加入的人员不熟悉开发团队的设计风格。经过一番周折，问题基本解决了。可等到项目进入到测试阶段，矛盾一下子就凸现出来了。测试报告指出，软件中存在着大量的问题，大部分的问题都被定性为无法满足需求的严重错误。经过对错误的复审，排除了其中17%的严重错误。经过分析，发现其中70%的错误都是发生在后加入人员负责的模块中。而产生大量错误的一个主要原因是在编码阶段，由于银行启用了新的会计制度，导致大量模块被修改，由于时间紧迫，因此没有进行正规的需求调研。现在看来，领域专家和技术专家对同一个问题的理解并不相同。最后，项目的开发周期延长了40%。

    上下文

    软件过程每经历一个阶段，就会发生一次知识转换的情况。这种转换是由人来完成的，这就是像是接力一样，一个人把脑中的知识以某种方式传递给另一个人，再有另一个人传递下去，直至编码人员把这些知识固化在最终的软件中。在软件成型之前，知识的主要载体是文档和模型。我们称它们为工件（Artifact）。例如，需求阶段时，领域专家在技术专家的帮助下，将自己脑中对领域的认识传递给技术人员，并最终形成需求规格书或是用例模型。而在分析设计阶段，技术专家借助需求规格书，把脑中对软件的初始认识进一步转换为分析模型、设计模型、数据模型等工件。最后，在编码阶段，编码人员把这些工件中隐藏的知识转化为软件的形式。经过测试和部署，软件将会交付到用户手中。这是非常典型的软件开发过程，再简单的软件开发也需要经历上述的这些阶段。

    可以看到，在上述的软件开发过程中，知识形式发生了两次的重要转换，知识所属角色也改变了两次。知识完成第一次的形式转换之后，将成为需求规格书（或同类工件）的形式，知识从领域专家的脑中转换到技术专家的脑中。然后，知识开始了第二次的形式转换，形成设计模型（以及同类工件）。随着知识从技术专家转移到编码人员，知识转换为其最终的软件形式。在这些转换的过程中，最容易出现信息遗漏、信息失真的情况。保证转换过程中知识的完整性和正确性，对软件开发具有重要的意义。

    问题

    如果保证转换时知识的完整性和正确性？

    方法

    知识转换的主体是人，因此我们主要的对策也是针对人来展开的。我们知道，软件过程的特点就是：越早埋下祸根对项目的杀伤力越大。所以我们首先需要重点防范的对象应该是在初始需求分析阶段。需求分析阶段涉及的知识非常的多，大家如果有兴趣可以参看我的文章－需求的实践。但这里我们重点的任务是找出需求分析阶段中发生知识转移的关键点。

    领域专家和技术专家是需求阶段中最重要的两种人，不论你的项目和团队规模属于哪一种层次，一定都包含这两种角色。如果你的团队中领域专家和技术专家是同一种人，那么恭喜你，你可以不用阅读这一段的内容了。可惜在强调分工协作和软件规模不断扩大的今天，这种人已经非常难找了。领域专家是知识的最初持有者，其职责是为项目提供准确的、完整的需求信息。技术专家的职责则是帮助领域专家完成这一项工作。所以，首先请保证领域专家和技术专家是能够沟通的，示例中的项目的第一个问题就是团队的新成员和领域专家之间存在沟通壁垒。在我们的经验中，就发生过一位优秀的技术人员和一位资深的领域专家争吵的事情。剖析原因之后，我们发现，最主要的原因是他们两个人都太优秀了，技术人员有一定的领域经验，领域专家有一定的开发经验，这导致了双方在讨论中的强硬立场。因此，如果遇到类似的情况，请对你的组织进行岗位调整。但在执行这项工作之前，请小心你的说辞，不要伤害到任何一个人。"我们的某个小组有麻烦，那边非常需要你的经验和能力"会是一句不错的说辞。其次，技术专家不应该提出任何可能影响领域专家的问题。只有领域专家才能够提出需求，技术专家起到的只是辅助作用。因此请杜绝这种情况。再次，如果你的领域专家不只一个人，那么你需要考虑领域专家之间可能出现的不一致。为领域团队指定一位领导者是一种不错的做法。在我们的一个项目中，就曾邀请对方公司的财务总监担任这一角色。理由有二：1、财务总监具有权威性；2、财务总监了解公司的全部运作。此外，如果领域专家分布在不同地点的话，你需要在该阶段的某个时期，安排需求讨论会，并考虑一种能够沟通的方式，以便随时能够了解身处异地的领域专家的意见。这种情况对于那些拥有分公司的公司（例如银行、证券、保险、销售公司等等）而言非常的普遍。因此，我们在需求分析阶段，首先要处理好领域专家和技术专家之间的关系。应该说，这里提到的内容不仅仅适用于需求阶段，在整个的开发过程中都有用处。

    需求不是实现。需求表示的是有什么（What），并不关心如何做（How）。如果在需求分析阶段把精力分散到了如何实现需求上，那么需求分析的效果就会受到影响。这体现在需求的完整性和正确性两个方面。领域专家和技术专家都可能犯类似的错误。领域专家往往只能够针对自己的工作来描述需求，而他会很容易的把自己对于需求实现看法参杂到需求描述中。从项目的整体范围来看，这种需求描述有时候是有问题的。如果你开发的是一个定制应用，那问题还不大，如果你开发的是一个产品，那么问题就很严重了。领域专家描述的需求一定是你需要的内容吗？例如，你打算开发一个配送的管理应用，但是领域专家把大量的精力花在了他在原先的公司中如何实现配送的流程上，这个过程可能适合于他的公司，但是对于产品而言，可能就不合适，因为并非所有的配送公司都使用这种流程的。好吧，你想要的内容和你不想要的内容混合在一起，这使得你不得不花费精力对需求进行进一步的整理。因此，好的做法是，一开始就明确领域专家应该提供什么，而且，尽可能的提供需求，而不是需求实现。多问一些诸如"如果环境发生变化，你该如何做"之类的问题，否则你会发现，用户的需求变化将会对你的软件造成很大的影响。再说技术专家，技术专家常常犯的毛病是把分析参杂到需求调研中来，从需求描述中精练出一些业务实体（或进行CRC讨论）是可以的，但是过早的考虑实现方式将会限制你的思维。因此，请确保需求只是需求，这样才能够尽可能保证需求的完整性和正确性。