Ruddy Lee 分享空間

Emergent Design 演化設計

貴公司的品質如何?

leave a comment »

.

有沒有實施「缺陷管理」是品質好壞的基本分水嶺。

.

品質好還是不好?好抽象!這個問題還真是很難回答。我們作顧問的經常會問客戶這個問題,目的倒不是想聽到什麼特別的回答,其實只是做個開場,問一下客戶是怎麼作專案開發的,有沒有把測試當作是重點。通常;我會接著表明會從「要求品質」開始。(如果你問我為什麼要從品質開始呢?回答是,品質跟紀律是一體的二面,從要求品質開始就是要求紀律。這是從事顧問工作的第一步,先奠定團隊的基礎,雖然要求品質這種做法,效果很難立即看得出來,但是它對團隊而言總是好的,是從長遠作計畫的作法,而對顧問工作來說則是為了紀律,紀律可以幫助團隊更容易接受變革(尤其是由傳統的開發法轉變成敏捷開發),紀律可以幫助團隊更容易邁上自我管理之途,同時也能幫助顧問取得與團隊之間的彼此尊重。反觀;程式設計人員是一種腦力工作者,自由自在的思維容易帶來散漫(這是一種常態),因此亟需要紀律。而紀律是由一群工程師組成的團隊,最容易缺乏的東西。總之;提高紀律是一個成功的開始。

 

缺陷管理系統 Bug tracking system

有沒有實施「缺陷管理」是品質好壞的基本分水嶺。將缺陷記錄在資料庫裡然後便可以持續的去追蹤問題,這是最基本的品質要求。約耳( Joel Spolaky)在 Joel on Software 裡寫過如何來評鑑軟體團隊對質量的測試,寫得很籠統卻十分值得借鏡,就是下面的12條問題,本文想強調其中的第四條問題,然後用「缺陷追蹤看板」來協助那些還沒做到的團隊。

.

The Joel Test (註 1.)

  1. 你有使用原始碼控制系統嗎?

  2. 你能用一個步驟建出所有結果嗎?

  3. 你有沒有每天都重新編譯建立(daily builds)嗎?

  4. 你有沒有問題追蹤資料庫(bug database)?

  5. 你會先把問題都修好之後才寫新的程式嗎?

  6. 你有一份最新的時程表嗎?

  7. 你有規格嗎?

  8. 程式人員有沒有安靜的工作環境?

  9. 你有沒有用市面上最好的工具?

  10. 你有沒有測試人員?

  11. 有沒有在面試時要求面試對象寫程式?

  12. 有沒有做走廊使用性(hallway usability)測試?

.

缺陷與需求具有本質上的差異

負責專案生命週期管理的軟體通常都會包含 Bug Tracking 的缺陷管理機制,它們(一般)把Bug當成需求開發的項目來處理。乍看之下似乎沒有甚麼問題,但實質上對工程師而言需求是運用邏輯創意來達成客戶的要求,一旦達成之後這個成功的功能便可以一再的來複製使用。而缺陷則是處理已知程式不能正常運作的問題,缺少了邁向未來的挑戰性,一旦缺陷解決之後,很少有工程師能夠有機會重複使用解決它的方法。所以當ALM(Application Life cycle Management)的管理程式等閒看待這二者時,缺陷便是經常被忽視的一方,也間接造成了缺陷管理上的不足,而使得品質上難以得到提升。

.

缺陷追蹤看板 – 讓你看見品質

缺陷跟蹤管理系統是用於記錄程式缺陷的報告它出現的時間、嚴重度,異常程式的表現以及如何重現此缺陷的細節;再來就是指出造成程式缺陷的人員和可能修正此缺陷的程式設計人員(註2.繁雜的缺陷屬性細項)。它應該是不斷跟蹤軟件缺陷在其生命周期中被分配的狀態指標。但由於一般的ALM系統把Bug當成需求開發的項目來處理,反而造成了大家忽視持續追蹤的重要性。關於這一點我們可以運用看板來補足它。這種所謂的「缺陷追蹤看板」與一般看板有所不同,很少工程師會在缺陷解決之後,還持續去關注它的,一般都只有主管或測試人員才會願意多花心力來關注它。因此缺陷追蹤看板通常都是置於測試部門或是主管房間,讓有興趣關注它的人持續去追蹤。

.

000 Bug Tracking _3

缺陷追蹤看板

》缺陷經常是俱有即時性的,迅速對缺陷做正確的判定甚為重要。對於緊急事件,可以在看板下方另外開立渠道來做快速處理。

》一般對尚未定義缺陷優先等級或嚴重性時,就應該先行判定是缺陷、待補強功能或是未來的新開發功能。

缺陷管理系統的Queue處理原則就是團隊對於品質要求的原則。這也是缺陷與需求最相像的一個地方,他們都必須持續去關懷(refinement),因為它們都會隨著產品的生命週期而改變。

》工程師被要求針對這個缺陷需要多少時間才能修復完畢去做估算,這才是一種真正有意義的估算。怎麼說呢?因為這跟對還沒做過的需求做估算完全不同(那是對未來的一種猜測,很難猜得準的),這是對自己已經處理過的事情,只是因為某些因素沒有考慮到而表現得不太一樣的行為,進行估算如何修復它,這可是完全合情合理的。而且越是緊急就越能顯示出估算的真諦;也就是不必估算了,就是傾全力去做一直到解題完成為止,這就對了(這是我一直以為最有意義的事)。

.

將缺陷處理步驟分別以欄位的方式依序排列在看板上頭:

欄位一、缺陷與問題

將新的缺陷或是問題(指的是補強功能或是新增功能Feature)由測試團隊或產品經理提交給負責tracking的工具。一般而言除了急件,否則都是先把它放進Queue裡頭,等待下一個步驟被啟動時再來處理。

 欄位二、優先等級與嚴重性

由主管(產品經理)或團隊一同對缺陷(問題)設定優先等級和嚴重性,並將問題分配給特定的程式工程師。

 欄位三、估算

由負責修復的工程師估算修復這個缺陷所需要的時間。(缺陷與需求在估算上完全不相同,所謂解鈴還需繫鈴人,缺陷的估算無法採用類似需求的估算一樣,由團隊一起進行估算,一般只有原作者最清楚自己的程式有缺陷發生了,到底是怎麼一回事呢?因此也只有他本人才能做比較有意義的估算了)

 欄位四、發佈

開發部門或是負責修護的人員針對此特定缺陷或問題釋出新的內部版本。

 欄位五、測試

測試團隊檢查被標記為已修復的所有問題真的都已修復無誤。

 欄位六、完成

由測試團隊關閉此缺陷的跟蹤工具,並完整記錄修復此缺陷的整個過程。開始進行下一個缺陷(也就是回到欄位一)。

.

用圖形來試著做看板每個欄位背後的規則說明:

 

000 場景說明

缺陷處理的場景說明

.

缺陷管理的目標

  • 確保每個被發現的缺陷都能夠被有效的解決。

  • 這裡解決的意思不一定是被修正,也可能是其他的處理方式(例如保留作為功能或列入成為未來開發的新功能。至於缺陷是否在下一個版本中修正或是不做修正只列為保留,也就是持續追縱的意思),總之;對每個被發現的缺陷的處理方式必須能夠在開發組織中達到一致的做法。

  • 持續收集缺陷數據並根據缺陷趨勢曲線圖來識別測試過程的各個階段是否需要修正或加強。決定測試過程是否結束有很多種方式,通過缺陷趨勢曲線圖來確定測試過程(對時間的長短拿捏)是較為有效的一種方式。

  • 持續收集缺陷數據並在其上進行數據分析,並拿來作為組織在開發過程的種種紀錄的參考,最終將成為良好品質的基礎。

.

小結

缺陷處理」與「規格文件」都是評估團隊品質好壞的重要因素。約耳分別把他們列在第四、七項。這是一般團隊最容易忽略的二個項目,我們的理由都說是「等有時間的時候再來做它」,但我們就是從來沒有時間來處理它,而這些疏忽正是造就品質的重要依據。建議主管們就從今天開始採用缺陷記錄看板,用「看得見」來減少忽略問題提升品質吧!

到底是做「規格文件」重要還是處理「缺陷記錄」比較重要呢? 當然;記錄缺陷要重要一些,因為它總是比較緊急需要趕緊處理,一個是內涵另一個則是外觀,現在的Application 就是這樣,如果沒有外觀,則往往第一次被採用的機會都不會獲得,因此還是先把外觀弄好,也才能有機會展現內涵。

.

{ 為什麼只挑這二個項目來做說明呢? 因為它們是我每次做顧問時最常發現,他們可以做得很好卻經常疏忽的地方 }

{缺陷管理的描述細項相當的多,千萬不要用人工來進行,推薦二個工具給大家做參考,用Leangoo看板进行可视化的缺陷跟踪管理 ,另一個是 Lean Testing,它們都是Free的。(其實採用 Trello也行,但就像微軟的VSTS或是著名的 JIRA專案管理工具都已經內含Bug Tracking 的能力在其中了ㄧ樣,務必在製作自己的缺陷管理看板,如此就可以避免遺漏時時提升品質的重要性了)}

.

註1. Joel on test

為 Joel Spolsky 所著,他的 Joel on software 曾經獲得2012 JOLT大獎。

註2. 對缺陷的描述應該包含以下的內容: (參考自台灣word)

  • 可追蹤信息
  • 缺陷ID : 唯一的缺陷ID,可以根據該ID追蹤缺陷
  • 缺陷基本信息
  • 缺陷狀態: 缺陷的狀態,分為「待分配」、「待修正」、「待驗證」、「待評審」、「關閉」
  • 缺陷標題: 描述缺陷的標題
  • 缺陷的嚴重程度: 描述缺陷的嚴重程度,一般分為「致命」、「嚴重」、「一般」、「建議」四種
  • 缺陷的緊急程度: 描述缺陷的緊急程度,從1-4,1是優先順序最高的等級,4是優先順序最低的等級
  • 缺陷提交人: 缺陷提交人的名字(郵件地址)
  • 缺陷提交時間
  • 缺陷所屬項目/模塊: 缺陷所屬的項目和模塊,最好能較精確的定位至模塊
  • 缺陷指定解決人: 缺陷指定的解決人,在缺陷「提交」狀態為空,在缺陷「分發」狀態下由項目經理指定相關開發人員修改
  • 缺陷指定解決時間: 項目經理指定的開發人員修改此缺陷的deadline
  • 缺陷處理人: 最終處理缺陷的處理人
  • 缺陷處理結果描述 : 對處理結果的描述,如果對代碼進行了修改,要求在此處體現出修改
  • 缺陷處理時間 : 缺陷處理所發掉的時間
  • 缺陷驗證人: 對被處理缺陷驗證的驗證人
  • 缺陷驗證結果描述: 對驗證結果的描述(通過、不通過)
  • 缺陷驗證時間: 對缺陷驗證的時間
  • 缺陷的詳細描述: 對缺陷的詳細描述;之所以把這項單獨列出來,是因為對缺陷描述的詳細程度直接影響開發人員對缺陷的修改,描述應該儘可能詳細
  • 測試環境說明: 對測試環境的描述
  • 必要的附件

 

Written by ruddyllee

2016 年 08 月 22 日 於 11:49:41

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: