现代软件工程讲义 4 方法论 - MSF
果冻：超总，听说你要讲MSF，我就先预习了一下，但是MSF的名词太多了，我真是头大，能不能解释一下这两句： “MSF的一个基础原理是学习所有的经验。这一原理在MSF过程模型里的关键里程碑上得到了充分的应用，在过程模型里愿意学习这一关键概念成功应用这一原理所需要的。愿意学习这一概念通过后里程碑回顾的经过检验的做法在项目里得到体现。在大型的和复杂的项目里，Microsoft建议是利用客观的外部服务商来确保有一个无过错的环境，并把学习最大化。”
阿超：你从哪里找到的绕口令？
果冻：MSDN中文官方网站呀。
果然，阿超在网上找到了这一段话（如图2-1所示）。
图2-1
他和果冻一起读了两遍，最后叹了一口气。
阿超：本来MSF挺简单明了的，这样一搞，反而很神秘晦涩了。
二柱：是不是有意搞得如此晦涩，以延缓我等的进步，阻碍我国软件大业的发展?
大栓：我以前听过MSF的讲座，觉得这玩意儿好像对大企业才有用处。而且MSF容易被人用来忽悠，我相信，一帮庸人，在MSF的大旗下还是庸人，只不过红旗飘飘，可以忽悠客户。
荔荔：我在网上看到IT企业有三大忽悠，大栓哥说的好像是第二种：
● 程序员用UML忽悠；
● 项目经理用Process忽悠；
● 老板用企业文化忽悠。
隔壁的小飞探过头来。
小飞：果冻，听到你还预习，我差点晕倒。
阿超：你说应该怎么学习呢？
小飞：好不容易出了学校，我现在对“学”好像兴趣不大，什么东西过耳就忘，要用的时候现学就可以了。
果冻：好像流行歌曲你经常学习，那些歌词你记得很牢嘛。
小飞：如果是载歌载舞，那倒印象深刻。可惜呀，MSF 好像不能载歌载舞，能不能在KTV学MSF？KTV、MSF都是3个单词的英语缩写，应该是兼容的吧。
阿超：果冻，你不用预习了，我会搞一个“白话MSF”，你一听就懂。为了让大家记忆深刻，MSF 的每个基本原则，都用一首流行歌曲来代表，小飞，你看怎么样？
小飞：好啊！如果你能带着阶级感情讲MSF，我就能声情并茂地唱KTV。
阿超，好，那就听好了……
MSF，即Microsoft Solution Framework，也就是微软推荐的做软件的方法。
MSF简史：约摸在1994年，微软在总结了自己产品团队的开发经验和教训，以及微软咨询服务部门的业务经验后，推出了Microsoft 解决方案框架Microsoft Solution Framework（MSF）。当时的MSF只是这些经验和教训的松散集合。在以后的几年中，MSF进一步吸收了微软各个部门和微软的合作伙伴在实际项目中的经验。在2002年，随着Visual Studio .Net的发布，微软发布了一系列关于MSF 3.0的白皮书，针对MSF 3.0的大规模培训也在中国开始举办。当时有一个“Architect 2000”的全国巡回演讲，很多IT企业都参加了。
2006年，MSF 4.0随着Visual Studio Team Foundation 2005发布。它增加了不少敏捷开发的内容，并且明确描述了团队协作的典型流程和在新的团队协作软件包VSTS中的应用。
2008年，MSF 4.2随着Visual Studio Team Foundation 2008发布, 它在文字和表达上有一些变化，但实质精神和MSF 4.0是非常一致的。
果冻：哪一年出的2.0呢?
阿超：我们需要关心么?
荔荔：果冻是怕考试时会考到这一题吧。
阿超：我们可以不用管MSF演化的细节，要记住所有模式都不是一成不变的，关键是要掌握变化的原因。
MSF有8个基本原则，我把它们都翻译成中文，并加上了我的理解。下面来分别讨论：
（1）推动信息共享与沟通（Foster open communications）
（2）为共同的远景而工作（Work toward a shared vision）
（3）充分授权和信任（Empower team members）
（4）各司其职，对项目共同负责（Establish clear accountability and shared responsibility）
（5）重视商业价值（Focus on delivering business value）
（6）保持敏捷，预期变化（Stay agile, expect change）
（7）投资质量（Invest in quality）
（8）学习所有的经验（Learn from all experiences）
第一个原则，用大白话来说，就是所有信息都保留，并公开，讨论要包括所有涉及的角色，决定要公开，并告知所有人。当然，对牵涉到技术机密、安全性等信息要采取必要的保护措施。
二柱：我们以前都是“老板让你知道，你就会知道，别多问。”看起来比较好控制吧？
阿超：以前两三个哥们一起捣鼓软件，大家都知根知底，好像没有意识到“沟通”的重要性，但是随着项目复杂度和团队规模的增加，没有信息共享与沟通是万万不行的。
二柱：如果有一些事情，我个人也没拿准是不是要通知某一方面的人员，怎么办？
阿超：在这种情况下，宁可过分沟通。
小飞：这是不是很烦？我得不断地告诉别人——我刚做了某事，我刚做了某事，好像网上有不少关于 “修改了文档的一个文字错误，就要发邮件告知天下” 这样的事儿 ……
阿超：对，人不能被规则累死，最好是让这些通知能随着事件的发生而自然地传递给关心这些事情的人。例如，在TFS 中，你可以设置提醒（Alert），让TFS自动通知你你所关心的事。另外，在TFS中，所有和项目有关的信息都会保存起来。例如：所有工作项及其历史；所有源代码的修改记录。
TFS用户经常问的一个问题是：在TFS中，我为什么不能删除工作项？
答案很简单，MSF的第一原则：所有的信息都保留，并公开。TFS的记录就像银行账户里的资金流动记录，是不可以删除的。
大牛：有人犯了一些比较愚蠢的错误（比如一个很低级的Bug），TFS把它们都记录下来了，从个人角度来看，有人会说：“我知道我做错了，已经改正，那最好把原来的记录删除了吧”，这样做，不是有利于打造和谐的团队么？
阿超：和谐的“谐”，是一个“言”和一个“皆”字，说的就是大家都可以发言，所有的事情都要记录。记录留下来，可以做事后分析，给后来的同事，或者别的项目的同事学习。如果删除，那也就违反了第8条原则“学习所有的经验”。如果历史是一笔糊涂账，某些事件被删除了，或者不能提，哪来的和谐？！我们公司要建立“对事不对人”的文化，好像有一句古话，把人的错误比做日食……
果冻：“君子之过也，如日月之食焉：过也，人皆见之；更也，人皆仰之。”还有，“人谁无过？过而能改，善莫大焉。”
大牛：我们以前关于项目的好多事，都装在几个头头的肚子里，最开放的，也不过是把一些问题列在Excel文件，或者是MS Project文件中，但是也没有历史记录。
阿超：看不到所有的信息，那么项目进度以及项目中存在的各种问题就不能及时让所有人知道，这样MSF中其他的原则也就不能实行了。没有开放的信息，也就谈不上“授权”，或者“建立清晰的责任和共同的职责”，以及“保持敏捷，预测变化”。这也是为什么“推动信息共享与沟通”是第一个基本原则。
MSF团队模型和MSF过程模型也是建立在“信息共享与沟通”原则上的。
小飞：对于这一个原则，我要推荐庾澄庆的 “请开窗”——
如果相爱能轻易推测出结果
谁还需要用真心来沟通
……
阿超：“为共同的远景而工作”，对于这句话，大家是怎么理解的？
杂曰：这就是所谓同心同德。兄弟同心，其利断金。我们当然是同心的啦，大家都是哥们，都为了移山公司的兴旺才来的。
阿超：好，但是这里面提到一个“共同的远景”，这是什么玩意？
杂曰：就是我们移山公司以后要发！
阿超：发是肯定的，大家注意这个“共同的远景”是指产品的远景。我们做一个产品，不管是应用软件、行业软件，还是通用软件，要明确项目的目标是什么。
（1）这个目标必须是明确的，没有二义性；
（2）这个目标不是当前就能达到，必须是通过努力才能达到的；
（3）这个目标不是空泛的，它应该对项目成员每天的工作都有指导作用。每天你来上班，如果发现你做的事情对项目的远景没有帮助，你应该跟老板提出来。
荔荔：我们有些项目好像没法订出来这样的目标耶，或者老板也不清楚我们到底要干什么。
阿超：那么，很显然这些项目的带头人没有及格，这些项目最后没有达到预期的目标，也就不奇怪了，因为我们连预期的目标是什么都没有搞清楚。
大牛：能举例说明么?
阿超：比如我们村里曾经有个体育新闻网站，当时它的远景号称是——
“移山体育网提供即时、准确的体育新闻，它提供论坛，体育用品购物网络，使得体育爱好者能共享一个公平、健康、安全的交流环境。”
刚开始做得不错，我也经常光顾访问，但是后来好像新闻和论坛的质量都下降了，购物网页没有下文，几次改版之后，占据头条的经常是关于体育明星的小道消息，和他们传说中的女友传说中的三围尺寸，还有河曲村中上层人士争喝某种饮料的消息等。我一直想问谁是主编。
大牛：（举起手）我就是移山体育网的总编，刚开始，我每天做的事还是和我们最初的远景相吻合的，人气也不错，后来我们觉得什么能吸引眼球就上什么，慢慢搞成了四不像，名声也搞坏了。我们的内部远景已经改为——
“移山体育网要吸引眼球和广告，直到找到买家为止。”
大栓：大牛，你们啥时候改的远景？我怎么不知道？
大牛：这个要问阿超。
阿超：这样的远景也不见得错，但是不要忘了我们讲的是“共同的远景”，即团队的领导人要让全体成员都同意项目的远景，并为之奋斗。如果一部分人还为远景1.0而奋斗，但是另一半人却在为远景2.0而努力，那是要出乱子的。
如果没有“共同的远景”，即使团队发布了产品，不同的成员对项目是否成功，以后如何发展，也会有不同的看法，因为他们心里的远景（参照物）是不一样的。
小飞：对了，后来河曲村中上层人士争喝的饮料咋样了？
大牛：别提了，他们以货抵广告费，放在办公室的几箱饮料后来都被我爹扛回去喂猪了。
阿超：另外，在项目到了关键的时刻，我们再和大家统一思想，向往远景，已经晚了。
大牛：我想起以前国家足球队在某次世界杯的表现，预选赛到一多半的时候，足协的领导叫全体队员向国旗宣誓，我就觉得很搞笑，如果大家平时都目标一致，搞这种宣誓只是形式，如果大家平时没有这样的目标，突然间宣誓并不会让队员们突然更爱国，脚上功夫更好一些。
阿亨：另一个事例，说明远景也和实际工作有密切关系。大松博文在中国女排搞“魔鬼训练”的时候，如果大家的远景不是世界冠军，干嘛费那么大的劲？每天随便练练，早点洗洗睡得了。
阿超：对，如果我们移山公司的目标只是业余玩玩网站，大家干嘛费劲学什么MSF？
小飞：远景是由领导决定，还是自下而上形成的？
阿超：一般是由“有远见的人”提出，然后公开讨论，在讨论的过程中，可以消除误解，凝聚共识。这是一个项目的关键，是项目第一阶段要达到的主要目标。
二柱：这是不是俗话说的“统一思想”，或者另一个俗话说的“洗脑”？不是说国外不兴洗脑的么？
阿超：可以这样看，但是我们下面要说另一个基本原则，需要你的大脑有原创精神。
小飞：洗脑归洗脑，我要用这首歌曲表达洗脑后的心情——“嘻唰唰”：
闪闪红星里面的记载
变成此时对白
嘻唰唰嘻唰唰嘻唰唰嘻唰唰
……
这一点的关键是“授权”这个词，英语是Empower，是什么意思呢？
授权（Empower）有两个意思：一是给某人权力和权威（Give authority to somebody：to give somebody power or authority）；二是给予某人更多自信和自尊（Inspire somebody with confidence：to give somebody a sense of confidence or self-esteem）。
在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权力在自己的职权范围内按照他们自己的承诺完成任务，同时，他们也充分信任其他同事也能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也认为团队能兑现承诺，并进行相应的规划。
二柱：这样做好像很危险哪！
阿超：那应该怎么办？采用“命令”的方式？！
充分授权的管理方式是MSF的核心观念之一。MSF团队模型就是建立在以下两个原则上的：
（1）平等协作——成员之间、团队之间是平等协作的关系；
（2）充分授权给团队和成员。
这就是为什么MSF团队模型是网状，而不是层次结构。
这样做有什么好处？好处有两点：
（1）被授权的人会承担起自己对项目的责任，同时也期望同事们也同样对项目负责；
（2）MSF提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间，而不是上级交给的时间，这意味着让真正做这件事的人按照自己的估计去完成任务。这样做的结果是啥？是人人都会支持项目的计划和时间表，因为这个时间表是每个人自下而上订出来的！
二柱：听上去很美，但是我作为一个组长，给我的组员充分授权，到头来发现事情都没做完，咋办？我只好不断地问：你做到哪里了，还差多少？
阿超：这要靠工具的支持，在VSTS系统中，由于所有工作的进展都记录在案，任何延迟都会被及时发现，这样组长（或其他层次的领导）就不用把精力花在“询问”上，而在“帮助解决”上，在最关键的时候提供指导和帮助。领导在项目中的角色是“支持成员完成任务”，而不是“控制成员，迫使他们完成任务”。充分授权在MSF团队模型的另一个含义是：信任，鼓励团队成员成长，每人都可以在某一时段、某一领域当领导。比如二柱是程序安全性的专家，他就可以带领其他成员对项目进行安全性检查。如果测试工程师斯坦刚刚学习了如何做压力测试，他可以带领其他测试人员对产品进行全面的压力测试。
果冻：能不能推而广之，如果企业的各级领导秉持充分授权的信念，让员工觉得被充分授权，从而对工作产生热情，变得积极，进而能够充分发挥自我潜力，企业整体即能够产生良性循环。
斯坦：在《致加西亚的信》中，我觉得如果没有总统对罗文的授权和信任，罗文也不可能完成这一艰巨的任务。比如，如果总统信不过罗文，派另一个“助手”和他一起走；或者，让罗文每天向领导汇报进展，然后决定下一步行动，这样的话，罗文肯定就不能把信送到。
大牛：斯坦，我觉得你的发言，不同于网上成千上万条的《致加西亚的信》读后感，提供了新的视角，真不容易。
这一原则还对企业传统招人、用人的方式有冲击，我觉得这是MSF最难在中国公司实行的一部分，“授权”、“放权”的管理理念和很多公司的企业文化不相符。
二柱：我早就说过MSF在中国不灵的啦。
果冻：我国古代也有充分授权和信任的例子，看这一段——
“郢人垩慢其鼻端，若蝇翼，使匠石斫之。匠石运斤成风，听而斫之，尽垩，而鼻不伤。郢人立不失容。宋元君闻之，召匠石曰：‘尝试为寡人为之。’匠石曰：‘臣则尝能斫之，虽然，臣之质死久矣。’自夫子之死也，吾无以为质矣，吾无言之矣！”
大家一致反映要听白话文的解释，果冻解释完了以后，大家七嘴八舌地议论，这里面有授权和信任么？
大牛：有啊，郢人授权匠石，他并没有管匠石的操作细节（用斧头，还是菜刀、匕首或者手术刀）；然后他“立不失容”，才能让整个操作成功，这里面体现了信任。
阿超：要注意这种信任是两方面的，匠石也信任郢人会“立不失容”，不会缩头缩脑，因此他才能“运斤成风，听而斫之”。如果有互相猜疑，就会出乱子，例如，匠石心里琢磨“我估计他会害怕，脑袋会往里缩二寸，我要往里再砍两寸”，而郢人心里想“我得再伸出去一些，这样斧子才够得着”……如果没有双方互信的基础，宋元君真的敢试？匠石真的敢砍？这个故事里的相互信任，可以与“高山流水”中伯牙、子期的相互理解相媲美。另外，充分授权之后，领导是不是显得有点没用了呢？
小飞：如果团队很厉害，领导就会升上去喽！
阿超：这个我也不知道，如果我能证明我的人马很厉害，甚至显得我都没有什么必要，那我倒是可以做一些更无足轻重的事了……
小飞：比如说总裁什么的。
阿超：这倒提醒了我，“充分授权和信任”对于领导者提出了什么样的要求？
领导者能不能对手下人说：“这事就交给你了，你办事，我放心。” 就完了？
大牛、阿亨、大栓你们几个是当领导的，都说说看？
阿亨：我扯得远一点，这教训是，不能等到自己快不行了的时候，才授权。
阿超：授权不等同于放任不管，领导者在授权之后，要为手下的成功提供各种必要的帮助——技术上的培训，策略上的提醒，以及各方面的信息和资源。
大栓：我们以前的项目中也放权了，并且鼓励大家勇于发表意见，结果大家倒是很踊跃发表意见，每个人对其他任何人的做法都发表了意见，大家最后吵得不亦乐乎，但是没有实际的进展。
阿超：这就牵涉到下一个原则。
小飞：等等，我选的歌曲是“信任”——
没有信任
爱情就失去了颜色
……
团队中的每个角色都有自己的职责（见表2-1），如果出了问题，这个角色就要负责任。
表2-1 MSF团队模型和关键质量目标
| 关键质量目标 | MSF小组角色 | 出口条件 |
| 按约束条件交付产品 | 程序管理 | 我们的项目是在时间/资源的条件内交付的么？ |
| 按产品规格说明交付产品 | 开发 | 我们是否按照功能说明完成了各项功能？ |
| 保证所有问题都得到处理 | 测试 | 我们发现了所有的问题，而且都有处理方案吗？ |
| 产品部署和后续管理 | 发布管理 | 客户是否能快速方便地部署产品和进行后续管理？ |
| 让产品更好用 | 用户体验 | 产品是否适应用户的使用习惯？易学易用？ |
| 让客户满意 | 产品管理 | 客户是否（在总体上）满意我们的项目？ |
比如说，如果产品发布后，客户在部署和管理上出现了很多问题，那负责“产品部署和后续管理”的角色“发布管理”人员就要站出来对此负责。
与此同时，团队的各个角色合起来，对整个项目最终的成功负责，为什么？因为每个角色在其职责范围内的失败都会导致整个项目的失败。而且各个角色的工作都是互相渗透、互相依赖的。这种互相依赖的方式也鼓励团队成员在自己本职之外为其他领域做贡献。例如，测试人员可以帮助“用户体验”角色更好地设计用户界面，因为如果用户界面很差，再好的功能也不能发挥应有的作用。
问：如果我要做一件事情，但是周围的人有不少不同意见，短时间又不能完全说服他们，怎么办？
答：对此事负责任的角色要自己拿主意。
阿超：我今天在“顶球”网吧看到大牛他爹老崔在下棋，围观者支招的不少，有的说上马，有的说拱卒，有的说出车。大牛他爹一会儿招法就乱了，眼看局势不灵了，围观者一哄而散，老崔后来也没法，只好认输了。
一个围棋国手在一次重要的对局后，听到旁观者对棋局的进程有很多不同的看法，他也没有过多争辩，只是说：“无责任的旁观者和有重大责任的当局者的看法自然是不一样的”。
无责任的旁观者在支招后，如果不灵，他可以面不改色地继续支招，甚至可以给另一位对局者支招，不管最后谁输谁赢，旁观者随时都能安心地离开，回家吃饭。有重大责任的当局者在走了损招或败招之后，他很可能就要认输下台，丢掉比赛的奖金和头衔。
大家还记得父子和驴的故事吧：
“父子出门，子骑驴，人诽之；父骑驴，人亦诽之；父子同驴，人人诽之；无奈，遂父子抬驴。”
这些都说明一个什么问题？如果我是责任人，最终还要我自己拿主意。别人的意见都只是参考。我的责任是把事情做出来，而不是讨好所有人，让他们知道我按照他们的意见做了。
在项目进展的过程中，对于每一项任务，每个人都要明确以下几点：
◆ Who：谁负责；
◆ What：做什么，具体的执行方案，什么叫做“做好了”；
◆ When：什么时候开始，什么时候结束；
◆ Why：为什么是这样安排（和项目的远景是否吻合），在什么情况下可以变更？
与“信息共享与沟通”原则相呼应，这样的安排能让所有人都明确自己的职责，同时有“大局观”——知道别人在做什么，为什么，以及整个项目的目标。
小飞：对这种连大牛他爹都可以从中受益的原则，我觉得应该选一首家喻户晓的好歌“敢问路在何方”——
你挑着担，我牵着马，踏平坎坷，终成大道。
……
各司其职，圆满完成任务。
阿超：我们都是搞技术的，但同时我们也是一个商业实体，我们的项目都应该是出于商业目的，如果没有商业的需求，再酷的技术也没有用，商业项目需要重视市场和用户，技术是处于第三位的。
阿毛：我们村的技术在这一带是有口碑的，王屋河水流经之处，人们都知道王屋村的年轻人是打奶（.net）的好手，这是我们的品牌呀。
阿超：一个沉溺于技术而忽略商业价值的团队，就像盲人骑烈马，跑起来很拉风，但最终不免人仰马翻。我要给大家介绍一首歌 “错误” （词：郑愁予，曲：罗大佑）——
我嗒嗒的马蹄
是个美丽的错误
我不是归人
是个过客
……
为什么他是过客，因为他光知道拉风，不知道他的情人在楼上等他。
回首望去，很多“高科技”的公司就是过客。怎样衡量一个项目的成功？并不是最酷的技术，而是商业的成功。
一个项目的商业价值只有在它被成功地发布并运行时才能体现出来，所以，MSF过程模式包括了开发和发布阶段。当年在学校的时候，所有课程的项目都没有真正在实际环境中运行过，现在的学生应该有条件这么做了吧？
［小飞、荔荔、九条面面相觑］
阿超：我听说你们在软件学院比赛中做了一两个很酷的项目，得了奖，解决了实际问题，不是么？难道没有真正运行起来？
荔荔：项目演示完了，我们就没有管了，好像也没有人要求我们在实际环境中运行。我们把代码交给院里，过不久代码就不全了，也不能编译了，后来也就不了了之。
阿超心想：糟了，软件学院领导推荐的学生就这水平，也许应该找那些在外兼职的学生……
小飞：我经常听说“激情”才是最重要的，写软件的大拿们当初都是激情万丈，代码如泉涌……
阿超：激情可以被激发出来，也可以消失，或者移情别恋；而且激情因人而异。当项目遇到困难的时候，当项目看不到尽头的时候，有人就会问世间激情为何物，能叫我每天加班？一个团队项目如果没有经得起考验的商业价值，没有明确的远景，是很难坚持下去的。
看看国外的观点，他们搞了很多年的商业：
“Don’t start a business if you can’t explain what pain it solves, for whom, and why your product will eliminate this pain, and how the customer will pay to solve this pain.”
如果你还没有能说清楚你的产品解决了什么问题，为谁解决问题，为什么你的产品会解决这些问题，以及客户怎样付钱让你解决问题，那你就不应该贸然创业2
类似地，如果我们没有搞清楚我们的项目会解决什么问题，为谁解决问题，为什么它会解决问题，以及怎样才能拿到客户的报酬，那我们的项目还不能算是真正开始。
斯坦：那开源/共享软件是怎么一回事，如果开源了，商业价值如何体现？
阿超：这个问题问得好，我估计如果开放讨论，以咱们的风格，三天三夜也讲不完。但是回到具体问题，让我们设想一下，如果我们项目成功了，有人以“开源”的名义来要我们的源程序，我们答应么？
二柱：凭什么！
阿超：对呀，凭什么？！在软件中凝聚了我们“无差别的人类劳动”——这就是软件这一商品的价值，我们的口粮、公司的水电费都得用这一价值去交换，我们如果重视商业价值，就要有重视商业价值的做法。有一些原来 “闭源” 的项目，后来变成开源的，总是有各自的原因，这些原因里面，商业运作的因素也很明显。
二柱：但是正如你所说的，我们都是搞技术的，那怎样才能保证我们“重视商业价值”？
阿超：在MSF团队模型中，“用户体验”这个角色代表了用户的利益，保证产品能真正易于使用；“产品管理”这个角色代表了客户的利益，保证了我们的产品能为顾客提供商业价值。搞技术的，要尊重这两个角色，因为他们代表的是我们的衣食父母。
二柱：我们的激情会变，但是大牛才是变得最快的，他隔三岔五跑来说，客户有点新想法，我们要做一些小改动……
大牛：那怪不得我，是咱们的“衣食父母”提出来的。
阿超：这就扯到下一个原则。
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化。
除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开……这些都要求我们团队保持敏捷的身段。
大牛：最近业界有人总结，项目需求的生存期是18个月，就是说如果一个项目的需求是18个月前确定的，而产品还没有做出来，那几乎就可以不做了，因为需求肯定已经发生了很大变化。
大牛：大家有没有注意到微软的一些成功项目的各个版本之间也是间隔18~24个月。有些别的公司产品发布的间隔更短。
小飞：那为什么SQL Server要5年后才更新？
大牛：（清了清嗓子）在座的哪位能分析一下？
阿超：5年发布一个新的版本，肯定是有不少问题。例如，我们可以想象一下，在2000年，根据市场占有率的分析和预测，某个产品说我们一定要支持Win2000和Win9x平台，因此产品组做了不少技术攻关，保证代码同时可以在两个平台上运行，代码复杂度也因此上去了，测试组也要花大力气 “保证所有问题都得到处理”，两年过去了，2002年，大家终于实现了预期目标。然而产品并没有发布，Windows XP/Windows 2003 Server正成为市场新宠，大家开始讨论是否有必要保持Win2000/9x的一致性，因为它增加了开发和测试的难度；到了2004年，这个产品还没有发布，当时的决定看起来像一个笑话，管理层开始讨论是否砍掉Win9x平台的测试预算。2005年底，产品终于发布了，这时谁还关心Win9x呢？前几年的投资有回报么？
斯坦：既然总会变，那么似乎没有必要在每一步骤都保持高质量？
阿超：你的潜台词是因为变了之后，以前做的事就没有意义了。但是高质量在任何时候都是有益的，低质量的工作，会误导客户和团队，也许会导致错误的变化。达到高质量是有代价的，关键是要给客户提供及时、准确的信息，根据客户的反馈进行修改。质量是重要的，但是如果你的功能不能满足客户不断变化的需求，注意是“不断变化的需求”，那么再高的质量也没有用处。软件的质量在敏捷的开发流程中处于什么样的地位？请看下一节。
小飞：等等，我觉得最符合这一原则的歌曲是“不是我不明白”——
不是我不明白
这世界变化快
……
（反复多次，直至声嘶力竭为止）
对质量的重视，引起对质量的投资，引起对人、过程和工具的投资。
大牛：为什么叫投资？干脆叫“质量第一”，或者“全面质量管理”不就完了么？
阿超：之所以叫“投资”，是很有道理的。听我慢慢道来。
（1）投资要讲效率。软件开发过程大部分时间花在了解/设计/变更/再了解/再设计的过程中。我们要重视质量，但并不是要不惜一切代价达到最高的质量标准（听众中有人倒吸了一口凉气），因为提高人/过程/工具的质量是要花成本的！ 我们不是为提高质量而提高质量。我们要讲投资的效率。比如，在做快速原形的过程中，有些部分可以做得粗糙一点。
（2）投资要讲时机，比如说对于某项技术的培训，最好的做法是在即将需要的时候进行培训。太超前或滞后都不灵。
（3）投资是长期的。和投资股票/不动产一样，真正的投资者看重的是长线的收益；人的成长、团队的成熟都需要时间，不可能短期内立竿见影。 那些“短平快”的东西，叫投机，不叫投资。
大牛：对，投机的事儿多了。比如，有些公司听说国家要求软件企业必须达到CMM某个等级才能参与投标，于是花了两个月的时间，公司就奇迹般地提高到CMM 3级，这是投机，不是投资。
阿毛：另外，什么叫软件的质量？每当一个大型软件发布之后，紧接着这个软件“服务包——Service Pack”就会出动。然后我经常看到报道说微软的Windows或者Office有几千个Bug没有解决，就发布了。我们移山公司的质量尺度是什么呢？不会像微软那样吧。
大牛：如果我们能做出Windows或者Office，占领全世界80%到90%的个人电脑市场，我个人很愿意像微软那样。不愿意的同志别来和我争这个利润。
阿超：我觉得和人类血型类似，大家的“软件血型”也可以分4种：
A型：他们知道优秀的软件公司会发布有已知缺陷的软件；
B型：他们不相信这一点；
O型：他们不知道这一点，因此嘴巴惊讶成O型；
AB型：他们对于自己开发的软件是A型，对于别人开发的软件是B型。
觉得自己是A型的举手……好，大约一半人举手是A型，好像大部分是工作了几年的同事。那么剩下的另一半人没举手就是B型了？
小飞：我在犹豫。我可能算AB型。呵呵。
阿毛：我虽然觉得我可能是错的，但是我目前确诊是B型。而且我们老师曾教导我们QA的使命就是不让一个Bug跑掉。
阿超：B型的人会发现搞软件开发是很痛苦的事。要说明的一点是，所有软件公司都希望能够把缺陷都改正了才发布软件，但是第一什么叫“缺陷”？如果只是一些无关大局的问题，用户可以绕过去的（荔荔：是不是英语叫Workaround?），我们非得马上解决么？第二什么叫“改正”？如果改正的方案中又有“缺陷”怎么办？我们做商用软件的人都在为此苦恼，只有优秀的软件公司能找到一个平衡点，及时发布能够解决用户问题的软件，并且能及时修改软件中的问题——注意，这两个“及时”并不一定是同一个时间。做非商用软件（比如为了演示、交作业）可以不用管这两个及时，交了卷，就万事大吉了。所以，MSF没有提“质量第一”，或者“全面质量管理”，我希望移山公司不是质量第一，而是解决用户的问题第一。我也不希望移山公司是“全面质量管理”，因为“全面”之后，会出现“大道废，有仁义”的现象，大家都讲“全面质量管理”，往往意味着我们的质量管理没有抓到点子上。而且有些庸人往往会以“要达到高质量”为由，阻碍正常的工作进程。
大牛：对，现在社会上到处讲诚信、荣耻，事实上说明这个社会是很有问题的。
杂曰：对呀……[在此略去大家对社会现象的讨论5000字]
小飞：我要选一首歌“爱的代价”，正如对爱的追求，对高质量的追求也是有代价的。
大家一齐哼哼：
那些为爱所付出的代价，是永远都难忘的啊
……
阿超：古今中外，人们对经验的学习还是比较重视的，我们经常听到“忘记过去的人注定会重复过去的错误”等类似的谚语。咱们中国的老祖宗也没少唠叨，哪位能提供一些成语典故？
杂曰：数典忘祖，好了伤疤忘了痛，一朝被蛇咬，十年怕井绳……
阿超：停！“一朝被蛇咬，十年怕井绳”并不是“学习所有的经验”，而恰恰是没有学习，不敢分析蛇和井绳的区别。
我们要重视经验，但是不能错误地沿用过去的经验——寓言里讲过这样的故事：驴子驼着两袋盐过河，不小心跌在水中，起来后觉得货物轻了不少，暗喜；后来它驮着两大包棉花过河，也故伎重演，但是效果却适得其反。
在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题。
荔荔：那为什么在软件开发中我们往往没有吸取前人的经验教训？
杂曰：“没时间”；
“每一个项目都有自己的特色，不宜生搬硬套”；
“项目的经验都在各人的脑子里”；
“项目结束后，大家都散伙了，没人组织总结，或者写总结的人有偏心”；
“有时总结变成互相指责，搞得不欢而散”；
……
阿超：这一原则有两个含义——
（1）把经验总结出来；
（2）分享经验。
为什么要坚持总结和分享？是为了——
（1）让团队成员从别人的成果和失败的例子中学到东西；
（2）帮助新项目重复以往成功的做法；
（3）培育团队总结的习惯和“批评与自我批评”的文化。
MSF在每一个里程碑结束时都要做一个“里程碑回顾”，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广。
在项目结束时，MSF推荐请团队以外的专家来主持召开“事后诸葛亮”会，这样的专家会比较系统地总结团队的成功经验和失败教训，同时也客观评价团队的一些特性和团队的开发过程管理，这样能促使团队成员以客观、向前看、解决问题的心态来参加“事后诸葛亮”会，避免主观臆断或相互指责。
二柱：但是这样的做法是否能符合国情？我们文明古国讲的是“以德报怨”，有一些错误，交了学费，就算了，不要拉下脸皮嘛。最后大家聚餐一下，灌醉了领导和同事，擦干嘴边的油渍，又继续前进了。
斯坦：似乎国外有说法是什么“打你的左脸，你要把右脸也凑上去……”
阿超：我们似乎也扯得太远了。我只知道文明古国的孔子好像是反对“以德报怨”的吧。
果冻：孔子他老人家说过，“以德报怨，何以报德？”，他老人家主张“以德报德，以直报怨”，我的理解是别人做了错事，特别是对你做了错事，你要指出来，并且争取得到改正。由此看来MSF还是比较符合儒家思想的。
斯坦：微软的同志们没想到用“儒家思想”这一招牌来给VSTS做广告，否则早就卖火了。
小飞：我还没有想起什么儒家思想的歌曲，姑且用这一首歌吧——“改变所有的错”：
改变所有的错
让我从头爱过
改变所有的错
再错也不回头
改变所有的错
就是我的承诺
……
二柱：哇！总共有8项基本原则之多，有没有搞错，我们上学的时候只要求能背4项就可以了。
果冻：8项的确太多，如果在工作中忘了几项，怎么办？
阿超：记住，我们的目标是把软件做出来，不是记住条文。当你记不住这些东西的时候，想想怎么样才能把软件做出来，实现我们的远景，该干嘛就干嘛。
MSF团队模型定义了小组同级成员的一些角色和职责，如图2-2所示。
MSF团队模型认为，任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。如果任何一个角色无法实现其目标，都将危及整个项目。因此，每个角色都被认为是同等重要的，重要的决定都要共同做出。相关的目标和角色如表2-1所示。
图2-2 团队模型
说白了，一个项目要达到的目标很多，MSF团队模型让不同的角色去实现这些目标。在一个项目结束的时候，每个角色都问自己这样的问题——我是否达到了我的质量目标？
最后，比如测试团队（角色：测试）要保证“我发现的所有问题都得到解决”，那么测试团队就会做以下两件事：
（1）发现产品的问题；
（2）保证这些问题都得到处理。
要注意的是，保证这些问题都得到“处理”和得到“解决”是不一样的，有些问题目前不能得到完美的解决，但是可以有让用户满意的处理方案，项目团队不能回避这些问题。
问：我们发现了问题，但是我们目前的“处理”不能让用户满意，怎么办？
答：测试团队就要和别的角色（如：产品管理/程序管理/开发）一起研究用户需求，在可能的方案中选出一个，比如：
（1）按照目前的状态交付，向用户说明（如：在某个操作系统/浏览器版本下，某个功能不能正常工作）；
（2）推迟交付时间，让团队有足够的时间来解决问题；
（3）修改产品的约束条件（如要求客户的操作系统/浏览器必须是某一个版本以上，或者增加一个附加条件：产品发布后半年会出新的插件解决问题）。
在讨论处理方案的时候，每个角色从自己的质量目标出发，对自己的质量目标负责。
问：那有冲突怎么办？
答：那就吵呗（众笑）。各个角色的利益是有一定的冲突的，MSF没有掩饰这一点。MSF团队模型的核心是，成功的技术项目必须符合各种利益相关人（stake holder）完全不同且常常对立的质量观点。
问：这么说在团队中有矛盾是正常的了？
答：对！例如，用户代表觉得新增加一个功能很酷，因为新功能“让产品更好用”，但是程序管理角色觉得会影响“按约束条件内交付产品”的目标，测试会觉得“保证所有问题都得到处理”的目标受到威胁，用大白话说，就是“我没有时间测试你的新功能，因此不能加这个功能”。这就要各方在整个项目的共同利益之下，协商解决。
问：我原来认为测试人员说“我没有时间测试你的新功能，因此不能加这个功能！”是态度问题，会被开发人员鄙视的。
答：这是对产品质量负责的态度，你要代表你角色的利益，如果你有充分的授权和信任，你就要直言不讳。
除了项目的各个角色之外，MSF团队模型还可以推广到包括操作、业务和用户等外部因素。在对立中寻找共同利益，在冲突中达到平衡。MSF团队模型推动了不同利益代表在追求共同利益过程中的融合。
果冻：“在对立中寻找共同利益，在冲突中达到平衡”，其实我们的孔夫子对此早看得门儿清——
子曰：君子和而不同，小人同而不和。
二柱：儒家思想这么厉害，干脆让孔子和他的三千弟子开发软件得了。那么后来也不会有C语言，用《论语》就可以写操作系统了。
果冻：《论语》本来就是操作系统呀！半部《论语》就可以治天下，何况操作系统乎？
每个项目都要经过一个生命周期，图2-3是MSF过程模型生命周期的一个简图。
图2-3 过程模型
MSF过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中基于里程碑的规划优势与螺旋模型中增量迭代的长处结合了起来。
MSF过程模型的基本元素是阶段和里程碑。所谓“阶段”，就是在这一段时间里团队集中精力做某一类事情，每个阶段的结束都代表了项目的进展和团队工作重心的变化。比如在“开发阶段”结束后，团队就不再允许设计/实现新的功能，除非有充分理由的“变更请求”。
问：我觉得这样也太理想化了，一个10多人以上的团队，不可能在某月某日同时完成某一阶段，然后第二天进入下一阶段。
答：对，各个阶段之间会有缓冲区，团队中各个功能组的进度是各有区别的，不必强求一律。
团队用里程碑来检查工作是否结束和同步各个角色的进度，以此来确定当前阶段的目标是否已经实现。
此外，里程碑标志着每个阶段的结束，团队在此时应该引导成员转移工作的重心，并鼓励队员以新的视角来看待下一阶段的目标。在上一个阶段产生的各种交付内容，将成为下一阶段的起始点。
在Visual Studio 2005中，MSF演化为以下两个分支：
◆ MSF敏捷开发模式；
◆ MSF CMMI开发模式。
我的感觉是，MSF敏捷开发模式吸收了近几年来在软件业界流行的各种“敏捷”开发模式的优点，认识到目前大部分软件是以网络应用相联系，强调和用户更紧密地交流，快速叠代，避免不必要的过程。
在继承MSF 3.0基本原则的基础上，MSF敏捷开发模式和以前有什么不同？有以下几点。
项目的商业价值要由用户说了算，那些“我觉得用户会喜欢”的东西要及早和用户交流。因为“我觉得”和“用户觉得”是两码事。
小飞：我说一句可能不太中听的话，我觉得有时用户好像很，嗯，很不愿意交流，很自负。有时又很傻，很天真。和他们交流有时好像是对牛弹琴。
二柱：那就派大牛去弹好了。
大牛：有这么几种情况——
（1）用户不懂他想要什么。有些用户只有一个模糊的需求，他们说：我们企业要上ERP！你给我整出来。这种情况下，我们得和用户一起做需求分析，先把牛找出来；
（2）用户想要的和商业价值无关。比如有些用户说，我想让每个按钮都是半透明的，还要有三维效果，就像一些网络聊天软件一样酷！这些要求和他的企业管理项目的价值没有直接联系。也许这个用户代表是一头牛，而不是用户代表，我们要找管牛的人；
（3）用户想要的我们还不懂。这种情况下，我们是牛，用户是在对我们弹琴；
（4）大家心里想的不是牛，也不想弄清牛想什么，只要有钱就行。例如：
客户：你能不能做3G？
我们：上3G干啥？我们还搞不懂3G，好像没有人真正需要3G。
客户：对，我也不懂3G，但是我手里有三百万预算要花掉。
我们：啊呀，你干吗不早说，那咱们就搞一个三百万的3G项目好了！
防止缺陷的发生成为团队质量控制的首要任务，所有的角色都要对防止缺陷的发生和确保缺陷被修复负责。
有一些团队把开发和测试有意无意地对立起来，好像二者是矛盾的。一个典型的例子是，有时开发人员不想给测试人员足够的信息，好像不想“帮”测试人员找到缺陷；与此同时，测试人员一旦找到缺陷，会有一些得意的表示——“看，你写的代码那么臭，我又发现了N个Bug”。这种对立情绪，也许在短期内能刺激成员的工作热情，而从长远来看是有害的。很少有人会希望在这种充满对立情绪的环境中工作。
微软公司内部做过统计，在一个中大规模的团队中，一个“缺陷”从发生到被改正，中间经过了近20道工序，平均总的时间开销是12小时。最好的事情，是可能的缺陷在设计阶段之前就讨论过，并且在代码中已经避免了，因此在“缺陷跟踪系统”中，并没有出现很多缺陷记录在案，但是软件的质量仍然很高。
这一点要求我们保持随时可以发布的高质量。如果用户说：时间到了，网站要上马。我们应该很快地交给用户一个可用的版本，也许有不少功能没有加入，但是版本中包括的功能都可用。
这就要求我们必须保证项目的质量是“随时可用”。为了达到这一点，我们要重视产品的安装和发布——产品要尽早能够达到随时安装、发布的标准。在我们以前的项目中，安装和发布都是最后阶段才做，这就导致几个问题：
（1）开发过程中，测试团队很难安装产品，阻碍了测试团队的进展。很多情况下，测试人员不得不从多个源头拷贝不同的文件到测试环境中，才能开始测试。浪费了很多时间；
（2）关于安装的缺陷得不到重视——用户拿到一个Beta版，意见最大的就是：安装不上！或者好不容易装好了，却卸载不了，不得不重新安装系统。
二柱：好像这个VSTS早期的版本就有这个问题，真是具有讽刺意义呀。
鼓励团队在实战条件下使用产品，就是“吃自己的狗食（Dogfood）”，或者叫“自作自受”。
大栓：所谓“dogfood”，也不难理解，比如我们小学食堂的伙食都很差，简直可以和“狗食”媲美。（众人大笑），但是食堂领导无动于衷，因为食堂的领导和职工都是吃自己的小灶。如果食堂的领导实行“dogfood”制，身体力行，和食堂员工一起吃给学生做的大锅饭、大锅菜。我想这个问题应该很快就能得到解决。
小飞：我们要做的项目，怎么才能dogfood？
大栓：那我们就自己注册成为用户和商户，然后在系统上做一些交易吧。
阿超：这就要求我们的安装程序能够随时安装最新的版本，同时对于我们服务器端的数据迁移提出了很实际的要求。
果冻：听说微软成功的秘密之一就是“狗食”，看来我们也要掌握这一秘密武器了，不过，狗食有没有副作用？（众笑）
阿超：好像是有的。狗食过分的话，会让软件开发人员不自觉地把自己当成了典型用户，造成的一个结果是开发出来的软件只适合技术人员使用，一般的用户往往不得其门而入。比如，好多功能都深藏不露，如果你问一个技术人员，技术人员往往略带不屑地告诉你，把菜单中的“工具 | 选项”打开，在某个“高级选项”下，改某个参数即可。但是我们的客户谁有这种技术水平？谁有胆在“工具 | 选项 | 高级”里乱按？
实战条件下质量的另一方面是，进行经常性的迭代（小的里程碑），使用户能够及时看到产品，并提供反馈。
小飞：这不就是快速原型法？
阿超：这不完全等同于快速原型法，用户看到的功能应该是能够马上使用的，而不只是一个原型。
我们一帮人吭哧吭哧干活是为了什么？主题是什么？是为了解决用户的问题。用户给项目投资了成千上万，不是为了看到一堆过时的文档。
同样，在团队成员之间的交流要简明，不必为了交接而搞出许多文档。另外一个重要的因素是，如果团队在整个软件生命周期都使用团队协作服务器（TFS），那么很多活动、决定、文档都自然地记录在TFS上，不必额外去为了文档而再写一些东西。
大栓：这几点还讲得我心有戚戚焉。
阿超听说大牛以前参加过CMM的脱产培训，还给一些同事现炒现卖过，就叫大牛给大家讲讲CMMI。
大牛：我虽然参加过，但是都是“俱往矣”的事情了。再说现在后面又多出来一个字母，可能已经发生了质变。另外，一些时髦的产品，都是把这个“I”放在前面，像iPod、iTune，为什么CMM的I是在后面？
大伙：拜托，我们以前已经搞过CMM了，像背政治课文一样。不要让我们吃二遍苦，受二茬罪了吧。
阿超：那大牛能不能讲得深入浅出，图文并茂？
大牛：那我试试。
阿超：如果你讲得能让小飞这样的同志记下一些有意义的要点，那就是成功了。
大牛硬着头皮讲了一通CMMI，讲座之后，阿超看了看果冻和小飞的笔记。
2.6.1 果冻的笔记
CMMI是什么
CMMI是英文Capacity Maturity Model Integrated（能力成熟度集成模型）的简称。CMMI是CMM模型的最新版本——CMM已经被淘汰了（果冻批注：一叹！）。资料显示，运用CMMI模型管理的项目，不仅降低了项目的成本，而且提高了项目的质量与按期完成率。因此，美国在国防工程项目中全面地推广CMMI模型，规定在国防工程项目的招标中，达到CMMI一定等级的公司才有参加竞标的资格。该模型包括了连续模型和阶段模型这两种表示方法，一个组织根据自己的过程改进要求可以自由选择合适的表示方法来使用。
CMMI有两种不同的实施方法，其级别表示不同的内容。
（1）连续式，主要是衡量一个企业的项目能力。企业在接受评估时可以选择自己希望评估的项目来进行评估。因为是企业自己挑选项目，其评估通过的可能性就较大一点。但是，它反映的内容也比较窄一点。它仅仅表示企业在该项目或类似项目的实施能力达到了某一等级。
（2）阶段性。它主要是衡量一个企业的成熟度，亦即企业在项目实施上的综合实力。就是说处于某一阶段的企业，做大部分项目都要到达某一要求。一般地讲，一个企业要想在阶段性评估中得到三级，其企业内部的大部分项目要达到三级，小部分项目可以在二级，但绝不能够只有一级。阶段性实施方法的难度要大一些。
CMMI虽然源于美国，但在世界各地得到了广泛的推广与接受。CMMI在印度的应用甚至超过了美国。据SEI统计，世界软件企业评估达到5级的共有25个，印度占了其中的16个。（果冻批注：会考试！）这也是印度软件业得以迅速发展的一个原因。
CMMI目前已成为许多大型软件业者用于改善组织内部软件工程所采行的软件评估标准，CMMI也陆续应用于系统工程及软件采购方面，成为国际间通用的一种软件生产程序标准。有专家预测，在未来的几年内，CMMI将成为ISO9000之后的又一个国际标准。
实施CMMI的意义
很多人认为，实施CMMI的意义在于项目工程走向世界，可以在西方国家接到订单。实际上，更为重要的意义则是，CMMI的实施能够提高我国企业的管理水平，降低企业的成本。事实表明，企业实施CMMI技术的投入都会得到丰厚的回报。据SEI统计，用于软件项目上的CMMI的投资，其回报率在5:1到8:1之间。（果冻批注：何以算出来8:1？）由此可见，为什么这么多的企业纷纷实施CMMI项目管理技术。
CMMI一级，完成级。在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。
CMMI二级，管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并联合上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。
CMMI三级，明确（定义）级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化。这样，企业不仅能够在同类的项目上成功地实施CMMI，也能在不同类的项目上成功地实施。
CMMI四级，量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
CMMI五级，优化级。在优化级水平上，企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。
由上述的5个级别我们可以看出，每一个级别都是更高一级的基石。要上高层台阶必须首先踏上较低一层台阶。
MSF for CMMI能做什么
能帮助团队加速达到CMMI第三级“明确”阶段。但是MSF的过程模板只实现了第三级所要求的21个过程的17个，因此，它并不能保证团队自动获得第三级的评估，但是，加以一定程度的管理规章和文档管理，第三级应该不难实现。
2.6.2 小飞的笔记
小飞：我的感觉是CMMI 在所有的流程上都加了一个“提议”（Proposed）阶段，通过“审核”或者决定“开始调查”，处于“提议”阶段的工作项可以变为“激活”状态。如果调查的结果不是要开始着手工作，那么工作项可以退回到“提议”状态。
以缺陷类型（Bug）为例（如图2-4所示）：
图2-4
其他的工作项类型如问题（Issue）、需求（Requirement）、复审（Review）、 风险（Risk）任务（Task）都是类似的流程，这里就不一一列举了。
阿超：小飞，你选了什么歌曲来表达你的心情？
小飞：我选了歌曲——“不要挡在我的面前”，希望MSF CMMI不要挡着我写软件——
因为我已渐渐成熟
必须坦然接受生活的考验
因为我已渐渐成熟
我的软件你们都将看见！
……
荔荔：我体会最深的是——“如果你问一个技术人员，技术人员往往略带不屑地告诉你——把“工具 | 选项”打开，在某个“高级选项”下，改某个参数即可”这一段。移山公司的一些技术人员，特别是开发人员，甚至还带有一些轻蔑的眼神。参照这一新闻（北京禁止售货员用轻蔑审视的眼光扫视顾客）3，我大胆地提一个建议——“移山公司禁止开发人员用轻蔑审视的眼光扫视测试人员”！
大牛：我同意，而且要扩展到“禁止开发人员用轻蔑审视的眼光扫视非开发人员”！
斯坦：西方管理学大师戴明曾经说：“Eliminate numerical goals, numerical quotas and management by objectives. Substitute (that with) leadership”，意思就是说（在团队中）要消除以数字定义的目标、份额，以及以类目标为基础的管理原则。我们要用领导能力取而代之。
这和“数量化的管理”级别的要求有没有冲突？
二柱：软件工程讲的净是一些奇妙玄幻的概念，拗口的专业名词加上纷繁复杂的流程，其实做软件完全没那么难，主要靠的还是程序员自身的修养和完成工作的素质。
小飞：能否有一个打折扣的MSF？让一个团队一下子接受MSF的“8项基本原则”似乎并非易事，那么我们可以打折扣地贯彻MSF吗？如果可以，应该如何实施呢？
阿超：这些原则都是相互依赖、相互促进的。如果只实施了50%的原则，也许只有10%的作用。
九条：越是充分授权和信任，很多人在团队中越不自觉，结果写的代码都是敷衍了事（大学里面的团队很多都是这样），需要用什么激励机制来促进吗，还是说只能依靠团队成员的个人自觉？
阿超：那我们要问一下这个项目的商业价值是什么？如果这个项目没有任何商业价值，我想你也不好意思照搬商业软件的做法。但是也许这个项目对个人而言很有价值（提高个人技术的价值），那些有心锻炼自己的同学，能够自我驱动，值得你去“授权”和“信任”。
