你知道自己所用Windows的版本號嗎?
Daily Build的意義:
模塊得以及時整合
要求程序員及時把最新代碼放入代碼庫
用腳本語言和編譯/鏈接工具實現
BVT Build Verification Test
對Build進行驗證
Blocking Bug
讓Build無法完成的問題
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
決定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. 根據需要調整團隊結構