【IT168 专稿】
本文是Rational软件技术征文大赛（http://tech.it168.com/focus/200903/rationalgame/index.html）一等奖获奖作品。
对于IBM Rational的Jazz平台投放市场的这条消息，我是要起立鼓掌的。我一直在思考软件行业将来会是什么样的。我欣喜的看到Jazz已经实现了我心目中的一部分愿景。尽管只是一部分，尽管现在还不能确定Jazz会否真的改变软件行业的将来，至少在我看来Jazz已经往我所憧憬的将来迈出了美妙的一步，也许将会是至关重要的第一步。在我而言，无论如何，Jazz的出现都是值得书写一笔的。在我所憧憬的未来里，“开放协作”和“开发即过程”无疑是两个最重要的主题。我之所以为Jazz鼓掌，原因就在于Jazz让我在这两个方面都看到了希望。
“开放协作”或许已经不是一个新鲜的词汇了，但是至今为止，开放协作的真谛却从未真正在软件开发过程当中成功实现过。可能有人置疑，现在的软件开发都是在团队化运作了，这难道不是协作吗？在我看来，现在开发团队里的各个角色之间的互动仅能称为合作而非协作。两者之间的差异在于，合作是各司其职相互配合来做事情；而协作则是不分你我同做一件事情。在现在的开发团队里，设计师设计，程序员写代码，配置管理员打包，测试人员测试，实施人员安装，他们合作而非协作着完成一个项目。而各个角色所承担的工作之间基本没有开放可言，他们奉行的哲学是你只需要告诉我你要什么，不要管我是怎么做的，更不要干涉我内部的决策；他们相信只有有效的控制才能保证代码的稳定和可靠。
真正的开放协作体现在Web2.0的世界里。例如Wiki，每个人都是贡献者，每个人都可以创造新的和修改旧的，不分你我。Wiki的成功让我们感受到协作的高效和巨大能量，这是任何一个负责编写百科全书的专家小组无法比拟的。因此在这里，我所说的未来的协作是指这样一个场景：在一个协作的平台上，任何人既可以是开发者，又可以是测试者；既可以是需求提出者，又可以是最终使用者；既可以是设计师，又可以是程序员……所有人在力所能及的范围内贡献着自己的力量而不被局限于某一个角色。Wiki和开源社区的成功证明了这样一个基本事实：在一个真正协作的平台上，有规则的向人们开放并不会导致混乱和不负责任的结果，而是恰恰相反。在我看来，在未来的协作场景里，一份需求、一个设计、一个问题的讨论不再局限在某几个人或某一个小组里 ，不再需要把文档发出去、反馈、修改、再发出去……这样低效的反复。不论是设计师、程序员、测试员、用户，都可以参与共同编写项目文档，就如同Wiki里的词条一样，经历无数人的共同编写以后，留下了最正确的那一个版本。
尽管Jazz目前并没有完全提供这样的协作，也未必完全认同这种理念。不过Jazz的确是目前为止距离真正协作最为接近的开发平台。从Jazz采用的开发模式——开放商业软件开发模式（open commercial software development）可以看出这种开发和协作的倪端。Jazz.net允许客户在项目早期参与进来就体现了有效协作的精神。在这种开发模式下，客户不再被动的接受结果 ，他们可以成为设计的参与者、早期版本的测试者，甚至项目决策的参与者。
尽管在Jazz平台里我们还不能够完全协作的同时做同一件事情，例如身处异地的开发人员和测试人员共同调试一段代码，至少Jazz这两个角色之间的信息是快速共享的。开发人员不必再每天切换到ClearQuest里查看defect状态，测试人员也不必再每日询问patch是否打好。Jazz让快速的信息共享成为可能，项目组成员不必再在众多工具当中切换来切换去的寻找需要的信息。仅就这一点，Jazz就值得我的掌声。
“开发即过程”！我十分惊喜的发现“开发即过程”这个词组在Google和百度上搜索的结果都是零！在这个信息爆炸的时代能够创造出一个词组是值得惊喜的，说明我吃到了第一只螃蟹！如果可以申请专利！？如果现在就有一个Wiki来记录那些创造出新词汇的人们！？呵呵，或许我也有机会在历史上留下一个足印……闲话了几句，还是书归正传吧。
长久以来，开发被归为技术范畴，过程被归为管理学范畴。学科分类如此，社会分工也如此。自从软件危机发生，人们引入软件工程学以来，软件技术和软件方法一直是在两个分枝上发展的。软件技术从结构化设计到面向对象，从J2EE到SOA；软件方法从ISO到CMM，从RUP到敏捷；然而软件成功最为关键的这两项技术却遗憾的处于一种分离的状态。在一个典型的项目里，质量部门、项目经理或过程小组设定一个软件开发过程，搭建管理工具；技术经理、架构师或设计师做出技术决策，决定开发环境；于是，开发人员在学习软件技术和使用IDE工具之外，还要学习和遵守软件过程，使用软件过程工具。开发人员懂得软件过程是必不可少的，但就他们的感受而言，在写代码的同时遵守软件过程和使用过程管理工具多少都是一个负担；尤其当软件过程过于复杂以至于拖累开发效率的时候。而我所憧憬的“开发即过程”是这样一种场景：软件方法服务而不是管理软件开发，它隐藏在开发背后，开发人员在开发过程当中感受不到过程的存在。这正如一条高度自动化的生产流水线,，生产过程隐藏在流水线背后，流水线上的工人只需要专心的完成自己的装配工作。
开发即过程意味着，我们需要这样一个平台，它将软件方法和软件技术集成在一起，开发人员只需像流水线上的工人一样，拿到自己的任务，完成自己的任务然后提交自己的任务。而软件方法则在背后默默完成配置管理、质量管理、项目管理等软件方法范畴的工作。
Jazz再次赢得了我的掌声。这并不是因为Jazz集成了配置管理、质量管理等工具，更重要的是Jazz将软件过程管理也集成到了开发工具当中。可配置的开发流程让Jazz拥有了定制高度自动化生产流水线的可能，Jazz不仅仅是实现软件技术的IDE，同时Jazz也是开发流程的管理平台。我很高兴能看到这样一个场景：软件管理人员在Jazz里定制开发流程来体现软件管理方法，将软件管理工具集成到Jazz里实现对开发的管理；开发人员使用Jazz完成开发工作任务的同时也完成了软件管理的任务。我相信如果流程定义适当，Jazz的这个特性一定会受到程序员欢迎并大幅提高生产效率！
掌声之余不得不说，现在的Jazz仅仅是一个开始。Jazz对“开放协作”和“开发即过程”这两方面的支持也不是完美的，例如离我心目中真正的“开放协作”也有一些距离。并且我对Jazz的期望可不仅仅是“开放协作”和“开发即过程”，而是还有更多的期望。例如项目文档协作（不仅仅是分享，类似GoogleDoc）、自动社区信息集成（将开发过程社区化）、代码地图（ 图形化快速定位代码）、代码依赖RSS（获知所依赖代码的变更）、虚拟共享计算环境（这需要通过云计算获得，我期望异地协作者不仅仅是通过即时通讯工具等沟通，而是就如同两个人并排坐在 一台计算机面前）等等……这些想法在我脑子里很久了，今天就这个时机简单的把它们罗列了一下，等以后我将再撰文详细讨论这些愿景的细节。
最后，期待Jazz能够成功，并且由此引发软件行业的下一个大事件。
