蔡锫
微软中国高级架构师
微创软件研发部经理
--------------------------------------------------
[名人观点]:
一．团队组织
1．常见问题
• 没有人愿意做测试
• 觉得养不起那么多测试人员
• 开发人员不遵循规范，随心所欲
• 项目经理事必躬亲，分身乏术
2．微软团队模型
各角色的职责
项目经理 : 编写功能规范，协调各角色关系
产品经理 : 客户联系的桥梁，进行需求分析
用户教育 : 让产品容易使用
发布经理 : 保证产品顺利发布
二．项目管理
1．常见问题
• 无法决定项目所需的资源（人力和预算）
• 无法决定项目的进度表
• 无法控制外包项目的进度和质量
2．微软项目管理-- 多里程碑式流程
• 每个里程碑完成部分功能
• 便于团队集中力量完成一个又一个功能
• 提供多个机会以适应需求的更改
如何完成一个里程碑??
步骤一： 达成共识
• 基本完成需求调研和分析 （产品经理负责）
• 确定大方向和长中短期目标
• 所有角色都参与讨论并真正认同结论
• 产生的文档：
o 常见用户情景：覆盖80%以上功能
o Vision：言简意赅地说明大方向，并有激励团队的作用
步骤二： 完成项目计划
o 编写详细的功能规范（项目经理负责）
o 在编程前想清楚所有功能流程，并引导用户明确需求
o 所有角色都参与审阅功能规范
o 制订开发计划和进度表（开发团队）
o 制订测试计划和进度表（测试团队）
o 分配资源（人力和预算）
o 形成项目综合计划和综合进度表
o 产生的文档：
功能规范，开发计划，测试计划（用例），项目综合计划
开发进度表，测试进度表，综合进度表
步骤三： 完成功能
• 开发人员分别完成自己的功能
• 使用版本控制工具
• 使程序员及时 check out和 check
• 及时进行模块间的整合，及时发
• 对每一项可测试的功能进行测试
• 使用测试用例工具，对功能进行
• 使用 BMS进行缺陷跟踪
• 记录所有程序问题
• 实现解决 Bug 的自动流程
• 按照综合进度表不断检查进度
• 使用的工具：
o 版本控制工具 VSS
o 缺陷跟踪工具 Raid/BM
o 测试用例管理工具
• 步骤四： 稳定与发布
• 测试组全面地测试功能，包括性能和稳定性
• 开发组全力配合解决 Bug
• 使用 BMS进行
o 监测质量情况
o 预测发布日期
• 专家会诊机制：
o 决定 Bug 的优先度
o 决定哪些 Bug 可以等到下个里程碑或版本中解决
o 决定由谁解决某个 Bug
• 使用的工具：
o 版本控制工具 VSS
o 缺陷跟踪工具 BMS
o 测试用例管理工具
三． 微软的开发管理经验：100%以 Bug 为核心
四．微软的一天
1． 让我们看看项目中每个角色的一天是如何度过的
• 开发
• 测试
• 项目经理
注：里程碑的每个阶段每个角色的工作有不同侧重点，我们以“完成功能”阶段为例
微软的一天从几点开始？
答案：半夜
为什么？
因为Daily Build 是所有工作的核心，而且是在半夜自动启动。
每日构造 Daily Build
• 你知道自己所用Windows的版本号吗？
• Daily Build 的意义：
o 模块得以及时整合
o 要求程序员及时把最新代码放入代码库
• 用脚本语言和编译/链接工具实现
• BVT Build Verification Test
o 对 Build 进行验证
• Blocking Bug
o 让 Build 无法完成的问题
o BVT 中发现的问题
2．程序员每天上班前最担心什么？
答案：因为自己昨天的代码 check-in，造成 Blocking Bug.
为什么？
因为每天的 Build 是所有人当天工作的基础：
程序员需要 Build 验证与其他模块的接口
测试需要 Build 发现新 Bug，并验证新 Build 中已解决的 Bug
有 Blocking Bug怎么办？
解决问题，并对今天的 Build打 Patch。
开发人员的正事
经历对 Build的提心吊胆和争分夺秒之后，第一件事做什么
答案：打开缺陷跟踪工具，查看指定给自己的 Bug，解决高优先度的 Bug。因为质量重于新功能。
接下来，开发人员会…
从版本控制工具中 Check out代码
修改代码（解决 Bug或实现新功能）
取得版本工具中最新变化，在本机 Build和单元测试
请开发组同事作 Code Review
Check in代码
3．测试人员第一件事做什么？
答案：打开 Raid/BMS，查看指定给自己的 Bug，验证已解决的 Bug。
接下来，测试人员会…
• 根据测试用例检验今天的 Build
• 在 Raid/BMS中记录新发现的 Bug
4．专家会诊
• 参加者：项目经理和开发组长、测试组长
• 通过 Raid/BMS 评估每个未解决的 Bug
o 决定 Bug 优先度
o 可否等到下个里程碑或版本解决？
o 谁来解决
• 预测项目实际进度和发布时间
缺陷走势图
5．回顾微软的一天
• 构造: daily build
• 开发: 解决blocking bugs, 实现功能, check-out, code review, check-in
• 测试: BVT, 使用测试用例进行测试
• 项目经理/组长: 专家会诊
6．微软的做法解决了那些常见问题？
质量问题
• 以前解决过的问题发布时又出现了，需要返工
• 无法预估发布时间 过早发布，带来质量和维护问题
• 测试发现的问题被忘却或不了了之
• 无法衡量测试员和开发员的工作
• 程序中的问题往往在发布后才发现
文档管理问题
• 文档与程序脱节，文档成为程序结果的描述
• 项目组把写文档看成负担
团队协调问题
• 开发人员各自为战，进行整合时发现模块衔接中的严重问题 需要作大的改动
• 没有保管好公司以往的版本和代码，无法满足用户对旧版本的更改要求
• 开发人员离职对项目带来很大冲击，没有人知道代码在哪，或无法读懂
五．提高软件管理的步骤
1. 使用 Raid/BMS，将流程管理自动化
2. 使用测试用例管理工具
3. 使用文档管理工具
4. 使用版本控制工具，进行 Daily Build
5. 建立代码标准
6. 建立 Code Review机制
7. 建立专家会诊机制
8. 建立团队沟通机制
9. 根据需要调整团队结构