iT邦幫忙

DAY 16
3

PMP的敏捷之路系列 第 16

PMP的敏捷之路-品質管理

一個大家都知道但不能說的秘密,就是品質在專案中通常會淪落成僅只是個口號。

[PMBOK Guide 4th,191]

一個大家都知道但不能說的秘密,就是品質在專案中通常會淪落成僅只是個口號,傳統Waterfall的開發方式,測試是開發階段的最後活動。一旦時程開始delay時,大頭們所採取的策略不外乎是加班趕工和壓縮測試時程,好讓自己能保有進度能迎頭趕上的幻覺。也因此在這種「死亡行軍」的情形下,品質被犧牲是必然的結果。

根據溫伯格的定義:品質即在某些人心中的價值。因此在敏捷專案當中,藉由小型且周期性發佈,使得客戶能夠快速地回饋產品是否符合其心中的價值,並且修正徧差,使得品質不再只是個口號,而是真實能交付給客戶的價值。

除此之外,Agile practices(http://guide.agilealliance.org)中亦有許多在開發過程當中能確保品質的方法,例如Pair programming、Test-driven development和Continous integration等等實務作法。

根據PMBOK的定義,品質管理共有以下3個流程

  1. 規劃品質 (Plan Quality)
  2. 執行品質保證 (Perform Quality Assurance)
  3. 執行品質管制

規劃品質
PMBOK中即寫明「品質是設計(規劃)出來的,不是檢查出來的」。但是一旦計畫趕不上變化時,連檢查這道關卡都會被強迫大開方便偷懶之門。如同其他的管理計畫,敏捷是採取依循慣例及「恰好及時」的滾動式規劃來微調執行方法。此外,在每次的Sprint planning meeting當中,PO即會定義出該次的產出該達成何種程度的品質,好讓各項工作皆能有做完的定義。

執行品質保證
在Sprint執行的過程當中,品質保證的活動一直都在進行的。像是採取Pair programming、Code review或是撰寫Automatic unit test case等等作法,皆能有效地確保程式的品質。此外,在Daily standup meeting更新Task borad上工作的執行情形時,亦能觀察到是否有工作一直無法通過測試,無論是對成完的定義不清或是程式品質低落,皆能早期發現而早期處理解決。

執行品質管制
最後,在Sprint最後的Retrospective Meeting會針對本次Sprint的成果做最後的品質確認,並將需要修正的問題或變更的項目紀錄至Product Backlogs當中。另外在Retrospective Meeting,團隊會針對流程及產品低落的原因,自我提出改善的建議並行動。PMBOK中的品保七工具雖然並沒有規類在敏捷方法中,但並不表示就是絕對不能使用。敏捷的彈性能容納任何對流程改善有益處的事情,如果團隊能藉由品保七工具的分析方法識別出問題,自然要多加利用。不過照經驗來講,通常最嚴重的問題都是顯而易見的,不靠工具分析大家也都知道。 XD


上一篇
PMP的敏捷之路-Scrum的雙品質回饋迴路
下一篇
PMP的敏捷之路-人力資源管理
系列文
PMP的敏捷之路30

1 則留言

我要留言

立即登入留言