「敏捷軟體開發」並不敏捷

有什麼方法可以有效處理軟體開發的延遲交付

Agile

如果貴公司的軟體開發，從不延遲交付 (delay delivery)，或是說，導致延遲交付的原因，是單純的「需求沒有釐清」，顯然不是軟體開發人員的問題，那我想，本文應該對您沒有幫助，您可以跳過這篇文章了。

我從 2009 年開始從事軟體開發的工作。一直到 2019 年年中，在我從業接近十年後，才算是成功地第一次在 nontrival software project 上辦到「準時交付」。「準時交付」應該不是什麼難事吧？我曾經一度認為人類是辦不到的。

延遲交付的原因是什麼？

有人可能會想問，為什麼「敏捷軟體開發」不能讓軟體準時交付，卻還可以大言不慚地叫做敏捷？大家會有這種美麗的誤會，也許跟「敏捷開發宣言」裡的一些句子有點關系。比方說，「敏捷程序提倡可持續的開發。贊助者、開發者及使用者應當能不斷地維持穩定的步調。」這一類的句子。其實，平心而論，它只說了提倡，沒有說保証辦得到。

不只是敏捷軟體開發不能有效地處理軟體開發的延遲交付，靜態型別語言也不行、單元測試也沒有辦法。軟體開發的延遲交付，其實是一種效應 (effect)。它比較像是「症狀」，而不是「病因」。我們要避免「延遲交付」發生，要先去探討它的原因 (cause)。

延遲交付的成因主要有兩個：

1. 使用者的需求定義不清楚
2. 只可意會、難以言傳的軟體複雜度 (software complexity)

就我個人的經驗，由於第一點相對容易被企業的管理階層認知到，所以企業的管理階層可能會採取下列措拖去改善，比方說：雇用有經驗的專案管理人員、積極地對使用者進行訪談、甚至請人類學家去了解使用者的社會情境等方法。

第二點，因為「難以言傳」，軟體開發者講不出來，管理階層更是難以了解。沒有採取積極措施去處理的結果，軟體複雜度就容易發展到不可控 (unmanageable) 的程度。

軟體複雜度

照論文 Out of the Tar Pit 的說法，軟體開發者在開發軟體時，必須要能了解程式到底如何運作？要了解程式運作的方式，不外乎兩種方法：

1. 測試 (test)
2. 非正式推理 (informal reasoning)

測試的話，不一定會存在，另外，就實用性來講，非正式推理遠比測試常用且實用。非正式推理是指：「軟體開發者對著一堆的程式碼，把自己的腦子當作程式碼的直譯器，去模擬程式碼的執行，透過模擬執行程式碼的行為，來掌握這段程式碼到底是怎麼運作的。」然而，軟體複雜度卻可以大大地妨礙非正式推理的運作。這裡談的軟體複雜度的定義並不是演算法裡的 big O complexity ，而是當人要去做「非正式推理」時，主觀感到困難的程度。導致複雜度增加的因子主要有三個：

1. 變動的狀態 (mutable states)
2. 控制結構 (control flow)
3. 程式碼的數量 (code volume)

談到軟體複雜度的時候，一般人最容易先注意到的複雜度，是程式碼的數量。但是，程式碼的數量只是因為「量」而導致的複雜，它跟上述兩者放在一起比較時，就變成了最不重要的因子。變動的狀態、與控制結構，則是在「質」的層次就可以讓人難以理解。(註：變動的狀態與控制結構為什麼妨礙 informal reasoning ，可以參考這篇文章裡的「位址導向編程」的舉例。)

程式是被人寫出來的，而人腦有所謂的「七物件法則」的限制。如果採用的軟體開發方法，就是會引誘軟體開發者去寫出高軟體複雜度的程式碼，那延遲交付也就指日可待了。

如何有效減少軟體複雜度

在我個人的經驗裡，有效減少軟體複雜度的方法可以拆成兩個層面：

1. 程式碼
2. 資料庫

對程式碼減少複雜度的方法

• 使用依賴注入 (dependency injection) 來開發程式
• 應用函數式程式設計 (functional programming)
• 採用只支援函數式編程範式的語言，比方說 Clojure

對資料庫減少複雜度的方法

• 對於 OLTP 的使用情境，原則上採用關聯式資料庫，而不是 noSQL
• 可以使用輔助生成 SQL 的函式庫，但是不要使用 ORM (object relational mapper)
• 採用讀寫分離的方式，來設計存取資料庫服務的 API 。
• 採用本身就支援事件溯源 (event sourcing) 的資料庫，比方說，Datomic 又或是這邊的 Datahike, Asami, Crux。

又或者是，你也可以考慮連絡我？

2024/01 更新：
新文章已經轉換到 https://replware.substack.com 發表，歡迎讀者訂閱