免费试读章节

免费试读章节
(非印刷免费在线版)
如果你喜欢本书,请在
http://www.dearbook.com.cn/book/199657 或者
http://www.huachu.cn/itbook/itbookinfo.asp?lbbh=10061096
http://www.huachu.cn/itbook/itbookinfo.asp?lbbh=10061096
http://www.huachu.cn/itbook/itbookinfo.asp?lbbh=10061096 或者
http://product.dangdang.com/product.aspx?product_id=9352387
http://product.dangdang.com/product.aspx?product_id=9352387
http://product.dangdang.com/product.aspx?product_id=9352387
购买印刷版以支持作者和 InfoQ 中文站
向作者邹欣和博文视点出版公司致谢
本图书节选由 InfoQ 中文站免费发放,如果你从其他渠道获取此摘选 ,
请注册 InfoQ 中文站以支持作者和出版商
本摘选主页为
http://infoq.com/
http://infoq.com/cn/articles cn/articles cn/articles/zouxin-vsts-development-kit
zouxin-vsts-development-kit
《移山之道——VSTS VSTS 软件开发指南》配套网站为
http://yishan.cc/
移山之道——VSTS 软件开发指南

28
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
第2 章
白话 MSF 方法论

2.1 果冻的预习
果冻:超总,听说你要讲 MSF,我就先预习了一下,但是 MSF 的名词太多
了,我真是头大,能不能解释一下这两句:“MSF 的一个基础原理是
学习所有的经验。这一原理在 MSF 过程模型里的关键里程碑上得到
了充分的应用,在过程模型里愿意学习这一关键概念成功应用这一原
理所需要的。愿意学习这一概念通过后里程碑回顾的经过检验的做法
在项目里得到体现。在大型的和复杂的项目里,Microsoft 建议是利用
客观的外部服务商来确保有一个无过错的环境,并把学习最大化。”
阿超:你从哪里找到的绕口令?
果冻:MSDN 中文官方网站呀。
果然,阿超在网上找到了这一段话(如图 2-1 所示)。
他和果冻一起读了两遍,最后叹了一口气。
阿超:本来 MSF 挺简单明了的,这样一搞,反而很神秘晦涩。
2.1 果冻的预习 29
图 2-1
二柱:是不是有意搞得如此晦涩,以延缓我等的进步,阻碍我国软件大业的
移山之道——VSTS 软件开发指南

30
第 2 章 白话 MSF 方法论
发展?
移山之道——VSTS 软件开发指南
大栓:我以前听过 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 的大规模培训也在中国开始举办。当时有

一个“Architect2000”的全国巡回演讲 1 ,很多 IT 企业都参加了。
2006 年,MSF 4.0 随着 Visual Studio Team Foundation 2005 发布。它增
加了不少敏捷开发的内容,并且明确描述了团队协作的典型流程和在新的团
队协作软件包 VSTS 中的应用。
果冻:哪一年出的 2.0 呢?
阿超:我们需要关心么?
荔荔:果冻是怕到时考试时会考到这一题吧。
我们可以不用管 MSF 演化的细节,要记住所有模式都不是一成不变的,
关键是要掌握变化的原因。
2.2 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)
2.2.1 推动信息共享与沟通
这一原则,用大白话来说,就是所有信息都保留,并公开,讨论要包括
所有涉及的角色,决定要公开,并告知所有人。当然,对牵涉到技术机密、
1 作者也作为讲师介绍了微软的开发方法。
2.1 果冻的预习 31
移山之道——VSTS 软件开发指南

32
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
安全性等信息要采取必要的保护措施。
二柱:我们以前都是“老板让你知道,你就会知道,别多问。”看起来比较
好控制吧?
阿超:以前大家两三个哥们一起鼓捣软件,大家都知根知底,好像没有意识
到“沟通”的重要性,但是随着项目复杂度和团队规模的增加,没有
信息共享与沟通是万万不行的。
二柱:如果有一些事情,我个人也没拿准是不是要通知某一方面的人员,怎
么办?
阿超:在这种情况下,宁可过分沟通。
小飞:这是不是很烦?我得不断地告诉别人——我刚做了某事,我刚做了某
事……
阿超:对,最好是这些通知能随着事件的发生而自然地传递到关心这些事情
的人。例如,在 TFS 中,你可以设置提醒(Alert),让 TFS 自动通
知你。在 TFS 中,所有和项目有关的信息都会保存起来。
例如:所有工作项及其历史;所有源代码的修改记录。
TFS 用户经常问的一个问题是:在 TFS 中,我为什么不能删除工作
项?
答案很简单,MSF 的第一原则:所有的信息都保留,并公开。TFS
的记录就像银行帐户里的资金流动记录,是不可以删除的。
大牛:有人犯了一些比较愚蠢的错误(比如一个很低级的 bug),TFS 把它
们都记录下来了,从个人角度来看,有人会说“我知道我做错了,已
经改正,那最好把原来的记录删除了吧”,这样做,不是有利于打造
和谐的团队么?
阿超:和谐的“谐”,是一个“言”和一个“皆”字,说的就是大家都可以
发言,所有的事情都要记录。记录留下来,可以做事后分析,给后来
的同事,或者别的项目的同事学习。如果删除,那也就违反了第八条
原则“学习所有的经验”。如果历史是一笔糊涂账,某些事件被删除
了,或者不能提,哪来的和谐?!我们公司要建立“对事不对人”的
文化,好像有一句古话,把人的错误比做日食……
果冻:“君子之过也,如日月之食焉:过也,人皆见之;更也,人皆仰之。”
还有,“人谁无过?过而能改,善莫大焉。”
我们以前关于项目的好多事,都装在几个头头的肚子里,最开放的,也

不过是把一些问题列在 Excel 文件,或者是 MS Project 文件中,但是也没有
历史记录。看不到所有信息,那么项目进度以及项目中存在的各种问题就不
能及时让所有人知道,这样 MSF 中其他的原则也就不能实行了。没有开放
的信息,也就谈不上“授权”,或“建立清晰的责任和共同的职责”,以及
“保持敏捷,预测变化”。这也是为什么“推动信息共享与沟通”是第一个
基本原则。
MSF 团队模型和 MSF 过程模型也是建立在“信息共享与沟通”原则上 。
小飞:对于这一个原则,我要推荐庾澄庆的“请开窗”——
如果相爱能轻易推测出结果
谁还需要用真心来沟通
……
2.2.2 为共同的远景而工作
阿超:大家是怎么理解的?
杂曰:这就是所谓同心同德。兄弟同心,其利断金。我们当然是同心的啦,
大家都是哥们,都为了移山公司的兴旺才来的。
阿超:好,但是这里面提到一个“共同的远景”,这是什么玩意?
杂曰:就是我们移山公司以后要发!
阿超:发是肯定的,大家注意这个“共同的远景”是指产品的远景。我们做
一个产品,不管是应用软件、行业软件,还是通用软件,要明确我们
项目的目标是什么。
(1)这个目标必须是明确的,没有二义性;
(2)这个目标不是当前就能达到,必须是通过努力才能达到的;
(3)这个目标不是空泛的,它应该对项目成员每天的工作都有指导
作用。每天你来上班,如果发现你做的事情和项目的远景没有
帮助,你应该跟老板提出来。
荔荔:我们有些项目好像没法订出来这样的目标耶,或者老板也不清楚我们
到底要干什么。
阿超:那么,很显然这些项目的带头人没有及格,这些项目最后没有达到预
期的目标,也就不奇怪了,因为我们连预期的目标是什么都没有搞清
2.1 果冻的预习 33
移山之道——VSTS 软件开发指南

34
第 2 章 白话 MSF 方法论
楚。
大牛:能举例说明么?
移山之道——VSTS 软件开发指南
阿超:比如我们村里曾经有个体育新闻网站,当时它的远景号称是——
“移山体育网提供即时、准确的体育新闻,它提供论坛,体育用品购
物网络,使得体育爱好者能共享一个公平、健康、安全的交流环境。”
刚开始做得不错,我也经常光顾访问,但是后来好像新闻和论坛的质
量都下降了,购物网页没有下文,几次改版之后,占据头条的经常是
关于体育明星的小道消息,和他们传说中的女友传说中的三围尺寸,
还有河曲村中上层人士争喝某种饮料的消息等。我一直想问谁是主
编。
大牛:(举起手)我就是移山体育网的总编,刚开始,我每天做的事还是和
我们最初的远景相吻合的,人气也不错,后来我们觉得什么能吸引眼
球就上什么,慢慢搞成了四不像,名声也搞坏了。我们的内部远景已
经改为——
“移山体育网要吸引眼球和广告,直到找到买家为止。”
大栓:大牛,你们啥时候改的远景?我怎么不知道?
大牛:这个要问阿昌。
阿超:这样的远景也不见得错,但是不要忘了我们讲的是“共同的远景”,
即团队的领导人要让全体成员都同意项目的远景,并为之奋斗。如果
一部分人还为远景 1.0 而奋斗,但是另一半人却在为远景 2.0 努 力 ,
那是要出乱子的。
如果没有“共同的远景”,即使团队发布了产品,不同的成员对项目
是否成功,以后如何发展,也会有不同的看法,因为他们心里的远景
(参照物)是不一样的。
小飞:对了,后来河曲村中上层人士争喝的饮料咋样了?
大牛:别提了,他们以货抵广告费,放在办公室的几箱饮料后来都被我爹扛
回去喂猪了。
阿超:另外,在项目到了关键的时刻,我们再和大家统一思想,向往远景,
已经晚了。
大牛:我想起以前国家足球队在某次世界杯的表现,预选赛到一多半的时候,
足协的领导叫全体队员向国旗宣誓,我就觉得很搞笑,如果大家平时
都目标一致,搞这种宣誓只是形式,如果大家平时没有这样的目标,

突然间宣誓并不会让队员们突然更爱国,脚上功夫更好一些。
阿亨:另一个事例,说明远景也和实际工作有密切关系。大松博文在中国女
排搞“魔鬼训练”的时候,如果大家的远景不是世界冠军,干嘛费那
么大的劲?每天随便练练,早点洗洗睡得了。
阿超:对,如果我们移山公司的目标只是业余玩玩网站,大家干嘛费劲学什
么 MSF?
小飞:远景是由领导决定,还是自下而上形成的?
阿超:一般是由“有远见的人”提出,然后公开讨论,在讨论的过程中,可
以消除误解,凝聚共识。这是一个项目的关键,是项目第一阶段要达
到的主要目标。
二柱:这是不是俗话说的“统一思想”,或者另一个俗话说的“洗脑”?不
是说国外不兴洗脑的么?
阿超:可以这样看,但是我们下面要说另一个基本原则,需要你的大脑有原
创精神。
小飞:洗脑归洗脑,我要用这首歌曲表达洗脑后的心情——“嘻唰唰”:
闪闪红星里面的记载
变成此时对白
嘻唰唰嘻唰唰嘻唰唰嘻唰唰
……
2.2.3 充分授权和信任
这一点的关键是“授权”这个词,英语是 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)。
在一个高效的团队中,所有的成员都应该能得到充分的授权,他们有权
力在自己的职权范围内按照他们自己的承诺完成任务,同时,他们也充分信
任其他同事也能实现各自的承诺。类似地,团队的顾客(包括内部和外部的
顾客)也认为团队能兑现承诺,并进行相应的规划。
二柱:这样做好像很危险哪!
2.1 果冻的预习 35
移山之道——VSTS 软件开发指南

36
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
阿超:那应该怎么办?采用“命令”的方式?!
充分授权的管理方式是 MSF 的核心观念之一。MSF 团队模型就是建
立在以下两个原则上的:
(1)平等协作——成员之间,团队之间是平等协作的关系;
(2)充分授权给团队和成员。
这就是为什么 MSF 团队模型是网状,而不是层次结构。
这样做有什么好处?好处有两点:
(1)被授权的人会承担起自己对项目的责任,同时也期望同事们也
同样对项目负责;
(2)MSF 提倡自下而上的计划,每个人有充分的权力估计并决定自
己的任务需要多长时间,而不是上级交给的时间,这意味着让
真正做这件事的人按照自己的估计去完成任务。这样做的结果
是啥?是人人都会支持项目的计划和时间表,因为这个时间表
是每个人自下而上订出来的!
二柱:听上去很美,但是我作为一个组长,给我的组员充分授权,到头来发
现事情都没做完,咋办?我只好不断地问:你做到哪里了,还差多少?
阿超:这要靠工具的支持,在 VSTS 系统中,由于所有工作的进展都记录在
案,任何延迟都会被及时发现,这样组长(或其他层次的领导)就不
用把精力花在“询问”上,而在“帮助解决”上,在最关键的时候提
供指导和帮助。领导在项目中的角色是“支持成员完成任务”,而不
是“控制成员,迫使他们完成任务”。
充分授权在 MSF 团队模型的另一个含义是:信任,鼓励团队成员成长,
每人都可以在某一时段、某一领域当领导。比如二柱是程序安全性的专家,他
就可以带领其他成员对项目进行安全性检查。如果测试工程师斯坦刚刚学习了
如何做压力测试,他可以带领其他测试人员对产品进行全面的压力测试。
果冻:能不能推而广之,如果企业的各级领导秉持充分授权的信念,让员工
觉得被充分授权,而对工作产生热情,变得积极,进而能够充分发挥
自我潜力,企业整体即能够产生良性循环。
斯坦:在《致加西亚的信》中,我觉得如果没有总统对罗文的授权和信任,
罗文也不可能完成这一艰巨的任务。比如,如果总统信不过罗文,派
另一个“助手”和他一起走;或者,让罗文每天向领导汇报进展,然
后决定下一步行动。罗文肯定就不能把信送到。

大牛:斯坦,我觉得你的发言,不同于网上成千上万条的《致加西亚的信》
读后感,提供了新的视角,真不容易。
大牛:这一原则还对企业传统招人、用人的方式有冲击,我觉得这是 MSF
最难在中国公司实行的一部分,“授权”、“放权”的管理理念和很
多公司的企业文化不相符。
二柱:我早就说过 MSF 在中国不灵的啦。
果冻:我国古代也有充分授权和信任的例子,看这一段——
“郢人垩慢其鼻端,若蝇翼,使匠石斫之。匠石运斤成风,听
而斫之,尽垩,而鼻不伤。郢人立不失容。宋元君闻之,召匠
石曰:‘尝试为寡人为之。’匠石曰:‘臣则尝能斫之,虽然,
臣之质死久矣。’自夫子之死也,吾无以为质矣,吾无言之矣!”
大家一致反映要听白话文的解释,果冻解释完了以后,大家七嘴八舌地
议论,这里面有授权和信任么?
大牛:有啊,郢人授权匠石,他并没有管匠石的操作细节(用斧头,还是菜
刀、匕首或者手术刀);然后他“立不失容”,才能让整个操作成功 ,
这里面体现了信任。
阿超:要注意这种信任是两方面的,匠石也信任郢人会“立不失容”,不会
缩头缩脑,因此他才能“运斤成风,听而斫之”。在没有双方互信的
基础上,宋元君真的敢试?匠石真的敢砍?这个故事里的相互信任,
可以与“高山流水”中伯牙、子期的相互理解相媲美。
另外,充分授权之后,领导是不是显得有点没用了呢?
小飞:如果团队很厉害,领导就会升上去喽!
阿超:这个我也不知道,如果我能证明我的人马很厉害,甚至显得我都没有
什么必要,那我倒是可以做一些更无足轻重的事了……
小飞:比如说总裁什么的。
阿超:这倒提醒了我,“充分授权和信任”对于领导者提出了什么样的要求?
领导者能不能对手下人说:“这事就交给你了,你办事,我放心。” 就
完了?
大牛、阿亨、大栓你们几个是当领导的,都说说看?
阿亨:我扯得远一点,这教训是,不能等到自己快不行了的时候,才授权。
阿超:授权不等同于放任不管,领导者在授权之后,要为手下的成功提供各
2.1 果冻的预习 37
移山之道——VSTS 软件开发指南

38
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
种必要的帮助——技术上的培训,策略上的提醒,以及各方面的信息
和资源。
大栓:我们以前的项目中也放权了,并且鼓励大家勇于发表意见,结果大家
倒是很踊跃发表意见,每个人对其他任何人的做法都发表了意见,大
家最后吵得不亦乐乎,但是没有实际的进展。
阿超:这就牵涉到下一个原则。
小飞:等等,我选的歌曲是“信任”——
没有信任
爱情就失去了颜色
……
2.2.4 各司其职,对项目共同负责
负责任。
每个角色都有自己的职责(见表 2-1),如果出了问题,这个角色就要
表 2-1 MSF 团队模型和关键质量目标
关键质量目标 MSF 小组角色 出口条件
按约束条件交付产品 程序管理
按产品规格说明交付产品 开发
保证所有问题都得到处理 测试
产品部署和后续管理 发布管理
让产品更好用 用户体验
让客户满意 产品管理
我们的项目是在时间/资源的
条件内交付的么?
我们是否按照功能说明完成
了各项功能?
我们发现了所有的问题,而且
都有处理方案吗?
客户是否能快速方便地部署
产品和进行后续管理?
产品是否适应用户的使用习
惯?易学易用?
客户是否(在总体上)满意我
们的项目?
比如说,如果产品发布后,客户在部署和管理上出现了很多问题,那负
责“产品部署和后续管理”的角色“发布管理”人员就要站出来对此负责。
与此同时,各个角色合起来,对项目整体最终的成功负责,为什么?因
为每个角色在其职责范围内的失败都会导致整个项目的失败。而且各个角色
的工作都是互相渗透、互相依赖的。这种互相依赖的方式也鼓励团队成员在

自己本职之外为其他领域做贡献。例如,测试人员可以帮助“用户体验”角
色更好地设计用户界面,因为如果用户界面很差,再好的功能也不能发挥应
有的作用。
问:如果我要做一件事情,但是周围的人有不少不同意见,短时
间又不能完全说服他们,怎么办?
答:对此事负责任的角色要自己拿主意去做。
我今天在“顶球”网吧看到大牛他爹在下棋,围观者支招的不少,有的
说上马,有的说拱卒,有的说出车。大牛他爹一会儿招法就乱了,一会儿局
势就不灵了,围观者一哄而散,老崔后来也没法,只好认输了。
一个围棋国手在一次重要的对局后,听到旁观者对棋局的进程有很多不
同的看法,他也没有过多争辩,只是说:“无责任的旁观者和有重大责任的
当局者的看法自然是不一样的”。
无责任的旁观者在支招后,如果不灵,他可以面不改色地继续支招,甚
至可以给另一位对局者支招,不管最后谁输谁赢,旁观者随时都能安心地离
开,回家吃饭。有重大责任的当局者在走了损招或败招之后,他很可能就要
认输下台,丢掉比赛的奖金和头衔。
大家还记得父子和驴的故事吧:
“父子出门,子骑驴,人诽之;父骑驴,人亦诽之;父子同驴,
人人诽之;无奈,遂父子抬驴。”
这些都说明一个什么问题?如果我是责任人,最终还要我自己拿主意。
别人的意见都只是参考。我的责任是把事情做出来,而不是讨好所有人,让
他们知道我按照他们的意见做了。
在项目进展的过程中,对于每一项任务,每个人都要明确以下几点:
◆ Who:谁负责;
◆ What:做什么,具体的执行方案,什么叫做“做好了”;
◆ When:什么时候开始,什么时候结束;
◆ Why:为什么是这样安排(和项目的远景是否吻合?),在什么情
况下可以变更?
与“信息共享与沟通”原则相呼应,这样的安排能让所有人都明确自己
的职责,同时有“大局观”——知道别人在做什么,为什么,以及整个项目
2.1 果冻的预习 39
移山之道——VSTS 软件开发指南

40
第 2 章 白话 MSF 方法论
的目标。
移山之道——VSTS 软件开发指南
小飞:对这种连大牛他爹都可以从中受益的原则,我觉得应该选一首家喻户
晓的好歌“敢问路在何方”——
你挑着担,我牵着马,踏平坎坷,终成大道。
……
各司其职,圆满完成任务。
2.2.5 重视商业价值
我们都是搞技术的,但我们同时也是一个商业实体,我们的项目都应该
是出于商业目的,如果没有商业的需求,再酷的技术也没有用,商业项目需
要重视市场和用户,技术是处于第三位的。
阿毛:我们村的技术在这一带是有口皆碑的,王屋河水流经之处,人们都知
道王屋村的年轻人是打奶(.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 。
类似地,如果我们没有搞清楚我们的项目会解决什么问题,为谁解决了
问题,为什么它会解决问题,以及怎样才能拿到客户的报酬,那我们的项目
还不能算是真正开始。
问:那开源/共享软件是怎么一回事,如果开源了,商业价值如何
体现?
答:这个问题问得好,我估计如果开放讨论,以咱们的风格,三天
三夜也讲不完。但是回到具体问题,让我们设想一下,如果我们项
目成功了,有人以“开源”的名义,来要我们的源程序,我们答应
么?
二柱:凭什么!
阿超:对呀,凭什么?!在软件中凝聚了我们“无差别的人类劳动”——这
就是软件这一商品的价值,我们的口粮、公司的水电费都得用这一价
2 Joel Spolsky, http://www.joelonsoftware.com/articles/Micro-ISV.html。
2.1 果冻的预习 41
移山之道——VSTS 软件开发指南

42
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
值去交换得来,我们如果重视商业价值,就要有重视商业价值的做法 。
问:但是正如你所说的,我们都是搞技术的,那怎样才能保证我们
“重视商业价值”?
答:在 MSF 团队模型中,“用户体验”这个角色代表了用户的利
益,保证产品能真正易于使用;“产品管理”这个角色代表了客户
的利益,保证了我们的产品能为顾客提供商业价值。搞技术的,要
尊重这两个角色,因为他们代表的是我们的衣食父母。
小飞:我们的激情会变,但是大牛才是变得最快的,他隔三岔五跑来说,客
户有点新想法,我们要做一些小改动……
大牛:那怪不得我,是咱们的“衣食父母”提出来的。
阿超:这就扯到下一个原则。
2.2.6 保持敏捷,预期变化
软件工程,唯一不变的是变化。所以干脆别幻想客户的需求会在第一时
刻很明确,然后保持不会变。要注意,我们是预期变化,不是期望变化。
除开外部原因,团队内部也在变化,我们对技术的掌握每天都在提高,
原来认为不可能的事可能变得容易。我们对客观世界和系统的了解每天都在
深化,原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事
忽然要离开……这些都要求我们团队保持敏捷的身段。
大牛:最近业界有人总结,项目需求的生存期是 18 个月,就是说如果一个
项目的需求是 18 个月前确定的,而产品还没有做出来,那几乎就可
以不做了,因为需求肯定已经发生了很大变化。
大牛:大家有没有注意到微软的一些成功项目的各个版本之间也是间隔
18~24 个月。有些别的公司产品发布的间隔更短。
小飞:那为什么 SQL Server 要 5 年后才更新?
大牛清了清嗓子,问:在座的哪位能分析一下?
阿超:5 年发布一个新的版本,肯定是有不少问题。例如,我们可以想象一
下,在 2000 年,根据市场占有率的分析和预测,某个产品说我们一
定要支持 Win2000 和 Win9x 平台,因此产品组做了不少技术攻关,
保证代码同时可以在两个平台上运行,代码复杂度也因此上去了,测
试组也花大力气要“保证所有问题都得到处理”,两年过去了,2002

年 , 大 家 终 于 实 现 了 预 期 目 标 。 然 而 产 品 并 没 有 发 布 ,
WindowsXP/Windows2003 Server 正成为市场新宠,大家开始讨论是
否有必要保持 Win2000/9x 的一致性,因为它增加了开发和测试的难
度;到了 2004 年,这个产品还没有发布,当时的决定看起来像一个
笑话,管理层开始讨论是否砍掉 Win9x 平台的测试预算。2005 年底,
产品终于发布了,这时谁还关心 Win9x 呢?前几年的投资有回报么?
问:既然总会变,那么似乎没有必要在每一步骤都保持高质量?
答:你的潜台词是因为变了之后,以前做的事就没有意义了。但是
高质量在任何时候都是有益的,低质量的工作,会误导客户和团队 ,
也许会导致错误的变化。达到高质量是有代价的,关键是要给客户
提供及时、准确的信息,根据客户的反馈进行修改。质量是重要的 ,
但是如果你的功能不能满足客户不断变化的需求,注意是“不断变
化的需求”,那么再高的质量也没有用处。软件的质量在敏捷的开
发流程中处于什么样的地位?请看下一节。
小飞:等等,我觉得最符合这一原则的歌曲是“不是我不明白”——
不是我不明白
这世界变化快
……
(反复多次,直至声嘶力竭为止)
2.2.7 投资质量
对质量的重视,引起对质量的投资,引起对人、过程和工具的投资。
问:为什么叫投资?干脆叫“质量第一”,或者“全面质量管理”
不就完了么?
答:之所以叫“投资”,是很有道理的。听我慢慢道来。
(1)投资要讲效率。软件开发过程大部分时间花在了解/设计/变更/
再了解/再设计的过程中。我们要重视质量,但并不是要不惜
一切代价达到最高的质量标准(听众中有人倒吸了一口凉
气),因为提高人/过程/工具的质量是要花成本的!我们不
是为提高质量而提高质量。我们要讲投资的效率。比如,在
做快速原形的过程中,有些部分可以做得粗糙一点。
(2)投资要讲时机,比如说对于某项技术的培训,最好的做法是
2.1 果冻的预习 43
移山之道——VSTS 软件开发指南

44
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
在即将需要的时候进行培训。太超前或滞后都不灵。
(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 字]
小飞:我要选一首歌“爱的代价”,正如对爱的追求,对高质量的追求也是
有代价的。
大家一齐哼哼:
那些为爱所付出的代价,是永远都难忘的啊
……
2.2.8 学习所有的经验
古今中外,人们对经验的学习还是比较重视的,我们经常听到“忘记过
去的人注定会重复过去的错误”等类似的谚语。咱们中国的老祖宗也没少唠
叨,哪位能提供一些成语典故?
杂曰:数典忘祖,好了伤疤忘了痛,一朝被蛇咬,十年怕井绳……
停!“一朝被蛇咬,十年怕井绳”并不是“学习所有的经验”,而恰恰
是没有学习,不敢分析蛇和井绳的区别。
我们要重视经验,但是不能错误地沿用过去的经验——寓言里讲过这样
的故事:驴子驼着两袋盐过河,不小心跌在水中,起来后觉得货物轻了不少 ,
暗喜;后来它驮着两大包棉花过河,也故伎重演,但是效果却适得其反。
在学习过去的经验的同时,也要避免让过去的经验妨碍解决现在的问题。
问:那为什么在软件开发中我们往往没有吸取前人的经验
教训?
杂曰:“没时间”;
“每一个项目都有自己的特色,不宜生搬硬套”;
“项目的经验都在各人的脑子里”;
“项目结束后,大家都散伙了,没人组织总结,或
者写总结的人有偏心”;
2.1 果冻的预习 45
移山之道——VSTS 软件开发指南

46
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
“有时总结变成互相指责,搞得不欢而散”;
……
阿超:这一原则有两个含义——
(1)把经验总结出来;
(2)分享经验。
为什么要坚持总结和分享?是为了——
(1)让团队成员从别人的成果和失败的例子中学到东西;
(2)帮助新项目重复以往成功的做法;
(3)培育团队总结的习惯和“批评与自我批评”的文化。
MSF 在每一个里程碑结束时都要做一个“里程碑回顾”,这个回顾不
必等到整个项目结束才做。这样做的好处是,大家对最近的成败都记忆犹新 ,
能提供比较准确和全面的反馈;如果发现了错误,可以马上研究解决办法,
在下一个里程碑中通过实践来验证。另外,一些好的做法可以及时得到总结
和推广。
在项目结束时,MSF 推荐请团队以外的专家来主持召开“事后诸葛亮”
会,这样的专家会比较系统地总结团队的成功经验和失败教训,同时也客观
评价团队的一些特性和团队的开发过程管理,这样能促使团队成员以客观、
向前看、解决问题的心态来参加“事后诸葛亮”会,避免主观臆断或相互指
责。
二柱:但是这样的做法是否能符合国情?我们文明古国讲的是“以德报怨”,
有一些错误,交了学费,就算了,不要拉下脸皮嘛。最后大家聚餐一
下,灌醉了领导和同事,擦干嘴边的油渍,又继续前进了。
斯坦:似乎国外有说法是什么“打你的左脸,你要把右脸也凑上去”……
阿超:我们似乎也扯得太远了。我只知道文明古国的孔子好像是反对“以德
报怨”的吧。
果冻:孔子他老人家说过,“以德报怨,何以报德?”,他老人家主张“以
德报德,以直报怨”,我的理解是别人做了错事,特别是对你做了错
事,你要指出来,并且争取得到改正。由此看来 MSF 还是比较符合
儒家思想的。
斯坦:微软的同志们没想到用“儒家思想”这一招牌来给 VSTS 做广告,否
则早就卖火了。
小飞:我还没有想起什么儒家思想的歌曲,姑且用这一首歌吧——“改变所
有的错”:

改变所有的错
让我从头爱过
改变所有的错
再错也不回头
改变所有的错
就是我的承诺
……
二柱:哇!总共有 8 项基本原则之多,有没有搞错,我们上学的时候只要求
能背 4 项就可以了。
果冻:8 项的确太多,如果在工作中忘了几项,怎么办?
阿超:记住,我们的目标是把软件做出来,不是记住条文。当你记不住这些
东西的时候,想想怎么样才能把软件做出来,实现我们的远景,该干
嘛就干嘛。
2.3 MSF 团队模型
MSF 团队模型定义了小组同级成员的一些角色和职责,如图 2-2 所 示 。
MSF 团队模型认为,任何技术项目都必须达到特定的关键质量目标才
能够被认为是成功的项目。如果任何一个角色无法实现其目标,都将危及整
个项目。因此,每个角色都被认为是同等重要的,重要的决定都要共同做出 。
相关的目标和角色见表 2-1 所示。
2.1 果冻的预习 47
移山之道——VSTS 软件开发指南

48
第 2 章 白话 MSF 方法论
用户
体验
测试
图 2-2 团队模型
移山之道——VSTS 软件开发指南
产品
管理
交流
发布
管理
项目
管理
开发
说白了,一个项目要达到的目标很多,MSF 团队模型让不同的角色去
实现这些目标。在一个项目结束的时候,每个角色都问自己这样的问题——
我是否达到了我的质量目标?
最后,比如测试团队(角色:测试)要保证“我发现的所有问题都得到
解决”,那么测试团队就会做以下两件事:
(1)发现产品的问题;
(2)保证这些问题都得到处理。
要注意的是,保证这些问题都得到“处理”和得到“解决”是不一样的 ,
有些问题目前不能得到完美的解决,但是可以有让用户满意的处理方案,项
目团队不能回避这些问题。
问:我们发现了问题,但是我们目前的“处理”不能让用户满意,怎
么办?
答:测试团队就要和别的角色(如:产品管理/程序管理/开发)一
起研究用户需求,在可能的方案中选出一个,比如:
(1)按照目前的状态交付,向用户说明(如:在某个操作系统/
浏览器版本下,某个功能不能正常工作);
(2)推迟交付时间,让团队有足够的时间来解决问题;
(3)修改产品的约束条件(如要求客户的操作系统/浏览器必须是

某一个版本以上,或者增加一个附加条件:产品发布后半年
会出新的插件解决问题)。
在讨论处理方案的时候,每个角色从自己的质量目标出发,对自己的质
量目标负责。
问:那有冲突怎么办?
答:那就吵呗(众笑)。各个角色的利益是有一定的冲突的,MSF
没有掩饰这一点。MSF 团队模型的核心是,成功的技术
项目必须符合各种利益相关人(stake holder)完全不同且常常对立
的质量观点。
问:这么说在团队中有矛盾是正常的了?
答:对 !例如,用户代表觉得新增加一个功能很酷,因为新功能“让
产品更好用”,但是程序管理角色觉得会影响“按约束条件内交付
产品”的目标,测试会觉得“保证所有问题都得到处理”的目标受
到威胁,用大白话说,就是“我没有时间测试你的新功能,因此不
能加这个功能!”。这就要各方在整个项目的共同利益之下,协商
解决。
问:我原来认为测试人员说“我没有时间测试你的新功能,因此不
能加这个功能!”是态度问题,会被开发人员鄙视的。
答:这是对产品质量负责的态度,你要代表你角色的利益,如果你
有充分的授权和信任,你就要直言不讳。
除了项目的各个角色之外,MSF 团队模型还可以推广到包括操作、业
务和用户等外部因素。在对立中寻找共同利益,在冲突中达到平衡。MSF
团队模型推动了不同利益代表在追求共同利益过程中的融合。
果冻:“在对立中寻找共同利益,在冲突中达到平衡”,其实我们的孔夫子
对此早看得门儿清——
子曰:君子和而不同,小人同而不和。
二柱:儒家思想这么厉害,干脆让孔子和他的三千弟子开发软件得了。那么
后来也不会有 C 语言,用《论语》就可以写操作系统了。
果冻:《论语》本来就是操作系统呀!
2.1 果冻的预习 49
移山之道——VSTS 软件开发指南

50
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
2.4 MSF 过程模型
每个项目都要经过一个生命周期,图 2-3 是 MSF 过程模型生命周期的
一个简图。
MSF 过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的,
它把瀑布模型中基于里程碑的规划优势与螺旋模型中增量迭代的长处结合
了起来。
MSF 过程模型的基本元素是阶段和里程碑。所谓“阶段”,就是在这
一段时间里团队集中精力做某一类事情,每个阶段的结束都代表了项目的进
展和团队工作重心的变化。比如在“开发阶段”结束后,团队就不再允许设
计/实现新的功能,除非有充分理由的“变更请求”。
图2-3 过程模型
问:我觉得这样也太理想化了,一个 10 多人以上的团队,不可能
在某月某日同时完成某一阶段,然后第二天进入下一阶段。
答:对,各个阶段之间会有缓冲区,团队中各个功能组的进度是各
有区别的,不必强求一律。
团队用里程碑来检查工作是否结束和同步各个角色的进度,以此来确定
当前阶段的目标是否已经实现。
此外,里程碑标志着每个阶段的结束,团队在此时应该引导成员转移工
作的重心,并鼓励队员以新的视角来看待下一阶段的目标。在上一个阶段产

生的各种交付内容,将成为下一阶段的起始点。
2.5 MSF 敏捷开发模式
在 Visual Studio 2005 中,MSF 演化为以下两个分支:
◆ MSF 敏捷开发模式;
◆ MSF CMMI 开发模式。
我的感觉是,MSF 敏捷开发模式吸收了近几年来在软件业界流行的各
种“敏捷”开发模式的优点,认识到目前大部分软件是以网络应用相联系,
强调和用户更紧密地交流,快速叠代,避免不必要的过程。
在继承 MSF 3.0 基本原则的基础上,MSF 敏捷开发模式和以前有什么
不同?有以下几点。
2.5.1 更强调与用户的交流
项目的商业价值要由用户说了算,那些“我觉得用户会喜欢”的东西要
及早和用户交流。因为“我觉得”和“用户觉得”是两码事。
小飞:我说一句可能不太中听的话,我觉得有时用户好像很,嗯,很蠢。和
他们交流有时好像对牛弹琴。
二柱:那就派大牛去弹好了。
大牛:有这么几种情况——
(1)用户不懂他想要什么。有些用户只有一个模糊的需求,他们说:
我们企业要上 ERP!你给我整出来。这种情况下,我们得和用
户一起做需求分析;
(2)用户想要的和商业价值无关。比如有些用户说,我想让每个按
钮都是半透明的,还要有三维效果,就像一些网络聊天软件一
样酷!这些要求和他的企业管理项目的价值没有直接联系。也
许这个用户代表是一头牛,而不是用户代表,我们要找管牛的
人;
(3)用户想要的我们还不懂。这种情况下,我们是牛,用户是在对
2.1 果冻的预习 51
移山之道——VSTS 软件开发指南

52
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
我们弹琴;
(4)大家心里想的不是牛,也不想弄清牛想什么,只要有钱就行。
例如:
客户:你能不能做 3G?
我们:上 3G 干啥?我们还搞不懂 3G,好像没有人真正需要 3G。
客户:对,我也不懂 3G,但是我手里有三百万预算要花掉。
我们:啊呀,你干吗不早说,那咱们就搞一个三百万的 3G 项目好了 !
2.5.2 质量——防患于未然
防止缺陷的发生成为团队质量控制的首要任务,所有的角色都要对防止
缺陷的发生和确保缺陷被修复负责。
有一些团队把开发和测试有意无意地对立起来,好像二者是矛盾的。一
个典型的例子是,有时开发人员不想给测试人员足够的信息,好像不想“帮”
测试人员找到缺陷;与此同时,测试人员一旦找到缺陷,会有一些得意的表
示——“看,你写的代码那么臭,我又发现了 N 个 bug”。这种对立情绪,
也许在短期内能刺激成员的工作热情,而从长远来看是有害的。很少有人会
希望在这种充满对立情绪的环境中工作。
微软公司内部做过统计,在一个中大规模的团队中,一个“缺陷”从发
生到被改正,中间经过了近 20 道工序,平均总的时间开销是 12 小时。最好
的事情,是可能的缺陷在设计阶段之前就讨论过,并且在代码中已经避免了 ,
因此在“缺陷跟踪系统”中,并没有出现很多缺陷记录在案,但是软件的质
量仍然很高。
2.5.3 重视在实战条件下的质量
这一点要求我们保持随时可以发布的高质量。如果用户说:时间到了,
网站要上马。我们应该很快地交给用户一个可用的版本,也许有不少功能没
有加入,但是版本中包括的功能都可用。
这就要求我们必须保证项目的质量是“随时可用”。为了达到这一点,
我们要重视产品的安装和发布——产品要尽早能够达到随时安装、发布的标
准。我们以前的项目中,安装和发布都是最后阶段才做,这就导致几个问题 :

(1)开发过程中,测试团队很难安装产品,阻碍了测试团队的进展。
很多情况下,测试人员不得不从多个源头拷贝不同的文件到测试
环境中,才能开始测试。浪费了很多时间;
(2)关于安装的缺陷得不到重视——用户拿到一个 Beta 版,意见最大
的就是:安装不上!或者好不容易装好了,却卸载不了,不得不
重新安装系统。
二柱:好像这个 VSTS 早期的版本就有这个问题,真是具有讽刺意义呀。
鼓励团队在实战条件下使用产品,就是“吃自己的狗食(Dogfood)”,
或者叫“自作自受”。
大栓:所谓“dogfood”,也不难理解,比如我们小学食堂的伙食都很差,
和“狗食”媲美。(众人大笑),但是食堂领导无动于衷,因为食堂
的领导和职工都是吃自己的小灶。如果食堂的领导实行“dogfood”,
身体力行,和食堂员工一起吃给学生做的大锅饭、大锅菜。我想这个
问题应该很快就能得到解决。
小飞:我们要做的项目,怎么才能 dogfood?
大栓:那我们就自己注册成为用户和商户,然后在系统上做一些交易吧。
阿超:这就要求我们的安装程序能够随时安装最新的版本,同时对于我们服
务器端的数据迁移提出了很实际的要求。
果冻:听说微软成功的秘密之一就是“狗食”,看来我们也要掌握这一秘密
武器了,不过,狗食有没有副作用?(众笑)
阿超:好像是有的。狗食过分的话,会让软件开发人员不自觉地把自己当成
了典型用户,造成的一个结果是开发出来的软件只适合技术人员使
用,一般的用户往往不得其门而入。比如,好多功能都深藏不露,如
果你问一个技术人员,技术人员往往略带不屑地告诉你,把“工具 |
选项”打开,在某个“高级选项”下,改某个参数即可。但是我们的
客户谁有这种技术水平?谁有胆在“工具 | 选项 | 高级”里乱按?
实战条件下质量的另一方面是,进行经常性的迭代(小的里程碑),
使用户能够及时看到产品,并提供反馈。
小飞:这不就是快速原型法?
阿超:这不完全等同于快速原型法,用户看到的功能应该是能够马上使用
的,而不只是一个原型。
2.1 果冻的预习 53
移山之道——VSTS 软件开发指南

54
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
2.5.4 精简过程,直奔主题
我们一帮人吭哧吭哧干活是为了什么?主题是什么?是为了解决用户
的问题。用户给项目投资了成千上万,不是为了看到一堆过时的文档。
同样,在团队成员之间的交流要简明,不必为了交接而搞出许多文档。
另外一个重要的因素是,如果团队在整个软件生命周期都使用团队协作服务
器(TFS),那么很多活动、决定、文档都自然地记录在 TFS 上,不必额外
去为了文档而再写一些东西。
大栓:这几点还讲得我心有戚戚焉。
2.6 MSF CMMI 开发模式
阿超听说大牛以前参加过 CMM 的脱产培训,还给一些同事现炒现卖过 。
就叫大牛给大家讲讲 CMMI。
大牛:我虽然参加过,但是都是俱往矣的事情了。再说现在后面又多出来一
个字母,可能已经发生了质变。
大伙:拜托,我们以前已经搞过 CMM 了,像背政治课一样。不要让我们吃
二遍苦,受二茬罪了吧。
阿超:那大牛能不能讲得深入浅出,图文并茂?
大牛:那我试试。
阿超:如果你讲得能让小飞这样的同志记下一些有意义的要点,那就是成功
了。
大牛的讲座搞过之后,阿超看了看果冻和小飞的笔记。
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?)由此可见,为什么
2.1 果冻的预习 55
移山之道——VSTS 软件开发指南

56
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
这么多的企业纷纷实施 CMMI 项目管理技术。
CMMI 一级,完成级。在完成级水平上,企业对项目的目标与要做的努
力很清晰,项目的目标得以实现。但是由于任务的完成带有很大的偶然性,
企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项
目实施对实施人员有很大的依赖性。
CMMI 二级,管理级。在管理级水平上,企业在项目实施上能够遵守既
定的计划与流程,有资源准备,权责到人,对相关的项目实施人员有相应的
培训,对整个流程有监测与控制,并联合上级单位对项目与流程进行审查。
企业在二级水平上体现了对项目的一系列管理程序。这一系列的管理手段排
除了企业在一级时完成任务的随机性,保证了企业的所有项目实施都会得到
成功。
CMMI 三级,明确(定义)级。在定义级水平上,企业不仅能够对项目
的实施有一整套的管理措施,并保障项目的完成;而且,企业能够根据自身
的特殊情况以及自己的标准流程,将这套管理体系与流程予以制度化。这样 ,
企业不仅能够在同类的项目上成功地实施 CMMI,在不同类的项目上一样能
够成功地实施。
CMMI 四级,量化管理级。在量化管理级水平上,企业的项目管理不仅
形成了一种制度,而且要实现数字化的管理。通过量化技术来实现流程的稳
定性,实现管理的精度,降低项目实施在质量上的波动。
CMMI 五级,优化级。在优化级水平上,企业的项目管理达到了最高的
境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理,而且
能够充分利用信息资料,对企业在项目实施的过程中可能出现的次品予以预
防。能够主动地改善流程,运用新技术,实现流程的优化。
由上述的 5 个级别我们可以看出,每一个级别都是更高一级的基石。要
上高层台阶必须首先踏上较低一层台阶。
MSF for CMMI 能做什么
能帮助团队加速达到 CMMI 第三级“明确”阶段。但是 MSF 的过程模
板只实现了第三级所要求的 21 个过程的 17 个,因此,它并不能保证团队自
动获得第三级的评估,但是,加以一定程度的管理规章和文档管理,第三级
应该不难实现。

2.6.2 小飞的笔记
小飞:我的感觉是 CMMI 在所有的流程上都加了一个“提议”(Proposed)
阶段,通过“审核”或者决定“开始调查”,处于“提议”阶段的工
作项可以变为“激活”状态。如果调查的结果不是要开始着手工作,
那么工作项可以退回到“提议”状态。
以缺陷类型(Bug)为例(如图 2-4 所示):
2.1 果冻的预习 57
图2-4
其他的工作项类型如问题(Issue)、需 求( Requirement)、复 审( Review)、
风险(Risk)任务(Task)都是类似的流程,这里就不一一列举了。
阿超:小飞,你选了什么歌曲来表达你的心情?
小飞:我选了歌曲——“不要挡在我的面前”,希望 MSF CMMI 不要挡着
我写软件——
因为我已渐渐成熟
必须坦然接受生活的考验
因为我已渐渐成熟
我的软件你们都将看见!
……
移山之道——VSTS 软件开发指南

58
第 2 章 白话 MSF 方法论
移山之道——VSTS 软件开发指南
2.7 本章讨论
荔荔:我体会最深的是——“如果你问一个技术人员,技术人员往往略带不
屑地告诉你——把“工具 | 选项”打开,在某个“高级选项”下,改
某个参数即可。”这一段。移山公司的一些技术人员,特别是开发人
员,甚至还带有一些轻蔑的眼神。参照这一新闻(北京禁止售货员用
轻蔑审视眼光扫视顾客) 3 ,我大胆地提一个建议——“移山公司禁止
开发人员用轻蔑审视眼光扫视测试人员”!
大牛:我同意,而且要扩展到“禁止开发人员用轻蔑审视眼光扫视非开发人
员”!
斯坦:西方管理学大师戴明曾经说:“Eliminate numerical goals, numerical
quotas and management by objectives. Substitute (that with) leadership”,
意思就是说(在团队中)要消除以数字定义的目标、份额,以及以类
目标为基础的管理原则。我们要用领导能力取而代之。
这和“数量化的管理”级别的要求有没有冲突?
二柱:软件工程讲的净是一些奇妙玄幻的概念,拗口的专业名词加上纷繁复
杂的流程,其实做软件完全没那么难,主要靠的还是程序员自身的修
养和完成工作的素质。
小飞:能否有一个打折扣的 MSF?让一个团队一下子接受 MSF 的“8 项基
本原则”似乎并非易事,那么我们可以打折扣地贯彻 MSF 吗?如果
可以,应该如何实施呢?
阿超:这些原则都是相互依赖、相互促进的。如果只实施了 50%的原则,也
许只有 10%的作用。
九条:越是充分授权和信任,很多人在团队中越不自觉,结果写的代码都是
敷衍了事(大学里面的团队很多都是这样),需要用什么激励机制来
促进吗,还是说只能依靠团队成员的个人自觉?
阿超:那我们要问一下这个项目的商业价值是什么?
3 http://news.sina.com.cn/c/2006-11-30/202110650498s.shtml。