敏捷架構、精益架構，還是兩者兼而有之？

作者 | Kurt Bittn、Pierre Pureur

譯者 | Sambodhi

策劃 | 丁曉昀

多年來，我們會聽到人們將他們的軟件架構稱爲“精益和敏捷”的架構。這讓我們不禁思考精益和敏捷實踐究竟如何助力團隊在軟件產品的架構設計上取得突破？有些人將這兩者混爲一談，認爲精益和敏捷在很大程度上是相似的方法。但我們認爲，在軟件架構的語境下，精益和敏捷方法有着本質的不同，它們都有各自的優勢和侷限性。

精益方法的核心在於消除低效開發過程和實踐所帶來的浪費，縮短產品開發週期，該方法主要是在製造問題領域中發展起來的。它們主要關注產品開發的手段和方法，但也包括逐步改進產品的機制。

精益方法的前提假設是，組織已經對要構建的產品或解決的問題有了較爲清晰的認識，因此其主要關注在構建已知解決方案時減少浪費。

許多管理者青睞精益方法，因爲它能夠顯著提升開發效率、增強生產力、降低成本並增強項目的可預測性。

他們將軟件開發視爲一條生產線，而精益方法起源於製造業，與這種生產線式的軟件開發理念高度契合。

然而，這並不是敏捷方法的重點。敏捷方法的核心目標並非單純地追求效率、生產力、成本削減或可預測性的提升，儘管這些都有可能是實現敏捷方法主要目標的副產品：迅速驗證組織是否在構建正確的產品。

爲了實現這一目標，團隊需要減少浪費以實現快速反饋週期，從而降低成本並提高效率，但這些只是實現不同目標的手段。

正如愛麗絲在迷茫中詢問切西貓應該選擇哪條路時，切西貓的迴應 “如果你不知道你想去哪裡，那麼走哪條路都無所謂”。在軟件架構的語境下，敏捷方法要回答的問題是 “產品應該去哪裡？”（即產品要實現什麼） ，精益方法要問的問題是 “構建產品最快最有效的方式是什麼？” ，它假設團隊已經明確他們需要構建的產品是什麼。

對於軟件架構而言，這意味着什麼呢？

MVP、MVA 與經驗主義

最小可行產品（MVP）作爲一種經驗性的方法，已廣泛應用於驗證團隊是否走在構建正確產品的正確道路上。在一些系列文章中，我們在此基礎上引入了最小可行架構（MVA）這一相關概念，作爲對 MVP 概念的擴展。MVA 是開發團隊對解決方案所作的一系列基礎設計決策，它強調 MVP 的可持續性和長期可行性，在滿足產品功能需求的同時也滿足 QAR，注重產品的可持續性，併力求減少技術債務。

在 MVP 和 MVA 的實踐中，客戶需求以及滿足這些需求所需的技術決策常常存在一定的未知性，至少部分是未知的。這要求團隊運用經驗反饋循環，深入瞭解客戶需求，並收集關於其解決方案是否滿足這些需求的反饋。這一點對於 MVP 和 MVA 來說都是一樣的。

值得注意的是，MVP 和 MVA 並非一蹴而就的過程。每個產品發佈都是團隊運行的一組 MVP 和 MVA 實驗，旨在更好地瞭解客戶需求並交付價值。因此，每一次發佈都可以被視爲 MVP/MVA 組合的一個新版本。

敏捷、精益與複雜性

Dave Snowdon 的 Cynefin 框架 提出了四個問題空間：

明顯的（Obvious），在這種情況下，選項清晰，對因果關係的共識很容易達成。

複雜的（Complicated），在這種情況下，可能存在多個 “正確” 的解決方案，需要專業知識來診斷和決定。

難以理解的（Complex），在這種情況下，可能沒有“正確”的解決方案，因爲它們太不可預測，無法應用已被證明的解決方案或確定因果關係。解決這些問題需要採用經驗方法來形成和測試假設，並根據結果進行調整。

混亂的（Chaotic），在這種情況下，沒有因果關係，最好的做法是儘量減少混亂，並建立一定程度的秩序和穩定。例如，緊急情況和自然災害響應都屬於此類。精益方法確實注重可預測性，並在處理明顯和某些複雜問題時展現出其獨特的優勢。在這些情境中，問題的解決方案相對明確或至少是可定義的。當滿足這些條件時，減少浪費、改進效率以及提高可預測性是追求的關鍵目標。

當面對目標和解決方案不明確定義的複雜問題時，敏捷方法則展現出其獨特的價值。在這種情境下，沒有現成的解決方案可以套用，只有一系列帶有權衡和假設的部分解決方案。

這並不意味着精益方法在解決複雜問題時完全無用。相反，在軟件開發的許多環節中，一些工作仍然十分簡單或者沒有那麼複雜，如構建和測試過程，特別是使用持續交付管道或減少團隊之間的交接浪費。構建正確的產品是一個複雜的問題，而正確地構建產品並沒有那麼複雜。

敏捷、精益與軟件架構

爲軟件產品構建架構是一項複雜的任務，每個產品都面臨着一系列獨特的挑戰，要求架構師通過細緻的權衡來尋找最佳的解決方案。在之前的 文章 中，我們深入探討了這一決策過程，並引入了最小可行架構（MVA）的概念，它作爲這些權衡決策的重要反映。MVA 是最小可行產品（MVP）的架構補充，確保 MVP 在技術層面是可行、可持續且具備未來可擴展性，這是 MVP 與一次性概念驗證的區別所在。

雖然精益方法主張將軟件開發的核心聚焦於工作流程的改善，但從架構的視角來看，其核心問題在於如何構建既是最小可行產品又是最小可行架構的解決方案。

MVA 的一個顯著特點在於它是在一系列產品發佈的過程中逐步發展和完善的。開發團隊通過收集和分析每次發佈的實證數據，不斷驗證和調整對 MVA 適用性的假設。在沒有充分實證數據支持的情況下，團隊無法準確判斷 MVA 是否適合當前的 MVP，也無法預測其在產品生命週期內的可行性。團隊需要不斷獲取反饋，解決出現的問題，並在後續發佈中持續改進 MVA。這種基於實證的反饋循環與敏捷方法的核心理念相契合。

鑑於開發團隊在構建架構過程中需要作出多種類型的決策，且工作本身具有新穎性，因此這項任務本質上具有不可預測性。團隊成員面對的是前所未有的挑戰，他們的工作重點並非追求效率，而是確保決策的有效性。當然，通過應用一些精益原則，如減少在做的事情的數量（WIP）、縮短等待時間、減少中斷和交接等，可以在一定程度上提高團隊的工作有效性。他們當然對縮短獲得反饋的時間感興趣，但並沒有顯式地關注如何優化他們的工作流程。

精益方法適用於需求相對穩定且問題定義明確的情境，其優化目標在於消除不必要的浪費。然而，架構工作的挑戰在於，在產品生命週期的早期階段（有時是在產品生命週期的後期），形成架構的需求（我們稱之爲質量屬性需求或 QAR）往往沒有被透徹理解。

精益方法還追求減少浪費，這是一個有價值的目標。架構工作的問題在於，開發團隊在缺乏實驗驗證的情況下難以判斷決策的正確性。實驗過程中，一些決策可能會被證明是錯誤的，但這樣的 “失敗” 並非真正的浪費，而是爲團隊提供了寶貴的反饋信息，有助於減少未來的浪費。

在軟件開發過程中，精益方法特別關注由流程本身產生的浪費，尤其是那些已開始但未完成的工作造成的浪費。過多在做的事情（WIP）是造成這類浪費的常見原因，但在軟件產品中，推遲決策、技術債務往往會造成一種特殊的浪費。敏捷交付週期的反饋能夠揭示出技術捷徑和推遲決策對產品滿足 QAR 能力的潛在損害。當這種情況發生時，開發團隊通常需要投入額外的時間和精力來解決技術債務並重新設計架構。從精益的角度來看，這可能會暫時打亂工作流程。然而，從長遠來看，這是減少因產品無法維持其價值而產生的更大浪費所必需的。

結 論

組織既需要敏捷方法，也需要精益方法，但原因不同。敏捷方法的核心在於提供及時的反饋，確保團隊正在構建的產品能夠精準地滿足客戶需求，特別是在產品未能滿足預期時，敏捷方法能夠迅速揭示問題所在。他們也需要精益方法來消除浪費，幫助組織以更成本效益的方式交付高質量產品。因此，精益方法是敏捷方法的補充。

對於開發團隊而言，敏捷實踐是獲取關於 MVP 及其相關 MVA 是否達到預期目標的關鍵途徑。他們需要在後續產品中持續改進 MVP/MVA。如果 MVP/MVA 未能達成既定目標，單純追求效率和生產力將無助於團隊提供更優質的解決方案。

一旦團隊對產品的發展方向和架構實現的目標有了較爲明確的信心，他們可以將關注點逐漸轉向效率、生產力和成本控制等方面。然而，即便在此時，團隊也應牢記每次產品發佈都是對產品價值和可持續性的一次實驗性測試。

作者簡介

Kurt Bittner， 擁有超過 30 年的經驗，通過短期、以反饋爲驅動的週期交付可工作的軟件。他幫助了各種各樣的組織採用敏捷軟件交付實踐，包括大型銀行、保險、製造和零售組織，以及大型政府機構。他曾爲或與包括甲骨文、惠普、IBM 和微軟在內的大型軟件交付組織工作過，並曾是 Forrester Research 的技術行業分析師。他的重點是幫助組織建立強大的、自組織的、高績效團隊，交付客戶喜愛的解決方案。他是與軟件開發相關主題的四本書的作者，包括《用於擴展 Scrum 的 Nexus 框架》。他目前居住在科羅拉多州博爾德，並擔任 Scrum.org 的企業解決方案副總裁。

Pierre Pureur，是一位經驗豐富的軟件架構師，具有廣泛的創新和應用開發背景，對金融服務行業有着廣泛的瞭解，擁有廣泛的諮詢經驗和全面的技術基礎設施知識。他過去擔任過一家主要金融服務公司的首席企業架構師，領導過大型架構團隊，管理過大規模的併發應用開發項目和指導創新計劃，以及制定戰略和業務計劃。他是書籍《持續架構實踐：在敏捷和 DevOps 時代的可擴展軟件架構》（2021）和《持續架構：在敏捷和云爲中心的世界中的可持續架構》（2015）的合著者，並在該領域發表了許多文章並在多個軟件架構會議上做過演講。

https://www.infoq.com/articles/agile-lean-architecture/

聲明：本文爲 InfoQ 翻譯，未經許可禁止轉載。