请大虾说一下
21 个解决方案
#1
首先，配置管理之中的版本管理使得产品井然有序，减少了因为版本混乱而引起错误的机会，从而减少了发现/修正这些错误而产生的内耗。
其次，配置管理之中的变更记录使得统计产品的缺陷分布成为可能，为分析产品质量提供了数据，从而为进一步优化产品质量提供了着眼点。
暂时就想到这么多……
其次，配置管理之中的变更记录使得统计产品的缺陷分布成为可能，为分析产品质量提供了数据，从而为进一步优化产品质量提供了着眼点。
暂时就想到这么多……
#2
其实老李说的是，在这次实践中，你做了什么，取得了什么样的效果：（
我现在想说，我作为配置管理员，对小组的工作空间进行划分，每天由项目经理安排schedule，然后由我来分配到开发人员，就是在Clearcase中的活动分配的执行者，你觉得这样如何？？
我现在想说，我作为配置管理员，对小组的工作空间进行划分，每天由项目经理安排schedule，然后由我来分配到开发人员，就是在Clearcase中的活动分配的执行者，你觉得这样如何？？
#3
还有想说的说（吹）的是，进行更新集成工作区，并通知开发人员同步私有工作区
如何？？^_^
因为他说要实际做点东西,不能光是说概念
如何？？^_^
因为他说要实际做点东西,不能光是说概念
#4
嗯，
划分工作空间，设置权限，搭建开发环境、测试环境。
schedule应该由项目经理发送给leader，由leader分发，要不然就没有权威性了。
其它的随你吧！
划分工作空间，设置权限，搭建开发环境、测试环境。
schedule应该由项目经理发送给leader，由leader分发，要不然就没有权威性了。
其它的随你吧！
#5
还想再吹的话就说说做缺陷分析，提供品质强化计划。
#6
就没有其他工作了吗?
比如建立基线,晋升基线什么的?
另外搭建开发环境和测试环境都要干吗啊?
比如建立基线,晋升基线什么的?
另外搭建开发环境和测试环境都要干吗啊?
#7
因为我觉得整个项目的开发环境和测试环境不可能由我来搭建
我一说人家肯定知道我是在吹呢
我一说人家肯定知道我是在吹呢
#8
要说在一个TEAM里做点什么事情还是不容易被人怀疑的吧
#9
我们不常建立基线。
有也就是几次纳品吧：PD1、PD2、Coding、UT1、UT2、品质分析、品质向上。
至于开发环境和测试环境，你说我和客户研究之后由你搭建的不就结了。
测试环境有个详细的说明，是个execl文档，你找一下吧。
里面记载了整个测试目录的结构，各个子目录的用途，文件的存放，环境变量的设置，脚本文件的使用等等。
其实那个测试环境真的是我想好后找人实施的。不过不是你。:)
有也就是几次纳品吧：PD1、PD2、Coding、UT1、UT2、品质分析、品质向上。
至于开发环境和测试环境，你说我和客户研究之后由你搭建的不就结了。
测试环境有个详细的说明，是个execl文档，你找一下吧。
里面记载了整个测试目录的结构，各个子目录的用途，文件的存放，环境变量的设置，脚本文件的使用等等。
其实那个测试环境真的是我想好后找人实施的。不过不是你。:)
#10
>要说在一个TEAM里做点什么事情还是不容易被人怀疑的吧
当然是统计进度了
;)
很没有意思、很锻炼人忍耐能力的工作……
当然是统计进度了
;)
很没有意思、很锻炼人忍耐能力的工作……
#11
关键是我不知道搭建开发环境都干什么
到时候有人一问不就露馅了
到时候有人一问不就露馅了
#12
还有划分工作空间的工作都做什么啊
#13
首先，要建立一大堆目录。放我方source的目录、客户方source的目录、客户提供的lib的目录、测试驱动的目录、庄模块的目录、存放测试数据的目录、输出测试结果的目录……子目录下又有子目录，光是那个目录树就打印了10多页……@_@建好目录就把东西往里装，由于是AIX，还要注意设置模块的可执行权限。
然后就是把环境变量的设置写成脚本，放到测试目录的根目录下。
再然后就是在放source的目录下编写makefile。从最下边的目录写起，一层层汇总，最后汇成一个总的makefile。（如果你不会写，就告诉别人你是按模板填的好了……）
确认一遍，把这些东西都扔到ClearCase里边去，测试环境就算搭好了:)
然后就是把环境变量的设置写成脚本，放到测试目录的根目录下。
再然后就是在放source的目录下编写makefile。从最下边的目录写起，一层层汇总，最后汇成一个总的makefile。（如果你不会写，就告诉别人你是按模板填的好了……）
确认一遍，把这些东西都扔到ClearCase里边去，测试环境就算搭好了:)
#14
makefile 是什么啊?是测试代码的外曾代码吗?
还是编译环境?
还是编译环境?
#15
模板什么样啊?
#16
这东西涉及的东西太多了,哥们就怕他们瞎问了
#17
>工作空间
应该是各个开发人员负责的source/文档的集合吧。
这可是你提出来的啊，我不是很懂的说……
说实话我挺讨厌UCM那个破玩意儿的。
应该是各个开发人员负责的source/文档的集合吧。
这可是你提出来的啊，我不是很懂的说……
说实话我挺讨厌UCM那个破玩意儿的。
#18
哎...我也没办法啊，可是已经写到这一步了:(
早知道就写点代码,做个小程序得了:(
早知道就写点代码,做个小程序得了:(
#19
makefile是一种表达文件依赖关系的有特定格式的文本文件，有编译工具makefile使用，以达到部分编译的效果。
模板就是说，我写好了主要的框架，留下一些空白让你填空。:)
模板就是说，我写好了主要的框架，留下一些空白让你填空。:)
#20
别太担心了，他们再狠也不会让你不过吧。
#21
再说那帮老师也没有什么实践经验，他们也未必懂的……
#1
首先，配置管理之中的版本管理使得产品井然有序，减少了因为版本混乱而引起错误的机会，从而减少了发现/修正这些错误而产生的内耗。
其次，配置管理之中的变更记录使得统计产品的缺陷分布成为可能，为分析产品质量提供了数据，从而为进一步优化产品质量提供了着眼点。
暂时就想到这么多……
其次，配置管理之中的变更记录使得统计产品的缺陷分布成为可能，为分析产品质量提供了数据，从而为进一步优化产品质量提供了着眼点。
暂时就想到这么多……
#2
其实老李说的是，在这次实践中，你做了什么，取得了什么样的效果：（
我现在想说，我作为配置管理员，对小组的工作空间进行划分，每天由项目经理安排schedule，然后由我来分配到开发人员，就是在Clearcase中的活动分配的执行者，你觉得这样如何？？
我现在想说，我作为配置管理员，对小组的工作空间进行划分，每天由项目经理安排schedule，然后由我来分配到开发人员，就是在Clearcase中的活动分配的执行者，你觉得这样如何？？
#3
还有想说的说（吹）的是，进行更新集成工作区，并通知开发人员同步私有工作区
如何？？^_^
因为他说要实际做点东西,不能光是说概念
如何？？^_^
因为他说要实际做点东西,不能光是说概念
#4
嗯，
划分工作空间，设置权限，搭建开发环境、测试环境。
schedule应该由项目经理发送给leader，由leader分发，要不然就没有权威性了。
其它的随你吧！
划分工作空间，设置权限，搭建开发环境、测试环境。
schedule应该由项目经理发送给leader，由leader分发，要不然就没有权威性了。
其它的随你吧！
#5
还想再吹的话就说说做缺陷分析，提供品质强化计划。
#6
就没有其他工作了吗?
比如建立基线,晋升基线什么的?
另外搭建开发环境和测试环境都要干吗啊?
比如建立基线,晋升基线什么的?
另外搭建开发环境和测试环境都要干吗啊?
#7
因为我觉得整个项目的开发环境和测试环境不可能由我来搭建
我一说人家肯定知道我是在吹呢
我一说人家肯定知道我是在吹呢
#8
要说在一个TEAM里做点什么事情还是不容易被人怀疑的吧
#9
我们不常建立基线。
有也就是几次纳品吧：PD1、PD2、Coding、UT1、UT2、品质分析、品质向上。
至于开发环境和测试环境，你说我和客户研究之后由你搭建的不就结了。
测试环境有个详细的说明，是个execl文档，你找一下吧。
里面记载了整个测试目录的结构，各个子目录的用途，文件的存放，环境变量的设置，脚本文件的使用等等。
其实那个测试环境真的是我想好后找人实施的。不过不是你。:)
有也就是几次纳品吧：PD1、PD2、Coding、UT1、UT2、品质分析、品质向上。
至于开发环境和测试环境，你说我和客户研究之后由你搭建的不就结了。
测试环境有个详细的说明，是个execl文档，你找一下吧。
里面记载了整个测试目录的结构，各个子目录的用途，文件的存放，环境变量的设置，脚本文件的使用等等。
其实那个测试环境真的是我想好后找人实施的。不过不是你。:)
#10
>要说在一个TEAM里做点什么事情还是不容易被人怀疑的吧
当然是统计进度了
;)
很没有意思、很锻炼人忍耐能力的工作……
当然是统计进度了
;)
很没有意思、很锻炼人忍耐能力的工作……
#11
关键是我不知道搭建开发环境都干什么
到时候有人一问不就露馅了
到时候有人一问不就露馅了
#12
还有划分工作空间的工作都做什么啊
#13
首先，要建立一大堆目录。放我方source的目录、客户方source的目录、客户提供的lib的目录、测试驱动的目录、庄模块的目录、存放测试数据的目录、输出测试结果的目录……子目录下又有子目录，光是那个目录树就打印了10多页……@_@建好目录就把东西往里装，由于是AIX，还要注意设置模块的可执行权限。
然后就是把环境变量的设置写成脚本，放到测试目录的根目录下。
再然后就是在放source的目录下编写makefile。从最下边的目录写起，一层层汇总，最后汇成一个总的makefile。（如果你不会写，就告诉别人你是按模板填的好了……）
确认一遍，把这些东西都扔到ClearCase里边去，测试环境就算搭好了:)
然后就是把环境变量的设置写成脚本，放到测试目录的根目录下。
再然后就是在放source的目录下编写makefile。从最下边的目录写起，一层层汇总，最后汇成一个总的makefile。（如果你不会写，就告诉别人你是按模板填的好了……）
确认一遍，把这些东西都扔到ClearCase里边去，测试环境就算搭好了:)
#14
makefile 是什么啊?是测试代码的外曾代码吗?
还是编译环境?
还是编译环境?
#15
模板什么样啊?
#16
这东西涉及的东西太多了,哥们就怕他们瞎问了
#17
>工作空间
应该是各个开发人员负责的source/文档的集合吧。
这可是你提出来的啊，我不是很懂的说……
说实话我挺讨厌UCM那个破玩意儿的。
应该是各个开发人员负责的source/文档的集合吧。
这可是你提出来的啊，我不是很懂的说……
说实话我挺讨厌UCM那个破玩意儿的。
#18
哎...我也没办法啊，可是已经写到这一步了:(
早知道就写点代码,做个小程序得了:(
早知道就写点代码,做个小程序得了:(
#19
makefile是一种表达文件依赖关系的有特定格式的文本文件，有编译工具makefile使用，以达到部分编译的效果。
模板就是说，我写好了主要的框架，留下一些空白让你填空。:)
模板就是说，我写好了主要的框架，留下一些空白让你填空。:)
#20
别太担心了，他们再狠也不会让你不过吧。
#21
再说那帮老师也没有什么实践经验，他们也未必懂的……