Agile 🏈 怎麼衡量軟體工作進度? 以可用的軟體 Working Software 為準!

Jayden Lin
Jun 26 · 6 min read

筆者任職於 Yahoo ,粉絲團:《程式猿吃香蕉🍌》

(圖片來源:https://www.metageek.com/blog/scrum/)

衡量軟體工作進度向來不是一件容易的事情,想像一下 ,在聽工作進度的時候,你更喜歡聽到哪一種報告方式:

(1) 我已經完成了模組的70%, 明天會完成90%(2) 我先做了A功能,已經給業務先測過了,目前少B和C功能,明天會先完成B功能

想必大家都會選擇後者,然而這兩者的差別又在哪裡呢?

先說結論,我認為是後者採用了「可用的軟體 」(Working Software) 作爲衡量進度的標準,而前者沒有。以管理者的角度來說,透過「可用的軟體」能夠讓我們更有效的來控管進度,讓每一次「進度」等於產品「價值增加」。

Working software is the primary measure of progress

— Agile Manifesto

敏捷宣言(Agile Manifesto) 更是早已倡導使用可用的軟體 (Working Software) 作爲衡量進度標準,以下將說明這樣做的好處與挑戰,讓我們在實務應用的時候能夠更理解敏捷宣言的深意。

本篇內容:
✔ 可用的軟體是什麼?
✔ 可用的軟體做進度衡量
✔ 可用的軟體的優點
✔ 可用的軟體的挑戰
✔ 總結

▍可用的軟體 (Working Software) 是什麼?

根據定義,可用的軟體 (Working Software) 是完全整合的 (Fully-integrated)、可以被測試的 (Testable)、可以被驗證的 (Verifiable),並且可以準備交付給使用者或是部署到正式環境的。

簡單來說,可用的軟體 (Working Software) 之所以還沒有成為最終產品,「只是因為他還缺少一些功能」,而那些缺少功能是「值得或必須被等待的」,但軟體依然可以讓其他使用者先測試與驗證其他部分。

以下為幾個可用的軟體 (Working Software) 的範例:

💡 電商系統:客戶可以下訂單,但還缺乏取消訂單功能。
💡 PTT爬蟲系統:可以爬文章列表顯示,但還無法爬內文和推文。
💡 廣告系統:可以設定廣告預算,但只有單一廣告版型。

▍可用的軟體 (Working Software) 做進度衡量

根據可用的軟體 (Working Software) 定義我們發現,如果以「可用的軟體」做為進度衡量,這會大大地改變我們建造軟體的「步驟」,因為我們必須在每一次「進度」,保持它「可用」:也就是完全整合的 (Fully-integrated) 、可以被測試的 (Testable) 、可以被驗證的 (Verifiable)。

每一次「進度」,在敏捷開發中又稱為「增量」(Increment)。

因為軟體開發領域早期借鑒了許多建築學的知識,所以這裡我舉蓋房子的例子來譬喻可用的軟體 (Working Software):

可用的軟體 (Working Software) 概念就有如「你一邊蓋房子還能一邊住,客廳還沒蓋完,你可以先住臥室,同時還能反饋調整客廳的佈局」。

以下分別說明,這樣做的優點與挑戰。

▍可用的軟體 (Working Software) 優點

一邊蓋房子一邊住的優點顯而易見, 它提供了很大的彈性:

(1) 能有更快速的反饋,做出真正有價值的產品

由於每一次「進度」都能有反饋,使用者可以快速驗證這個產品是不是他/她要的,達到「快速失敗 (Fail fast),快速學習(Learn fast)」的效果。

(2) 可以作為「溝通的素材」而不只是「產品」

敏捷宣言也強調「Working Software over comprehensive documentation」,意即可用的軟體先於完整的文件,將可用的軟體作為團隊中彼此溝通交流的素材,討論這個軟體哪裡可以再做得更好。

想起我菜鳥時期在日商的日子,就曾被日本主管教育說:

沒有東西 (軟體) 給人家就看,業務單位沒有感覺,你畫面一出來,他們馬上就會有意見回饋了,你才可以知道接下來要怎麼做。

這就是可用的軟體 (Working Software) 的力量。

▍可用的軟體 (Working Software) 挑戰

一邊蓋房子一邊住的挑戰也十分明顯,它需要技術上的支援:

(1) 團隊需要建立共同的理解 (Shared Understanding)

舉例來說,要決定先蓋客廳還是蓋臥室?若沒有共同的理解 (Shared Understanding),這件事情整個團隊可能就吵不完。更糟的是,如果團隊對業務內容不夠理解,甚至會沒辦法把功能切小,以譬喻的方式來說,需求可能就是:「我要蓋一間房子!」,連客廳跟臥房等小功能都沒辦法切分出來。

(2) 工程師要有足夠的技術力

如果每次「進度」都要完全整合的 (fully-integrated),那麼「持續整合 (Continuous Integration) 」與「持續部署 (Continuous Delivery) 」是肯定要做的。此外,可運行軟體還要能夠可以被測試 (testable)、可以被驗證 (verifiable),那麼自動化測試肯定也要有,如此才能「確保」先前測試的結果,不會改了 A 卻壞了 B。

▍小結

衡量軟體工作進度向來不是一件容易的事情。目標在於要讓每一次「進度」等於產品「價值增加」,因此以「可用的軟體」來作為每一次「進度」是最好的方式。即使有許多挑戰,但依然值得我們追尋。

專注於「可用的軟體」能讓我們每一次的進度報告能針對以下幾點討論:

  • 什麼時候能測?
  • 有得到什麼回饋?
  • 達成了什麼價值?(有哪些功能可以了)

若是我們在進度報告時出現更多以上的對話,那麼我們離敏捷又邁向了一大步。

若是喜歡我分享的內容,歡迎幫我按個拍手,可拍 50下,給我一點鼓勵,或是加入我的粉絲團《程式猿吃香蕉🍌》,一起分享軟體知識與心得!

喜歡將軟體知識以簡單生動的方式講給你聽

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!

Jayden Lin

Written by

Yahoo 擔任 Lead Engineer,負責廣告系統,帶團隊做跨國開發。也是《程式猿吃香蕉》團隊創辦人,喜歡將實用的軟體知識以簡單生動的方式講給大家聽 😄😄😄

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!