| 人们总是期待将改变我们行业的下一件大事。我的愿望通常没那么大。我期待推动我们的下一个增长或发展阶段。的确有一些宏伟的想法根本地改变了我们创建软件系统的方法 —— 像增量或迭代的开发 —— 但总的来说它们都没有完全地改变我们的世界观。 最近我对一个领域产生了兴趣，我认为该领域有潜力创造软件开发中的下一个根本的改变：协作和创造力支持。敏捷运动令团队不断且良好的沟通的需求引人瞩目。它强调了好的开发人员都知道的其他实践，并且将这些实践编入不断增加的实践和原则集合中。我遇到的所有成功项目的公共特征是在整个团队中的有效沟通和协作。 整个团队包括客户、开发人员、管理人员、质量专家、文档人员，和其他参与项目的所有人。不管项目使用瀑布、迭代，或敏捷方法，这一点都是一样的。 许多工具都声称支持协作，然而直到最近实际的协作支持程度也是最小限度的。但是，一种新的工具已经出现了，它让我有希望看到团队协作实际支持中的惊人增长。协作支持之后的是创造力的支持。这两个领域 —— 协作和创造力 —— 密切相关。这个月我将探讨协作、一些现在可用的工具，并且预见一下我们能达到哪里。成功开发协作和创造力的自动化支持会让我们达到生产重大软件系统的下一个层次。 了解协作和创造力 开始让我们确保对协作和创造力有个一般的了解。虽然有大量描写创造力的资料，但是协作是这两个概念中更容易掌握的，因为在软件开发环境中我们对其了解的更多。在本文中，我将协作定义为 一组人合作达到一个共同的目标。协作本来意思是一人以上参与。协作还是面向目标的。人们为特殊的目的而协作。在软件开发中，目的是及时并在预算之内成功地开发并部署软件系统。 协作需要沟通，但只沟通是不够的。协作需要对工作目标达成协定，了解如何达到目标，并且知道协作工作的状态。我将在下面更深入地介绍。 我曾说过，我们对协作的了解比创造力多，但我不确信在科学的意义上，对协作的研究已经像创造力那样多了。我仅仅是说我们直观地了解协作。每个在团队中工作的人都了解协作是怎样进行的。当我搜索关于协作和创造力的研究论文时，创造力的论文似乎更多。然而，二者紧密相通，并且从了解性质的观点看有一些相同的特征。 创造力已经成为各种规程中许多研究和调查的焦点。心理学家试图了解创造力的本质。有创造力的人如何想出点子？有创造力的人的工作风格是什么？我们能教人具有创造力吗？社会科学家、计算机科学家，和其他人都参与了此项探索，因为它很重要。随着全球化已经成为标准而不是偶然，一些国家将繁荣起来，因为它们可以交付比其他国家更便宜的服务，而一些将繁荣起来，因为它们是有创造力的。未来我相信我们将看到需要生产率、服务和产品的成本，及创造力相混合，来保持经济的竞争力。这是巨大的挑战，并且赌注是相当高的。 最近我读到的关于该主题的文章是 Mihaly Csikszenthmihalyi 写的。 1 Csikszenthmihalyi 说，了解创造力要分三个部分：
研究人员使用此框架来指导他们了解创造力及支持创造力的方法。我将在下面继续说明。 协作和创造力之间的关系 协作和创造力这两个概念是如何关联的？我对它们的关系的看法如图 1 所示。根据定义，协作涉及一个团队，并且协作的工作是基于任务的，但经常有一些探索，例如极限编程中的“尖峰”。 2 我不确定的是，根据 Csikszenthmihalyi 所给出的组成，是否会称这样的工作为创造性的。创造性的工作即可以由个人做，也可以是基于团队的，但主要是探索性的。
在软件开发方面，大部分软件应用程序是用来解决特殊问题的。因此典型的 IT 项目是基于任务的，并且处于图 1 的上半部分中。开发软件工具和其他内容的项目有类似的概况，但工作方式不同。一般个人或小组投入创造力来开发工具背后的核心思想。一旦探究了各种方法，并选定一个，项目就转换为协作模式，团队在此模式下构建产品。 支持协作 协作的成功源于许多因素。一些最重要的是：
协作工具的历史 支持成功的协作应该支持这些因素。让我们来看看工具是如何支持它们的。我将从最简单且最老的开始，一直到如今我们使用的。 十多年来，帮助团队识别任务以及任务分派是项目管理工具的一部分。对于非常简单的项目，可以使用电子表格和一些宏命令。拥有大型团队、必须集成的多个组件，以及长时间的开发周期的项目使用成熟，复杂的项目计划工具。 项目管理工具稍微支持协作，但人们不会必然将其分类为协作支持工具。一个原因是这些工具没有使得团队成员很容易地 察觉到 队友的活动。如果您是开发人员，并且您的项目使用成熟的项目管理工具，那么扪心自问，当您最后使用该工具时，您能知道另一个开发人员在做什么吗？非常可能的答案是“从未”。 不能察觉是一个很重要的问题。一个好的协作工具会让团队成员很容易地了解同伴在做什么。这样的工具还将把项目的整个进展告诉团队甚至没有工作的每一个人。这是生产力的问题。如果花费时间寻找所需信息，那么这些时间可以花在更重要的任务上，例如，实现新特性。同样，如果花费时间和精力定位信息，那么人们不会定期访问这些信息。人们只在出现危机时才访问这些信息。此时这些信息虽然关键，但是是以响应式来使用的。 抢先地使用项目进展和任务分配信息是更有意义的。信息有更多价值。设想程序员被分派实现应用程序上的新特性。当她工作时，她发现系统的另一个部分将使用她正在实现的特性。她可以仅仅实现该特性，并且提交，但需要使用该特性的程序员将不得不调整其代码。如果她可以快速地找出将利用其特性的人，那么她可以与该程序员一起合作，以最适合二者需求的方式实现该特性。这就是我所说的信息的提前使用的意思。 丰富的历史信息有许多用处。对于协作，这些信息令团队可以回顾项目，并且了解在哪里可以做出更好的选择，或者回复到项目的先前版本，并走另一条路径。许多年前，版本控制系统就已经提供用于获取丰富的历史信息的许多功能了。IBM ? Rational? ClearCase? 已经成为软件配置管理（SCM）工具市场中的优质产品很长时间了。这样的产品能够分支、合并，及进行并行开发。这样的产品拥有提供丰富历史的基础，但我们仍旧需要更多。 沟通的作用 我们希望能够及时回到可以看到项目全景的地方。当然该全景包含可以在版本控制系统中获得的工件，但也包含从典型的版本控制系统中不那么容易获得的信息。该信息可能包含电子邮件、网络会议抄本和记录，等等。这些信息还应该以鼓励探究和协作的方式提出。 这就要求我们进行沟通。我们都知道，通常面对面或通过电话与某人交流比写电子邮件更有效。当我们进行实时会谈时，我们能够更好地弄清问题并交流意图。在当今高度分布的环境中，这不总是可能的，事实上人们在同一个地点的现象越来越少。我们希望在可以的时候尽可能同步地交流。但如果我们不能做到，我们需要有效地移步交流。 交流生成了开发项目的有价值工件 —— 团队应该用于协作的信息。我们面临的一个挑战是，我们如何能够在随需的基础上获得交流并使团队获得信息？最近我参与了许多开始涉及此问题的 Worcester Polytechnic Institute（WPI）的学生项目。 如今的协作支持工具 上面的评论是十分概括的。现在我想要讨论一下如今支持协作的工具类型。此列表不是详尽的，但提供了一个如今专业人员可用的工具的适当示例。 在线协作社区和项目环境。团队可以计划项目并合作的在线社区的数量已经迅速增长了。其中一些，例如 sourceforge.net 和 Java community projects 是开源社区的两个实例。 4 商业产品支持同样的功能，并且更多支持想要管理自己的项目概要的组织。只要组织使用这些产品，那么它们就开始分布团队的协作。 版本控制和源代码管理系统。这些对任何团队，分布的或集中的，都是必要的。以前类别中的大部分产品都包含这些产品或提供对这些产品的接口。 故障追踪工具。虽然它们只提供异步的功能，但是这些工具是开发团队另一个基本的需求。这种工具可以了解项目的健康程度（缺陷的数量）以及任务分配信息。 网络会议工具。许多网络会议工具是随着互联网和网络技术发展为成熟、快速的通信媒介而发展的。人们在广播和电视上听说这样的工具的广告，并且在许多流行的杂志上看到关于它们的广告。这些工具的功能各式各样，但是它们的本质都是让一组人进行启用视频、音频，和共享的计算机桌面的虚拟会议。这些工具所提供的经验上的质量依赖于许多因素，包括参与者接受这些工具并学习适当地使用的意愿。 IDE 中内嵌的协作功能。许多交互开发环境包含协作功能。Eclipse 平台用许多插件，令 Eclipse 用户能够且更容易地协作。一个较成熟的项目和插件是 Mylyn 项目 5 。Mylyn 向程序设计人员的工作提供集中于任务的工具。它还与许多故障追踪工具相集成。在 WPI 中，我们拥有 Webfoot 项目 6 ，它是向 Eclipse 用户提供丰富的协作功能的进行中的项目。开发工具的一个很好的技术框架是 Eclipse Communication Framework 7 。该项目多年来用于向开发人员提供构建他们自己的工具的功能。它有一些实例应用程序，例如在最新的 Eclipse 版本中的实时共享的编辑器。 其他的 IDE 已经添加了许多 Eclipse 包含的功能。NetBeans IDE 曾经有一个非常好的共享编辑功能。其他工具提供更集中的功能，像 Smart Bear 的 Code Collaborator。 不幸的是，对于这些工具的互用没有什么标准，这限制了开发团队的选择。整个团队必需使用同样的 IDE 以获得协作功能的好处。 持续集成工具。持续集成工具最近几年流行起来了。它们与 SCM 系统联合，自动地观察代码存储库，并周期地或在有任何变更的时候构建系统（包括运行测试和打包工件）。它们还能够通知整个团队，或团队中被选定的成员。它们经常提供可以立即看到当前的构建状态的仪表盘。 Jazz：下一个阶段 我真的非常激动看到 IBM Rational 的 Jazz 平台投放市场。 8 它将有效协作所需的许多功能放入一个平台中。并且它构建于 Eclipse 平台之上，因此您不需要了解许多新的工具。Rational Team Concert（RTC）产品是 Jazz 产品线中的第一个产品。我在 WPI 中用过早期版本，并且很高兴使用它。设置和管理很简单，并且在我和一些学生的测试中，证明它十分有用。我希望今年将其拿到我的课上，并且让学生团队使用它。 三个版本的 RTC 有一系列令人印象深刻的特性，如图 2 所示。将其与我认为有必要的协作属性相比较，您将看到十分匹配。 我特别喜欢 RTC 的地方是它提供的察觉功能，以及过程定制潜能。现在，团队成员可以看到任意时间其他人在做什么，如果有问题提出，并且回答的人在线，那么程序员可以很容易地协作获得答案并确保他们对任何问题都达成协定。在我看来，这是向前迈出的一大步。 在本文中，我没有讨论太多关于过程的内容。但是，不论写不写出来，每个团队都有一个过程。RTC 交付一个现成的直截了当的敏捷过程。但该过程不用许多工作就可以定制。我还没有多该过程进行过许多定制，但我期望今年给我的学生一个完整，简单的过程。 如果您还不了解 RTC，那么我推荐您看看。前三个用户可以免费得到 Express 编辑器。您可以感受一下我所谈论的。
图 2：IBM Rational Team Concert 特性 结束语 我们正看到协作支持工具变革的开始。Jazz，虽然令人印象十分深刻，但仅仅是个开始。我寻找许多开始发布附加的协作功能的软件工具厂商。我希望产生某个互通标准的合理集合，以便开发人员可以自由采用他们觉得最舒适且多产的工具，并且仍旧能够与使用不同工具的团队成员协作。 我期望对创造力的支持可以像协作支持同样重要，越来越不易改变。我将在后面的文章中讨论创造力支持。 |
