BugNET 這套問題追蹤工具除了具有免費、容易安裝設定等優點,個人用到現在也都沒碰到什麼大問題(目前用在約 20 人的團隊),挺穩定的,而且一直都還持續更新,功能也愈來愈強。最近對目前參與的專案有一些軟體品質方面的疑慮,想要從平日登錄到 BugNET 的資料抓出一些統計數據,這才發現 BugNET 提供的統計圖表並不是很夠用。所幸它提供了一個 view,從這個 view 取出的資料,幾乎已經能夠滿足我的需要了,剩下的只是如何產生圖表而已。這篇就大概介紹一下我從這個 view 取出哪些資料,以及利用 Excel 產生的圖表,同時扼要說明一下這些圖表的用途。BugNET 提供的 view 名稱叫做 BugsView。以下分別介紹用來產生統計圖表的 SQL 命令、圖表範例、以及用途說明。由於 BugNET 本身已經有提供的問題狀態統計圖(一張圓餅圖,顯示已結案、處理中、重新提出...等各種問題處理狀態各佔多少百分比),所以這裡就不列出了。
要先說明的是,有些 SQL 命令看起來很冗長,我也沒特別花時間去查是否還有更精簡的指令,基本上只求能達到我的目的。此外,這裡的圖表範例,都是先利用 SQL 命令得到資料,然後直接貼到 Excel,稍作加工(修改欄位標題、加總等等),再使用 Excel 的插入圖表功能即可完成。當然你也可以撰寫程式將這些產生圖表的動作自動化,方便隨時查閱。1. 每個月的問題數量
SQL 命令:
SELECT STR(YEAR(ReportedDate), 4, 0) + '/' + STR(MONTH(ReportedDate), 2, 0) AS RptYYMM,
COUNT(YEAR(ReportedDate) + MONTH(ReportedDate)) AS Cnt
FROM BugsView
GROUP BY YEAR(ReportedDate), MONTH(ReportedDate)
ORDER BY RptYYMM
圖表範例:
說明:
從這張統計圖可以看出哪些月份的問題數量比較多,以發現數字背後所隱藏的事件或原因。例如 2007 年 10 月可能有某個新系統上線,而使用者對該系統反映的問題較多,因此數量明顯增加;2008 年 2 月份由於經過一次年假,問題的數量就少得多。當系統完成驗收之後,系統應該會逐漸穩定,因此這張統計圖的問題數量應該呈現逐漸減少的趨勢,若非如此,專案經理就得進一步了解實際的原因。
2. 問題的優先等級分布
SQL 命令:
SELECT PriorityName, COUNT(PriorityName) AS Cnt
FROM BugsView
GROUP BY PriorityName
圖表範例:
說明:
在登錄問題時,必須根據問題的嚴重或緊急程度做分級(triage)。在所有提出來的問題當中,我們比較有興趣的是「緊急」跟「很重要」的問題佔多少比例,因為我們將這類問題定義為較具急迫性的問題,開發團隊必須在指定的期限內處理完畢。如果這類嚴重問題的數量很多,要不是軟體的品質水準太低,就是登錄問題的人員對於問題的分級不確實,比如說,可能每次登錄時都希望問題盡快獲得解決,就一律歸類為緊急問題。
3. 問題數量與軟體品質的關係
SQL 命令:
SELECT TypeName, COUNT(TypeName) AS Cnt
FROM BugsView
GROUP BY TypeName
圖表範例:
說明:
BugNET 的問題類型也可以自行指定。我把問題的類型分成 Bug、改進意見、新增需求、需求變更、待討論、以及無效問題等六類。Bug 代表軟體的設計錯誤,包括設計不符合使用者的需要、無法執行特定的功能、以及執行結果不正確等等;改進意見代表功能雖然可正常執行,但是在易用性、穩定性、效能等方面有待加強之處;以上兩項均代表軟體的品質,若其總和數量偏高(例如:超過事先定義的警戒線),專案經理就要特別注意。新增需求與需求變更皆屬於需求異動的部份,開發團隊可以從這兩項數據得知使用者是否經常提出需求變更,以了解需求蒐集和系統分析階段是否有需要改進的地方是,例如:需求誘導技巧是否需要改進、每一項需求是否皆經過使用者的同意即確認、或使用者是否傾向於事後(上線後)才提出新需求等等。屬於「待討論」的項目代表該問題的範圍或定義尚未釐清,主要是讓開發人員可以紀錄一些尚未確定的需求或議題(後來發現這項並不實用)。「無效問題」則是開發人員實際測試後,發現是使用者對系統操作方式不熟悉,或者其他環境因素所造成。
4. 各子系統的品質
SQL 命令:
SELECT ComponentName, TypeName, COUNT(*) AS Cnt
FROM BugsView
GROUP BY ComponentName, TypeName
ORDER BY ComponentName, TypeName
圖表範例:
說明:
BugNET 可讓我們設定系統有哪些 Components,也就是說,你可以自行定義子系統及各項元件,這樣在登錄問題時才能夠特別指明該問題是發生在哪個子系統,將來也才能夠得到比較詳細的統計數據。當整個系統的 Bug 數量偏多,你可以從這張圖進一步看出各個子系統/元件的品質。例如圖中的人事系統光是 Bug 和改進意見的數量加起來就有 171 個,佔整個系統問題數量(689)的 25%,專案經理可能要針對這個子系統特別研究一下是哪裡出了問題。
P.S. 以上圖表都沒有標示時間範圍,它們都是同一個專案的 current stat,也就是從一開始登錄問題到目前為止的狀態統計。
P.S. 以上圖表除了子系統名稱被我換掉,其餘皆是真實資料的統計數據。
結語
有時候,我們從最近 user 的反應「感覺」最近系統好像很多毛病,並將此意見反映給開發團隊時,經常得到的答案是:「程式的品質並沒有太大的問題,很多都不是 bugs,而是 user 的需求一直變更和新增。」此時解決爭議的最好辦法,就是拿出數據,這也是我製作這些圖表的用意:讓數字說話。
不過,在運用這些圖表時,務須牢記一件事:無論是問題統計圖表還是其他專案度量結果,其提供的資訊可能只偏單一面向,專案經理在獲得此初步資訊之後,應進一步蒐集其他相關資訊,以提供問題的佐證,或者向團隊詢問,如此方能確定問題的根源,並提出正確的解決方案;如果單憑某個單一數據就驟下結論,而向團隊質疑或提出指控,不僅容易做出錯誤的決策,將專案開發工作引導至錯誤的方向,也很容易造成團隊成員的反感。
還有一種統計圖我很想看到卻沒有做的,就是問題的成長速度 vs. 問題的解決速度。因為有些問題實在花很多時間才解決掉,對於 bugs,我們特別關心它的平均處理時間。
以上有不少想法和觀念均來自《軟體工程與 Microsoft Visual Studio Team System》。我不時會回頭參考這本書,每每覺得這本書寫得真好,因機緣巧合而能夠翻譯此書,實在是沾了作者的光。希望 Guckenheimer 在 Rosario 問世之後也能更新這本書的內容。呃......大概只是奢望。
要先說明的是,有些 SQL 命令看起來很冗長,我也沒特別花時間去查是否還有更精簡的指令,基本上只求能達到我的目的。此外,這裡的圖表範例,都是先利用 SQL 命令得到資料,然後直接貼到 Excel,稍作加工(修改欄位標題、加總等等),再使用 Excel 的插入圖表功能即可完成。當然你也可以撰寫程式將這些產生圖表的動作自動化,方便隨時查閱。1. 每個月的問題數量
SQL 命令:
SELECT STR(YEAR(ReportedDate), 4, 0) + '/' + STR(MONTH(ReportedDate), 2, 0) AS RptYYMM,
COUNT(YEAR(ReportedDate) + MONTH(ReportedDate)) AS Cnt
FROM BugsView
GROUP BY YEAR(ReportedDate), MONTH(ReportedDate)
ORDER BY RptYYMM
圖表範例:
說明:
從這張統計圖可以看出哪些月份的問題數量比較多,以發現數字背後所隱藏的事件或原因。例如 2007 年 10 月可能有某個新系統上線,而使用者對該系統反映的問題較多,因此數量明顯增加;2008 年 2 月份由於經過一次年假,問題的數量就少得多。當系統完成驗收之後,系統應該會逐漸穩定,因此這張統計圖的問題數量應該呈現逐漸減少的趨勢,若非如此,專案經理就得進一步了解實際的原因。
2. 問題的優先等級分布
SQL 命令:
SELECT PriorityName, COUNT(PriorityName) AS Cnt
FROM BugsView
GROUP BY PriorityName
圖表範例:
說明:
在登錄問題時,必須根據問題的嚴重或緊急程度做分級(triage)。在所有提出來的問題當中,我們比較有興趣的是「緊急」跟「很重要」的問題佔多少比例,因為我們將這類問題定義為較具急迫性的問題,開發團隊必須在指定的期限內處理完畢。如果這類嚴重問題的數量很多,要不是軟體的品質水準太低,就是登錄問題的人員對於問題的分級不確實,比如說,可能每次登錄時都希望問題盡快獲得解決,就一律歸類為緊急問題。
3. 問題數量與軟體品質的關係
SQL 命令:
SELECT TypeName, COUNT(TypeName) AS Cnt
FROM BugsView
GROUP BY TypeName
圖表範例:
說明:
BugNET 的問題類型也可以自行指定。我把問題的類型分成 Bug、改進意見、新增需求、需求變更、待討論、以及無效問題等六類。Bug 代表軟體的設計錯誤,包括設計不符合使用者的需要、無法執行特定的功能、以及執行結果不正確等等;改進意見代表功能雖然可正常執行,但是在易用性、穩定性、效能等方面有待加強之處;以上兩項均代表軟體的品質,若其總和數量偏高(例如:超過事先定義的警戒線),專案經理就要特別注意。新增需求與需求變更皆屬於需求異動的部份,開發團隊可以從這兩項數據得知使用者是否經常提出需求變更,以了解需求蒐集和系統分析階段是否有需要改進的地方是,例如:需求誘導技巧是否需要改進、每一項需求是否皆經過使用者的同意即確認、或使用者是否傾向於事後(上線後)才提出新需求等等。屬於「待討論」的項目代表該問題的範圍或定義尚未釐清,主要是讓開發人員可以紀錄一些尚未確定的需求或議題(後來發現這項並不實用)。「無效問題」則是開發人員實際測試後,發現是使用者對系統操作方式不熟悉,或者其他環境因素所造成。
4. 各子系統的品質
SQL 命令:
SELECT ComponentName, TypeName, COUNT(*) AS Cnt
FROM BugsView
GROUP BY ComponentName, TypeName
ORDER BY ComponentName, TypeName
圖表範例:
說明:
BugNET 可讓我們設定系統有哪些 Components,也就是說,你可以自行定義子系統及各項元件,這樣在登錄問題時才能夠特別指明該問題是發生在哪個子系統,將來也才能夠得到比較詳細的統計數據。當整個系統的 Bug 數量偏多,你可以從這張圖進一步看出各個子系統/元件的品質。例如圖中的人事系統光是 Bug 和改進意見的數量加起來就有 171 個,佔整個系統問題數量(689)的 25%,專案經理可能要針對這個子系統特別研究一下是哪裡出了問題。
P.S. 以上圖表都沒有標示時間範圍,它們都是同一個專案的 current stat,也就是從一開始登錄問題到目前為止的狀態統計。
P.S. 以上圖表除了子系統名稱被我換掉,其餘皆是真實資料的統計數據。
結語
有時候,我們從最近 user 的反應「感覺」最近系統好像很多毛病,並將此意見反映給開發團隊時,經常得到的答案是:「程式的品質並沒有太大的問題,很多都不是 bugs,而是 user 的需求一直變更和新增。」此時解決爭議的最好辦法,就是拿出數據,這也是我製作這些圖表的用意:讓數字說話。
不過,在運用這些圖表時,務須牢記一件事:無論是問題統計圖表還是其他專案度量結果,其提供的資訊可能只偏單一面向,專案經理在獲得此初步資訊之後,應進一步蒐集其他相關資訊,以提供問題的佐證,或者向團隊詢問,如此方能確定問題的根源,並提出正確的解決方案;如果單憑某個單一數據就驟下結論,而向團隊質疑或提出指控,不僅容易做出錯誤的決策,將專案開發工作引導至錯誤的方向,也很容易造成團隊成員的反感。
還有一種統計圖我很想看到卻沒有做的,就是問題的成長速度 vs. 問題的解決速度。因為有些問題實在花很多時間才解決掉,對於 bugs,我們特別關心它的平均處理時間。
以上有不少想法和觀念均來自《軟體工程與 Microsoft Visual Studio Team System》。我不時會回頭參考這本書,每每覺得這本書寫得真好,因機緣巧合而能夠翻譯此書,實在是沾了作者的光。希望 Guckenheimer 在 Rosario 問世之後也能更新這本書的內容。呃......大概只是奢望。
沒有留言: