《软件工艺》—第1章“有组织的、可计量的”软件开发过程现实吗？

本节书摘来自异步社区《软件工艺》一书中的第1章“有组织的、可计量的”软件开发过程现实吗？，作者【美】pete mcbreen，更多章节内容可以访问云栖社区“异步社区”公众号查看。

“有组织的、可计量的”软件开发过程现实吗？

软件工艺

对于软件开发来说，所谓“确定的、可重复的过程”真的能够达到吗？scrum软件开发过程1的创始人曾经这样说道：

如果某个过程能够完全确定下来（即能够了解过程所涉及的所有细节，从而将其设计为可以重复地多次运行，并且完全能够预测其结果），那么该过程就被称为“确定过程”。从理论上来说，一切确定的过程都可以被自动完成。另一方面，如果人们并未了解某个过程中的所有细节，只是大致地知道在某些初始条件下、通过某些调节和控制就能得到想要的结果，这样的过程就被称为“经验过程”。2

按照这个定义，软件开发不是一个确定过程。实际上，我们所能希望获得的最好结果也就只是一个经验过程而已。之所以这样说，是因为所有的软件需求都来自于人。需求的获取无法自动完成，开发者必须和用户彼此沟通才可能了解用户真正的需求。同样，用户也必须在与开发者的交流中了解项目中存在的技术局限性和克服这些局限所需要的开销，从而不断调整自己要求的功能，使软件项目的性价比达到最佳。

在软件开发者了解用户的需求之后，下一个问题就是：如何将这些需求记诸文档。在一个确定的开发过程中，我们应该从一开始就整理出完整而明确的需求。可是，在一般情况下，要想做到这一点难于登天。gause和weinberg曾经非常精辟地阐释过这个问题3：对于一个最简单的句子，“玛丽有一只小羊”，根据语句的重音不同，就可能有截然不同的含义。

玛丽有一只小羊。（是玛丽的羊，而不是约翰的。）

玛丽有一只小羊。（她的确有这只羊，不是骗人的。）4

玛丽有一只小羊。（她只有一只羊，没有更多的。）

玛丽有一只小羊。（这只羊真小，小得令人吃惊。）

玛丽有一只小羊。（她拥有的是一只羊，而不是火鸡。）

从这个例子中，我们就可以清楚地看到：对于任何一种自然语言，实际上根本无法做到精确无误的地步。需求获取要求开发者与用户保持紧密的联系，即使在需求文档成型之后，开发者也需要不断与用户交流，因为谁都无法保证需求文档中所写的内容不会有多种不同的解释。由于自然语言与生俱来的不精确性，你不可能喜欢一个确定而僵死的需求获取过程。

我们当然可以将软件开发中的某些部分自动化，不是吗？

当然，我们可以。但只有确定的过程才能被自动化，而那些需要大量人际交流的部分则无法被自动化。现在的确有很多这样的工具存在，它们将软件开发中的一些小规模的、精确定义的行为自动化了，它们对于提高软件开发的效率大有裨益。例如，配置管理工具和构建工具能够自动地将高级编程语言的代码转换成相应的低级语言代码甚至机器代码。我们能够实现这样的自动化工具，是因为我们可以精确地定义这个转换的过程。

但是，我们必须记住：在软件开发中，绝大部分可以被自动化的工作都已经被自动化了。也就是说，我们已经拥有了软件开发所需要的绝大多数工具——唯一缺少的就是使用现有工具的技巧和能力。仍然以构建工具为例：自动化的构建过程可以在无人值守的情况下自动运行，并将构建过程中的失败信息通过电子邮件通知关键开发者，从而极大地减少构建的工作量。可是，我所观察过的大多数商用软件开发项目都没有这样的自动化构建过程，因此，拥有这一能力的项目组就占了很大的优势。而且，自动化构建还是项目的一张安全网：每当项目的核心源码被修改时，整个应用程序就会被重新构建，随后自动运行回归测试，以确保这次修改没有造成任何破坏。如果一个项目没有这样的安全网，我简直无法想象如何在其中工作。

当我们将软件开发中一个又一个的部分自动化以后，我们却发现：软件开发仍然是一团乱麻，其中的复杂性和困难性并没有消失，只是换了个形式而已。只有对那些能够完全了解的问题，我们才能用系统化的方式来解决，因此软件工程就将我们的注意力集中到了软件开发中机械的部分，进而忽视其他非机械的部分。所以，尽管我们有了高级语言的编译器和解释器，尽管我们有了各种各样的新技术，实际上仍然没有任何办法帮助我们设计用户真正需要的东西，而且能够帮助我们找出用户的真实需求的工具或技术更是少之又少。

3 don gause和gerald weinberg，《在设计之前，先了解需求质量》（undersanding requirements quality before design），dorset house，1989。

4译注：此处原文是“mary had a little lamb”，表示的含义是“玛丽现在已经不再拥有这只小羊”。为了方便读者理解，译者根据汉语的语言习惯做了调整。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。