蜗牛在前进

 用EXCEL来工作的时候，常常会碰到清空表格里面的内容的需要。如果用手去清空的话，有点麻烦。用代码以点就可以实现这个功能。

这个代码使用来删除TEXT的

worksheet(“sheetname”).range(cells(11，2），cells(500,4)).clearcontents

这个是用来删除COLOR的 很方便的！

worksheet(“sheetname”).range(cells(11，2），cells(500,4))..interior.colorindex = xinone

软件配置管理是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性，控制这些特性的变更，记录和报告变更的过程和状态，并验证它们与需求是否一致。

　　“配置第一”这个理念是一位IT公司的项目经理告诉我的，他用了“深刻教训”四个字来为这个言论作注脚。他告诉我这样一件事：

　　这家公司曾为电信企业开发一个手机收费的中间业务系统。按规定，系统的收费平台应根据第三方传来的手机资费信息进行扣款。其中，负责网络通讯的路由器是由多家厂商提供的。

　　在项目试运行阶段，系统运行一切正常。这时，有一家路由器厂商（以下简称A厂商）要升级运行程序，网络通讯接口要变，A厂商向电信提出了修改接口程序的提示。负责项目开发的这家IT公司很快完成了通讯接口修改，和A厂商联调测试无误后，准备将接口程序发布运行。负责程序发布的老兄嫌版本发布流程太麻烦，便走捷径，私自将程序更新上线了。未料到，接口的改变影响了电信与其他厂商路由器的数据通讯。途经A厂商路由器的通讯数据没有问题，可其他品牌的路由器却收不到信息了。后果是：当天电信用户的手机资费信息数据报大量遗失，相关电信资费损失无法挽回。

　　负责软件承包的IT公司境遇可想而知。“痛定思痛，痛何如哉！”从此，该公司痛下决心，买工具、定规范、搞培训，将配置管理切切实实地作为日常重点管理工作来抓。

　　配置管理是什么“东东”，它真这么重要吗？

　　软件配置管理是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性，控制这些特性的变更，记录和报告变更的过程和状态，并验证它们与需求是否一致。

　　简而言之，配置管理（Software Configuration Management ， 简称SCM）就是对软件产品的配置项进行控制和管理。它的目标是最大限度的减少错误和混乱，保证软件项目工作产品在整个生命周期内的完整性。

　　配置管理的对象是配置项，主要包括：接口描述、过程描述、需求、设计、测试计划、测试结果、代码及模块、工具、系统参数、版本描述等。配置项与配置人员、配置工具、配置规范等构建起了整个配置管理体系。

　　配置管理的出现是项目发展的必然结果

　　软件技术迅速扩展，项目开发日趋复杂，人员数量不断扩充，系统开发平台多样化，开发及测试场所分布各地，开发规模日益扩大，随之而来的管理复杂性急剧增加。

　　软件开发永远不变的特点就是变化，需求变更、技术更新、人员变化、环境变化、架构变化等层出不穷，所有这些使项目风险大大增强，如何应对并追溯变化，从而控制变化，是一个重要课题。

　　软件系统越做越大，产品组件动辄上千，多者上万，版本控制如何着手，令人头痛。

　　“乱世出英雄”，配置管理便在这样的环境下应运而生了。

　　配置管理的管理范围恰是项目开发、协调最混乱的地方：

　　交付给用户的软件产品（需求、源代码等）

　　软件产品的外部产生“环境”（操作系统参数、编译程序等）

　　对项目内部而言工作产品（过程描述、流程控制等）

　　那么，这种管理的特点是什么呢？它到底能带来什么好处呢？

　　特点

　　相对独立。配置管理相对独立于其他管理控制活动，它可以在其他活动都未开展或还不成熟的时候独立进行。

　　是其他各项管理的基础。需求管理、需求变更、资源变更、系统维护、合同管理、计划管理、文档管理等都是在配置管理这个“平台”基础上进行的。

　　优点

　　对项目产品单元进行统一的版本变更管理，统筹安排系统的修改、发布以及系统资源的使用，预防开发的进程混乱，保证系统版本的完整和一致。

　　支持并行开发与维护。软件开发过程时常要求多个开发人员同时在同一个软件模块或项目文档上工作，同时对同一个代码或文档部分作不同的修改，配置管理能满足这样的要求，同时使跨平台、跨地域的并行开发成为可能。

　　使项目管理人员能掌握项目开发进度。配置管理系统可以提供配置状态报告，对每日变更完成的工作量、开发中存在的问题等会有详尽的反映。

　　减少人员变动对项目带来的影响。项目的变更轨迹可跟踪，文档的增删、代码的修改、参数的改变、配置项的状态、基线之间的差异等都有案可查。参照变更的原因、内容描述等内容，我们便可对项目的开发进程有详细而完整的把握，从而避免对相关人员的过分依赖。

　　配置管理的重点工作描述

　　1） 配置项识别

　　软件配置管理工具的选择

　　“工欲善其事，必先利其器”，配置工具的选择对配置管理的好坏影响巨大。

　　配置工具是配置管理的自动化平台，是一个管理具体实施的基础。一套功能强大、实施容易、管理方便的配

　　置管理的好坏影响巨大。

　　配置工具是配置管理的自动化平台，是一个管理具体实施的基础。一套功能强大、实施容易、管理方便的配置管理工具，可以极大地提高配置管理的实施效果。

　　目前配置管理工具大致分3类：

　　版本控制工具，提供基本的版本管理功能，例如：CVS， Visual SourceSafe；

　　项目级配置管理工具，适合中小型的项目，除版本管理功能外，还提供变更控制、状态统计功能，例如：ClearCase，PVCS，StarTeam；

　　企业级配置管理工具，除上述功能外还提供较强的过程管理功能，例如：ALLFusion Harvest.

　　如何选择配置工具呢？通常的选择标准如下：

　　提供基线化管理，对于基线有明显的标识。在工具所管理的配置库中，所有的配置项都应清晰、完整的得到保存，对于同一基线所包含的配置项可以迅速而明确地查到。如：项目人员在实施某一个需求变更时，可以方便地查到与此更改相关的编码、文档、测试用例、使用手册等产品单元，从而保证变更的完整性。

　　操作简单、流程便利。项目开发是一项复杂工程，项目人员工作繁重，应尽量减轻他们的工作压力，消除其使用戒心。

　　提供完善过程管理功能。能根据实际情况定制不同的开发规范，包括访问权限控制、开发规则的实施等；能跟踪、控制开发过程中出现的缺陷、变更等，可以随时了解变更的实施状态。

　　提供灵活多样的配置状态报告。在配置的不同阶段能提供多角度的配置状态报告，详细反映配置项的变化过程，追溯变更任务的进程，为项目管理提供第一手参考资料。

　　管理规范的制定与推广

　　通常人们会认为，配置管理就是工具管理，就是找几个人，买几个工具，就可以开干了，这实在是大大的误解。再好的工具都要靠人来操作、管理。工具是死的，人是活的。工具虽好，若无严格可行的规章、流程做保证其实施，要做好配置管理是空谈。

　　配置管理规范是成功实施配置管理的根本保障。它包括：配置管理计划、版本控制规则、变更控制规则、配置库操作规则、配置审计规则等，所有这些，构成了完整的配置规范及配置管理基础。

　　如何做好配置管理的相关规范及流程呢？

　　1、明确项目要做到的配置管理目标。

　　2、根据目标确立配置管理应提供的功能。

　　3、确定相关人员，明确其岗位职责。

　　4、确定是否要引入配置管理工具，如需引入，要引入何种工具。

　　5、确定配置管理流程。

　　制定配置管理计划。

　　1）配置控制委员会（Configuration Contronl Board ，简称CCB）根据项目的开发计划制定阶段里程碑，明确开发策略；

　　2）配置管理人员（Confiuration Management Officer，简称CMO）根据CCB的规划，制定配置管理计划，交CCB审核；

　　3）CCB审核通过配置管理计划后，将其交项目经理批准，然后对外发布。

　　执行配置管理计划。

　　1）CCB设定项目研发的初始基线；

　　2）CMO设立配置库与空作空间，为软件开发做准备；

　　3）开发人员根据软件配置策略获得授权资源，进行研发工作。

　　4）CCB根据研发进展情况，审核项目变更请求，根据里程碑来确定新的基线，推进配置管理活动。

　　6、制定相关规范来保障流程的实施。

　　规范规定完毕，还要有执行，如何来推进配置管理各项制度及流程呢？

　　领导的重视是前提，没有领导的支持与推进，过程控制规范便没有执行力，是一纸空文。

　　培训。不光要对配置管理人员进行培训，还要对相关的技术及管理人员进行培训，使他们认识到配置管理的重要性，应如何来应用，如何来配合。培训是化解阻力的重要手段，大家只有了解你的好处才会支持你，否则，迎接你的往往是拒绝。

　　建立反馈渠道及反馈机制。“鞋子合适不合适，只有脚知道。”规章合理不合理，用户最清楚，听取各方的意见，不断自我完善，才能建立起切实可行的规范制度。

　　结束语

　　配置管理离不开“人、工具、规范”三要素，我们若把软件项目比喻成隆隆向前的战车的话，配置人员便是战车的机械师，负责及时通报战车的性能、方位，排除系统故障；配置工具则是战车的传送带，平稳而准确地推动着战车前进的步伐，确保它到达一个又一个新的目标；配置规范就是润滑油，有它在，战车的各个部件才能精确地耦合运转。配置管理对项目是如此重要，没有它的保障，项目“战车”便是一堆废铁。

软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力，所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础，必须在建立有效的软件如管理工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，才能持续地成功。
　　软件质量是一模糊的、捉摸不定的概念。我们常常听说：某某软件好用, 某某软件不好用；某某某软件功能全、结构合理, 某某某软件功能单一、操作困难……这些模模糊糊的语言不能算作是软件质量评价，更不能算作是软件质量科学的定量的评价。软件质量，乃至于任何产品质量，都是一个很复杂的事物性质和行为。产品质量，包括软件质量，是人们实践产物的属性和行为，是可以认识，可以科学地描述的。可以通过一些方法和人类活动，来改进质量。
　　实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关，主要相关领域和因素有：需求工程(REQUIREMENTS ENGINEERING)。理论上，需求工程是应用已被证明的原理、技术和工具，帮助系统分析人员理解问题或描述产品的外在行为。软件复用(SOFTWARE REUSE)，定义为利用工程知识或方法，由一已存在的系统，来建造一新系统。这种技术，可改进软件产品质量和生产率。还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。

CMM的基本思想是，因为问题是由我们管理软件过程的方法引起的，所以新软件技术的运用不会自动提高生产率和利润率。CMM有助于组织建立一个有规律的、成熟的软件过程。改进的过程将会生产出质量更好的软件，使更多的软件项目免受时间和费用的超支之苦。
　　软件过程包括各种活动、技术和用来生产软件的工具。因此，它实际上包括了软件生产的技术方面和管理方面。CMM策略力图改进软件过程的管理，而在技术上的改进是其必然的结果。
　　必须牢记，软件过程的改善不可能在一夜之间完成，CMM是以增量方式逐步引入变化的。CMM明确地定义了5个不同的“成熟度”等级，一个组织可按一系列小的改良性步骤向更高的成熟度等级前进。
　　成熟度等级1：初始级(Initial)。处于这个最低级的组织，基本上没有健全的软件工程管理制度。每件事情都以特殊的方法来做。如果一个特定的工程碰巧由一个有能力的管理员和一个优秀的软件开发组来做，则这个工程可能是成功的。然而通常的情况是，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。结果，大多数的行动只是应付危机，而非事先计划好的任务。处于成熟度等级1的组织，由于软件过程完全取决于当前的人员配备，所以具有不可预测性，人员变化了，过程也跟着变化。结果，要精确地预测产品的开发时间和费用之类重要的项目，是不可能的。
　　成熟度等级2：可重复级(Repeatable)。在这一级，有些基本的软件项目的管理行为、设计和管理技术是基于相似产品中的经验，故称为“可重复”。在这一级采取了一定措施，这些措施是实现一个完备过程所必不可缺少的第一步。典型的措施包括仔细地跟踪费用和进度。不像在第一级那样，在危机状态下方行动，管理人员在问题出现时便可发现，并立即采取修正行动，以防它们变成危机。关键的一点是，如没有这些措施，要在问题变得无法收拾前发现它们是不可能的。在一个项目中采取的措施也可用来为未来的项目拟定实现的期限和费用计划。
　　成熟度等级3：已定义级(Defined)。在第3级，已为软件生产的过程编制了完整的文档。软件过程的管理方面和技术方面都明确地做了定义，并按需要不断地改进过程，而且采用评审的办法来保证软件的质量。在这一级，可引用CASE环境来进一步提高质量和产生率。而在第—级过程中，“高技术”只会使这一危机驱动的过程更混乱。
　　成熟度等级4：已管理级(Managed)。一个处于第4级的公司对每个项目都设定质量和生产目标。这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离(统计质量控制措施的一个简单例子是每千行代码的错误率。相应的目标就是随时间推移减少这个量)。
　　成熟度等级5：优化级(Optimizing)。—个第5级组织的目标是连续地改进软件过程。这样的组织使用统计质量和过程控制技术作为指导。从各个方面中获得的知识将被运用在以后的项目中，从而使软件过程融入了正反馈循环，使生产率和质量得到稳步的改进。
　　整个企业将会把重点放在对过程进行不断的优化，采取主动的措施去找出过程的弱点与长处，以达到预防缺陷的目标。同时，分析各有关过程的有效性资料，作出对新技术的成本与效益的分析，并提出对过程进行修改的建议。达到该级的公司可自发的不断改进，防止同类缺陷二次出现。
　　在表中可以看出，CMM为软件的过程能力提供了一个阶梯式的改进框架，它基于以往软件工程的经验教训，提供了一个基于过程改进的框架图，它指出一个软件组织在软件开发方面需要那些主要工作，这些工作之间的关系，以及开展工作的先后顺序，一步一步的做好这些工作而使软件组织走向成熟。CMM的思想来源于已有多年历史的项目管理和质量管理，自产生以来几经修订，成为软件业具有广泛影响的模型,并对以后项目管理成熟度模型的建立产生了重要的影响。尽管已有个人或团体提出了各种各样的成熟度模型，但还没有一个象CMM那样在业界确立了权威标准的地位。但PMI于2003年发布的OPM3以其立体的模型及涵盖范围的广泛有望成为项目管理界的标准。

谬误的开始
作为质量体系中的配置管理
作用与反作用
为什么要有组织
Process Guideline Handbook Template以及Audit Review
既不是Admin也不是Desktop Support更不是网管
有多少CI可以统计
跨越鸿沟
谬误的开始
    很多时候需求者的观点会穿越工业生产或者是物理定律甚至于逻辑,比如你给人造飞机,他会说,哦你要是能顺便改进一下发动机,让飞机飞入太空就好了,但我们知道飞机飞行需要空气。空天飞机到目前为止也必须有两套动力系统。
    SCM也是同样，需求方会因为误解而产生不符合逻辑，配管管理现行业状甚至于不符合他自己需求的问题。由此两大流派应运而生，工具派和Coder派，前者贯彻工具本身的策略以及所附属高层下发的解决方案，后者从VC出发充斥着繁多的小工具脚本小型网站小型XX。当然也有假装前者收尾于后者的，也有开始于后者又迷失与前者的。
    具体而言，比如最近收到的令人鼓舞的需求，“我需要在PG提交后看到他修正的BUG的范围，对比Review所有SC，然后登陆到修正一览上去“。
    工具派说，我们的工具当然支持这个需求，根据组织级别的定义，你必须首先将BUG登陆到系统的xx页面，此外每一个BUG都需要你打一个tag进行完成性跟踪，然后手动关联起来，此外你也可以使用比较工具对两个tag进行比较，哦绝大部分内容帮助文档上都有，我给你个截个手顺出来，BUG和tag关联时候先要找Test Leader确认。
    Coder派：OK,提交了BUG写一个特定的comment，然后我写个perl抓出来就可以了，剩下的你在Excel自己处理，什么你要比较？我给你按24小时进行差分，差分结果会以html包进行展现的，你给我2天我调试一下这个脚本。
    我们可以看出前者很麻烦，不过统一管理可以保证质量，后者很方便，却又容易遗漏。但要知道麻烦的事情往往就是错误的事情，如何找PL确认?口头？报表？Test Leader负责整个测试，但这不意味着他实际在确认所有的改动，这个确认既没有意义也没有实效。后者很方便，但却依赖于PG以及维护Excel者的持续正确，我们设计的同行评审或类似Review机制来保证工作的正确性，但完整性却需要PG本人保证？

网上一直有人讨论asp,jsp,php,asp.net,java的可学性，既学哪门语言找工作容易点，薪水多点，公说公有理，婆说婆有理，但都拿不出事实证据，现在我们就来看看各大权威招聘网站对各门语言技术人员的需要，把关键字设置成上面五种语言，看哪个搜索出来的结果多，那么我们是不是就可以的客观的认为那门语言有前途呢，不管怎么样，下面是我搜索出的结果：

先从51JOB开始：　

地点　日期　关键字　职位搜索记录数

上海　　　近两周　　　asp    205条(包括有asp,net关键字)

上海             近两周            jsp      65条

上海             近两周            PHP      221条

上海             近两周            JAVA    1105条

上海             近两周            ASP.NET   137条

 杭州           近两周           asp      25条

杭州            近两周           JSP    7条

杭州           近两周            PHP      23条

杭州           近两周             JAVA    245条

杭州            近两周             asp.net    16条

北京           近两周            asp      266条

北京           近两周            JSP         30条

北京           近两周            PHP    305条

北京           近两周          JAVA      1285条

北京           近两周            asp.net   161条

我们再来看看中华英才网chinahr.com

上海　　　15天　　　asp    643条

上海　　　15天             jsp    496条

上海　　　15天            php     275条

上海　　　15天             asp.net   401条

上海　　　15天             java     1414条

杭州            15天             asp   45条

杭州            15天            jsp    2255条

 杭州            15天            php     19条

杭州            15天             asp.net    1674条

杭州              15天             java    187条

北京             15天          asp    1515条

北京             15天          jsp      1347条

北京             15天         PHP     904条

北京             15天           asp.net     901条

北京             15天          java         6589条

好了，我选择了三个在IT领域强劲的城市进行搜索，搜索到的结果令我出乎我的意外，为什么两个网站的统计分析却有点出入，在51JOB里，我们可以排个名次：JAVA>PHP>ASP>ASP。NET>JSP

可在中华英才网，我们排出的是JAVA>JSP>ASP.NET>PHP>ASP,在51JOB里排名倒数的两个却在这排到了第二，三位。同时我们可以看到，JAVA稳做老大的位置，而且需求非常旺盛，只有最高的，却看不出最低的

第二点，我们分析两个招聘网站，在相同的搜索条件下，搜索结果中华英才网明显多过51JOB，但其中的质量我们就不得而知了，还请各位自己分辨!

以上数据可供各位参考 !

       今天在工作的时候，看到前辈没在使用EXCEL的时候，用到了一个我觉得非常高深的技巧，那就是在用DATA-FILTER弄出下拉菜单的效果后。在点击下拉的时候，里面有Custom这一选项，我试了试里面的功能非常强的，呵呵又学到一招了。以后工作可能又快捷不少。

   EXCEL果然很强的！！！！！

之前还不知道，visual studio代码管理还可以用命令的，今天看到这些东西，让我看到了希望。后来做了一个工具，好像非常方便，效率提高了几百倍啊！！我的天啊 

签入挂起的更改

从命令行签入项

tf checkin [/author:author name] [/comment:("comment"|@comment file)]
[/noprompt] [/notes:(“Note Name”=”note text”|@notefile)]
[/override:reasonfile|@reason] [/recursive] [/saved] [/validate]
[filespec]

/author


标识指定或隐含的挂起的更改的作者，以便某个用户可以代表其他用户签入更改。

需要 CheckinOther 权限。




/comment


将注释与变更集关联起来。




/noprompt


取消显示需要您输入的任何提示。




/notes


提供要与变更集相关联的一个或多个签入说明。




/override


允许您重写签入策略失败。只有当签入策略已存在，而您仍要签入时才需要此选项。




/recursive


签入指定的或暗示的工作文件夹及子文件夹中的所有项。




/saved


此选项不使用任何参数。当签入失败或用户取消签入时，或当用户将更改取消搁置时，如果存在任何选定的更改、注释、工作项、签入说明和签入策略重写原因，则会将这些内容存储到计算机上。

当与 /noprompt 一起使用时，/saved 选项会将已保存的任何注释等内容与更改一起签入。




/validate


/validate 选项允许您在不实际执行签入的情况下对其进行测试。

/validate 选项使签入评估签入策略、检查签入说明并查找冲突，但不实际执行签入。可以解决冲突等任何问题。

从源代码管理资源管理器签入挂起的更改

如果这些项与 Team Foundation 工作项相关联，请单击“工作项”通道，然后选择要签入的项。有关更多信息，请参见如何：将工作项与变更集相关联 和 如何：在“挂起的更改”窗口中查看工作项详细信息。

注意
如果为此团队项目启用了工作项策略，则当没有选择工作项时，将提示您进行选择。有关更多信息，请参见如何：启用和禁用签入策略。