解決開發測試過程中的不可控因素 – 傷停補時

by | 12 月 5, 2022 | blog

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

2022-07-30 Fußball, Männer, DFL-Supercup, RB Leipzig - FC Bayern München 1DX 3179 by Stepro.jpg
By Steffen Prößdorf, CC BY-SA 4.0, Link

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

首先,什麼是傷停補時?

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

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

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

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

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

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

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

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

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

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

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

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

  1. 突發狀況的嚴重性

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

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

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

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

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

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

文章作者介紹

Fabian Lin

你也想要分享知識和觀點嗎?KEENLITY目前推出INSIGHT觀點報,誠徵「專欄作家」與「單篇投稿」,點擊連結投稿並了解好處和責任。

精選軟體測試線上課程

邀請您訂閱INSIGHT觀點電子報

Similar Posts

沒基礎就用AI寫程式是什麼樣子? – 使用AI前要先知道的小故事

沒基礎就用AI寫程式是什麼樣子? – 使用AI前要先知道的小故事

近期面試了一位自動化測試工程師,而我的習慣,是會以一個貼近實務的題目作為考題,請人選用程式解決,這次是請他將API的Response做解析,並取得我要的資料內容。 人選說他有帶自己的電腦來,想直接上手寫。我覺得沒有不妥,比起上白板更有效率,就等他開好電腦,打開VS Code。 接著他開始寫註解,我剛開始覺得這個習慣不錯,接著發現他有安裝Copilot,畫面上跳出了一條條的Auto...

你憑什麼教人?憑我的執念和哲學觀 – 軟體測試顧問之路

你憑什麼教人?憑我的執念和哲學觀 – 軟體測試顧問之路

孟子曰:「人之患,在好為人師」
如果這句話是出自經典,但為什麼我仍然執著於指導著下屬?即使在我聽到很多人都覺得我沒資格,或是我憑什麼的時候,我依然堅持著。
我反思了我的成長歷程,發現到,因為我曾經遇到過不好的老師,以及遇到過影響我一生的老師。在我的思維中,我覺得這個世界上欠缺太多好的老師了,而我想用我的方式,來給予願意相信我的人一些指引。因為我覺得有個曾經相信你的人是非常重要的,即使過了十幾二十年,甚至當我們老去的時候,你都會想著曾經有一個過客,影響著你的人生。

KEENLITY的3年軟體測試創業回顧

KEENLITY的3年軟體測試創業回顧

KEENLITY三週年慶推出多重優惠!宣布30家企業訂閱Armoury+可享「價格鎖定,終身不漲價」的特惠,並加碼推出Starter方案,滿足小型測試團隊需求。此外,用量更大幅提升,在價格不變下可用案例量翻倍。我們的測試管理系統Armoury+擴展至完整API功能,並計劃年底上線API監控。過去三年,KEENLITY從零客戶成長至服務多家企業,並組建軟體測試聯盟,攜手國際夥伴。KEENLITY的成長軌跡已成定局,迎接下個輝煌三年!