大家疑问 | 嘉宾答疑 |
| | 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 各位好，很荣幸参加这个活动，与大家一起探讨配置管理这个话题。 |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 本次活动主要谈论以下几个话题1、配置管理工作开展；2、SVN工具使用；3、日常配置管理遇到的问题 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 同时也希望我在讲的过程中，大家踊跃的提出问题，我们可以一起讨论并分享各自的看法 | |
| @每天读点管理学--IT界小哈罗： #思步专题，微讲坛# #配置管理实战# 如何通过配置管理对需求变更进行服务？ | 胡子慢慢飘 这个问题比较好！我谈下我的看法吧！配置管理工作目的是要做到工作产品完整、一致、可追溯。目前业界有比较成熟的配置管理工具对需求管理进行有效的控制。软件的需求，从提出，分析，设计，实现，验证都需要纳入配置管控起来。有个名词叫需求跟踪矩阵。通过配置管理系统结合软件交付成果和权限 |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 配置管理，从事过软件管理工作的，并不陌生这个话题。实际项目的配置管理工作是如何开展起来的呢？首先及时制定配置管理计划 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 一般比较成熟的公司会由配置管理计划模板，根据公司配置管理规程进行配置管理计划的制定。配置管理计划主要内容有1、配置项识别；2、配置库管理；3、变更管理；4、配置状态发布；5、配置库备份与恢复；6、配置审计。由于每个公司角色职责定义不同会有所不同。 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 先谈谈配置项识别。配置项识别是配置管理工作首要考虑的问题。有效的识别配置项，来确定配置项的管控的范围。这里有个概念配置项一个产品在生命周期各个阶段所产生的各种形式和各种版本的文档程序及其数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项 | |
| @无边无际_se： #思步专题，微讲坛# #配置管理实战# 请嘉宾分享一下分支和回归的经验，比如时机、难点等！谢谢！ | 胡子慢慢飘 谈下我的理解。SVN有建立分支这一功能。通过SVN客户端工具，tag或者copy to方式建立分支。一个分支的建立，确立了一个可重用基础版本。分支出现了，就会出现合并这个概念。SVN客户端工具，提供了如下合并1、分支与主版本合并2、合并两个分支的差异到工作副本。在合并过程中，我们经常回到些冲突 |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 了解了配置项的概念了，配置项识别就好办了。我们结合客户要求、公司规定，根据项目特点，进行配置项的识别。如项目前期的工作任务书、设计规格、与设计的系统交互的接口文档、项目在实际执行过程中的需求分析，详细设计、代码、编译、构建等纳入配置项中进行管控 | |
| @每天读点管理学--IT界小哈罗： #思步专题，微讲坛# #配置管理实战# 我认为理想化的情况下是可以通过配置管理来服务需求变更的，但是很多项目在实际操作的时候，都只认开发库的东西，不关注基线库上的东西，从而导致基线库总是过去式，而不是最新release的，并且变更也不走流程，直接修改开发库上的文档或代码。 | 胡子慢慢飘 是的，这样就会导致配置项不一致。后续项目出现问题，不可回溯。如果出现人员流失，又好花大量的培训等返工成本。无法保证项目的质量 |
| @每天读点管理学--IT界小哈罗： #思步专题，微讲坛# #配置管理实战# 如何通过配置管理对需求变更进行服务？ | 胡子慢慢飘 谈谈我个人看法1、需求细化的力度 需求可以按照质量特性进行划分，就是我们经常说的DFX。项目首先需要满足功能特性。一个系统我们可以分解到子系统、子系统可以分解到模块、模块可以细化到功能点。一般可以将包含增删改查的功能级划分一个单元，有点类似面向对象的需求分析。 |
| @每天读点管理学--IT界小哈罗： #思步专题，微讲坛# #配置管理实战# 如何通过配置管理对需求变更进行服务？ | 胡子慢慢飘 像我们公司为了控制需求的力度明确要求在项目估算的时候一个功能点代码不要超过1k |
| @每天读点管理学--IT界小哈罗： #思步专题，微讲坛# #配置管理实战# 如何通过配置管理对需求变更进行服务？ | 胡子慢慢飘 谈谈问题2吧！实际过程中是存在这种情况的。【分析】原始需求更接近业务用户需求，而在需求分析的时候开发人员更细化面向功能的思维方式。所以产生这种现象。我们可以根据项目特点，确定需求跟踪的程度。例如：在项目前期将些公共功能独立开来，这样可以保证系统可扩展，软件更好的与业务适配 |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 配置项识别出来了，就可以建立项目配置库。项目配置库结构，一般公司都有明确的定义。好的配置库结构方便我们查找存放工作产品。如我们公司对配置库结构进行了分层。大致分为3层，开发库，过程库，发布库。开发库主要是存放代码、分支、编译、构建等。 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 过程库主要存放过程识别的项目工程文档、管理文档和支撑性质的文档。发布库用于存放基线的版本、发布给客户的工作产品等。根据公司角色职责进行来配置项权限分配。 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 变更管理，需要根据公司变更管理流程定义，明确变更活动如何开展。基线计划，根据项目阶段划分，对工作产品进行受控。配置审计：这里的配置审计主要是项目CMO对配置库进行物理审计。当然QA会对项目进行功能审计和配置管理过程审计。 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 配置管理还有个比较重要的活动就是配置状态发布。很多项目经常由于状态发布不及时的原因，导致出现项目网上问题。配置状态发布让整个团队及时了解团队的成果，也会增强团队的成功信心。 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 配置管理备份恢复也是很重要的环节。911事件以后备份是谈论的重要话题。有关配置库备份方法可以在后面配置库管理工具主题谈论。 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 变更管理补充说明：一般变更存在一个CCB（变更委员会）。CCB是站在组织级层面，对变更申请进行评估和分析，识别和评估受影响的所有配置项，确定修改方案、修改人、修改版本、修改时间、验证方式和验证人。 | |
| @CNMOON： #思步专题，微讲坛# #配置管理实战# 在这里请教各位老师吧。一个10万行规模的软件，建立和维护这样一个网状的需求跟踪矩阵需要多少管理成本？得到的收益是什么？有没有统计数据。需求管理和配置管理算是同胞兄弟，不算跑题吧。 | 胡子慢慢飘 一个成熟的公司会将项目的成本投入进行细化，建立度量模型，收集项目收集，并对项目开展偏差分析来有效的控制项目成本。我们可以采用数据统计分析方法，可以将项目特点相似的项目数据分析找到数据的稳态，反应公司的能力。这个能力就是公司的PCB。PCB建立可以对新的项目进行预测。如对需求管理成本预测 |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 配置管理计划制定好了，我们按照配置管理计划实施项目，并开展计划偏差控制。项目配置管理工作基本上可以做到位。实际项目存在很多变数。大家可以踊跃提问，我们可以一起来分析问题解决问题。 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 接下来，我们谈谈配置管理工具篇吧！配置管理工具有很多，如：SVN,CVS,Clearcase,vss等。这些工具有各自的优点缺点。我们今天就谈谈SVN。 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# SVN操作典型的工作周期是这样的：更新工作副本SVN Update；做出修改SVN Add，SVN Delete，检查修改SVN Diff，SVN status 合并别人的修改到我的工作副本SVN update，SVN resolved提交人的修改SVN commit 这些常用的方法都不陌生。主要是分支、合并、冲突，多人修改同一文件出现的问题比较频繁。接下来着重讲解下这方面内容，同大家讨论 分支用来维护独立的开发支线，在一些阶段，你可能需要将分支上的修改合并到最新版本，或者将最新版本的修改合并到分支。分支可以通过tag或copy to方式进行建立。只要注意给新的分支命名，不要与建立分支的目录下的目录名称重复。 分支建立了就存在合并。合并时候要注意：将分支合并到最新版本上,在合并之前，要先把分支进行提交,并保证两个文件夹的版本相同 同时执行clearup操作来解除该文件夹下的所有锁,在工作副本或主流(这里的选择是根据你是要把分支与主流同步还是要把分支合并到主流上来定)上右击选择TSVN →Merg出现对话框:选择合并类型1把分支与主流进行同步2把分支合并到主流上3表示合并两个分支的差异到工作副本 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 日常中由于操作不当出现很多稀奇古怪的问题。我在这里收集了一些问题和解决办法给大家分享下。 本地删除 1)本地删除，指的是在客户端delete了一个文件，但还没有commit，使用revert来撤销删除. 2)Update上一个版本，但这只适用于修改较少的情况。 服务器端删除 不管是通过本地删除后提交服务器 还是在在Repo-Browser中删除都可以通过TortoiseSVN-> show Log,找到被删的项选中，点击右键 选择Revert changes from this revision; 在执行提交之前，要先执行Update操作,然后再执行commit操作便能找回删除的文件。 关于两个人同时更改同一个文件，提交时出现版本冲突问题 解决方法一: 首先选择发生冲突的文件，右击选择你要执行的操作,处理完后再选右击选择”标记为已解决” ,最后再点击确定 方法二：在修改文件时对该文件进行锁定,使其它用户不可以对其进行更改 当两个用户同时更改了同一个文件的同一行，而且更改的内容不同时就会出现该冲突. 解决办法为:点击Editconfilct按钮，然后出现对话框:这里可以在最下面的文本框中对冲突进行编辑，修改后再按保存，关闭对话框,再点击上面那个对话框中的Resolved按钮,最后执行Commit. 日常操作主要注意问题总结如下 一、同一个文件如果有可能有多个人会对其进行更改，那么在更改时可以对其进行锁定,这样能避免以后合并时发生冲突.其余使用尽量少对文件进行锁定 二、执行提交前先执行update操作，这样能避免提交是报**已过时错误. 三、增加新文件或文件夹时，如果命名是采用英文来进行命名，则文件名尽量全部采用一致的大小写字母，如果是小写的就全部采用小写，大写就所有文件都采用大写来命名.或者在新增文件或文件夹时先执行update操作 四、检出时不能检出单个文件 | |
| 胡子慢慢飘 大致注意下上面几点就足够了。可能有些朋友会由更好的办法，仅在这里抛砖引玉。 下面我们看下还有哪些问题，我们一起讨论下吧！ | |
| #思步专题，微讲坛# #配置管理实战# 问题1：移动互联网的配置管理工作与传统的软件行业配置管理工作的区别在哪里？ | 胡子慢慢飘 这个问题需要对移动互联网行业比较了解的GGMM来回答了。个人解决好像没有啥区别。可能需要关注行业的不同，找出配置管理工作的重心，在保证质量的前提下开展配置管理工作。 |
| #思步专题，微讲坛# #配置管理实战# 问题2：对于快速迭代或游戏类的配置管理怎么做才能更快速响应及完善配置管理的工作？ | 胡子慢慢飘 快速迭代类项目。注意下每次提交的代码是经过编译成功的；每轮迭代可生成可执行没有问题的版本。严格控制好版本发布环节 |
| #思步专题，微讲坛# #配置管理实战# 问题3：跨地域的移动软件配置管理工作怎么开展？ | 胡子慢慢飘 这个问题比较好。目前项目为了减低成本，虚拟团队扮演着重要的角色。虚拟团队更需要加强团队沟通。包括及时掌握团队人员不同文化差异。借助业绩比较成熟的沟通工具和配置管理工具，跨地域，跨网络来管理项目配置库 |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 有朋友提问：功能配置审计，目的是验证功能和性能与软件需求规格说明书中定义的需求的一致性，就是验证配置项是否符合需求的定义，评估测试方法、开发过程，报告和其他工程和设计文档是否完成；应检查交付件是否正确地完成、有无漏测现象，结论是否为通过等。 | |
| 胡子慢慢飘 #思步专题，微讲坛# #配置管理实战# 功能审计一般由QA和PM以及开发组的Leader一起去做，是通过文档的评审、软件的测试等活动进行的；功能配置审计完毕后，PM提交《需求跟踪矩阵》 |
大家疑问 | 嘉宾答疑 |
| | @胡子慢慢飘： #思步专题，微讲坛# #配置管理实战# 本次活动主要谈论以下几个话题1、配置管理工作开展；2、SVN工具使用；3、日常配置管理遇到的问题 思步科技  ：很高兴做交流分享！ #思步专题，微讲坛# #配置管理实战# // @思步网 :这是今天主题的分享条目，大家可以围绕这些方面交流、提问。 |
| @每天读点管理学--IT界小哈罗： #思步专题，微讲坛# #配置管理实战# 如何通过配置管理对需求变更进行服务？ CNMOON：请教问题1:需求跟踪矩阵的粒度要细分到什么程度？我们目前采用的策略是按需细化。也就是说刚开始建立粗粒度的矩阵，等到变更时再把相应部分细化。但是从组织层面仍无法给设计师具体的准则。问题2:需求和设计是多对多的关系，这样的关系网实践中很难用一个简单的矩阵描述清楚，请问有啥好的建议？谢谢！ | 胡子慢慢飘 谈谈我个人看法1、需求细化的力度 需求可以按照质量特性进行划分，就是我们经常说的DFX。项目首先需要满足功能特性。一个系统我们可以分解到子系统、子系统可以分解到模块、模块可以细化到功能点。一般可以将包含增删改查的功能级划分一个单元，有点类似面向对象的需求分析。 像我们公司为了控制需求的力度明确要求在项目估算的时候一个功能点代码不要超过1k/ 谈谈问题2吧！实际过程中是存在这种情况的。【分析】原始需求更接近业务用户需求，而在需求分析的时候开发人员更细化面向功能的思维方式。所以产生这种现象。我们可以根据项目特点，确定需求跟踪的程度。例如：在项目前期将些公共功能独立开来，这样可以保证系统可扩展，软件更好的与业务适配 王小刚_我是小刚小而刚强 我来提议中可操作的控制业务需求（用户需求）颗粒度的方法。首先，要求需求使用UseCase方法撰写（具体可参考《编写有效用例》一书），然后每一个场景里的一个步骤定义为一个需求单元。由于Usecase的每一个步骤代表系统与用户的一次交互，所以颗粒度大体上是一致的。 质量市场学：// @思步网 : @CNMOON // @胡子慢慢飘 :谈谈我看法1…… |
| | CNMOON：对的，我们就是需要制定类似这样的准则。那我明白了:根据自身的领域特点制定，比如工控软件可以要求划分到控制指令粒度，信息管理软件按CRUD划分成一个跟踪单元等等。 @胡子慢慢飘 // @思步网 一般可以将包含增删改查的功能级划分一个单元，有点类似面向对象的需求分析。 |
| | @胡子慢慢飘： #思步专题，微讲坛# #配置管理实战# 分支用来维护独立的开发支线，在一些阶段，你可能需要将分支上的修改合并到最新版本，或者将最新版本的修改合并到分支。分支可以通过tag或copy to方式进行建立。只要注意给新的分支命名，不要与建立分支的目录下的目录名称重复。 |
| @CNMOON： #思步专题，微讲坛# #配置管理实战# 在这里请教各位老师吧。一个10万行规模的软件，建立和维护这样一个网状的需求跟踪矩阵需要多少管理成本？得到的收益是什么？有没有统计数据。需求管理和配置管理算是同胞兄弟，不算跑题吧。 | 战略执行与项目化管理_康河水：我的项目化管理系统就是做这个事的，收集人工成本和其他成本数据。 |
| | 胡子慢慢飘： #思步专题，微讲坛# #配置管理实战# 变更管理补充说明：一般变更存在一个CCB（变更委员会）。CCB是站在组织级层面，对变更申请进行评估和分析，识别和评估受影响的所有配置项，确定修改方案、修改人、修改版本、修改时间、验证方式和验证人。 王小刚_我是小刚小而刚强 多说两句：实际操作中存在两种类型的CCB，有决策权的和没有决策权的。“胡子”说的是前一种。但在很多公司CCB实际上是技术咨询角色，即：有权给出变更影响度评估（变更对进度、工作量等项目参数影响的定量评估），但是决策还是高层领导/客户。// @思步网 : CCB的作用。 #思步专题，微讲坛# #配置管理实战# williams乐悠悠  CCB是战术制定者，等同于PMT之类，你说有决策权的CCB实际上被称为MSG，是战略制定者，不等同；其次CM规范会描述什么时机启动决策阶段，所以CCB就是CCB，按照职责来划分，不按名称来划分。// @思步网 : // @王小刚_我是小刚小而刚强 王小刚_我是小刚小而刚强 回复 @williams乐悠悠 :如果不考虑CCB、MSG这些外表的名词，我们实际上讨论的是关于变更的两种决策机制：委员会评估——>委员会决策，当然委员会的组成包括决策人；委员会评估——>高层&客户决策。以我的经验，在国内企业中后者居多——大多数国内企业并不习惯与委员会决策机制。 williams乐悠悠 同意！分析原因：国内大部分IT企业解决的是生存问题，因此期望更快交付产品，所以经常回避复杂的流程。但有积累的企业却会有更多问题思考，决策会要求更严谨些，要知道生物链上层的企业毕竟少些，希望随着IT企业做大做强，能对决策的细节做的更夯实些// @王小刚_我是小刚小而刚强 |
| 欢迎光临 思步网 (http://www.step365.com/) | Powered by Discuz! X3.2 |