In 91

（本文授權 DevOpsDays Taipei 2018 及天瓏網路書店全文轉載）

何謂軟體開發的本質

這本書書名的副標，把軟體開發的【本質】一語道破，我更喜歡英文呈現的意義：

• Keep It Simple
• Make It Valuable
• Build It Piece by Piece

以價值為最終目標，以終為始，其他的實踐都只是為了幫助我們達到最終的目標：【在時刻變動的世界，頻繁且持續地交付出具有價值的軟體產品】。千萬不要本末倒置，迷失在絢爛的工具或糾結於方法論本身實踐的定義，因為【敏捷】的本質就是【適應性】的能力，讓自己能因應不同的變化或意外，調整以適應變化，時刻追求「最適當解」，而非高大上的「最佳解」，敏捷是種進化的能力，進化是為了生存，取得競爭優勢，而不是「快速」，快不一定活得下來，能隨時調整以適應變化的能力才是。

圖片來源：《軟件開發本質論》摘錄

探索軟體開發的本質

首先要有個觀念，「簡單」不代表「容易」，相反地，越簡單往往越不容易。軟體開發如此，平面、廣告設計也是如此。

軟體產品要能快速頻繁地交付，以取得回饋，最重要的一件事，就是「避免浪費」。把所有精力、時間都先關注在最有價值的功能上，才有可能縮短交付的時間，且對使用者帶來的價值不會因為功能不夠「完整」而縮減太多。

舉個例子，如果各位要開發 Excel 這個產品（毋庸置疑，Excel 是個很成功的產品），這產品應該要具備多少的功能呢？你知道 Excel 有多少功能呢？而你最常用的功能有多少呢？這些對你來說最重要、最常用的功能，佔了 Excel 整體功能數的百分比有多少呢？

以我自己的需求來說，我最需要、最常用的功能大致上是：

• 計算類的公式
• 快速的複製、貼上
• 格式、樣式
• 樞紐分析表

我相信這些功能，以「數量」來算的話，絕對不到 Excel Feature 的 20%，但對我來說，我有 80% 以上都只用這些功能。如果我的樣本是有代表性的，或是我代表有價值的使用者群體（例如願意花錢買授權），那只要有這些功能，我就願意用了，甚至我會更希望，「我可不可以只買這些功能的 Excel 就好」。

對開發人員來說，要完成一個完整的 Excel，一年半載以上跑不掉。然而，要開發一個符合我需求的 Excel，時間可能只需要原本的 1/3 或一半。

• 使用者在乎的，是我常用的功能要很好用，在乎價格，在乎品質。
• 公司、老闆在乎的，不是產品的完整程度，而是產品的獲利能力，市場的佔有率，搶市場的時間點。
• 團隊在乎的，是交付有價值的產品，而不是耗盡心力產出一個沒有使用者願意用的產品。

「價值優先」，才有機會「避免浪費」，避免浪費才快得起來。

就一個軟體產品而言，一樣的功能範圍，一樣的時間完成，可以創造的累計價值是截然不同的。用圖表來做個簡單說明，如果把產品的功能需求，都以長方形來呈現，寬度代表需要的成本或時間，高度代表價值。

這 8 個 item 的編號，是按照「高度/寬度」的值來進行排序，這邊舉出兩個極端的例子，針對價值的升冪排序跟降冪排序，如下圖所示，同樣的時間或成本（x 軸)，其面積代表單位時間內能創造的價值，分別為 x + y 與 x - y ，兩者的差異可以到 2y。這還是沒有觀測是否具備更有價值的需求出現的情況。由此可見，「價值」與「開發順序」對於軟體產品來說，位於舉足輕重的地位。

「產品功能列表」與「完成百分比」是傳統專案管理最常犯的迷思，因為它能量化，自然容易落入數字的陷阱裡。原因是，每個功能的價值權重並不相等，所需時間也不相同。

敏捷的本質是「務實」的，過去大家看的數字，都是關注在 output，而敏捷重視的「價值」是 outcome。如何用最小的成本，獲取最大的 outcome，才是敏捷的真實模樣。

所以，在 Scrum 裡面的 Product Backlog 才會具備 ODDE 的特性：

透過本質論裡面所重視的「體現價值」，方能理解為何 scrum framework 裡面會如此設計。而只要目標是相同的，目標/需求/問題，這都是中性的，你應該要有足夠的能力、夠多的選擇，才能針對目前的 context 挑出「最適當解」，不被方法論的一字一句綁住，達到「役物而不役於物」的境界。

大家讀到這邊都會有個疑問，「我該怎麼判斷價值呢？」其實在原本 BA, 產品發展甚至行銷，就都有很多評估功能與獲利的方式，這些都可以當作是產品功能價值的「預估」方式。

然而我想強調的是，關在會議室裡面的產品價值預估都是覺得產品功能推出後會大鳴大放、大紅大紫的。（如果你們連關在會議室裡面都不覺得產品有價值，真的，不要繼續做了，不要做那些你自己都不認為有價值的需求）但推到市場上，真的能一鳴驚人的產品比例有多低呢？大概就跟新創公司能活下來的比例一樣低。

因此，交付的週期拉得越長，代表投入的成本越高，也代表著風險越高，一旦市場不接受，這些沒有帶來價值的 feature 事實上是不如不做的。要怎麼縮短交付週期，提高交付頻率？Build It Piece by Piece，讓開發的功能變少，就有機會集中火力。

當你能用最少的成本，達到最大的 outcome，自然就有餘力依據現況來進行調整。最有效的產出，除了自身帶來的價值以外，還有兩種價值常被忽略：

1. 因為你的交付，產生出更有價值的需求。
2. 因為你的交付，發現原本的需求價值被嚴重高估，甚至低落到應該捨棄這些需求。

持續小而精美的交付，真實目的是發現上面兩種狀況，「交付、觀測、反饋、調整」也才是 DevOps 最重要的精神。如何將這樣的過程 Lead Time 降到最低，則是各個協作流程優化與工程實踐能帶來的改善。

Lead Time 長短，會是決定敏捷體質的關鍵因素。Lead Time 一長，就會陷入「沉沒成本」與「機會成本」的兩難選擇。舉例來說，如果我們要完成的產品需求，完整需求所需要的時間是一年。而傳統的交付是一年之後一翻兩瞪眼見真章，敏捷交付則是縮短產品功能交付週期，並以價值預估的優先順序交付，週期可能是 2~4 週為一個迭代。

想像一下，當你功能完成度到 3/4 的時候，出現了一個更有價值的市場需求，你會面臨如何的選擇？傳統的開發方式，只有兩種：

1. 捨棄手上完成 3/4 的功能內容（通常捨不得），投入新需求的開發。 => 當下產出的價值為 0，這是選擇「沉沒成本」，避免失去「機會成本」。
2. 做完手上完成度已經有 3/4 的功能（但可能已經不具價值，或相對投資報酬比低落），等做完手上的功能之後，再選擇新的功能需求。 => 明知已經不具高價值的功能，卻仍堅持把它做完，這是選擇吃下「機會成本」，而避免那 3/4 的「沉沒成本」

總是陷入有心無力，而且方式不改變的話，其實就是個無間地獄，一直選 ① 的傳統團隊，大部分都無法交付價值，因為開發週期長，一直出現新的需求。一直選 ② 的傳統團隊，完成的功能可能很多，但創造的價值很低。因為每個需求有價值的時間點，都先被競業搶先交付、搶下市場了，自己就是頭反應緩慢的大象。

當你每兩週交付眼前產品最高價值的功能，就有機會取得回饋，就有機會進行調整。所謂迭代的節奏，除了讓團隊開發穩定、持續改善週期以外，對產品來說更重要的是，進入重新 planning 的機會，重新審視價值與需求，進行調整。這樣的方式，要付出的沉沒成本，不會多餘兩週的工作量。出現新的機會，最長的等待時間也不會多於兩週。

更別說，這些新的變化，很有可能都是基於你之前的交付所引發的新機會，相較於其他傳統團隊，你所引發出來新需求，往往你能搶得先機，建立進入門檻。

總之，Lead Time 越長，代表反應速度越慢，也就是越不敏捷，也就是越不具備因應變化的適應能力，這是個重要的領先指標。

而 Keep It Simple，事實上這是最吃產品開發團隊基本功的一點，從產品功能的分析、使用者習慣體驗的調查，乃至開發團隊能否滿足 Simple Design 的原則，這些是產品與開發團隊適應能力的碁石。

• 夠簡單，才能重用。
• 夠簡單，才能吸睛。
• 夠簡單，才能避免浪費。
• 夠簡單，才能好維護。

每一個新功能的產品開發，其成本來自於兩個難度：

1. 該功能本身的難度。
2. 在既有產品上，加入新功能的難度。

《軟體開發本質論》不是只有那些簡單的道理，還包含著如何培養出開發團隊因應變化的能力，例如重構、自動測試與其他 XP 實踐能帶來的好處與原因。

最後，軟體產品的開發，只有技術是不夠的。技術是簡單的，人卻是複雜的。《軟體開發本質論》裡面提到，要達到上面這些目標，組織該怎麼調整才能具有適應性、避免浪費，例如「Component Team」 VS 「Feature Team」，例如如何引入「大規模的敏捷」，如何組成強大的團隊，如何引發團隊成員的動機，如何管理這樣的敏捷團隊。

小結

這本書，就像是濃縮的寶藏，篇幅沒有任何的浪費，就如同書裡所提倡的敏捷精神一樣，夠簡單，充滿價值，讓人回味無窮、愛不釋手。

在引入 DevOps, Scrum, Kanban 等等之前，強烈建議大家花點時間閱讀一下這一本輕薄精美的經典之作。

• 當你在實務上迷惘時，回過頭來思考軟體開發的本質。
• 當市面上又出現了新的 buzzword，回過頭來思考，真正的目標為何，以終為始。
• 當你陷入了實作、實踐的細節，迷失在見樹不見林的牛角尖時，刻意讓自己放空一下，回過頭來讀讀這本書，讓你能回到起點，看到終點，校正方向，專注進行衝刺。

 

---

blog 與課程更新內容，請前往新站位置：http://tdd.best/