Agile 🏈 怎麼衡量軟體工作進度？ 以可用的軟體 Working Software 為準！
筆者任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，粉絲團《程式猿吃香蕉🍌》
衡量軟體工作進度向來不是一件容易的事情，想像一下 ，在聽工作進度的時候，你更喜歡聽到哪一種報告方式：
(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。
▍小結
衡量軟體工作進度向來不是一件容易的事情。目標在於要讓每一次「進度」等於產品「價值增加」，因此以「可用的軟體」來作為每一次「進度」是最好的方式。即使有許多挑戰，但依然值得我們追尋。
專注於「可用的軟體」能讓我們每一次的進度報告能針對以下幾點討論：
- 什麼時候能測？
- 有得到什麼回饋？
- 達成了什麼價值？(有哪些功能可以了)
若是我們在進度報告時出現更多以上的對話，那麼我們離敏捷又邁向了一大步。
