当前课程知识点：软件工程 > 第4章 软件开发过程 > 4.4 微软公司开发过程 > 微软开发过程之一
同学们 大家好
非常高兴有机会
能跟大家分享一下
微软的这个软件开发流程
那说到软件开发呢
就是说
很重要一点就是
对于这个开发的人员来讲
那我要做什么样的事情
我要把这件事情做了之后
才能满足这个用户的需求
在软件工程的数据中
我们把它叫做一个Work item
就是说你要做的事情
就是stuff me need to do
事实上这个软件开发的这个流程
就是怎么管理
我怎么样管理这个
我要做的这么多事情
而且是多个人合作
来管理这个事情
所以在根据
微软开发
有的很多传说
以及我个人的一些经验呢
我就总结了有这么几个步骤
从Cowboy开始到最后有个
Team Foundation Server
中间事实上
我们经历了好些的工具
我们就一个个来讲
那第一个事实上是
我们说牛仔的风格
为什么呢
因为微软的创始人
就是一个大学的辍学生
就是比尔盖茨
他当时在哈佛读大学
然后他就看见了这样一个产品
这个叫做AlTAIL computer
然后他就觉得看了这个机器之后
他就觉得
个人电脑的春天到了
那我们一般看了这个机器
我觉得这好象就是
一个做电路实验的东西
好象没觉得跟个人电脑的春天
有什么关系
但是他是很有这个远见的
当然在他那个时代
这个也是一个非常
高大上的一个设备
所以他就说服了他的伙伴
叫Paul Allen
他说那我们一块成立一个公司
就做这个机器的Basic
就是Basic的这个解释
解释器
这样的话让别人来用这个
Basic这个语言来开发
所以有了这个想法之后
他俩就开始行动了
然后他就行动他就写code
他并没有说
有很严谨的这种商业计划
或者是需要找到很多风投
他就是给这个公司联系说
我可以给你写一个
Basic的interpreter
就是解释器
你们要不要
那这个公司当然觉得很好
他说如果有一个
高级语言的解释器
那就意味着
别人就可以很方便的
在我这个机器上
开发各种各样的软件
那很好
所以他俩就合作
比尔盖茨就写这个解释器
然后保罗艾伦就做另外一些工作
最后是保罗
带着他们写的东西
就是软件
就去了这个公司
当时这个公司
在美国一个比较偏僻的州
叫做西墨西哥州
这个城市叫做阿尔伯克基
事实上以后比尔盖茨回忆的时候
他说我连这个城市的名字
阿尔伯克基怎么拼
我都不知道
我就开始决定要创业了
然后在这个
他们去了这个公司
把这个代码输进这个电脑去之后
这个Basic
就可以做一些简单的运算
然后他就做了一些加减法
完成这个工作了
然后这个公司的员工觉得
这个非常了不起
然后事实上保罗艾伦呢
觉得这个的确很了不起
因为
他是头一回在这个真的机器上
运行这个软件
而且就没有任何问题
所以在这个阶段呢
事实上是
他们是靠
我们叫做个人的这种能力
我们叫做Indiuidual excellence
就靠个人能力来做这个软件
并不需要很多别人的帮助
因为当时所有的别的人
对这个计算机
对软件的理解
就远远差于
这些凤毛麟角的这些先行者
所以他们就是
在这个阶段就是说
你就凭自己能力去写代码
就可以了
所以这是一种
然后在微软当时的前面十几年
事实上工作还是很辛苦的
所以这里有个笑话
大家可以看看
就是你觉得这个回答怎么样
就是她是上午10点来上班
然后晚上10点才离开
然后员工就跟比尔盖茨讲说
我好象觉得还蛮辛苦的
那比尔盖茨有一个典型的回答
他就说这个
他说你这样早上10点来
晚上10点走实际上只工作了半天
因为一天有24个小时
所以这从侧面
反映了他的一个风格
就是说
还是工作的非常辛苦
然后就凭个人努力
来做这个软件
在这个阶段呢
事实上大家就用一些
手上拿的工具
比如说有黑板 白板
有notepad 记事本
有Excel来管理你的项目开发
这个时候呢
就是说
当然这些工具也有它的问题
就是说你很难管理
所以这个事情
实际上个礼拜我是这么决定的
后来我又把它改了
然后我得把这个修改的理由
加起来 加进去
但是这个时候呢
你很难有一个结构化的这个表达
说这个任务原来交给谁
后来他又做了一些什么改动
我们决定交给另外一个人
然后也许它的优先级
发生变化 等等
因为我们并不能记录
每一个事情的历史
所以这个就很困难
但是呢
在早期的软件开发
就是这样过来的
然后呢
就是在微软这个
有了一定的规模之后
那大家觉得
我们的确需要一个
叫做bug Tracking System
就是要跟踪这个bug
或者叫做
Issue Tracking System
就是你的跟踪
你在这个软件开发过程中
你到底发生了什么事情
有些人要做这个事情
有些人做那个事情
而且也许我们要在不同的时间
要互相的协作
所以我们写了一个工具
那这个工具就像
中国人有一个叫做
他们叫做雷达
就像是雷达驱蚊剂一样
因为在软件工程的这个术语里面
我们把问题叫做Bug
就是虫子 对吧
那你要把这个Bug杀死
你得用雷达驱蚊剂
所以这个产品的名字就叫做Raid
然后你在这个Raid里面
你就是
他就是一个
Client Server里的结构
那你在这个Client上
你就可以问
今天我有什么样的Bug
我这个团队有什么样的Bug
然后我最近关心的这个Bug
它有什么样的状态
所以这些就是
主要这个Bug Tracking的
这样一些功能
然后呢
我们用所有的
当然在软件开发中
有很多很多的这种不同的工作
但是在微软早期
他们都叫Bug
在这个情况下呢
就是说Raid这个词
就变成了一个动词
因为
我们一直在这个工具里面工作
比如说有人说
你给我开一个Bug
他就说Raid me a bug
就是说你在这个Raid
这个系统里面给我开一个bug
那这样掌握的双方大家都知道
所以在这个系统中呢
我们用它
Bug Tracking System
开发了Windons95到2000
还有Office97
这样一些大型的软件
实际上这个软件
因为每一个Bug都有很多的历史
就是说谁开的
然后交给了谁
谁又做了一些什么样的操作
然后这个Bug最后被修复了
代码会迁入
然后也许这个迁入之后
发现事实上这个Bug
并没有真正的修复
还会再回来
然后这些每一个步骤
都是一个数据库的一个记录
所以它事实上是有
百万级的这样一个记录
所以它相当于是一个
数据库的一个专用系统
就是来跟踪我们的Bugs Issues
我们在做这个软件的过程中呢
就是我们当时在做这个软件
叫Out look
然后我们的服务器叫Exchange
然后它有一个功能
就像我们现在的BBS一样
就是说你可以去发帖子
你可以去讨论
你可以看这个帖子的历史等等
我们当时觉得这个Raid
有一些小问题
不是特别好用
那当时我们就想说
那我们平时就在这个BBS
这样的环境中玩
那么我们能不能用BBS
来管理我们这个软件开发
然后就像我们清华的同学
平时可能很多人上水木
那你事实上也可以开一个子板块
你说我要写一个软件
那大家有什么样的问题
都在这个子板块里面讨论
然后你有Bug
你也可以在这发
我有状态更新
我也在这里面发这个状态
所以这个我们就设一下
我觉得很有意思
然后它有它的优点
就是它很容易去定义一些表单
就是你相当于填表
就像我们有些新人
你要加入一个板块说
你要填表
我从哪儿来
我有什么样的特点等等
然后你也很清楚地说
谁是版主
谁是有决定权的人
谁是我们叫做contributor
谁是贡献的人
谁是开发 谁是测试
谁是这个项目管理
在这方面呢
就是这个做的很好
但是它还有一些小问题
就是说它很难
当你这个事情多了之后
你很难运行一个
数据库查询语言说
那有某某发现的Bug
到底有多少
那现在这个是不支持的
那你得一个一个去看
那这个呢就不太先进
所以我们当时就在
大概1997年的时候
我们就用BBS这个系统
来管理了我们整个
叫Out look98这个产品的开发
觉得还可以
但是还有很多的问题
所以在我们的下一个阶段呢
我们就用Micosoft Project
就是真正的用来管理项目的
一个软件
来管理我们的软件开发
但是这个软件
事实上是特别适用于
和硬件相关的
比如说搬个家
做一个旅行
或者是大家协作
来做一些具体的事
我们在用它来管理软件的
开发的过程中呢
的确碰到了好多的问题
但它有它的优点
就是它很容易给大家一个
我们叫做high level
就是说
你在一个高的层面上你一看
你觉得这个很好
因为这个项目
就是分这么几个阶段
你看到一个很粗的线条
这些人做这个工作
那些人做那个工作
中间有些线
好象觉得很好
所以有一段时间呢
我们有很多的项目经理
就是在这上面
就创建了很多的工作
就是Work iterm
就是工作项
让它打出特别巨大的一个
这样一些打印纸
就是挂在墙上
你就可以看出来
我们整个项目要做完的话
就是到底个人在做什么
互相有什么样的依赖性
这个就是在展现这种依赖关系
就是高层次的依赖关系非常好
然后它跟时间非常相关
然后你很容易就可以看出来
它哪个礼拜
哪些事情应该做完
哪些事情
应该到一个什么样的状态
这个很好
但是随着我们这个项目的进展呢
我们发现
事实上大部分的软件工作呢
就是你事实上是做到一半
比如说我要写一个功能
这个功能做到一半之后呢
我就觉得第一个版本做完了
但是我们并没有真正地完成
所以当这个软件开发
到了一定阶段之后
你发现
事实上没有任何一个工作
是全部的做完了
所以它就产生了无穷的这种
都是一些未完成的工作
然后它还有很复杂的依赖关系
为什么我这个工作没有做完呢
因为我依赖于另外一个人的
那个工作
而那个人的工作没做完呢
是因为还有第三个工作
还没有做完
所以这个时候
我们要
再要看一个详细的软件
项目的进度的时候呢
就发现这个表
好象给我们产生了
更多的混乱信息
而不是一个非常好看的这种
像一千米
从一千米的高空
你看下面觉得很好
所以这是一个问题
另外呢就是说
你怎么分享给别人
就是说
那我怎么把一个工作
交给另外一个人
我做到了一半
我觉得
因为我们的项目安排有变化
我得交给一个人
或者我分享一些信息
在这里面都不是那么好做
然后
所以有这样一些问题之后呢
我们再隐隐地用它管理一个项目
觉得还是不够好
因为这个软件开发
它的确跟我们说的硬件
比如说大家合起来搬一个家
这个有相似的地方
但是也有很多不一样的地方
所以我们就换了一个产品
就是我曾经工作过的
这个Product Studio
这个呢
事实上是我们上面提到的
这个Raid一个升级版
那它就能够处理很多的这种信息
我们用它就管理了
好几个Outlook的版本
然后它也在这个微软公司里面
得到很多很多的应用
在这个Product Studio之后呢
就是我们把整个的这种软件开发
我们认为是
比较适合于微软的这种开发模式
这种方法论
就搬到了这个
Team
Foundation Server
就是Visual Studio的一个版本
所以我们就正式地说
那所有的事情
就叫做Work item
就是说那你要做的工作
但是Work item有很多类型
有一些是Bug
有一些是Scenario
有一些是Risk
有一些我们叫做
Quality of service
Requirement
为什么呢
比如说
我要写一个功能
假设我们做一个火车票预售软件
那这个功能我写好了
就是说我可以
用户可以查阅某一次车
还有多少张票
这是一个功能性的需求
但是还有很多非功能性的需求
是什么呢
就是说我希望当我查的时候
我希望你1秒钟就要反馈结果
那这个是我描述了你做这个功能
那我希望它有很多的特性
就是它要1秒钟能做完
这是一个
或者说我希望你在这个客户端
做一个软件
但是我不希望你占用太多的内存
这个软件是有很多功能
但是我还有别的一些约束条件
那这些就叫做
Quality of service Requirement
就是它怎么管理
事实上它跟这个功能
是不一样的
就是我们要把它分开来
这样的话我们
我们才便于对每一类的工作
做不同的管理
好
这个是我们TFS的
一个客户端的一个界面
这边是讲说
你要完成这个项目
那你有很多类别的工作
那个是说
这就是我的一个查询结果
那给我这个个人有多少任务
下面就是说
那我这个任务具体是什么
所以我们刚才讲的有很多东西
然后呢
具体的细节我们可以就忽略
这个TFS呢
事实上在从2005年发布以后
就维持了大概每两年有一个版本
现在就是2015已经刚刚出来
在开发的过程中呢
它的目标是说
我们能够针对5个人
到2000个人的一个团队
都能够开发
然后呢
我们即便开发软件有不同的
这种方法论
那不同的方法论我们都要支持
那我们还要跟不同的云代码管理
报告系统 编译系统
以及外围的一些工具给结合起来
所以它就发展成特别丰富的一个
软件开发的管理环境
我们现在绝大部分
这个微软的项目
都用这个TFS来管理
当然外面的公司
也有很多用这个TFS
或者用它的比较精简的版本
来做这个项目管理
你比如说举一个例子就是说
我们刚刚发布的
这个Windows10
它就包括这个
Windows10的这个PC版
然后Windows的XBox版本
Windows10 Mobile手机版本
以及还有很多的这种
我们叫做App
以及微软的商店
这些都是用同一个TFS来管理
一块来协作做这个
Windows10的这个人员呢
大概有3万人左右
然后所有的源代码
你把它
比如说你把它都拷下来
然后你数一下
拷到一个盘里面你数一下有多少
大概是100G这个量级
然后团队呢
在至少有六个不同的时区
就是真正比较大的团队
比如说北京 日本 印度 美国
还有英国和欧洲
就是在不同的时区工作
然后大家都用同一个工具来交流
来管理
所以这个TFS它的扩展性呢
以及它能够处理
这种超级复杂的项目
这个能力还是非常了不起的
-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 软件演化与维护
--讲课视频
-测验题--作业
-第一部分：基础知识
-第二部分：编程与测试（选做）
