微软的Bug 管理指导原则
2006-12-11 19:54
169 查看
管理层要求所有的Bug 都要通过Raid(Product Studio)来跟踪处理。这个看起来很简单的Bug 管理工具是每个员工和其他同事有效协作的重要保证
每个产品都细分模块(Area,SubArea),每个模块都有明确的需求定义者(PM)、开发工程师(Dev)和测试工程师(Tester)这三个角色。一个问题出现了,一定会落实到某个人的头上去跟踪处理,绝不能出现无主的Bug
PM 负责书写的Spec 是这个功能特征(Feature)的合同,以此Spec 来指导开发和测试。当Dev 和Tester 就某个Bug 发生争执的时候,PM 负责给出一个明确的说明
测试不仅仅是Tester 的事情,尽管那是他们的专职工作。研发团队中的所有人每发现产品的问题时候,都有义务把这个问题告知负责这个模块的测试人员去记录跟踪这个Bug,或者干脆自己新建一个Bug 来跟踪
你可以创建一个Bug 指派给自己,以跟踪某件事的处理。比如开发人员把源代码中的某处问题用Bug 记录下来,以后抽出时间来进行处理
团队中的所有人都可以创建、指派和更改Bug 的状态
当你创建一个Bug 的时候,描述一定要足够详细,让下面处理Bug 的人和其他关心这个Bug 的同事能够通过Bug 描述准确的重现这个问题,而不是猜测某些步骤或者跑过来当面问你
通常一个Bug 的处理过程是这样的:
1. Tester 发现一个问题,到Raid 中创建一个Bug,描述这个Bug 的详细信息,比如重现步骤(Repro Step)、错误结果(Result)、期望的改动(Expect)、运行版本等;然后把这个Bug 指派给负责该模块的Dev Lead
2. Dev Lead 判断后把这个Bug 指派给某个特定的Dev
3. Dev 处理掉这个Bug 并返还给原Tester,或者请求PM 给出一个澄清说明
管理层通过Raid 来跟踪整体进度,以及每个员工、团队在其中的贡献
有专人定期给相关同事发出Bug 的状态报告
每个人都可以方便的自助查询Bug 的分布处理情况。Bug 管理系统对所有的团队成员都是毫无保留的敞开大门(除了你不能删除Bug,另外所有的操作都被忠实的纪录下来)
随着时间的推移,管理层要逐步给出明确的Bug 解决指导方针:哪些Bug 是可以不理睬的(Won’t Fix),哪些是可以推迟到下个版本处理(Postponed)。比如在最终Build到来前的几周,也许非常严重的Bug,像数据丢失、程序崩溃之类的也都要推迟到下个版本再解决了。
当一线员工出现争执、无法达成一致意见的时候(尽管这种情况不多见),管理层要快速给出处理意见。
每个产品都细分模块(Area,SubArea),每个模块都有明确的需求定义者(PM)、开发工程师(Dev)和测试工程师(Tester)这三个角色。一个问题出现了,一定会落实到某个人的头上去跟踪处理,绝不能出现无主的Bug
PM 负责书写的Spec 是这个功能特征(Feature)的合同,以此Spec 来指导开发和测试。当Dev 和Tester 就某个Bug 发生争执的时候,PM 负责给出一个明确的说明
测试不仅仅是Tester 的事情,尽管那是他们的专职工作。研发团队中的所有人每发现产品的问题时候,都有义务把这个问题告知负责这个模块的测试人员去记录跟踪这个Bug,或者干脆自己新建一个Bug 来跟踪
你可以创建一个Bug 指派给自己,以跟踪某件事的处理。比如开发人员把源代码中的某处问题用Bug 记录下来,以后抽出时间来进行处理
团队中的所有人都可以创建、指派和更改Bug 的状态
当你创建一个Bug 的时候,描述一定要足够详细,让下面处理Bug 的人和其他关心这个Bug 的同事能够通过Bug 描述准确的重现这个问题,而不是猜测某些步骤或者跑过来当面问你
通常一个Bug 的处理过程是这样的:
1. Tester 发现一个问题,到Raid 中创建一个Bug,描述这个Bug 的详细信息,比如重现步骤(Repro Step)、错误结果(Result)、期望的改动(Expect)、运行版本等;然后把这个Bug 指派给负责该模块的Dev Lead
2. Dev Lead 判断后把这个Bug 指派给某个特定的Dev
3. Dev 处理掉这个Bug 并返还给原Tester,或者请求PM 给出一个澄清说明
管理层通过Raid 来跟踪整体进度,以及每个员工、团队在其中的贡献
有专人定期给相关同事发出Bug 的状态报告
每个人都可以方便的自助查询Bug 的分布处理情况。Bug 管理系统对所有的团队成员都是毫无保留的敞开大门(除了你不能删除Bug,另外所有的操作都被忠实的纪录下来)
随着时间的推移,管理层要逐步给出明确的Bug 解决指导方针:哪些Bug 是可以不理睬的(Won’t Fix),哪些是可以推迟到下个版本处理(Postponed)。比如在最终Build到来前的几周,也许非常严重的Bug,像数据丢失、程序崩溃之类的也都要推迟到下个版本再解决了。
当一线员工出现争执、无法达成一致意见的时候(尽管这种情况不多见),管理层要快速给出处理意见。
相关文章推荐
- 微软的Bug 管理指导原则
- 从一般管理原则看微软的重组
- 张国祥老师在宁波金鸟服饰指导制度优化讨论绩效管理原则
- 从一般管理原则看微软的重组
- 从一般管理原则看微软的重组 . 分类: 项目管理 2014-06-14 14:40 183人阅读 评论(0) 收藏
- 从一般管理原则看微软的重组
- 敏捷项目管理(摘录)——指导原则
- 从一般管理原则看微软的重组 .
- 从一般管理原则看微软的重组 .
- 从一般管理原则看微软的重组 .
- 微软的开发管理经验:100%以Bug为核心
- Apache CXF使用JAXRSClientFactoryBean创建Client时的原则及连接管理机制的Bug
- 消灭Bug!18款最佳的问题跟踪管理应用程序
- 微软 .NET Framework 1.1 JIT Bug report (严重级别:非常高)
- 导航控制器管理原则
- TestLink中集成Mantis bug 管理系统
- 时间管理的三八原则
- 习惯三:要事第一--自我管理的原则
- 工作中任务管理的四个原则和四个技能
- 软件测试的重要环节:Bug管理流程