微软高级开发者管理峰会演讲摘要：产品质量的基石
微软高级开发者管理峰会演讲摘要：产品质量的基石
——微软Bug管理
整理: 暗涧幽火 更新时间: 2008-02-29 16:10:45
一．团队组织
1．常见问题
l 没有人愿意做测试
l 觉得养不起那么多测试人员
l 开发人员不遵循规范，随心所欲
l 测试组文档过少，没有人愿意写测试文档
l 项目经理不太注重测试工作
2．微软团队模型
各角色的职责
|
角色 |
职责 |
|
项目经理 |
编写功能规范，协调各角色关系 |
|
产品经理 |
客户联系的桥梁，进行需求分析 |
|
用户教育 |
让产品容易使用 |
|
发布经理 |
保证产品顺利发布 |
二．项目管理
1．常见问题
l 无法决定项目所需的资源（人力和预算）
l 无法决定项目的进度表
l 无法控制外包项目的进度和质量
2．微软项目管理—多里程碑式流程
l 每个里程碑完成部分功能
l 便于团队集中力量完成一个又一个功能
l 提供多个机会以适应需求的更改
如何完成一个里程碑
l 步骤一： 达成共识
l 基本完成需求调研和分析 （产品经理负责）
l 确定大方向和长中短期目标
l 所有角色都参与讨论并真正认同结论
l 产生的文档：
o 常见用户情景：覆盖80%以上功能
o Vision：言简意赅地说明大方向，并有激励团队的作用
l 步骤二： 完成项目计划
o 编写详细的功能规范（项目经理负责）
o 在编程前想清楚所有功能流程，并引导用户明确需求
o 所有角色都参与审阅功能规范
o 制订开发计划和进度表（开发团队）
o 制订测试计划和进度表（测试团队）
o 分配资源（人力和预算）
o 形成项目综合计划和综合进度表
o 产生的文档：
功能规范，开发计划，测试计划（用例），项目综合计划
开发进度表，测试进度表，综合进度表
l 步骤三： 完成功能
l 开发人员分别完成自己的功能
l 使用版本控制工具
l 使程序员及时check out和check in，避免积累大量代码
l 及时进行模块间的整合，及时发现问题（daily build）
l 对每一项可测试的功能进行测试，无需等待
l 使用测试用例工具，对功能进行完整和重复的检验
l 使用BMS进行缺陷跟踪
l 记录所有程序问题
l 实现解决Bug的自动流程
l 按照综合进度表不断检查进度
l 使用的工具：
o 版本控制工具VSS
o 缺陷跟踪工具Raid/BMS
o 测试用例管理工具
l 步骤四： 稳定与发布
l 测试组全面地测试功能，包括性能和稳定性
l 开发组全力配合解决Bug
l 使用BMS进行
o 监测质量情况
o 预测发布日期
l 专家会诊机制：
o 决定Bug的优先度
o 决定哪些Bug可以等到下个里程碑或版本中解决
o 决定由谁解决某个Bug
l 使用的工具：
o 版本控制工具VSS
o 缺陷跟踪工具BMS
o 测试用例管理工具
三． 微软的开发管理经验：100%以Bug为核心
1．Bug及常见类型
l 功能未实现，和规格说明书不一致
l 不能工作：死机，没反应
l 不兼容
l 边界条件
l 界面、消息、提示不够准确，不友好
l 把尚未完成的工作也作为一个Bug
l 文档与帮助信息中的缺陷也是Bug
2．RAID/BMS的基本功能
l 完整的Bug数据库
l 整个产品组的中央记录和控制
l 强大的查询功能，有效地跟踪项目的状态
l 所有的记录无法删除，对于每个记录只能一直添加内容
l 丰富的报表功能，为产品发布提供判断标准
3．Bug记录中的有效信息
|
·
导入论坛
引用链接
收藏
分享给好友
推荐到圈子
管理
举报
TAG:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
