从制造到创造

知识管理我的Blog上谈的比较少，我也不是这方面的专家，但知识和技能，经验，方法论，实践，思维思考都有关系。因此知识管理也是我关心的内容内容，包括个人知识和企业级和团队的知识管理。在2,3年前通过思维导图画的IT知识体系结构就是在这方面的一些实践，目的就是如何真正让知识发挥作用和创造效益。个人认为现在很多流行的知识管理系统都是辅助性的工具而已，关键还是是否真正的理解的知识管理的目标，理解了目标才知道如何做好知识管理，让知识管理真正的发挥作用。

知识库首先不是资料库，不是上传一大堆资料就完成知识库的建设了。资料必须经过多维属性的整理才能够真正入库，资料的关键字,TAG标签，多维度的分类都是属于资料的重要属性。而且入库的资料必须是有价值的资料，必须是经过我们分析，抽取和整理后的资料，这样可以减少后期其他人在无用的资料上面浪费时间。资料入库后完成了第一步，后面重要的就是知识的分享，一个资料能够在知识库中下载了不是分享，要成为知识的分享就需要对资料附加上团队中他人的评论，学习笔记和心得，有了这些就完成了知识库的基本建设。

在第一个层次上面，我们可以看到现在栖息谷或其他很多论坛的资料下载都是停留在资料库的层次上面。因此也就出现了我们前面常说的问题，论坛用户面对一大堆挪列的资料往往无从下手。我们的硬盘成为了我们资料收集的工具，而我们的大脑却根本还没有启动，更谈不上如何去将这些资料转化为系统的知识。从这点上再来看豆瓣网，豆瓣本身不存储任何的书籍和影音资料，但更多的针对书籍和影响的学习笔记，评论和相关小组更容易让理论性的东西转化为知识。

2.第二层次-形成知识地图

如果你不知道要到哪里去，给你张地图也没有用。但现在的问题是很多人知道往哪里去？他们有明确的想法想增加哪方面的知识或者说想提高哪方面的技能，但我们却很难针对他们给出一张类似于学习路线的知识地图。

在知识库建立和发布好以后重点就是要去形成知识地图，知识地图一方面应该是正对某一个业务领域或者应用场景需要的知识形成一个完整的知识体系结构图，让大家对要学习某项知识或技能有个全局的认识，同时也让每个人看清楚自己在地图中的位置。看清楚了你在地图中的位置，才能够知道如何达到目的地。

找到自己的位置后，就要发挥地图的第二个作用，如何在通过地图一步步的达到自己的目标，应该遵循什么样的行走路线，哪些地方需要慢慢走去体会，哪些地方可以跳跃下。要能够把行走路线准确的画出来，则需要理清楚知识和知识间的关系，哪些是关键约束和依赖关系，哪些是可选的依赖关系。把这些依赖关系理清楚后，知识路线自然就出来了。

针对处于不同位置的人，知识路线往往是不同的，我们可以给出常规的最佳路线，但无法给出针对每个人的最佳路线。所以有时候不要盲目的去迷信他人的学习路线，适合自己的路线才是最好的路线。由于无法解决个性化的最佳路线问题，需要过渡到第三个层次。

3.第三层次-从经验到方法论，模式的不断积累

任何知识管理工具和系统，如果走不到第三个层次则始终是停留在使用阶段，而无法真正过渡到创造阶段。我们进行的知识管理应该站在了前人的肩膀上面，后面要做的就是通过自我知识的学习形成相关的经验，大家通过知识平台的讨论和固化，将我们的经验积累为相关的方法论和模式。方法论会告诉我们遇到河流你需要通过桥过去，搭桥过去，或者说学习游泳技能过去；遇到山你可以爬过去，打个隧道过去，也可以绕过去。你可以根据你自己的情况选择相关的方法。所以有了这些大家共同积累下来的方法论和模式，再给你一张地图的时候，你不一定安装常规的学习路线走，你可以在方法论和模式的指导下创造出更多的行走路线，你要做的是根据自己的技能特点和面临的场景，选择最适合自己的学习路线。

知识管理的过程就是PDCA的过程，就是不断的和朋友分析和讨论自己的学习心得和经验，通过将经验固化为过程和特定的方法论和模式。知识能够真正的创造价值就在于知识能够以最快和最便捷的速度别它人所吸收，并转为自我的技能；知识真正的能够为企业创造价值就在于在形成经验技能后，个体能够将经验和心得分享，企业对经验和心得进行整合为不断完善方法论和模式的过程。

怎样评定一名软件开发人员？这是一个颇为奇怪的问题。现在已经有了很多的理论和形式来做这件事，人力资源部门也试着帮你管理和反省自己的行为。然而，怎样才是一个伟大的软件开发人员，在今天，你该怎样发展你的职业生涯？以下是我评定团队中软件开发人员的“军规”。按照这些技巧和规则，你可以改善你的现状，由一个优秀的程序员，成为一名伟大的程序员。

这里说的不是数量，而是质量。对此，一种歪曲是：要数量，也要质量。你也许会很多次的遇到以下的两种情境：

情境A：你有一个发疯似的能写代码的程序员，事情似乎在进展中……然后，Bug开始不断出现，你们也不知道为什么，好像永远补不完。补完十个，又出来五个，现在你手里的，就是一大堆代码……

情境B：你现在有一个看起来很聪明的程序员，你面试他的时候，他似乎无所不知，能把理论说的头头是道。然而，你留给他三个任务，三个星期以后，他还在做一些三天就该干完的事。这下该你困惑了，他这么聪明，他知道generics（详见备注），多线程的一切事情，甚至还能给祖母级的人讲解什么是指针，让老太太兴奋的想去编程。可是——怎么什么都没完成？

于是，在梦境中——你写出了堪称伟大的代码，——伟大的代码是伟大的程序员写出来的，他睿智，明白代码的真正品质所在。写代码就像托尼•霍克在玩滑板一样自然优美，看上去就令人愉快。这些程序员以让你眼花的速度搞定一切，他们知道每个问题应该处理多长时间，也不会追捧寻觅所谓的世界最好解决方案，弄很多线程很多层来写一个简单的游戏。他们写的程序没有Bug，因为写的时候自己测试过了，在睡觉时也在写代码说的就是这样的人。这些程序员太宝贵了。

可以明确的是：即使有问题暂时处理不了，还有成百上千的方法去解决。有些人反应很迅速，很快就能提出多种解决方案。然而，一个伟大的程序员应该在做出行动以前清晰阐明问题——创建文档或用白板表达出来。他们写邮件给项目的管理者，这样表述：“我想和你说说我是怎么理解这个问题的，我们能这样处理吗？”然后他们就会动手给你多种方案。

对，这些人明白自己看问题和阐明立场的方式，而这理解方式大概不会是问题创建者所想要被理解的。请牢记这就是关键所在。一名伟大的程序员在尝试解决问题以前，一定要完全的理解它。你百分百搞明白了吗？没有？百分之九十九？——回去再多问些问题，确保百分之百理解清楚了。

那一搞明白了问题，就开始动手写代码？错！一个伟大的程序员应该按照规划，开始思考面临的多种选择，基于问题开始考虑最好的解决方案。我觉的这像一场国际象棋比赛。你知道每个棋可以怎么走，知道所有的游戏规则。但是你会马上走棋吗？不，你要审时度势，制订计划，紧盯对手，分析其通常的做法。和这一样，在你coding解决问题以前，你也要这么做。

看看问题，计算出需要怎样的结果，你的时间能怎么安排，预期的质量，你必须用的工具，……好了，开工吧！

作为项目管理者，你怎么相信他们的代码。有些程序员，你可以对他们说：“我星期五就要结果”。——星期五到了，你收到了这样的Email：“代码我都已经检查过了，现在就等着测试了。”你很放心，只会有很少的瑕疵在质量确保的团队被查到。当然，还有些轻率的例子，一些程序员在邮件里是这样说的：“我还没弄完，星期一上午我会最先完成它”。你不太确信这东西，发现很多Bug，很长时间基本上不能用。又得花上几个星期清理代码中的Bug。

关键：你对一个开发人员越有信心，他离成为一个伟大的程序员的距离就越近。想象你是你的管理者，如果他并不担心你的代码，会给你多少信心和勇气！

和对代码的信任是一回事——如果你手上有伟大的程序员，你就会对解决方案有信心。这些程序员同时也是伟大的建筑师。他们剖析整个问题，指出问题需要怎样去解决。这就不只是用伟大的代码编程的问题了，很大程度取决于你怎样构筑解决方案。这是关键，而且会让你在软件世界里出类拔萃。

一天下来，你写出了最棒的代码、用了最好的框架和最好的解决方案，但这真的能迎合用户的需求吗？恐怕根本不是那么回事儿。你搞砸了。尽管现在多次失手，一个伟大的程序员还是会正中靶心，找出客户需要的，给用户逐步展示他们所需要的无bug的最终版本。需求正中靶心的同时，用户满意了。

伟大的程序员会积极主动地把自己的技术升级。他们对知识的态度就像饿猫见着了牛奶，他们从不用上级催促给自己设定目标、不用经理要求他们完成任务，因为他们自己就已经安排OK了。

他们发现自己想要参加的大会就会给公司写Email“本人非常想参加今年的Tech-Ed大会。我将用心研习，并对作出贡献。我预计这可节省<金钱/其他原因>。如果可行，不知公司是否帮我支付此行？”如果我收到这样的邮件，我不仅会帮他支付参会费用，他的路费我也会全程买单。

伟大的程序员们永远会关注例如.net用户组或Java用户组的所有用户群体。他们参加本地的技术会议，并从中汲取知识。你会看所有最新博客和最新的杂志吗？现在列出你最喜欢的前5个开发博客。你能做到吗？你应该像参加基督教青年会那样轻松做到。做到这些，可以很好的帮助你延伸你的思路！你将会不断获得更好的点子！你会得到更好的回报！

你可以是团队中最棒的那个人，可是如果你不是最好的程序员、不是建筑师、不是团队里最有活力的人，那么对我来说，如果你不能分享或对你的团队有帮助，你的价值就会大打折扣。一个好的程序员会使自己周围的人同样强大起来。试想一下，好程序员会不断完善自己的知识和能力，如果他们不和周围的人分享他们的知识，他们从哪儿能获得更多呢？

他们不断学习新东西，发掘新技术，但是不会让其他人知道他们这么做了。一个好的程序员会准时完成方案，但是那是在催促和团队得不到休息的前提下。然而一个伟大的程序员则会与团队中所有的项目保持联系，在需要的时候还可以出手帮忙。他们会如是说：“我注意到A团队的项目进行到xx进度了，如果不介意的话，我想我可以帮忙？”

做好会议记录绝对至关重要！开会期间，大家花大量时间来说明了新观点、新主张、集体讨论还有提出了新设计方案，可是会议结束后却没有人可以拿得出会议记录，简直没什么比这更糟糕的事情了。即使你有会议大纲，我还是期望见到参会的每一个人员都可以带着纸和笔（当然对于程序员来说笔记本则堪称完美）。一个伟大的程序员会注意到这点。他们会记下所有的会议记录，并且在会议结束的的时候说：“就刚才的会议，我着重记录了几点：XX…… 我是否记录全了呢？”

接下来，伟大的程序员就会把他做好的会议记录分发给项目管理者，列出会议时间、会议主题和参会者。接下来，是会议项目的标题和重要条目。在这之后，就是这些议题的详细记录。一个好的程序员没有做会议记录，并在会议上对提出的每项事宜都点头称是，那只能寄希望于他的记忆力足够好了。随后，他会给你发邮件让你看看他的改动，你得回头提醒他忘记的不多，百分之九十的都没错。——这不是浪费时间嘛！根本不是这么回事！所以，做好你的会议记录。

如果你读到这儿了，就表明你有希望接受这些建议，并在以后的开发行动中尝试执行。对，程序员的另一项重要能力就是向他人学习并且能够接受批评。通过把自己变为一个虚心受教的人，像海绵一样快速吸收大量知识，毕竟在编程的路上你还有很多前辈。当然，也许他们在写代码的岁月里慢慢生了锈，甚至伤痕累累，但是他们毕竟曾披荆斩棘跨过无数的坎儿。对于做出正确决定，他们又着瞬间的本能，让你不得不服。处于他们这个位置，很乐于见到你的成长和成功。

所以，只要你是个伟大的程序员，就会理所当然的拥有理想的工作环境。如果你不断改善技能、虚心好学、在别人给出的意见和批评中总结错误并得以改善，我向你保证你将会成为一个伟大的程序员而不只是想象自己变得伟大而已。如果你总把自己想象成为“精英”而不进步，那你只是自欺欺人。如果你不成长，你甚至不能停留到原地，等待你的只有灭亡！

这如同等价交易。如果你为一家伟大的公司工作，他们会给你足够的弹性。公司不会限制你如何工作，不限制你开始或结束的时间，也不会限制你什么时候停下来歇歇。公司会鼓励你在休息时间做做操，甚至会在你和团队成员出去吃饭的时候为你们买单……在繁复大量而紧张的工作后，公司会放你几天小假。诸如此类。

然而，毫无疑问，与前面的这些美事儿随之而来的是责任。如果赶上时间紧还得出活儿，伟大的程序员则建议你即使在周末也要加班。即使干得再晚也得把活儿干完。你看，伟大的程序员是要为自己的创作负责的。这虽不是必需的，但这是伟大程序员的标志之一。有些人只想朝九晚五的上班，他们可能不错，但是成不了伟大的程序员。伟大的程序员是团队中干到最后的那个，把作品视为完美的艺术，与团队成员亲如一家。

你永远也不知道一个客户会什么时候突然拜访。你也永远不会预知什么时候突然要参加一个会议，不是每一件事都在计划中的。你得随时准备好展现自己。一个好的程序员周一到周五穿着普普通通，甚至有可能穿牛仔装和运动鞋来上班。在某些周五，他们穿着T恤，短裤和运动鞋出现。当一个客户突然在周五出现，要谈一个大项目，你没法把衣衫不整的他一块儿叫上。

一个伟大的程序员周一到周五都穿着职业化，衣服也能带来成绩。如果你不在意穿着，你也会因为穿的太奇怪而得不到晋升。毫无疑问，套装和领带还是很能提升你自己的。我向你保证，一套得体大方的西服套装会让你在今年就觉的物超所值。

这是另外的判定条件。这世上有太多优秀程序员，却没几个伟大的程序员。为什么呢？因为大多数程序员不善交流。交流的层次很多：从发电子邮件、参加小型SCRUM开发小组会议到大一些的主管会议，水平逐渐提升。这样你就能在数百人参加的会议上自如地展示你的软件。在会议上你不需要有好演技，但是至少要清晰明了地表达你的观点。你的沟通能力越强，你的职业道路就会走得越远！

概要：想要成为管理人员，你的沟通能力得分至少要打到9到10分。甚至你在会议上只讲了几分钟，或只一个小汇报，你都需要非常好的表达能力。别只是在你的每天的工作日志寥寥写上“修补1371个bug”，你要做的是尽可能描述清楚如何在这么艰难的情况下解决了问题。阐明你的方法，说明你如何保证这个bug不再出现。你就不再为你的日志发愁了。这会是你向经理展示自己的精彩演出。

好的程序员日复一日的做你安排给他们做的事情，贯穿始终。他们并不往远看，不对明年、5年甚至10年后作打算。一些好程序员虽然知道自己想要什么，却没有具体计划去实现。伟大的程序员则给自己订立年度、未来5年的目标，而且大概预期到自己10年后的发展。

伟大的程序员有了目标不会只是想象，他们会具体实施。他们会根据具体情况，在预期的时间做具体的事情。他们会详细地制订明年的计划，包括要上的课程、要完成的项目甚至包括他们需要建立的人际关系。

把所有事情整合在一起的最关键要素是组织。你可能是世界上最好的程序员，但如果你不善于组织你所做的事儿，你的工作将陷入瘫痪，最终丧失优势。伟大的程序员保持自己工作平台的整洁有序，保留所有的笔记并调理清晰。他们标出自己的会议日程表。他们有专门的收件箱给日程邮件、会议和新任务分类。他们保留文档并能在需要时迅速找到所需。

伟大的程序员如果没有热情，那么他的工作也并不伟大。好的程序员有了热情来对待他的工作、方案和团队，那么他比伟大的程序员还要伟大。

在回顾的时候，我用这些标准来评判我的开发团队。我给我的团队尽可能最好的环境，作为回报，我想要他们都成为最伟大的程序员。你可以用这些标准来评判你的团队，或者你本身就是一名程序员，请用这张列表来尽可能地改造自己来超越同侪。

备注：Generics是程序设计语言的一种技术，指将程序中数据类型进行参数化，它本质上是对程序的数据类型进行一次抽象，扩展语言的表达能力，同时支持更大粒度的代码复用。对于一些数据类型参数化的类和方法来说，它们往往具有更好的可读性、可复用性和可靠性。在设计集合类和它们的抽象操作时，往往需要将它们定义为与具体数据类型无关，在这种情况下，使用Generics就是非常适合的。

　　CMM理论和知识是最近几年的热点，在最近两年的系统分析员上午试卷中都有一题考察CMM知识的，一般有3-5分的样子。估计未来的系统分析员考试还会有这方面的考题。即使不考，我们的系统分析员也应该掌握这方面的知识，因为将来从事的系统分析与设计的工作也离不开CMM理论和知识，因为即使我们所在的公司不去进行CMM评估，CMM理论知识对于我们不断的进行公司的软件过程改进有一定的借鉴意义，从而有助于软件质量的提高，进而提升公司产品的市场竞争力。

　　本文是根据这两年试题中涉及CMM知识而特为广大考友搜集整理的关于CMM的基础知识的文章。主要内容是有关CMM的基本概念、CMM的基本框架和对CMM的正确态度等。希望这篇文章对你有所帮助，谢谢。

　　CMM（Capability Marurity Model，软件能力成熟度模型）是于1984年美国国会与美国主要的公司和研究中心合作创立的一个由联邦资助的非盈利组织——软件工程研究所（Software Engineering Institute,SEI）的一个早期研究成果。该模型提供了软件工程成果和管理方法的框架，自90年代提出以来，已在北美、欧洲和日本成功地应用。现在该模型已成为事实上的软件过程改进的工业标准。下面我们来一起学习有关CMM的一些基础知识。

一、 CMM基本概念

　　过程（Process）：为实现既定目标的一系列操作步骤[IEEE-STD-610].
软件过程（Software Process）：指人们用于开发和维护软件及其相关产品的一系列活动、方法、时间和革新。其中相关产品是指项目计划、设计文档、编码、测试和用户手册。当一个企业逐步走向成熟，软件过程的定义也会日趋完善，其企业内部的过程实施将更具有一致性。

　　软件过程能力（Software Process Capability）：描述了在遵循一个软件过程后能够得到的预期结果的界限范围。该指标是对能力的一种衡量，用它可以预测一个组织（企业）在承接下一个软件项目时，所能期望得到的最可能的结果。

　　软件过程性能（Software Process Performance）：表示遵循一个软件过程后所得到的实际结果。（与软件过程能力有区别，软件过程能力关注的是实际得到的结果，而软件过程性能关注的是期望得到的结果。由于项目要求和客观环境的差异，软件过程性能不可能充分反应软件过程整体能力，即软件过程能立受限于它的环境。）

　　软件过程成熟度（Software Process Maturity）：是指一个具体的软件过程被明确地定义、管理、评价、控制和产生实效的程度。所谓成熟度包含着能力的一种增长潜力，同时也表明了组织（企业）实施软件过程的实际水平。随着组织软件过程成熟度能力的不断提高，组织内部通过对过程的规范化和对成员的技术培训，软件过程也将会被他的使用者关注和不断修改完善。从而使软件的质量、生产率和生产周期的到改善。

　　CMM是软件过程能力成熟度模型（Capacity Maturity Model）的简称，是卡内基－梅隆大学软件工程研究院为了满足美国联邦政府评估软件供应商能力的要求，于1986年开始研究的模型，并于1991年正式推出了CMM 1.0 版。CMM自问世以来备受关注，在一些发达国家和地区得到了广泛应用，成为衡量软件公司软件开发管理水平的重要参考因素和软件过程改进事实上的工业标准。

　　CMMI（Capability Maturity Model Integration）即能力成熟度模型集成，这也是美国国防部的一个设想，他们想把现在所有的以及将被发展出来的各种能力成熟度模型，集成到一个框架中去。这个框架有两个功能，第一，软件获取方法的改革；第二，建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。

　　关键过程（区）域（Key Process Area）是指一系列相互关联的操作活动，这些活动反映了一个软件组织改进软件过程时所必须满足的条件。也就是说，关键过程域标识了达到某个成熟程度级别时所必须满足的条件。在CMM中一共有18个关键过程域，分布在第二至五级中。

　　关键实践（Key Practices）：是指关键过程域种的一些主要实践活动。每个关键过程域最终由关键实践所组成，通过实现这些关键实践达到关键过程域的目标。一般情况下，关键实践描述了该“做什么”，但没有规定“如何”去达到这些目标。

　　软件过程评估（Software Process Assessment）是用来判断一个组织当前所涉及的软件过程的能力状态，判断下一个组织所面向得更高层次上的与软件过程相关的课题，以及利用组织的鼎力支持来对该组织的软件过程进行有效的改进。

　　软件能力评价是（Software Capability Appraisal）用来判断有意承担某个软件项目的软件组织的软件过程能力，或是判断已进行的软件过程所处的状态是否正确或是否正常。

　　软件工程组（Software Engineering Group）：负责一个项目的软件开发和维护活动的团体。活动包括需求分析、设计、编码和测试等。

　　软件相关组（Software Related Groups）：代表一种软件工程科目的团体，它支持但不直接负责软件开发或维护工作，如软件质量保证组、软件配置管理组合软件工程过程组等等。在CMM的关键实践中，软件相关组通常应该根据关键过程域和组织的上下文来理解。

　　软件工程过程组（Software Engineering Process Group）：是由专家组成的组，他们推进组织采用的软件过程的定义、维护和改进工作。在关键实践中，这个组织通常指“负责组织软件过程活动的组”。

　　系统工程组（System Engineering Group）：是负责下列工作的个人的团体：分析系统需求；将系统需求分配给硬件、软件和其他成分；规定硬件、软件和其他成分的界面；监控这些成分的设计和开发以保证它们符合其规格说明。

　　系统测试组（System Test Group）：是一些负责策划和完成独立的软件系统测试的团体，测试的目的是为了确定软件产品是否满足对它的需求。

　　软件质量保证组（Software Quality Assurance Group）：是一些计划和实施项目的质量保证的团体，其工作目的是保证软件过程的步骤和标准是否得到遵守。

　　软件配置管理组（Software Configuration Management Group）：是一些负责策划、协调和实施软件项目的正式配置活动的团体。

　　培训组（Training Group）：是一些负责协调和安排组织培训活动的团体。通常这个组织负责准备和讲授大多数培训课程并协调其他培训方式的使用。

二、 CMM 的基本框架

　　任何一个软件的开发、维护和软件组织的发展离不开软件过程，而软件过程经历了不成熟到成熟、不完善到完善的发展过程。它不是一朝一夕就能成功的，需要持续不断的对软件过程进行改进，才能取得最终的成效。CMM就是根据这一指导思想设计出来的。该模型为了正确和有序地引导软件过程活动的开展，建立一个能够有效地描述和表示的软件过程的改进框架，使其能够对各阶段软件过程的任务和管理起指导作用。该模型一产品质量的概念和软件工程的经验教训为基础，指导企业如何控制开发、维护软件的生产过程和如何制定一套与之相适应的软件过程及管理体系。

（一）分级标准

　　CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准，如图1示。一方面软件组织利用它可以评估自己当前的过程成熟度，并以此提出严格的软件质量标准和过程改进的方法和策略，通过不断的努力去达到更高的成熟程度。另一方面，该标准也可以作为用户对软件组织的一种评价标准，使之在选择软件开发商时不再是盲目的和无把握的。

图 1 软件过程成熟度的级别

　　CMM的分级结构可以描述为：

　　①、初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。

　　②、可重复级：已建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。

　　③、已定义级：用于管理的和工程的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。

　　④、以管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。

　　⑤、优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地对促进过程进行改进。

　　除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，自然可以向下一级别迈进。CMM体系不主张跨级别的进化。因为从第二级开始，每一个低级别的实现均是高级别实现的基础。

（二）CMM的主要内容

　　CMM为软件企业的过程能力提供了一个阶梯式的进化框架，它采用分层的方式来解释起组成部分，如图2示。在第二至第五个成熟等级中，每个等级包含一个内部结构的概念，关于内部结构详细描述将在下面CMM内部结构的一栏中进行。

　　每一级向上一级迈进的过程中都有其特定的改进计划，具体情况如下。

　　初始级的改进方向是：建立项目过程管理，是使规范化管理，保障项目的承诺；艳进行需求管理方面的工作，建立用户域软件项目之间的沟通，使项目真正反映用户的需求；建立各种软件项目几乎，如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划及过车改进计划等；积极开展软件质量保证活动（SQA）。

　　可重复级的改进方向是：不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为权组织的标准软件过程，把改进软件组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任；确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中，从而可以跨项目改进软件过程效果，也可以作为软件过程剪裁的基础；建立软件工程过程小组（SPEG）长期承担评估域调整软件过程的任务，以适应未来软件项目的要求；积累数据，建立组织的软件过程库及软件过程相关的文档；加强培训。
已定义级的改进方向是：着手软件过程的定量分析，已达到定量地控制软件项目过程的效果；通过软件的质量管理达到软件质量的目标。

　　已管理级的改进方向是：防范缺陷，不仅在发现了问题能及时改进，而且应采取特定行动防止将来出现这类缺陷；主动进行技术改革管理、标识、选择和评价新技术，是有效的新技术能在开发组织中实施；进行过程变更管理，定义过程改进的目的，经常不断地进行过程改进。

　　优化级的改进目方向是：保持持续不断的软件过程改进。

（三）CMM的内部结构

　　CMM为软件过程能力的提高提供了一条改进的途径。CMM由5个成熟度等级组成，每个成熟度等级有着各自的功能。除第一级外，CMM的每一级按完全相同的内部结构构成的，如图3。成熟度等级为顶层，不同的成熟度等级反映了软件组织的软件过程能力和该组织可能实现预期结果的程度。

　　在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域，一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键古城域的目标。每一级的关键过程域的详细情况见表1。

（四）软件过程评估和软件能力评价

　　软件过程评估所针对的是软件组织自身内部软件过程的改进问题，目的在于法子按缺陷，提出改进方向。评估组以CMM模型为指引调查、鉴别软件过程中的问题，翻过来将这些问题与CMM关键实践活动所提出的指导一起用于确定组织的软件过程改进策略。

　　软件能力评价是对接受评价者在一定条件下、规定时间内能否完成特定项目的能力考核，即承担风险的系数大小。评价包括承包者是否有能力按计划开发软件产品，是否能按预算完成等。通过利用CMM模型确定评价结果后，就可以利用这些结果确定选择某一承包商的风险。也可以用来判断承包者的工作进程，推动他们爱进软件过程。
CMM为评估和评价提供了一个参考框架，指出了在评估和评价中通常采用的佛农步骤，如图4示。

　　具体来说，评估过程是：选择一个工作组；完成问卷调查和取样工作；结果分析；现场访问；与CMM模型对照分析；依据关键过程域的基本情况列出评估提纲。以上步骤在软件过程评估和软件能力评价题勾勒很有参考价值的方法，但在具体操作时以下这些特点也值得考虑：

　　①、在现场访问和考察中，充分运用成熟度问卷和结果分析为依据。

　　②、以CMM模型作为现场调查的路线图。

　　③、利用CMM中的关键过程域定义软件过程中的优点和缺陷，从中发现差异。

　　④、对关键过程域目标是否备满足的实际情况出发，分析满意程度，写出书面报告。

　　尽管软件过程评估和软件能力评价有很多相似之处，但由于其目的和结果的不同，它们之间的差异也是必然存在的，如：

　　①、软件过程评估和软件能力评价在出发点和目标上的不同，使得会谈目的、调查范围、收集的信息和输出的表示方式上有着本质的不同。尤其在一些细节规范方面，评估和评价的方法有很大差异。

　　②、软件过程评估和软件能力评价的结果和结果所起的作用不同。因为两者的侧重点不一样，即使是对同一个应用项目，运用相同的方法，也不会得出相同的结果。

　　③、被评估和评价单位的态度对评估和评价活动的影响。评估在某种意义上被评估单位的态度较积极，而评价在某种意义上被评价单位的态度可能比较慎重。软件过程评估是在一个开放的、互相协作的环境中进行的，而软件能力评价往往是在有较大的阻力的环境中进行的。

（五）CMM的组织保证

　　当人们面对CMM实施时，首先想到的就是人员的构成和各种小组的划分。它是实施CMM的组织保证，是一切活动的基础。CMM在制定软件过程实施中本着尽量不和具体的组织机构和组织形式相联系的原则，为的是提供一个独立于具体企业而又有广泛指导意义的模型框架。但在实施各种软件关键实践中，不可避免地要涉及到角色和组织结构。所以为了使CMM能够使用域各种级别和各种规模的企业，SEI提出了一个相对抽象的组织结构，它与组织、项目、人员（角色）相关联，具有自己特定的术语，而且可能不同于其他组织所用的名词。例如基本概念中提到的主要的软件工作组的概念。

三、正确的态度看待CMM

　　SEI的CMM并不是软件开发的方法学，也不是产品模板，更不是过程法律。CMM是过程改进的途径，是一套指南，帮助你通过持续的重复、测量和提炼，稳步创造与净化开发环境。CMM的假定是：如果你实施一个不断重复、测量和提炼的大纲，作为环境改进的副产物，质量便会自然的提高。不要把CMM设想为一套规则，而应将它理解为一个学科，做事的一般方法。在这套指南下运作，你会发现这里有着广阔的空间，让你剪裁和塑造自己的大纲，以适应组织的特定要求。

　　CMM不采用“用这种方法做这类事”的风格，它也不对由问题的IT组织提供快速的纠正方案。CMM是一个指南针，指导你如何逃离暴风雪。CMM是一个大纲，要求你对整个IT组织的有关部分，从高层领导到软件生产的第一次线工作者，都做出坚定的、长期的实施承诺。成熟的过程不可能在已也之间实现。

　　在如何解释CMM建议时，它允许极大的灵活性。CMM意识到，IT组织之间存在着很大的差别。他们的客户不同，使用的工具不同，人员智力和专业背景不同，从事的项目属于不同的类型，规模大小不同，要求也各不相同。因而，他们应当以自己的方式走向成熟。在一处活用的东西，在另一处未必适用。这一点非常重要，中国部分软件公司的前车之鉴也从某种程度上给了我们建议和经验教训，那就是，要灵活应用CMM，不要幻想一夜就有成效。

　　本文只是根据这两年的试题和自己的预测向广大系分考友提供一些CMM方面的知识。CMM不是重点，但也有可能会考到一些知识，如基本概念等。在搜集资料和整理着篇文章时，遇到了一个矛盾，那就是：我要提供足够的资料以使读者不必花费金钱再去买一本书就可以复习有关CMM的知识，而同时又不能放太多的内容使读者浪费太多的时间在这上面。最后采取了一个折衷的办法，那就是尽量满足考试需求的情况下减少篇幅。在此声明，本文所涉及的内容只是本人的预测，并不是说考试范围不会超过本文的内容。所以有时间的朋友还是尽可能的扩大这方面知识面。希望这篇文章对你有帮助，谢谢。

不同于单机游戏和网络游戏，Flash游戏大多为休闲型的小游戏。尽管如此，不少可玩性很高的Flash游戏还是会让我们津津有味的玩上一整天。这里有10款老外们选出来的最容易上瘾的Flash游戏，准备好沉迷吧。

从参加面试看责任感

    就拿面试这件事来说吧，流程大多是：电话简单沟通，约时间?初试（开发人员多是笔试）?复试?确认薪水、上班时间入职。

    十一长假之前的一周，某公司约候选人参加研发笔试、面试。在约面试的电话里，公司特别强调如果您本周不方便（很多候选人会回老家），我们可以把笔试（面试）安排在十一之后进行。有12人在电话里说可以到公司参加笔试，令人失望的是，笔试当天只来了3位，其余8人在未做任何说明的情况下没有出现。

    因为开发人员是所有应聘者中素质最高的群体，公司前台打电话向每个未到的候选了解原因，看看是在电话里没说清地址，还是别的什么原因，导致了大家的缺席。最终的反馈是：2人电话不接、2人电话关机、4人临时有事。

……

    每次与公司技术负责人或者HR沟通，”80后”的职业素质都会成为核心话题之一。而缺乏责任感又是最经常被提到的。候选人认为面试不来，对自己只不过是少个求职机会而已，公司则认为这件事足以体现候选人对工作没有责任心。有这种品质在身，很难让我们在事业上有什么建树。

    所谓一花一世界，求职过程中任何点上体现出缺乏责任感都会被马上淘汰。公司的逻辑是：如果不负责任的人进了公司，那么造成的损害绝不止耽误时间这么简单，很可能是项目的延误甚至是失败。

   不可否认，现在就业压力大，大部分人都对求职抱的态度都是普遍撤网重点培养。得到面试通知后，发现公司离家太远或者刚好被另一家录用的事儿时有发生。“中国这么大，接到面试不去的又不是我一个，没什么大不了。”也是很多人的正常想法。

    我们回头看看这种行为给同龄人带来的伤害吧——由于相当部分”80后”技术人员在面试给人留下没有责任感的印象，很多公司规定关键岗位不用25岁以下人士。更有甚者，因为几个人的原因，某学校的毕业生在公司都成为不约见面试的对象。也许我们已找到工作，安然自得，但同龄人呢？校友呢？是否有必要更多考虑一下。

   其实，比默默消失更恰当的处理方式有很多，这不但能体现自身素质、节省双方时间，还能为自己赢得机会。比如：

   可以在电话里直接说因为路远、已有工作机会希望下次合作，即礼貌回绝（这样节省双方时间）；

   也可告诉HR时间不方便，能否另外安排时间（相信任何智力正常的公司HR相信都会另行安排沟通时间）；

   如果能在得知是哪家公司通知我们面试之后，能说出公司的情况，必然能在面试之前为我们自己加分。只需要事先做小小功课，上网看一下公司介绍即可。（体现我们的高素质）。

    如此，即会竖立”80后”的风采，也会被冠以XX学校毕业生素质高的赞誉，何乐而不为！

从谈薪水看自我定位

    80年代的研发候选人对自己的认识常走两个极端，要么疯狂自信、要么超级自卑，归根到底还是对自己的认识不清楚，难以准确定位自己、定位自己在群体中的地位。很多候选人因此失去了机会。

疯狂自信

    只在公司工作三周即被辞退的小F

     拥有2年的JAVA开发经验的F面试时向公司要求5K薪水。此时的他自信满满。“我就值这么多！”这是F在谈及薪水时说的一句话。

    公司方面综合笔试、面试的结果，给出的薪水范围是3K——4K。

    HR：“公司希望你能在工作中证明自己的能力。试用最多能提供3K的薪水，如果能顺利转正，我相信薪水会达到您的要求。这样可以吗？”
F：“行吧。希望公司能信守承诺。”

    只是短短的3周之后，F就被公司解聘。理由很简单，水平不足、学习能力一般，加之对自己不切实的定位导致了眼高手低。部门最后的意见是：此人工作中的能力不足，短期内也很难提高，建议此人即刻解聘。

    自信，也请以能力为基础！

超级自卑

    自信相对的是自卑。谈及薪水。很多候选人以“在这儿生活费太贵，公司支付的薪水要满足生活吧！”为理由提出薪水要求。而不是从能给公司做出什么贡献、如何体现自身价值为出发点提出薪水要求。

    这背后反映的是“我不知道自己为什么应该拿这么多钱！我也不知道自己值多少！为什么值！”

    无论是疯狂自信，还是超级自卑，技术管理层普遍对此有一个共识——不能认清自己的人，干好工作的机率和效率都会很低。定位不清的候选人很难被录用，企业认为与其找这种人来拖项目后腿，不如不用。

    不像欧美国家，开发人员职业发展稳定、有明确的晋升路线，做为快速发展的社会国内形式变化太快，很多时候我们无所适从也是客观条件导致，比如：今天还在做开发，明天可能就被转去支持销售成为售前等等。很多时候，我们对自己不是不想定位，是无法定位。

    掌握下面一些基本方法，也话让我们机会给自己相对准确的定位。

   1. 先按以下渠道了解市场价

   向资力相当、已找到工作的朋友询问薪水情况（大概范围即可），从而了解自己平均市值；
请教自己的师兄、师姐，能力出从的他们一定已工作有成，从他们那里可以掌握薪水几年后的增长情况。

    2. 正确估价

   了解目前自己同龄人的薪水之后，给自己估个起薪（原则是：比你自己认为的薪水，至少低一档。掌握全面信息之后，我们反而可能倾向于高估自己的价格），然后向应聘公司咨询入职几年后的薪水增长情况，最终做综合判断。

入职即闪看对待困难的态度

    下面说说最让部门经理和HR感到疯狂的事吧——入职即闪。

    这也是最让公司发疯的事之一。

    求职过程中，无论是公司，还是候选人都付出了时间成本、精力成本，双方确定合作意向之后，候选人入职成为了公司正式员工。求职时信誓旦旦的候选人，只工作了1周（1天）就一声不吭地离开了公司，当被问及理由时，多回答：“工作不适合自己”。

    应该说这个理由是对公司和候选人自己的极大嘲弄——双方都缺乏判断力，公司不知道应该找什么样的人加盟，候选人不知道真正来干什么、什么是适合自己的。

    以上现象的原因可能有：

工作压力大

    社会竞争的加剧导致了每个公司必须全力做到最好，才有可能生存。公司面临的压力，在工作中被完全转嫁给员工。但刚刚走出校门的”80后”没有做好这方面的准备，巨大压力扑面而来的时候感觉不知所措，比如：入职第一天简单培训之后就开始代码的编写或者对产品的支持，更多的东西要在工作中学。
很多人说“80后”像草莓，表面看起来很光鲜，但不能碰、也不能压。这也许是真的，但更重要的是处事的方法。

遇到压力、困难，没有正确解决方法

    因为只要工作，都会有压力，大小不同而已。逃避无疑是面对压力时，成本最低的方法，但长远来看也是代价最高的方法。

   “入职即闪”的离开，不会令公司感到惋惜。试想公司是不愿意请不能正确面对和处理压力的人加盟的。
当然，很多公司没有完善的入司管理制度，培训不到位，新人入职不安排专人带领熟悉情况是绝大部分公司存在的问题。这导致了工作中遇到的困难比想向的大、遇事找不到或者没有正确解决方法，于是造成了离职。这可能也是很多人原因进500强的原因，有完善的培训、升职、薪酬体系。

     关于处理压力的方法我们先分享下面的故事。

    某家长常教育孩子做事要竭尽全力，一天孩子与父母出门，发现路边石头很漂亮，想搬块大石头回家收藏，抱起之后走了一段路，因为石头太重搬不动了。虽然舍不得，但已没有力气，孩子准备放弃。此时，父亲到流泪的孩子身边问：“做事不是要尽全力吗？”孩子回答：“确实没有力气了。”“有啊！”父亲边说，边抱起石头大步走向家的方向，“！永远不要忘记，我也是你力量的一部分！”

    工作中，在我们尽力之后，还有无法处理的困难、无法面对的压力，那么向更有经验的同事、朋友请教是个好方法。相信我们的现在正是他们的昨天，我们正在经历的他们都经历过，在如果正确应对和处理方面，他们一定会特别愿意分享经验、帮助我们。

    无法处理时，救助可能是最好的方法。不要害怕说出“帮我一下！”这句话。

    在成长型的公司里，大家互相帮助会成为一种习惯，成为一种企业文化。相信这种文化也是“80后”一代所期望的。大家一起面对压力、处理问题会比一个人独自解决问题用时更短、效率更高。

写在最后的话

     以上事件中出现的候选人均为“80后”。曾经有人说，不要以时间来划分人，因为每个人的情况都有不同。与此同时，我们更应该承认：每一个时代的人都有自己的共同社会背景和大环境，这些东西造就了很多共同的特征。所以，“60后”、“70后”、“80后”这样的划分为我们的判断提供了基础。

    在经历了3000场面试之后，我可以肯定地说，与同龄人相比“80后”的技术人员给公司HR留下的印象是：更具可素性、拥有更高的可信度、更有潜力。他们正在（已经）成为技术队伍中的生力军！
面对压力大、社会变化快，尤其是开发知识不断更迭的新一代职场人，必然要磨砺出比上一代更有效的方法正确应对。这是社会发展的要求，应该也是我们自我提高的必由之路。

常用链接

留言簿(9)

我参与的团队

随笔分类(245)

随笔档案(239)

文章分类(3)

文章档案(3)

收藏夹(576)

友情链接

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜