為什麼品質是不可被談判的
在上面那個三角形中，我刻意忽略了第四個變數： 品質。
我企圖去把品質區分成內部品質和外部品質。
• 外部品質是系統的使用者可以感覺到的，一個緩慢和不直覺的使用者介面，便是一個很明顯的例子。
• 內部品質是指一般使用者看不到的問題，但是它會深深影響到系統的可維護性。像系統設計的一致性、測試涵蓋度、程式的可讀性和重構等等。
一般說來，若是一個系統內部品質很高，仍然有可能會外部品質還是很差。但是若是內部品質差的系統，很少會有很好的外部品質。試想，在鬆軟的沙灘上，如何建立堅固精緻的大樓。
我把外部品質也視為範圍的一部份。有時在商業的考量下，可能會發佈一版，它的使用介面比較簡陋，並且反應速度也比較慢。不過隨後發行一版比較乾淨的版本。我會把這些做或不做的決定權留給產品負責人，畢竟他是負責決定範圍的人。
然而，內部品質就沒有得談了，不管在怎樣的狀況，團隊都要維護系統的品質，這是無庸置疑的，沒有可以討價還價的，向來都是這樣的。
(好吧，差不多是直到永遠)
所以我們如何區分哪些是內部品質，哪些是外部品質的問題？
假如說，產品負責人說：“我尊重妳們所估算的6個故事點數，但是如果你們能花點心思，你們一定找到一些快速解(quick-fix)的方法，來節省一半的時間”。
哈！他想把內部品質當作一個變數。你會想說我怎麼會知道呢？因為他要我們縮短所評估出來的時間，可是卻沒有要對縮小範圍這件事情來“買單”。所謂“快速解”這件事會敲響你的腦中警鐘﹒﹒﹒
為什麼我們不允許這樣做？
我的經驗告訴我，犧牲內部品質是一個很糟、很糟的想法。所省下來的時間，在之後的日子會不斷為它付出代價。一旦我們允許這樣做，後面就很難恢復品質了。
相反地，我會試圖把話題回到範圍上面來，“既然你覺得早一點達到這個功能是很重要的，我們能不能縮小這個範圍，好讓我們能縮短實作時間？或者我們可以簡化錯誤處理的的方式，讓完整的錯誤處理方式變成另一個故事，讓我們之後再去處理它？或是我們降低其它故事的優先順序，讓我們先集中精神處理這一個？”
一旦產品負責人學到內部品質是不能被討價還價的，那對於其他變數，反而他將會處理的很好。
原則上，是的。但是實務上，現在我比較務實。有時候短期犧牲品質，可以產生很好的商業效果 – 例如，我們在下個 sprint 之後有個超大的商業展覽，或是我們只需要一個雛型來驗證使用者行為的假設。但是在這兩個狀況下，產品負責人需要明確解釋，為什麼我們要做這件事，並且承諾讓團隊之後回來彌補這些技術債 (有時團隊可以在產品 backlog 中，補上一個”清理”的故事，來當作提醒) 。高水準的內部品質應該是基準，異常事件應該被視為例外。
全站熱搜
留言列表
