歪歪凍的細細私語

[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. 執行品質管制 (Perform Quality Control)

 

規劃品質

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

執行品質保證

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

執行品質管制

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