锁定老帖子 主题:较大项目组的集成周期多少才合理?
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2004-09-07
引用 [当然,如果条件允许,能够实现日集成是比较理想的,
唯一的条件就是你的硬件是不是可以支持这样的集成负载. 引用 我的意思是,在有些条件下,如开发人员过于分散,组织机构混乱,官僚主义严重,组间协调不畅,如果这些问题没有能力解决
你等着失败吧,现在已经不是集成的问题了 引用 做日集成是很不现实的,不能把日集成当教条,毕竟,国内开发人员的生存环境是很恶劣的。
每夜集成不是教条,它是一个项目是否工程化的最低标准.环境不管如何险恶,做到日集成也是必须的.当然这是要在你希望成功,或者你希望可以求得一个比较省力的开发步骤的情况下.如果你确实希望向没头苍蝇一样在代码这代码中乱撞(虽然这个说法很有刺激性,但是我实在找不到合适的词汇表达在一对代码和文档中寻找bug的原因的时候的状态了),而且也喜欢天天为一个bug产生究竟是在谁的模块中有的问题的时候,你确实可以把集成的时间间隔放大到足够大. 引用 另外,关于集成的目标,如果以敏捷的胖子的观点作目标,那么,一般情况下,日集成都是可以的。
集成不是要你就相信你的代码没有集成问题了,就是因为有问题,你才需要作集成.而且我这个人比较相信实际的东西,一个东西修改后是不是被别人都随着处理了,我除了会听别人的汇报,我更愿意看集成和测试的结果. |
|
返回顶楼 | |
发表时间:2004-09-07
如果一个项目需要超过两个人参与,如果只有一件事需要坚持,那就是每日集成。我就是把持续集成作为我的教条,就跟拒绝goto语句一样,我一定要求持续集成,至少是每日集成,否则这个项目我宁可不插足。
|
|
返回顶楼 | |
发表时间:2004-09-07
本来是真不想发言了,看了之后我的那个心急呀,不说两句睡不着,上百人的项目不会是平齐的项目组,应该会有一个核心组,而且项目分组应该也是按照一定的方式分组的,所以在集成这方面大家都没有问清楚具体的情况就开始讨论,我觉得有些掩耳盗铃之嫌,笔者参与过上百人的项目,并且不止一次,结合刚才看到上一贴“敏捷方法中的客户及时参与操作性不强”的感悟。
我感觉大家都很棒,也很坦诚,采用什么样子的方法来管理软件工程就跟我们讨论用什么语言开发一样,各取所需,n年前UP,XP方法没人提出的时候,美国的宇宙飞船不也在飞吗,管理软件开发和管理建筑工程相比较就是存储的介质不一样,工具不一样,人与人的交往都是一样的,我想这一切都不应该是我们唯一的选择。 不过软件开发也要规范,就像ISO9000之类的一样,CMM呀。 RUP真的是不错! |
|
返回顶楼 | |
发表时间:2004-09-07
gigix 写道 如果一个项目需要超过两个人参与,如果只有一件事需要坚持,那就是每日集成。我就是把持续集成作为我的教条,就跟拒绝goto语句一样,我一定要求持续集成,至少是每日集成,否则这个项目我宁可不插足。
:o 这么坚定? 有点算是“教条”吧。 |
|
返回顶楼 | |
发表时间:2004-09-07
两个人的集成?
一个人做一套系统? 代码集成?? 呵呵 |
|
返回顶楼 | |
发表时间:2004-09-08
xp中要求的集成标准:
·所有最新的源代码都被配置管理系统验证合格 ·所有文件都通过重新编译 ·得到的目标文件都通过连接,得到可执行文件 ·系统开始运行,针对系统的测试套件开始运行 ·如果所有的步骤都没有错误、没有人为干涉,所有的测试也都通过了,我们就得到了一个成功的创建。 这显然跟胖子指的标准是有很大差别的, 胖子的标准在xp中不能叫日创建,只是日创建的尝试。 显然,要达到xp标准的日创建不仅仅取决于硬件环境,因为如果创建中由于多个子项目组协调出现错误(编译错误,测试例错误)必须找相关人员来解决,在沟通成本很高的情况下(一般主要是项目组过于分布),相当于一次远程调用,在这种情况下,如果坚持日集成,显然难度是比较大的,当然一个子项目组内坚持日集成是必须的,关键是多个子项目组之间,不知大家有无可参考的经验。 |
|
返回顶楼 | |
发表时间:2004-09-08
agilecat
xp是没有日创建的,xp作的是持续集成,日创建在xp来说根本就是不够档次.由于xp中的集成是持续进行的,那么到底什么时候会有一个版本产生呢?你上面列出的条件就是判断是否得到一个版本的标准. 实施每日构建的最大经验就是马上开始实施每日构建,不管你遇到什么,不管你认为每日构建是不是会实现,都马上开始实施.实施以后你会马上看到其实每日构建并不是困难,根本和沟通之类的说法没有任何关系.影响每日构建是不是可以实施的唯一障碍就是你的硬件,也就是那个负责编译的机器是不是能在一夜的时间内编译出一个新版本.而影响每日构建效果的一个最大因素是你能不能在早期就提供一个比较合理的测试基础. 实际上我对每日构建并不看好,因为其对于bug出现的响应还是比较滞后,而且管理起来也比较让我觉得每天只是在早晨工作.但是这事我觉得也不能绝对化,毕竟要做到持续集成需要的门槛高一些.退而求其次只能是每日构建了.但是每日构建绝对是最低的标准了.nt开发的时候,每一次集成需要18个小时,但是ms并没有因此而放弃这一条最有效的经验. gigix说的一点也不绝对,其实在我看来,别说两个人的项目,就是一个人的项目,没有每日构建也是会出问题的.好在一个人的项目,大家都会自然的去持续集成. |
|
返回顶楼 | |
发表时间:2004-09-08
我晕!!!
那么对于上百人,多个子项目组的项目大概需要多长时间发布一个版本呢? 建议大家调整一下论题方向,我门讨论的是多个子项目组之间松耦合的集成,不是10人以下甚至一两个人项目的集成. |
|
返回顶楼 | |
发表时间:2004-09-08
agilecat
nt的开发队伍是几百个coder,几千个测试员.他们都可以做到你为什么做不到.根本就不是什么沟通问题,而就单纯是一个态度的问题.每日集成并不能消除什么bug,他只是告诉你那个bug还存在.任何一个软件也不可能没有bug. 同时纠正一个你的错误认识.发布一个版本和构造一个版本并不是一个概念,发布时需要满足很多的条件,上面你引用的那些就是xp发布一个版本的时候应该满足的最基本条件,然后还要加上稳定性和性能等等的约束满足需求,文档提供的充分并且和版本同步等等其他条件.但是构造一个版本则简单的多,只要你的代码放在一起就可以算一个版本,即使你并没有对他们作任何的编译也可以算一个版本. |
|
返回顶楼 | |
发表时间:2004-09-08
ozzzzzz 写道 agilecat
我晕!!!
nt的开发队伍是几百个coder,几千个测试员.他们都可以做到你为什么做不到.根本就不是什么沟通问题,而就单纯是一个态度的问题.每日集成并不能消除什么bug,他只是告诉你那个bug还存在.任何一个软件也不可能没有bug. 同时纠正一个你的错误认识.发布一个版本和构造一个版本并不是一个概念,发布时需要满足很多的条件,上面你引用的那些就是xp发布一个版本的时候应该满足的最基本条件,然后还要加上稳定性和性能等等的约束满足需求,文档提供的充分并且和版本同步等等其他条件.但是构造一个版本则简单的多,只要你的代码放在一起就可以算一个版本,即使你并没有对他们作任何的编译也可以算一个版本. 那么对于上百人,多个子项目组的项目大概应该多大频率成功编译,测试也都通过的一个版本呢? 建议大家调整一下论题方向,我门讨论的是多个子项目组之间松耦合的集成问题. 不要问我为什么盖茨那么有钱,而我则那么穷. |
|
返回顶楼 | |