微軟高級開發者管理峰會演講摘要：產品質量的基石——微軟Bug管理
來自：微軟 蔡锫
一．團隊組織
1．常見問題
- 沒有人愿意做測試
- 覺得養不起那么多測試人員
- 開發人員不遵循規范，隨心所欲
- 項目經理事必躬親，分身乏術
2．微軟團隊模型
各角色的職責
| 角色 |
職責 |
| 項目經理 |
編寫功能規范，協調各角色關系 |
| 產品經理 |
客戶聯系的橋梁，進行需求分析 |
| 用戶教育 |
讓產品容易使用 |
| 發布經理 |
保證產品順利發布 |
二．項目管理
1．常見問題
- 無法決定項目所需的資源（人力和預算）
- 無法決定項目的進度表
- 無法控制外包項目的進度和質量
2．微軟項目管理-- 多里程碑式流程
- 每個里程碑完成部分功能
- 便于團隊集中力量完成一個又一個功能
- 提供多個機會以適應需求的更改
如何完成一個里程碑
- 基本完成需求調研和分析 （產品經理負責）
- 確定大方向和長中短期目標
- 所有角色都參與討論并真正認同結論
- 產生的文檔：
- 常見用戶情景：覆蓋80%以上功能
- Vision：言簡意賅地說明大方向，并有激勵團隊的作用
- 步驟二： 完成項目計劃
- 編寫詳細的功能規范（項目經理負責）
- 在編程前想清楚所有功能流程，并引導用戶明確需求
- 所有角色都參與審閱功能規范
- 制訂開發計劃和進度表（開發團隊）
- 制訂測試計劃和進度表（測試團隊）
- 分配資源（人力和預算）
- 形成項目綜合計劃和綜合進度表
- 產生的文檔：
功能規范，開發計劃，測試計劃（用例），項目綜合計劃
開發進度表，測試進度表，綜合進度表
- 開發人員分別完成自己的功能
- 使用版本控制工具
- 使程序員及時check out和check in，避免積累大量代碼
- 及時進行模塊間的整合，及時發現問題（daily build）
- 對每一項可測試的功能進行測試，無需等待
- 使用測試用例工具，對功能進行完整和重復的檢驗
- 使用BMS進行缺陷跟蹤
- 記錄所有程序問題
- 實現解決Bug的自動流程
- 按照綜合進度表不斷檢查進度
- 使用的工具：
- 版本控制工具 VSS
- 缺陷跟蹤工具 Raid/BMS
- 測試用例管理工具
- 測試組全面地測試功能，包括性能和穩定性
- 開發組全力配合解決Bug
- 使用BMS進行
- 專家會診機制：
- 決定Bug的優先度
- 決定哪些Bug可以等到下個里程碑或版本中解決
- 決定由誰解決某個Bug
- 使用的工具：
- 版本控制工具 VSS
- 缺陷跟蹤工具 BMS
- 測試用例管理工具
三． 微軟的開發管理經驗：100%以Bug為核心
1．Bug 及常見類型
- 功能未實現，和規格說明書不一致
- 不能工作：死機，沒反應
- 不兼容
- 邊界條件
- 界面、消息、提示不夠準確，不友好
- 把尚未完成的工作也作為一個Bug
- 文檔與幫助信息中的缺陷也是Bug
2．RAID/BMS的基本功能
- 完整的Bug數據庫
- 整個產品組的中央記錄和控制
- 強大的查詢功能，有效地跟蹤項目的狀態
- 所有的記錄無法刪除，對于每個記錄只能一直添加內容
- 豐富的報表功能，為產品發布提供判斷標準
3．Bug 記錄中的有效信息
- 狀態
- 負責人
- 問題種類
- 嚴重級
- 優先級
- 修改時間
- 登記時間
|
- 缺陷來源
- 解決方案
- 運行環境
- 缺陷關聯
- 附件
- 附圖
- 缺陷細節
|
4．Bug 的嚴重程度
- 死機，數據丟失，主要功能組完全喪失，系統懸掛
- 主要功能喪失，導致嚴重的問題，或致命的錯誤聲明
- 次要功能喪失， 不太嚴重，如提示信息不太準確
- 微小的問題，對功能幾乎沒有影響，產品及屬性仍可使用. 如有個錯別字
5．激活的Bug數量的趨勢
- 代碼完成前：很少
- 代碼完成后：增長很快
- 接近Beta: 下降
- 接近RC: 奔向零
- 產品質量和里程碑的信號
- 每天新建的Bug 與 修正的 Bug 相比較
- Active 狀態 Bug 的總數
四．微軟的一天
1． 讓我們看看項目中每個角色的一天是如何度過的
注：里程碑的每個階段每個角色的工作有不同側重點，我們以“完成功能”階段為例
微軟的一天從幾點開始？
答案：半夜
為什么？
因為Daily Build是所有工作的核心，而且是在半夜自動啟動。
每日構造Daily Build
- 你知道自己所用Windows的版本號嗎？
- Daily Build的意義：
- 模塊得以及時整合
- 要求程序員及時把最新代碼放入代碼庫
- 用腳本語言和編譯/鏈接工具實現
- BVT Build Verification Test
- Blocking Bug
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
- 決定Bug優先度
- 可否等到下個里程碑或版本解決？
- 誰來解決
- 預測項目實際進度和發布時間
缺陷走勢圖
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. 根據需要調整團隊結構