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

[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