较大项目组的集成周期多少才合理?

有人说： 集成的难度与集成周期的平方成正比。
也就是说 日集成的难度是周集成难度的 1*1：5*5 即 1：25。

我主要担心的时间问题,在代码初始阶段，如果修改一个基础组件的接口，不能保证其他相关项目组能够当日及时更新调用方式,那么作日集成?

初期100%会出现集成的时候报错的问题,而这就是你需要的信息阿.每日集成不是说你每天都可以得到一个完美的集成,只是告诉你要在每一天都作集成,这样才可以告诉你究竟问题在上面地方,是不是可以进一步的去进行下一步的工作.而且你还可以利用分支,把问题的修改隔离起来.这个时候也就是你把你的修改造成的问题,划分为一个分支版本,针对这些修改的测试只是针对这个版本进行.当这个版本的测试都通过一个再合并到主版本中.但是我觉得这样的办法并不是很好,因为当你修改了基础性的接口以后,你应该消化好这个修改之后再前进.莽撞的做一个分支,就需要维护两个版本,这样做会带来很多麻烦.当然这首先是要你判断这个接口的修改是不是真的是很基础性的,后果很严重的.

看来大家都主张日集成,敏捷的胖子提出的"日集成不是说你每天都可以得到一个完美的集成,只是告诉你要在每一天都作集成"很有参考价值,不知大家有无百人以上团队的管理经验,我经历过的几个最好的才做到周集成,周五下午每组抽一人专门作集成,现在想作日集成,问题多多啊,如果都是10人以下的项目该多好啊!!

agilecat
项目规模越是大就越是要坚持小的集成规模.如果你的集成周期太久,那么遇到问题就很难找到究竟出在什么地方.特别是人数众多的项目,很多问题如果不早发现,到后来就成为一桩无头案,很多人知道有问题,但是就是不敢解决,因为谁也不敢负责任.这方面的讨论可以看看xp有关持续集成的论述.
这里说点题外话,我只有一次40左右的项目经验.其实真正开发的只有20个人,其余的基本都是测试人员(此项目的稳定性和安全性要求比较高,所以必须经过大量的测试,人员有很多外来的),然后是需求人员(负责需求的梳理和测试计划的制定).给客户看的功能模块有40多个,但是实际上系统内的结构模块只有6个.现在回忆起来,这个项目最后的结果是不好不坏,基本达到了客户的要求,但是开发方的要求(也就是建立一个基础构件体系)并没有达到.我事后总结,由于开始阶段并没有一个统一的强有力的领导,造成很多扯皮的事情发生.特别是这些扯皮会逐渐造成内部人员的不信任,从而使问题得不到解决.比如一个功能,就是交互的编辑同一个文件的功能,就是由于开发版本管理的人员和开发文档对照的人员之间有问题,到最后也没有实现同时在线编辑,而只是向cvs那样提交以后合并.实际上根本问题在于文档格式的制定者那里没有把文档的格式制定好,从而造成另外的人的麻烦,而这个制定格式的人是个老人,威望很高,所以没有人非议或者是敢非议他的决定.另外还有一个问题就是测试进度还是没有把握好,我认为问题出在测试计划也就是testcase书写进度落后.大概是当时这个小组的负责人还负责别的项目的部分工作,所以投入的精力不足.虽然最后测试没有出问题,而且运行情况也不错,但是我认为那纯粹是我们运气好.这里其实也牵涉到一个集成的问题,由于功能测试的很多工作需要手工完成,所以尽早的开始提交一个可以运行的不完全版本就显得很重要.而我本来最担心的结构设计不能很好的协调的问题,反倒没有发生.大概大家从一开始就明白这个地方是问题的难点,所以基本上还可以互相协调配合.而奇怪的是这个结构的协调,并没有带来基于结构的功能协调,也没有带来修改bug工作的协调,因此才有上面提到的种种扯皮.

转自 IBM developerWorks中国网站<XP活用原则>
...
集成频度的制定取决于团队的规模和沟通质量。对于小的团队而言，一小时一次的集成也是可行的。对于大的项目，可以划分子团队，子团队中采用频繁集成（一小时一次），子团队之间采用日集成（每天集成一次）。有了子团队的集成保证，整个团队的集成一般不会有什么问题。
...

我终于明白大项目日集成的困难了,这就是,孤立的使用xp的少数实践,
在我们项目. 沟通成本是很高的(汇报\领导,领导之间例会,任务下发),这就不符合xp的一个重要原则,所以在现有组织机构不变的情况下,日集成就不太现实,也许子团队中采用日集成，子团队之间采用周集成更现实一点.

agilecat
你依然没有理解阿.能阻碍日集成的唯一理由就是你的硬件环境不能支持一日一集成.所谓的沟通成本根本就和日集成没有什么关系.虽然你高频度的部分集成会大大降低问题的出现频度,但是这并不能保持就不会出现集成问题,而且一旦出现这样的集成问题将非常难被克服.而如果你再不能坚持一个小的集成频度,基本上你的这些集成错误,就不可能得到修正.
集成的频度必须以日为最大的单位,这一点几乎没有任何一个SCM专业人员会有异议.而不管你是持agile还是传统的重型方法论,都不会在集成的频度上有分歧.

集成的频度必须以日为最大的单位? 虽然我知道许多成功软件公司都是日集成,agile方法也提倡日集成,但是我从没听说过集成的频度必须以日为最大的单位,当然我不是SCM专业人员,但是我所知的几个国内知名大公司做的比较好的也就是周集成,甚至月集成,照你的理论,我所知的几个国内知名大公司就没有SCM专业人员了,他们都至少通过了cmm4,都有很成功的产品.

沟通成本根本就和集成频度没有什么关系?我不敢轻易认同,毕竟"集成频度的制定取决于团队的规模和沟通质量" 是我引用国外大师的话,虽不能盲从,但也不敢轻易否定.

每周集成肯定不会是什么好办法。要是一周之后才把大家的东西凑到一起，我估计起码得花一整天时间来解决一些原本不该出现的问题。要是每月集成……我能力不足，这种项目我肯定做不了。

当然，如果条件允许，能够实现日集成是比较理想的，我的意思是，在有些条件下，如开发人员过于分散，组织机构混乱，官僚主义严重，组间协调不畅，如果这些问题没有能力解决，做日集成是很不现实的，不能把日集成当教条，毕竟，国内开发人员的生存环境是很恶劣的。另外，关于集成的目标，如果以敏捷的胖子的观点作目标，那么，一般情况下，日集成都是可以的。