如何更好的控制基线后的配置项

xixiaojing666 · 发表于 2008-5-6 13:24:27

下面说说建立基线后的代码和文档的控制：
我们代码和软件工程的文档在建立基线后，控制手段不太一样。文档的控制是严格的按照变更流程进行执行的。配置项进入基线后，写权限就关闭了，只有读的权限。
流程如下：
变更申请->评估变更大小->审批变更申请->安排变更任务->执行变更任务->对更改后的配置项重新进行SCCB评审->结束变更
其中评估变更大小是由项目经理来进行评估；如果是大变更，项目经理交给SCCB来审批；如果是小变更，由项目经理进行审批。
但是单元测试完成后的代码基线，我们不般不把写权限进行关闭，因为在以后的测试过程中，变更的次数很多，所以只要开发人员在变更时通知PM、CM和相关人员，就可以了。

不知道各位是如何控制代码基线的，欢迎大家来讨论！

上一篇：关于产品分支管理的讨论
下一篇：Subversion培训教程

惹你见笑 · 发表于 2014-4-25 15:06:40

还不错哦，如果再能多分享一些就perfect了！

xixiaojing666 · 发表于 2008-6-18 09:23:20

原帖由 jiayan2000cn 于 2008-6-13 17:06 发表
这些内容我现在比较关注!

你可以在这里提出你的关注问题，或经验分享呀！:)

jiayan2000cn · 发表于 2008-6-13 17:06:12

这些内容我现在比较关注!

xixiaojing666 · 发表于 2008-5-29 08:44:39

感谢一下!
继续支持:victory:

iamredeye · 发表于 2008-5-28 17:14:05

我试试吧：）

瀑布在每个phase结束的时候都是期望相应的文档能够baseline甚至finalize。听起来很美好，流程很清晰，但这也带来了后期问题，主要是requirements / architecture change和quality issue。

迭代认识到了这些问题无法避免，与其消极的等后期来解决问题，不如提前confront the problem。所以迭代的phase不是按照discipline来划分时间线，而是按照风险的解决程度。比如conception解决或更准确的说降低的是business risk；elaboration 是technology。每个phase会按照需要跨多个discipline。

[ 本帖最后由 iamredeye 于 2008-5-28 17:29 编辑 ]

iamredeye · 发表于 2008-5-28 16:50:06

刚好看到一段话，觉得很有意思：“我经常说管理一个瀑布式的或者传统的项目，在项目的前80%非常直接而有趣，在那段时间内，任务是线性的，在一段时间内你可以集中注意于一项规则（比如需求）. 然而当集成和测试开始的时候，你会经常发现不是模版不能整合，测试很费劲，系统架构有缺陷，执行效果很差，就是用户提出这个应用不是他们所需要的。如果你在管理一个瀑布型的项目，你在项目临近结束的时候，需要找一个借口将这个项目转交给另一个可怜人。”

我记得这个论坛里有不止一个人说过他们的项目是高层领导，后来因为“时间问题”，“只好”把撒手不干。。。

xixiaojing666 · 发表于 2008-5-27 11:01:02

原帖由 iamredeye 于 2008-5-27 10:49 发表
这个有点难度啊:Q ，人家可是用一本书的篇幅在讲

你可以挑一两个关注点给我们讲讲呀!:lol

iamredeye · 发表于 2008-5-27 10:49:00

这个有点难度啊:Q ，人家可是用一本书的篇幅在讲

xixiaojing666 · 发表于 2008-5-26 14:21:04

原帖由 iamredeye 于 2008-5-22 17:44 发表
关键是，迭代的phase和瀑布的phase关注点是不一样的，没弄清楚这一点就比较麻烦了。迭代关注的是risk，瀑布关注的是deliverable。

有时间给我们详细讲讲他们关注点的区别！:lol

iamredeye · 发表于 2008-5-22 17:44:32

迭代是比瀑布难玩一些，玩的不好也许就变成了假迭代，真瀑布。

关键是，迭代的phase和瀑布的phase关注点是不一样的，没弄清楚这一点就比较麻烦了。迭代关注的是risk，瀑布关注的是deliverable。

但baselining基本上还是差不多的－－从change control的角度讲

rebeccazxy · 发表于 2008-5-22 15:52:35

关注！！！瀑布的确实比较好管理，迭代的感觉很容易管理混乱，或流于形式。请高手进来讲解下啊

iamredeye · 发表于 2008-5-12 22:01:24

你应该去train 那些pm:lol

xixiaojing666 · 发表于 2008-5-12 15:23:43

这个比喻很好，但是我觉得，真正能实现这个比喻的，恐怕没有。

细想想，计划都在头脑里，一周的事情恐怕能记清楚，但是一周以上的事情呢？
还有就是除非你自己一个人做项目，否则计划怎么沟通呢？别人怎么能知道你脑子里的计划？

iamredeye · 发表于 2008-5-9 14:46:32

原帖由 fishred 于 2008-5-9 11:19 发表
代码基线话，我们按上线来，因为每个月有多次上线，一次上线算一个基线

这个当然没问题。但是CM要解决的主要问题是什么？change control！ “只”baseline代码说明没有主动去control，只是等change来了被动的做些处理而已，具体说就是实现些次要的version control之类的功能。

打个比喻：比如有些PM很自信，“我们根本不需要plan！为什么要plan？！we plan by doing!”他没错啊，为什么要plan呢，还要改来改去，直接做就好了！最后的结果就是他的plan，100％的一致！

不知道这个比喻会不会很垃圾:Q

如何更好的控制基线后的配置项

浏览过的版块

逛了这许久，何不进去瞧瞧？