又來到了世界盃足球賽的年份，不知道大家支持的國家是否贏了呢？每每世界盃總讓我回想起2002年德國門神卡恩擔任隊長的那一年，雖然足球規則不是很懂，但覺得卡恩真的很霸氣啊！也就在那一年變成迷弟了。而且在足球的編制中，我最喜歡守門員的角色，總覺得只要守門員夠強，即使有最強的進攻都可以守住(腦海浮現少林足球的太極拳)。是否與現在軟體測試的守門員 – 測試工程師 不謀而合呢？

By Steffen Prößdorf, CC BY-SA 4.0, Link

趁著世界盃的熱潮，我們來聊一聊足球跟開發和測試的關聯性。如果只能挑一個來說，那我一定會選擇「傷停補時」。

首先，什麼是傷停補時？

在整個比賽過程中，一定會遭遇到一些突發狀況導致比賽無法如預期般的進行，例如犯規、更換球員、球員受傷治療等等，這些突發狀況發生時，不會停止計時，而是額外去計算這些事件影響了多少比賽時間，於比賽時間結束時補上。

接著來說，為什麼需要傷停補時？停錶不行嗎？

停錶當然是一種做法，像是籃球就採用這種機制，也不是說足球不行，但就是得取得一個全員共識。而足球和美式足球都採用了傷停補時，為的就是減少過多的演技派或是惡意拖延導致比賽被大量延長，導致對運動員的負擔過大。

我認為傷停補時的機制，也更貼近現實，畢竟時間是一直在流逝的，如果停錶，反而很容易被操弄。讓時間繼續流逝，也更能驅動所有人把目標都放在如何在有限的時間裡贏得比賽。講到這，應該對我們這次要聊的主題有點感覺了，也就是整個開發週期當中的突發狀況。

很多公司在估時會議中，往往只評估「實作順利」的時間和「測試順利」的時間，忽略了開發過程當中的「風險」和「意外」，也就是Bug。

如果你正處於軟體開發流程當中，可以回想一下每次開發到發佈的過程中，是不是跟預期的美好過程不一樣呢？即使給了Spike研究的時間，計畫永遠趕不上變化，但是專案時間就擺在那裡，也就讓整個團隊到了後期都在為了Deadline而熬夜趕工。

有的人就會問了，為什麼不直接在估時會議的時候，直接把可能的風險就估進去呢？例如我原本要兩天完成，我就加個一天來做緩衝；原本測試需要回歸三天，我也多加一天。

我得說，不是不行，但試著想想最糟的情況，如果已經包含了緩衝時間進去，仍然無法如期發版，也就意味著整個團隊失去了可控性，畢竟單純的緩衝是無法規避嚴重風險的；另一方面，時間抓得太寬鬆，實務上是很難去最大化團隊效率的，很容易發生超估的狀況，例如RD其實早就做完、QA早就測完，但因為估比較長，反而到了時限快到才交付。

基於各種原因，在估時會議上給出一個最準確的時間，也就變成實務上最被廣泛接受和使用的做法了。

但所有人都知道，即使盡量估準了，但還是會有很多零星的偶發事件發生，考驗著整個團隊的危機處理，試著想想，上一次沒有意外的準時發版是多久之前了啊？

那有沒有一個合適的解方呢？那就是傷停補時了

但是開發流程的補時遠比足球補時複雜得多，足球可以直接計算每次突發狀況損耗的時間，但軟體開發有時會需要開發重一點，有時是需要測試重一點，因此該從下列四個面向來進行補時評估

1. 突發狀況的嚴重性

2. R&D解決問題所需時間

3. 測試驗證問題所需時間

4. 未來規避類似問題的有效方案，以免累積技術債

除了產品是一個迭代的過程外，整個專案管理、開發流程、測試流程也都該是一個迭代的過程，經由不斷地累積對突發狀況的解決方案和應對機制，長遠來看會越來越穩定

知道了怎麼評估補時和怎麼補時，但其實最重要的，是公司願不願意採用補時的機制，畢竟絕大部分的公司都會很穩定的排定每個週期該完成的工作內容，並且預期某項功能會在固定的時間發表，也就不會很願意改變專案時間。甚至有些專案是簽定合約或是有真正的死線，若沒如期完成，反而會造成違約賠款，這類案例就很難透過傷停補時的方式來進行。

但若你公司的產品是可控的，可自訂的，可完全決定步調的，那傷停補時不失為一個調和混亂和時程的良方，最小化傷停補時的時間就會是整個專案的主要目標之一。