当前课程知识点：软件工程 > 第4章 软件开发过程 > 4.4 微软公司开发过程 > 微软开发过程之二
微软在开发软件的时候
它的确不是说永远是
这个公司内部开发
它有很多的合作者
实际上有这样一个故事
就是微软在通常跟很多的
别的公司合作然后
那这个一个项目结束之后呢
这些它会写些心得体会
很多人就提到它说微软
当然这个工程师也不错
这个但是我们公司的
工程师也挺好的
然后这个设备也很好
但是我们公司
我们公司也不差
很多人就提到
说它微软有一个
这个项目管理的工具
的确是很好
我们公司没有
而且在我工作这么长时间内
就跟这个公司合作
它的这个项目管理工具
做的很好
所以这个
就是因为我们用
这个内部用一些
RAID、Product Studio
TFS
就给别人很深的印象
所以是在早期这个
别人就来问微软
就是你这么成功的吗
那你一定有秘诀了
所以这个那微软就说
那我就总结几条吧
所以它叫做一个比较松散的
一些我们认为软件
应该怎么开发
就是我们的一些方法论
在这个03年的时候
就是我们就把它总结出来
组成一个比较正式的说
这个叫
Microsoft Solution Framework
或者叫 Microsoft Solution Foundation
就说那我是
这是我的一揽子
这个计划
和这个一揽子方案
然后后来这个别人说
这个外面有很多的
这种敏捷开发
你支持吗
我们说当然支持了
就是我们有支持敏捷
各种这个工作方式
所以这个MSF的
这也是不断的发展
所以它有一些principle
在这里大概有九条
那这九条呢
事实上就是它认为一个公司
你不能说只买了我的工具
比如说你听说你这个工具不错
我就把你工具买过去了
也许我就可以开发出
很好的软件
未必是这样所以
它说那你如果你想成为
一个高效的这个软件开发者
一个团队
那你必须遵循这九条
这种规则
所以这件事
我们得讲的这九条规则
我们在这里就不细讲
那当然就是
在微软开发软件的过程中
也很难讲说每一个团队
在每一时刻都遵循这个规则
所以微软
还有一个很重要的文化
就是说它在每一个项目
结束之后
它会做一个叫做尸体解剖
叫Postmortem
因为我们说软件开发
它有生命周期的
就是你把这个软件
从无到有写写完
之后这个1.0就发布了
或者是2.0就发布了
相当于这个开发流程就结束了
那你可以回头来看说
在这个过程中
我们犯了什么错误
那么我们如果我重新做一遍
我有什么东西会做的不一样
那这个实际上它每一个版本
它会留下一些经验教训
然后它会交给
下一个版本的开发人员
和这个项目经理以及测试
就是我们收集下来的
这个经验教训
希望我们能够改进
这就是我们经过一些
很多总结总结出来的经验
就说我们的经验证明
如果你这个软件很成功
事实上是你看
你这个软件开发过程
它的确是遵循的这些原则
那如果你不成功
实际上你很容易就看出来
说有些人有些角色
在某一方面
的确是就违背了这些原则
就是软件就不成功
然后这个在微软
发展的过程中
也有很多就是软件工程
这个学术领域
以及不同公司
这个业界一下发展它们的
这个方法论
那当然我们跟这个业界
有很多交流
那其中一点就是说
这个当时有这个
CMM
叫做
Capability Maturity Model
就是说我们怎么样
衡量一个团队是成熟的
怎么衡量一个团队是高质量的
这个卡内基梅隆
这这个软件工程学院
就总结出这样原则
那它们就想来
游说这个微软公司说
你能不能让我们
来做些实验看看
这个微软公司的这个团队
到底到了哪一个等级
对吧那我们怎么样
或者看看我们这个模型
是不是有道理的
所以我们做了一些合作
当然微软它有一个文化
是说它说也许这些流程
不是那么重要
只要我能找到非常优秀的
这个员工就可以了
所以他们
就是微软中的很多老员工
对这些流程方法论
还是觉得比较保守
它是不会说
我听说外面
流传这样一个新的方法论
我们一定要
一定要采用的方法
因为我们只有这样
才能做好软件
他不这么认为
他说关键是
说你得给我找到优秀的人才
你找到优秀的人才
他会自己找到
适合这个产品
适合这个团队的这个方法论
不要说我要真的
要符合某一个官方发布的
一个模型
所以这是微软对
很多人对
这个方法论的一些看法
那还有一点
就是说在这个2000年前后
就是随着微软
这软件这样使用了很多
实际上我们发现了
很多的这种严重的这个bug
就是比如说
经常有一些这种黑客攻击
利用我们的一些漏洞
然后呢我们发现
我们为什么不能够
在我们软件开发的过程中
就把这些bug给消除掉
然后这个我们和硬件
做一个类比
所以我们发现硬件工程上
有很多标准 对吧
比如做电器
做这个手机电视机
你会发现
在现在这个年代
你很少发现有
这种功能性的缺失
所以它们就说为什么
因为这个质量控制
在这个工业界做得很好
有一个俗语叫做Six Sigma
就描述说
如果你有100万次机会犯错误
但是你犯错误的时候也许只有少于5个
大概有3个左右
那这个是质量的最高等级
叫Six Sigma
它从1到6都有是一个
相当于指数上升的
这样一个质量要求
那么它就衡量这个
那微软对吧
那比如说我写一个程序有
有那么300行代码
我第一遍写完之后
我拿出去
也许发现了10个Bug
后来也许我要改
我要改30行代码
那它就说 那好你有300行代码
对吧你有300个可以犯错误的机会
但是你在30个中
30个机会中你犯了错误
所以这个当然这个
称不上Six Sigma
这个是非常低的Sigma
所以那它说
你跟这个硬件比较看
比如说我们要做手机对吧
如果我把这个手机设计好
我在上产线上做手机
好像我不会说做300个手机
会有30个出问题
也许我会做这个3万个
说不定只有3个出问题
那你这个软件设计
能不能也到这样一个标准
就是说如果是以
这个代码的行出来比较
看你的工作量
你能不能减少这个犯错误的机会
这也是一个思潮
所以在这方面就是
我们在内部也做了很多研究
说软件开发到底是一个充满了创意
和不确定性的这样一个过程
就像艺术家画画一样
还是说一个是在流水线上
就组装机器这样一个过程
那如果是在流水线上组装机器
那当然我们可以用
这种工业的质量控制
Six Sigma来做
但是好像很少你听说这个
有一个软件是在
流水线上做出来的对吧
因为软件
有很多自己的一些特性
它需要在每一个新版本中
加入一些从来没有做过的东西
这个东西事实上
是有时候很难定义的
有点像艺术家一样
如果一个艺术家画了一幅名画
你不会讲说
这个你的名画画得很好
但是你在画的过程中
你比如说我们讲油画
你涂改好多对吧
你原来用的是白色后来用蓝色
这就是一个错误
后来你要用了棕色后来又改
后来又用刀把它刮掉
这是好多错误
你大概不会这么衡量
你会说这是一个艺术品质非常好
但是你生产的过程可能有很多的
不同的转折不同的方向
也许犯了错误
它的这个倒无所谓
所以我们认为这个软件开发
你大概不能够用完全的套用一些
硬件这个生产
这个模式来管理
所以这也是一个
我们学到一些经验教训
那还有一些就是说
还有一些别的一些思潮
比如最近经常讲的叫做MVP
MVP就是说
Minimum Viable Product
就是说我能不能就像创业一样
我做出一个最小的可用的产品
我就发布出去
然后我就收集用户的反馈
然后我就我做好
我就能够一步步的改进
这个我觉得很好
就是说在很多的
这种互联网相关的产业中
的确是有很多产品好像是这样做的
但是你真的要赢得市场
可能最后你要做一个
另外一个极端就是叫做MBP
就是Maximum Beautiful Product
就是你出来之后
是非常好非常吸引人的
就像我们看到这个iPhone一样
就说你即使拿最早期的iPhone比
那它也拿出来它并不是一个最小的
最简功能的那产品
它是一个的确是非常漂亮
设计的非常完备的一个产品
所以这两个我们叫做Methodology（方法论）
两个思潮我们也要辩证来看
就是你什么时候用这个MVP
什么时候用这个MBP
来指导我们的产品开发
那还有一点就是我想讲就是说
没有的软件可以说
我就很容易的做出来
实际上很多时候
在这个软件团队中开发
是非常辛苦的
就是我们当时做
这个Team Foundation Server
叫发布的时候
软件叫做燃尽图
Burn Down Chart
就是说你有这么多工作
你想把它都烧光
你想把它都变成零
但是你一味地达到某一个发布点
那你必须要求你的每一个模块
每一个组成部分
你的bug数量都得减少
所以这是一个
我们当时画下来的线
这个呢在有些情况下
就是我们叫做death march
就是说你工作很辛苦
每天你都去公司上班
但是这个bug就是很多
你解了这个bug你解了十个bug
会出来三个新的bug
然后呢你解了这三个bug
会出来一个再有一个bug
但是呢经过这些软件开发人员
这个无休止的工作
终于我们把这个东西给做出来了
微软在开发软件的过程中
还有很多这个文化
就是大家怎么决定一块
统一行动
其中一个很重要的特点就是说
我们有一个术语叫做ZBB
就是Zero Bug Build
就是我们在某一天
必须达到零个bug
就是你必须把所有已知的问题
进行修复
那这个日期如果一旦定好
那每个团队每个模块的负责的人
它就得执行
所以有些情况下
因为你的问题很多
有些时候就很难
所以你就得加班
做的比较辛苦一点
所以这个也是有个术语
叫做Death March
就像每天你出去打仗一样
但是你的伤亡很多
但是你不断的打
不断的打也说不定
你就能够你能做成功了
所以这个在微软相关的
这种Chart这种图表
用了很多
事实上最近呢
这个敏捷啊
或者别的一些这个方法论
也用到类似的图表
它们把它叫做
叫做Burn Down Chart
就是说叫做燃尽图
就相当于你原来有很多的工作
后来你把它们每一天每个礼拜
每个月就把它烧光了
所以这也是一个微软的一个特点
2008年之后呢
事实上这个微软的
这个开发流程也有很多的变化
其中一点就是说随着很多很多
这个互联网啊手机啊
这个的应用以及很多移动互联网
新兴的这种产品的出现
也许我们要采用一些
很多新的这种开发的模式
比如像敏捷的模式
这个持续改进的模式
这个我们叫SCRUM
以及还有这种我跟用户
有很紧密的结合
我不断的让用户来帮我
做这个测试
让用户来帮我做这个
提这个新的需求来改进
所以在这个最近的这个
Windows 10的这个发布中
实际上我们也用到了
类似的这样一些新的方法
就是说Windows它每天都会
产生一个我们叫构建
产生一个Build
我们内部叫做这个Canary
就是说这个金丝雀
为什么叫金丝雀呢
就是说因为每天都有很多人
迁入代码
修改这个整个产品
然后所以你这个构建不一定很好
你说不定就启动就启动不起来
或者是有一些这个驱动不支持
或者是有一些主要的功能
它就不工作
所以金丝雀什么意思
就是说如果金丝雀很早以前
这个在上一个世纪的时候
有很多煤矿
那煤矿下面经常有一些这个
有这个瓦斯爆炸的危险
传说呢这个金丝雀
对这个煤气就非常的敏感
所以你就下煤矿的时候
矿井的时候你带进去
那如果金丝雀突然间死掉的话
那你就觉得你得赶紧撤离
所以呢对于我们来说呢
这个金丝雀这个版本就是说
如果这个版本都不能行的话
那说明这些功能都做不了的话
那这个版本就不要了
但我们通过这个金丝雀版本之后
那我们说运行了几天
或者是通过了很多测试之后
我们把它发布给所有这个OSG
就是Windows这个团队
我就是其中一员
就大概有那么三万个人
让这些人来做测试来运行
所以我每天我们这个
我们电脑会收到一个新的更新
所谓还有一个新的版本
运行之后呢
当然我们会发现很多问题
我们会用这个它自带的工具
去报告这个bug
然后呢这个如果还可以的话
我们就可以发给这个
整个这个微软公司
大概有九万到十万个人
当然有些人不会说每一个版本都用
有些人会要比较积极的去使用
这些版本
然后呢这个测试也没有问题
之后我们就是说
那我们能不能给这个
我们叫Windows Insiders
就是外面的这个用户
但是对这个Windows比较好奇
比较积极的去响应
去安装版本去反馈意见给他们
大概有这个100万人左右的
这样一个团体
然后在这个整个Windows 10
发布的过程中
就是我们不断的有
有这样一个流程
就是这样的话呢
我们就可以很快的
得到用户真实的反馈
然后改进我们的工作
而不是说你把门关起来
你工作一年半
突然间有一个很新的版本
然后呢你又再把门关起来
又工作一年半又一个新版本
我们不是用这种方法
而是用这种积极的跟
不同层面的不同层次的
这个用户发布然后得到他们的反馈
然后快速地改正
-1.1 软件无处不在
--讲课视频
-1.2 软件的本质特性
--讲授视频
-1.3 软件工程的产生与发展
--讲授视频
-1.4 软件工程的基本概念
--讲授视频
-1.5 软件质量实现
--讲授视频
-1.6 业界人士谈软件工程
-测验题--作业
-讨论题
--讨论题
-作业题
--第一张 作业题
-2.1 编程过程与规范
--讲课视频
-2.2 良好的编程实践
--讲课视频
-2.3 Python集成开发环境
--讲课视频
-2.4 代码静态检查
--讲课视频
-2.5 代码性能分析
--讲课视频
-2.6 结对编程实践
--讲课视频
-2.7 刘贺谈软件工程
--讲课视频
--讨论
-测验题--作业
-作业题
--第二章 作业题
-3.1 单元测试概述
--讲课视频
-3.2 黑盒测试方法
--黑盒测试方法
-3.3 白盒测试方法
--基本概念
--代码覆盖标准
--基本路径测试
-3.4 单元测试工具
--单元测试工具
--html
-测验题--作业
-作业题
--第三章 作业题
--作业题附件
-4.1 软件过程
--讲课视频
-4.2 软件过程模型
--讲课视频
-4.3 敏捷开发过程
--讲课视频
-4.4 微软公司开发过程
--邹欣经理自我介绍
--微软开发过程之一
--微软开发过程之二
-测验题--作业
-5.1 团队组织与管理
--讲课视频
-5.2 项目沟通管理
--讲课视频
-5.3 软件项目计划
--讲课视频
-5.4 软件项目估算
--讲课视频
-测验题--作业
-讨论题
--讨论
-6.1 敏捷开发之Scrum
-- 敏捷开发之Scrum
--html
-6.2 用户故事与估算
--讲课视频
-6.3 团队协作工具Tower
-6.4 配置管理
--讲课视频
-6.5 配置管理工具Git
--讲课视频
-测验题--作业
-作业题--作业
-7.1 需求工程师
--讲课视频
-7.2 需求定义
--讲课视频
-7.3 需求的类型
--讲课视频
--讲课视频（2）
-7.4 需求工程过程
--讲课视频
-7.5 需求的主要来源
--讲课视频
-7.6 需求获取技术
--讲课视频
--讲课视频二
--讲课视频三
-7.7 撰写需求文档
--讲课视频
-测验题--作业
-讨论题
--讨论
-8.1 用例建模概念
--讲课视频
-8.2 用例建模过程
--讲课视频
-8.3 用例建模精讲
--讲课视频
-8.4 建模工具介绍
--讲课视频
-8.5 微信抢票应用案例
--讲课视频
-测验题--作业
-讨论题
--讨论
-9.1 面向对象分析
--讲课视频
-9.2 CRC卡片分拣法
--讲课视频-1
--讲课视频-2
-9.3 面向对象设计
--讲课视频-1
--讲课视频-2
-9.4 类图建模
--讲课视频-1
--讲课视频-2
-第9章 面向对象分析与设计--测验题
-讨论题
--讨论
-10.1 顺序图概念
--讲课视频
-10.2 顺序图建模
--讲课视频
-10.3 顺序图风格
--讲义视频
-10.4 状态建模
--讲课视频
-10.5 状态图
--讲课视频
-10.6 状态图精讲
--讲义视频
-测验题--作业
-讨论题
--讨论
-11.1 软件体系结构概念
--讲授视频
-11.2 软件设计原则
--讲授视频
-11.3 软件体系结构风格（一）
--讲授视频
-11.4 软件体系结构风格（二）
--讲授视频
-11.5 软件体系结构风格（三）
--讲授视频
-11.6 软件设计过程
--讲授视频
-11.7 Web系统架构设计
--讲授视频
-11.8 数据库选择策略
--讲授视频
-测验题--作业
-作业题
--html
--html
--html
-作业题--作业
-12.1 交互设计概述
--讲授视频
-12.2 交互设计目标
--讲授视频
-12.3 GUI设计原则
--讲课视频
-12.4 KLM效率模型
--Video
-12.5 Fitts定律
--讲授视频
-12.6 交互设计过程
--讲授视频
-测验题--作业
-13.1 软件测试概念
--讲课视频
-13.2 软件测试类型
--讲课视频
-13.3 软件功能测试
--讲课视频
-13.4 软件性能测试
--讲课视频
-测验题--作业
-14.1 软件部署与交付
--讲课视频
-14.2 软件演化与维护
--讲课视频
-测验题--作业
-第一部分：基础知识
-第二部分：编程与测试（选做）
