面向未来的“协作开发”

版权声明:原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。
否则将追究法律责任。

引子
有一天我在QQ群里发起了一个话题:
“当你从三个以上不同的途径得知同一件事儿,意味着什么?”
我又自问自答的说:
“说明这件事儿要么已经众所周知,要么很快就要众所周知。”

问这样一句话有些莫名其妙?非也,那是因为近期我先后看到了三个词:
Eclipse ECF,IBM Jazz 还有 Google Wave。
其中:
Eclipse ECF,是一个基于Eclipse的分布式应用开发框架,可以用于建造Eclipse插件、工具或者RCP应用,并为这些工具或者应用提供 异步点对点 或者 发布-订阅模式 的消息机制。
Jazz,被IBM定义为下一代协作平台,面向全球化和跨地域团队开发,致力于改变人们协作构建软件的方式——提高软件交付的协作性、效率和透明度。
Google Wave,是一款基于WEB的通信和协作工具,定义为下一代的网络通信平台,虽然尚未公开发布,但其提供的DEMO已经让业界有颇多的猜测和期待。

三个来自世界顶级厂商的产品或者概念,背后传递着完全相同的信息:communication,collaboration。
这说明什么?
我个人认为,这意味着实时、远程协作马上就要变得“众所周知”,马上就要成为下一个大热点,它将借力网络通信的大发展,给我们的生活和工作的很多方面带来改变。作为一个从事软件行业的人,我的直觉告诉我,这可能从根本上影响软件开发过程和模式。

定义协作
协作:可以解释为协调、合作;协调人力和资源,联合起来,共同完成一件事情。

传统的协作(本文将其称为“合作”以示区分),强调计划有序、各司其职,参与者的工作应该尽量内聚,接口应尽量清晰。
而未来的协作,强调的是目标一致、共同参与、默契配合。

举个例子就可以很好的说明合作和协作的差异:
假如你是项目经理,用户发给你一个未完成需求列表,要求你答复每项需求的完成时间。

在合作模式下,你将需求列表转发给相关员工,要求他们在下班之前回复跟自己相关的条目。收到回复后,你需要审核大家填写的内容是否符合要求,对有问题的条 目需要再跟责任人进行确认。如此经过几次往复,你终于可以将统计完毕的表格反馈给用户,这时可能已经有一周的时间过去了。

而在协作模式下,你可以邀请相关员工发起一次协作会话,在简单讲述用户的要求后,请大家共同编辑这份文档(注意,是每个人都在自己的机器旁,但大家同时在 一份文档上工作),每个人都可以寻找跟自己相关的条目并填写意见。作为项目经理的你,可以实时浏览大家填写的情况,并及时给出意见。两个小时之后,你就会 得到一份漂亮的文档反馈给用户。

商业机会
我在群里讨论的时候提到:在一件事情还没有众所周知之前,先知先觉者可以从中寻找一些机会。 那么在“协作”还没有变得如火如荼之前,我们是不是可以寻找到一些机会呢?

答案是肯定的。
我们可以很容易的预见种种需求,其实我们每个人都希望在工作中与别人更好的配合,减少内耗和重复工作量。小到同事之间共同编写一份文档,共同调试一段代 码;再到开发团队远程帮助实施人员解决问题,分布在各地的团队之间合作策划产品和设计;再到公司之间的协作与交流,远程为客户演示解决方案等等,都可以因 为协作的深入而受益。

具体到软件研发领域,如果有足够强大的协同工具,能够将音频、视频、电子白板等媒体手段集成起来,将共同文档编辑、共同代码编写等手段有机整合,使得面对面的交流不再必须,那么软件研发团队实现SOHO也就不是天方夜谭。
一旦软件研发团队实现SOHO,那么以研发为核心的公司将大大节省办公成本,这对资金紧张的初创企业有莫大的吸引力,而一向注重企业文化,提倡弹性工作制的的跨国公司,对这种创新的工作模式,说不定也会有不少拥趸。

何时万事备?哪日东风来?
实际上,2005年的时候,NetBeans就开始向开发工具中加入协作特性,允许多人共同开发代码,但必须基于一个Collaboration Server。这给实战带来了不少麻烦,也许正是这个原因导致NetBeans这一项本来非常有创造性的功能并没有得到广泛流传。

Eclipse在这一点上做的比较巧妙,ECF只是一个框架,第三方可以开发各种插件来兼容目前的各种IM协议,从而使得协同变得更加容易。一年前,国外 的牛人Mustafa K. Isik展示了一段基于ECF的远程协作视频(http://www.vimeo.com/1195398?pg=embed& sec=1195398)更是让无数开发人员为之惊叹。

眼下,IBM和GOOGLE又纷纷加入这个阵营,大力推动“协作”的概念,Jazz致力于将整个软件交付过程变得更加“协作”,而Wave则雄心勃勃的要将协作推向无处不在。

不过还不够,目前产业链还没有形成,参与的厂商还不够多,用户的认知程度还远远不够,网络带宽和硬件水平还需要进一步提升,这一切都制约着“协作”的普及和应用。

可预期的未来
不过这并不影响我们对未来充满憧憬。

在五年内,如果无线网络带宽得到充分释放,而手机终端的能力得到大副提升,我们不难见到拿着手机,一边陪夫人逛商场,一边协作调试代码或者主持设计评审会议的情形。

而再过十年,也许对脑电波的分析技术已经成熟,我们或许可以抛弃键盘鼠标,直接进行“意念编程”或者“意念会议”,从而进入真正的“深层协作”时代。

本文出自 “思考-jinxfei” 博客,请务必保留此出处

展开阅读全文

令人兴奋的"协作开发"

06-25

版权声明:原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。rn否则将追究法律责任。http://jinxfei.blog.51cto.com/831778/169282rnrn[b]引子[/b]rn有一天我在QQ群里发起了一个话题:rn“当你从三个以上不同的途径得知同一件事儿,意味着什么?”rn我又自问自答的说:rn“说明这件事儿要么已经众所周知,要么很快就要众所周知。”rn rn问这样一句话有些莫名其妙?非也,那是因为近期我先后看到了三个词:rnEclipse ECF,IBM Jazz 还有 Google Wave。rn其中:rnEclipse ECF,是一个基于Eclipse的分布式应用开发框架,可以用于建造Eclipse插件、工具或者RCP应用,并为这些工具或者应用提供 异步点对点 或者 发布-订阅模式 的消息机制。rnJazz,被IBM定义为下一代协作平台,面向全球化和跨地域团队开发,致力于改变人们协作构建软件的方式——提高软件交付的协作性、效率和透明度。rnGoogle Wave,是一款基于WEB的通信和协作工具,定义为下一代的网络通信平台,虽然尚未公开发布,但其提供的DEMO已经让业界有颇多的猜测和期待。rn rn三个来自世界顶级厂商的产品或者概念,背后传递着完全相同的信息:communication,collaboration。rn这说明什么?rn我个人认为,这意味着实时、远程协作马上就要变得“众所周知”,马上就要成为下一个大热点,它将借力网络通信的大发展,给我们的生活和工作的很多方面带来改变。作为一个从事软件行业的人,我的直觉告诉我,这可能从根本上影响软件开发过程和模式。rn rn[b]定义协作[/b]rn协作:可以解释为协调、合作;协调人力和资源,联合起来,共同完成一件事情。rn rn传统的协作(本文将其称为“合作”以示区分),强调计划有序、各司其职,参与者的工作应该尽量内聚,接口应尽量清晰。rn而未来的协作,强调的是目标一致、共同参与、默契配合。rn rn举个例子就可以很好的说明合作和协作的差异:rn假如你是项目经理,用户发给你一个未完成需求列表,要求你答复每项需求的完成时间。rn rn在合作模式下,你将需求列表转发给相关员工,要求他们在下班之前回复跟自己相关的条目。收到回复后,你需要审核大家填写的内容是否符合要求,对有问题的条目需要再跟责任人进行确认。如此经过几次往复,你终于可以将统计完毕的表格反馈给用户,这时可能已经有一周的时间过去了。rn rn而在协作模式下,你可以邀请相关员工发起一次协作会话,在简单讲述用户的要求后,请大家共同编辑这份文档(注意,是每个人都在自己的机器旁,但大家同时在一份文档上工作),每个人都可以寻找跟自己相关的条目并填写意见。作为项目经理的你,可以实时浏览大家填写的情况,并及时给出意见。两个小时之后,你就会得到一份漂亮的文档反馈给用户。rn rn[b]商业机会[/b]rn我在群里讨论的时候提到:在一件事情还没有众所周知之前,先知先觉者可以从中寻找一些机会。 那么在“协作”还没有变得如火如荼之前,我们是不是可以寻找到一些机会呢?rn rn答案是肯定的。rn我们可以很容易的预见种种需求,其实我们每个人都希望在工作中与别人更好的配合,减少内耗和重复工作量。小到同事之间共同编写一份文档,共同调试一段代码;再到开发团队远程帮助实施人员解决问题,分布在各地的团队之间合作策划产品和设计;再到公司之间的协作与交流,远程为客户演示解决方案等等,都可以因为协作的深入而受益。rn rn具体到软件研发领域,如果有足够强大的协同工具,能够将音频、视频、电子白板等媒体手段集成起来,将共同文档编辑、共同代码编写等手段有机整合,使得面对面的交流不再必须,那么软件研发团队实现SOHO也就不是天方夜谭。rn一旦软件研发团队实现SOHO,那么以研发为核心的公司将大大节省办公成本,这对资金紧张的初创企业有莫大的吸引力,而一向注重企业文化,提倡弹性工作制的的跨国公司,对这种创新的工作模式,说不定也会有不少拥趸。rn rn[b]何时万事备?哪日东风来?[/b]rn实际上,2005年的时候,NetBeans就开始向开发工具中加入协作特性,允许多人共同开发代码,但必须基于一个Collaboration Server。这给实战带来了不少麻烦,也许正是这个原因导致NetBeans这一项本来非常有创造性的功能并没有得到广泛流传。rn rnEclipse在这一点上做的比较巧妙,ECF只是一个框架,第三方可以开发各种插件来兼容目前的各种IM协议,从而使得协同变得更加容易。一年前,国外的牛人Mustafa K. Isik展示了一段基于ECF的远程协作视频(http://www.vimeo.com/1195398?pg=embed&sec=1195398)更是让无数开发人员为之惊叹。rn rn眼下,IBM和GOOGLE又纷纷加入这个阵营,大力推动“协作”的概念,Jazz致力于将整个软件交付过程变得更加“协作”,而Wave则雄心勃勃的要将协作推向无处不在。rn rn不过还不够,目前产业链还没有形成,参与的厂商还不够多,用户的认知程度还远远不够,网络带宽和硬件水平还需要进一步提升,这一切都制约着“协作”的普及和应用。rn rn[b]可预期的未来[/b]rn不过这并不影响我们对未来充满憧憬。rn rn在五年内,如果无线网络带宽得到充分释放,而手机终端的能力得到大副提升,我们不难见到拿着手机,一边陪夫人逛商场,一边协作调试代码或者主持设计评审会议的情形。rn rn而再过十年,也许对脑电波的分析技术已经成熟,我们或许可以抛弃键盘鼠标,直接进行“意念编程”或者“意念会议”,从而进入真正的“深层协作”时代。rnrn本文出自 “思考-jinxfei” 博客,请务必保留此出处http://jinxfei.blog.51cto.com/831778/169282 论坛

分布式协作开发

11-18

我在计划写一个分布式软件协作开发环境,但不知道现在的分布式软件开发中究竟有些什么需求,我希望这个系统既能够适应大教堂和市集等不同的分式布开发模式,也能够适应商业上的分布式开发和开放源码的分布式开发,我真的希望这个系统能够在实际中发挥出它的用处来。希望大家能给我点建议,万分感激。rn下面是我的一些想法:rnrn目的和需求:rn 大规模的软件必然是通过团队的力量来产生。在集中的环境下由于参与整个项目的工作人员可以很方便地交流及共享某些资源,很容易管理,但在分布式环境下就必须要有一个可靠的环境来支持整个软件的开发过程,协调各工作人员之间的工作。据我现有的资料分析,这种需求可能包括以下几个方面:rn1、 交流rn2、 资料库管理rn3、 开发流程管理rn4、 安全性rn所以本软件的目的是实现分布式环境下对协作开发的支持。rnrn详细分析:rn一、 交流rn交流可能是软件协作开发过程中最重要的一部分,为此我准备提供以下几种办法:rn1、 公告板。公告板是用来发送通告的地方。每个人都会收到这种通告,目的是让每个人能及时了解最新的更新信息,它分为系统通告和用户通告两种。用户通告是由开发组内的人员发送的;系统通告则是系统本身发出,提示某些资料的更新及进度的完成情况。例如:市场调查人员在文档区(下面叙述)发布了一份新的调查报告,这时系统就会自动发送这条通告,让每个人知道这一更新信息。该公告板的信息会被长期保存到数据库中。rn2、 会议室。会议室是一个在线讨论的地方。人们在这里发表言论,讨论开发的问题。这里很像一个聊到室,但我想让它能够在上面发送HTML的文本(假若不能,就外加一缓冲来存放非文本信息)。讨论记录会保留一段时间(例如一个星期)来允许工作人员作出会议记录,但不会长期保存,当这些记录被删除时将会发出一系统通告。rn3、 在线呼叫。这是一种即时呼叫方式,类似于ICQ,它允许开发人员作出即时的交流。提供的功能与会议室类似,但所有的信息均不被保留也不发系统通告。rn4、 电子邮件。当呼叫人不在时使用的另一种通讯方式,但本系统不提供任何的邮件客户或服务器,所有这些功能均通过外部程序来完成。rnrn二、 资料库管理rn资料库管理主要分开源代码区,发布区,文档区和共享资料库。管理员也可以另外建立新的区域来存放不同的数据。但这些新建区域都将与文档区使用相同的结构。rn1、 源代码区。源代码区之所以分开是因为它要提供版本控制的功能。这里保留的只是开发过程的中间版本,而不是最终版本。最终版本将会在发布区中发布。提供该区域的目的是利于程序员能够得到自己每一次的修改信息。由于这里要提供版本控制,而不是一般的数据库,所以我打算采用GNU的CVS系统。这里不发送系统通告。rn2、 发布区。显然,这里将会保存开发人员完成的最终版本。如:源代码,组件,二进制数据,用户手册等等。可按发布时间,开发作者,名称,版本号等来分类索引查询。索引信息将会保存到服务器端的数据库中,但具体文件内容将会保存在服务器端的文件系统中。当每一版本发布时将发出一系统通告。rn3、 文档区。这里记录了不同开发阶段,不同角色所产出的文档。可根据需要作出进一步的分类。当中可能有市场调查报告,开发模型论述,用户手册等等。也按时间,作者,名称等来分类索引。索引信息保存在服务器端的数据库中,具体文档内容保存在服务器端的文件系统中。rn4、 共享资料库。这里保存的是开发组的一些共享开发资料。例如:开发库,第三方组件,参考手册等等。它们都是以文件存储于服务器中。必然的索引信息及描述将保存到数据库。因为里面很多资料很可能是以URL的形式存在于别的服务器上。rn这些资料大部分以压缩的形式存在于服务器上,而且均可设置它们的读、写权限,以允许本开发组成员或其它工作组的成员访问(参看安全性)。rnrn三、 开发流程管理rn开发流程的管理中我借用了RUP(Rational Unified Process)的二维结构。因为我觉得分布式协作环境必须能够使用现代软件工程的思想,有科学、合理的组织和管理模式,即使这种模式是因不同的企业而异的。rn1、 进度表(横轴)。进度表预示着整个开发的计划流程。这是由项目经理来制定,各个工作人员都必须充分了解的。里面保存着开发各阶段的起始时间,预期目的,完成情况及总结信息。既预示着未来,也记录着历史。系统会根据各阶段的接近,完成来发出相应的通告,项目经理也能根据实际情况对进度表进行调整。这些信息将长期保存。rn2、 工作流(纵轴)。工作流是项目主管建立的一系列并行的工作序列。如RUP中就提及到分析设计工作流,实现工作流,测试工作流,分发工作流等9个核心工作流。在这些工作流中项目主管将会定义不同角色将要在何时完成何种任务,目标是什么,产物是什么,以及必要时会同步这些工作流。系统通告也会来协助这一过程。例如实现工作流,项目主管通过查看某程序员的任务状态,知道他前面的任务已经完成,于是主管给他一个新的任务,要求他在规定时间内写出实现某一功能的类。这时系统就会把这一任务放入该程序员的任务属性中,同时系统通告也会给该程序员发出一信息,让程序员能够知道这种变化。完成后他将这一任务提交,至此任务完成。这个过程的产出或者程序的中间版本会相应地保存到源代码区和发布区。系统会记录程序这一切的过程。当以后要查看这些历史时,则可通过时间,角色以及产物等来进行多方面的索引查询。rn这2点想法是我对RUP的抽象。但是不同的公司其开发模式必定不相同,所以我在这里只是提供了一个载体及模板,而不能够限制其活动。rnrn四、 安全性rn安全性显然有着至关重要的意义。除了软件本身的结构,服务器及数据库的安全外,我提供以下两种控制方法:rn1、 对于组内成员,项目主管可以根据成员的工作性质而把成员划分到组来进行管理。可以设定各组员的登录帐号及密码,各成员或小组对于上述各个区域的权限。同时可以添加或删除组员,设定各组员的一些参数,如e-mail等。这样方便开发过程中突然的人员变更。rn2、 对于组外成员,即需要相互交流合作的工作组(如Windows工作组与Office工作组),则提供一种组与组之间的信赖关系,使组外成员可以访问由权限设定的某些资料,如共享资料库。rnrn实现概要:rn 本软件的实现我打算采用CORBA来作为中间件,既支持C/S模式,也支持对等模式。一切的中间接口都用IDL来定义,使每一部分都具有分布的可移动性。其中Server将利用Linux作为操作系统,Client将暂且使用Windows,但以后可能会发展到其它平台。具体的实现过程有待以后详细研究。rn 论坛

没有更多推荐了,返回首页