在扁平的世界中协作: 协作开发工具

软件开发领域的协作包含了大范围的团队活动，从在同一个地方的小型项目的团队开发，到涉及三个或更多时区以及数百个开发人员的地理上分布的项目，还有一些是外包的。本文介绍了协作开发的目前状态，并且考虑了一些最佳协作的障碍。
　　一般来说，软件开发人员和技术专家总是在寻找下一件大事。我们中的许多人都试图成为预知行业中下一个趋势的权威。本月，我将试着预测一个我认为将成为成功软件开发的关键的领域 —— 协作开发，以及支持它的工具。什么是协作和协作开发?
　　软件开发人员在团队中工作。我们中大多数都在小型的 5-10 人的团队中工作，来构建完整的软件产品或大型产品的一个组件。我们中的一些人在大得多的项目团队中工作，而一些人在更小的团队中工作，但大多数工作都是在 5-10 人的团队中进行。1
　　在我们考虑为什么我认为协作开发如此重要之前，我应该明确我说的“协作开发”是什么意思。无疑，无论我们什么时候与其他人一起工作，我们都利用各种类型的信息作为一个团队来协作。对于非常小的团队来说，不需要太多的交流的途径。 随着团队的成长，交流途径的数量就值得注意了。但协作不止是交流。协作意味着不同实体的交互 —— 个人和小组 —— 朝着共同的目标工作。协作通过分享使每个人都能更接近于达到目标的知识和工件，使大家互相帮助。
　　当提到软件项目时，我们通过许多方式来协作。我们与直接的团队成员分享过程。我们让其他团队知道我们如何工作，并且使它们的工作方式与我们啮合。我们共享代码、设计、测试和开发过程所生成的其他工件。
　　协作是协同的。当我们成功协作时，我们将在比不协作时所处的更好层次上执行。当我们优化了人与人之间和团队与团队之间的交互时，我们就减少了完成工作的障碍。特别像一辆汽车，当所有部分都一起工作时，汽车就运行的更好。21 世纪简史
　　在过去的十年里，商业气候从主要是竞争变化为更多的协作。在软件行业中，我们构建基于组件的系统，以及构建于服务之上的系统，例如，Web 服务。这些组件和服务都不是由单个、同类的团队创建的。它们可能由那些来自世界各地，出于不同目的的开发人员创建的。当我们找到一个想要使用的组件或服务时，我们常常需要与组件或服务的创建者协作，以了解并让其适用我们的需求。许多这样的组件都可以从开源提供者那里得到。在这样的情况下，我们常常雇佣这样的提供者，或者一些熟悉该软件的人，从而修改它，并将其集成到我们的系统中。
　　就像 Thomas Friedman 在其非常成功的书籍，World is Flat: A Brief History of the Twenty-first Century中介绍的那样，世界已经显著地变化了。成功的商家将开始利用能够最好地提供他们所需的服务的人之间的协作，不论这些人在世界那个角落。随着协作的增加，出现了支持协作的工具的新市场。协作开发将成为未来几年软件行业中的主要因素。让我们来分析一些事情变化的方式。新的开发方法和实践
　　我们正在经历软件开发过程中一段剧烈活动的时期。在上个月的这个专栏中，我分析了敏捷过程(Agile processes)，但敏捷性不是出现新方法的唯一领域。我们正在观察针对软件开发实践所有方面的新方法，包括特别适合协作开发的方法。
　　随着时间的过去，协作开发过程将成为具有自身特性和实践的独立实体。现今 Agile 方法满足能够面对面的团队，因为面对面的交流是 Agile 的基本原则之一。2但是 Agile 团体中有许多人致力于开发及扩展能够在团队成员不可以经常见面的时候进行协作活动的过程。我相信问题的有效解决方案不绝对是 Agile。
　　更加形式化，定义的过程将满足跨地理距离的协作需求。例如，Watts Humphrey 最初开发的 Team Software Process 正解决这一问题。3TSP 是基于软件工程协会(Software Engineering Institute) 的能力成熟度模型(Capability Maturity Model，CMM) 和 能力成熟度模型集成(Capability Maturity Model Integration ，CMMI) 的。在许多大型组织中，使用这些模型来有效地管理大型项目。
　　跨地域和时间距离的协作已经引起了软件过程设计中许多名人的注意。Ivar Jacobson 一直致力于有效地结合实践的方法。他已经将他目前的方法写在 Enough of Processes: Let's do Practices中。4无疑，在处理必须有效协作的分布的团队的时候，不同的实践是有必要的。Grady Booch 已经进行了许多次协作开发。5Booch 和 Jacobson 是软件开发中的有名的构想家，他们，以及其他一些人，已经认识到了支持分布的团队的重要性。
　　目前的实践可能在哪里变更?最终要的焦点之一是同步分布的团队的活动和工件的能力。我们已经看到，现今使用的一些协作开发环境中支持了这点，例如 VA Software 的 SourceForge，它是使用最广泛的开发环境之一。VA Software 已经创建了一个提供了一些用于将 SourceForge 并入组织现有的过程中的最佳实践的协作开发过程，以及一个用于那些目前没有确定过程的组织的完整过程。6协作开发工具
　　支持协作开发的工具是造就新的变革思想的领域。如果 WPI(Worcester Polytechnic Institute)中任何一个我的学生来找我说对软件开发工具的构建感兴趣的话，我会鼓励他考虑协作开发工具，以及技术如何满足地理和时空上分布的团队的需求。
　　使协作开发工具令人感兴趣的是有短期的机会和长期的机会。就眼前来说，我们必须修改现有的工具，使之支持分布的协作。许多工具的支持多用户的能力都对这一点有一些支持。需求管理工具、源代码管理和版本控制软件对多用户的支持已经有很多年了。版本控制软件已经成为共享由不能很好地支持多用户的工具创建出来的项目中的工件的主要方法。我们经常将文档、计划、设计和其他工件存储在某种类别的团队存储库中，为了让团队中的其他人以一致的方式使用它们。集中存储库允许所有团队成员受控地访问资源，并且它给每个人呈现的项目都是一致的。分布的存储库已经成为现实，虽然它仍远远落后于集中存储库的部署。
　　现在，有一些工具自称是协作开发环境(collaborative development environment，CDE)。SourceForge 和 CollabNet 是较流行的两个。就如今天这些工具中所包含的，协作开发意味着向团队提供一个集中存储库，让它们交流并共享工件，包括代码。这些环境都使用了一个数据库，来存储工件，和一些类型的版本控制工具 —— 通常是 CVS 或 Subversion —— 用于源代码管理。它们可以扩展使用外部的工具，如 IBM Rational ClearCase 和其他工具，来创建并管理团队的工件。
　　在 WPI 中，我们已经使用 SourceForge Enterprise Edition 差不多三年了。目前，我们有几乎 1,000 个用户并且其上寄存了超过 300 个项目。“寄存”对于当前 CDE 提供的能力来说是个好词。它们通过为每个项目创建工作区来“寄存”团队创建和消耗的资源。它们还提供一些帮助团队更有效地协作的附加特性。由于我最熟悉 SourceForge，因而，我将向您介绍一些 SourceForge 为分布的协作开发提供的附加特性。我将通过“选项卡”的名称来指示环境中不同的部分，如图 1 所示，但我将不按照这里出现的次序来讨论这些特性。

　　图 1. SourceForge Enterprise 项目选项卡

　　首先，我们有 Discussions，它是可以在黑板系统或其他支持分布的团体的 Web 站点上找到的主题。最近，SourceForge 集成了 Wiki 能力，在我的项目中，对它的使用比讨论论坛要多。Wiki 提供更少的结构化信息架构，但是它通过让讨论的结构进行演进，而不是将其限制于结构中，来支持团队成员之间更丰富的对话。
　　SourceForge 支持团队任务管理和缺陷及其他工件的追踪。SourceForge 的 Tasks选项卡令团队创建一个结构化的工作分配记录。可以通过能够以各种方式映射到团队上的任务层次来实现。SourceForge 中的大多数视图许可您过滤您在其中看到的信息，并且选择您看到的每页的项数。图 2 展示了被过滤的任务，以便让您只看到没有开始的任务。过滤机制十分简单，随着产品的演进，它也将有希望提高。

图 2. 过滤任务的视图

　　Documents选项卡，是项目文档，或团队可能引用或生成的任何其他类型的文件的通用存储区域。对于文档的一个很好的特性是审阅的概念。您可以初始化文档的审阅，选择所需的和可选择的审阅器，通知它们，并当审阅完成时得到通知。这似乎很简单，但是它是一个理所当然采用的过程，或者是以特定方式完成的过程。其他 CDE 和协作工具，像 Microsoft SharePoint，也提供此特性。
　　代替将缺陷作为具体类型的工件进行跟踪，SourceForge 提供了通用的工件跟踪器。每个项目都可以设计、使用，并跟踪许多类型的工件。我们发现这是 SourceForge 极其灵活的特性。它让我们设计缺陷报告、用户经历，以及其他我们希望用于项目的工件。File Releases选项卡对生成软件的项目来说很重要。我们能够包装我们的产品，可能为不同的平台增加配置，标注它们，并让客户利用此特性来访问它们。对于开源的项目来说，这是一种使人们很容易获得现成形式的软件的好方法。对于任意的 CDE 来说，重要的是提供安全性。SourceForge 和 其他 CDE 很重视这一点，并且为项目管理人员提供了许多方法来定制用户特权和访问权力。缺少了这样的特性，对于希望管理其知识产权的组织来说，CDE 将是无用的。依然不存在银弹
　　可以使用 CDE 非常的好。但是，仍旧有许多抑制了在团队中真正协作的东西。我已经遇到了两个大问题：
　　对不同的用途使用不同的工具迫使我过于频繁地切换环境。
　　使用功能重复的不同工具导致混乱。
　　让我们来对每个问题进行分析。如果我工作于自己的程序设计环境(IDE)中，并且需要查看一个我将通过某个 Web 服务而集成的模块的最新 API 或 UML 图，设想会发生什么。很可能我需要的信息处于我正在使用的，我的 IDE 所连接的源代码管理系统中。如果是这种情况，我可能需要检查它，并且有希望在我的 IDE 中找到让我看到工件的一个视图。Eclipse 和其他这样的 IDE 对这一点大大支持。但如果我需要的工件处于其他类型的存储库中，像 SourceForge 工程中的 Documents选项卡，怎么办?如果那样的话，我必须离开我的 IDE，在 SourceForge 中寻找文档，下载到我的机器上，并试图查看它，而该视图可能通过第三个工具完成。理想的解决方案是在 SourceForge 中找到文档，并在我的 IDE 中全部打开。
　　当我用到带有重叠功能的不同工具时，出现了更严重的问题。这里介绍了在我试图向学生展示各种软件开发工具时所发生的事情。我所有的学生都使用 Eclipse 和 SourceForge。我们还有些 Rally，一个支持 Agile 软件开发的基于 Web 的项目管理工作区的许可。我想在班上使用三种产品。Eclipse 是 WPI 选择的 IDE，SourceForge 拥有以上介绍的特性，但 Rally 支持需求管理，并支持用户经历和用例规范。此外，必须切换环境来访问每一个产品，在 SourceForge 和 Rally 上用不同的登录身份，这令我们遇到了冲突。三种产品都有称为 task(任务)的不同工件。
　　在 Eclipse 中，任务只是带有名字，和与 IDE 中某个元素相依附的受限状态的标记符。元素可能是一段代码或一个文件。在 SourceForge 中，任务是定义了由团队中某人要完成的工作的一项内容。它有不能变更的预定义的格式。Rally 的任务概念十分类似于 SourceForge 的，但任务项的模式有些不同。显然，我们必须决定要做什么。Eclipse 的任务标记对我们的使用太制约了。我们想用任务来安排团队成员的工作。但是，如果我们选择将任务放在存储了许多其他资源的 SourceForge 上，那么我们将不能利用一些 Rally 任务提供的到用户经历和其他需求的链接。我们可以手工地复制这些任务，但似乎很傻。最终，为了减少启动的工作量，我们没有使用 Rally 工具。这是不幸的，因为我认为学生本可以通过对我们的需求规范使用 Rally 来学到很多。
　　现在，让我们来进一步看看这个问题。如果您与一个分布的开发团队进行一个项目，每人都使用不同的工具集，那该怎么办?这不是那么牵强的，现今，公司之间有多少外包和协作在进行。设想，团队 A 将 Eclipse 作为其 IDE，将 IBM Rational ClearQuest 用作缺陷跟踪，团队 B 使用 SourceForge 和 Eclipse，而团队 C 将 NetBeans 作为其 IDE，将 Rally 用作项目管理及其项目工作区。这三个团队如何协作?它们要么商定一个让所有团队都使用的环境，要么花费大量工作来复制工件，并保持环境的同步。哪一种都是不可接受的解决方案。协作开发工具的未来
　　这个复杂的可能性指出了协作开发工具的最佳着手点。如果我们将要在全球基础上协作，那么我们必须能够将开发文化与工具合并。这将需要极其灵活的，允许工具有效地一起工作的环境。向工具，如文本编辑器，提供个别的参数相当容易，事实上，没有什么真正要去完成的。但是，当您致力于部分存储在 ClearCase 存储库中，而部分存储在 Subversion 存储库中的代码时，您就需要一个跨越差距的工具。
　　为了实现这一点，我们需要有两件事发生：
　　必须公开个别的工具。“公开”，我的意思是，它们需要有定义明确的，可以让其他工具与之集成，并集成它们的 API。这些工具不必是开源的，但是它们的接口必须是公开的。
　　协作工具必须很容易地抽象出分布的开发团队所需要的概念，并且解决冲突，且在每个团队的环境中以工件形式表示那些概念。
　　我在这里谈论的许多工具都满足了首要的条件。Eclipse 和 NetBeans 是两个开源的 IDE，并且公布了用于扩展它们的 API。7同样的，SourceForge 和 Rally 有与之集成了的 API。API 在质量上大不相同，这主要由于产品的成熟度，但这将随着时间而改进。
　　一个较难的问题满足了第二个条件。我们需要能使我们同步项目工件的工具，尽管它们完全不同。一旦我们解决了这些问题，我们就顺利地改进了协作开发环境。
　　对添加协作工具的勘探是显著的。我们将开始观察连接到我们的 IDE 中的集成的连接技术。我们将观察注解视频和音频的方法，为了使需求更精确，更容易在跨文化的情况下得到理解。这将成为一个令人激动的时刻。
　　下个月我将向您介绍一个我们在 WPI 正在从事的关于协作的项目。它是基于 Eclipse 的，但有潜力扩展为许多工具和技术。我们的研究生和本科生都参与了这项技术和研究，并且在做出一些有趣的东西。我希望您对此报以期待。