概述#

軟體架構師在開發專案的脈絡中工作，因此必須理解自己在專案中的角色與責任。本章探討架構師如何與專案經理協作、如何以增量方式發布架構、架構與 Agile 開發的關係，以及分散式開發對架構工作的影響。

架構師與專案經理#

專案經理與軟體架構師扮演互補的角色：經理從行政管理角度運營專案，架構師從技術方案角度運營專案。兩個角色在多個面向交叉，架構師可以支援經理來提高專案的成功機率。

根據 PMBOK（Project Management Body of Knowledge），架構師在各個知識領域中的角色包括：

• 整合管理：建立設計、圍繞設計組織團隊、管理相依性、協調變更請求
• 範圍管理：引出與審查執行時期需求、估算滿足需求的成本、時程與風險
• 時間管理：協助定義工作分解結構（WBS）、定義追蹤指標、建議資源分配
• 成本管理：彙整各團隊成本、就自製/外購與資源配置提出建議
• 品質管理：為品質而設計、追蹤系統是否符合設計、定義品質指標
• 人力資源管理：定義所需技術技能、指導開發者職涯發展、面試候選人
• 溝通管理：確保開發者間的溝通與協調、徵求進度回饋
• 風險管理：識別與量化風險、調整架構與流程以降低風險
• 採購管理：確定技術需求、推薦技術、培訓與工具

與專案經理維持良好的工作關係至關重要。了解專案經理的任務和關注點，以及你作為架構師如何支援這些任務。

增量式架構與利害關係人#

即使你的專案不採用 Agile 方法論，也應該以增量方式開發和發布架構，配合專案自身的測試與發布節奏。增量式架構的核心是以增量方式發布架構文件（如 Chapter 22 所述），決定發布哪些視圖以及深入程度。

第一個增量應包含的內容#

• 模組分解結構（Module Decomposition Structure）：為開發專案提供團隊結構的依據，使團隊可以定義、配置人員、編列預算和安排培訓
• 模組 “uses” 結構：允許規劃增量發布，這對希望增量發布軟體的專案至關重要
• 元件與連接器（C&C）結構：選擇最能傳達整體解決方案的 C&C 結構
• 概略部署結構：至少解決系統是否部署在行動裝置、雲端基礎設施等重大問題

後續增量則以架構利害關係人的需求為指引。

利用你的影響力確保早期版本處理系統最具挑戰性的品質屬性需求，以避免在開發週期後期出現令人不快的架構驚喜。

架構與 Agile 開發#

Agile 開發最初是對僵化流程、過度文件、前期規劃設計以及單次大量交付等傳統做法的反叛。Agilist 主張將原本花在流程與文件上的資源，重新分配到弄清客戶真正需要什麼，並以小型、可測試的交付增量儘早提供。

「正確」的前期工作量取決於多個因素，其中最主要的是專案規模，其他重要因素包括複雜的功能需求、高要求的品質屬性需求、需求的波動性（與領域的新穎程度相關），以及開發的分散程度。

三種架構設計方法#

關鍵問題在於：專案應進行多少前期工作（需求分析、風險緩解、架構設計）？對此沒有唯一正確答案，但可以為任何專案找到一個「甜蜜點」。

• BDUF（Big Design Up Front）（Figure 24.1a）：瀑布式的完整前期設計
• 湧現式方法（Emergent Approach）（Figure 24.1b）：信任架構會在編碼過程中自然湧現。對小型簡單專案可能有效，但作者從未見過它在大型複雜專案中成功
• Iteration 0 方法（Figure 24.1c）：推薦的中間路線——先進行幾輪 ADD（Attribute-Driven Design）迭代，選擇主要架構模式、框架和元件，再進入開發週期

Iteration 0 方法的核心思想：當需求變更時——特別是驅動品質屬性的需求——採用 Agile 實驗實踐，使用 spike（時間箱限定的任務）來解決新需求。Spike 在獨立的程式碼分支中開發，成功後合併到主分支。

Agile 宣言與架構的對話#

Agile 程式設計與架構之間的關係並不總是和諧的。2001 年的 Agile 宣言暗示架構是「湧現」的，不需要預先規劃或設計。對於中大型系統，這種觀點在殘酷的經驗面前不可避免地崩塌了——品質屬性需求的解決方案無法在開發後期任意「螺栓上去」，安全、高效能、安全性等關切必須從一開始就設計進系統架構中。

作者逐一檢視了 Agile 的 12 項原則，從架構中心的視角進行評論，結論是：

• 6 項「完全同意」：包括持續交付有價值的軟體、歡迎變更需求、可持續開發步調等
• 4 項「大致同意但有保留」：例如「工作軟體是進度的主要衡量標準」——是的，只要「主要」不被當作「唯一」
• 2 項「強烈反對」：
  • 「面對面交談是最有效的溝通方式」——對非瑣碎系統來說這是不正確的，介面、協定、架構結構必須被書面記錄
  • 「最佳架構從自組織團隊中湧現」——不，最佳架構是由有技能、有才華、受過訓練且經驗豐富的架構師有意識地設計出來的

SAFe 與大規模 Agile#

中大型組織希望將 Agile 應用於大型專案時，很快發現協調大量小型 Agile 團隊是巨大挑戰。在 Agile 中，小團隊在短時間內做小工作。一個挑戰是確保數十到數百個小團隊已適當分工，不遺漏也不重複工作；另一個挑戰是排序眾多團隊的任務，使結果能頻繁且快速地合併為下一個合理運作的系統增量。

SAFe（Scaled Agile Framework） 約 2007 年出現，提供了一個工作流程、角色和流程的參考模型。SAFe 承認架構的角色，提出了 intentional architecture（有意識的架構）的概念——定義一組有目的的、計劃性的架構策略和倡議——同時也強調 emergent design 作為平衡力量。

架構與分散式開發#

現今大多數重要專案都由分散式團隊開發，分布範圍可能從同一棟建築的不同樓層到全球不同時區的不同子承包商。

分散式開發的利弊#

• 成本：將部分開發移至低成本地區可能降低整體成本，但在達到足夠的領域專業知識和管理實踐調整之前，大量的返工可能抵消甚至超過工資節省
• 技術技能與人力可用性：可讓工作移動到人才所在之處，但需付出額外的溝通與協調成本
• 當地市場知識：在地開發者對當地市場特性和文化議題有更深入的了解

協調方法#

當模組 A 使用模組 B 的介面，且介面需要修改時，負責 B 的團隊必須與負責 A 的團隊協調：

• 非正式接觸：僅在團隊同地點時可行（咖啡間、走廊偶遇）
• 文件：若撰寫完善、組織良好且妥善散佈，可作為協調手段
• 會議：定期或臨時，面對面或遠端
• 非同步電子溝通：電子郵件、新聞群組、部落格、wiki 等

在分散式開發中，責任分配與模組相依管理比同地點開發更為重要。全球分散團隊之間的模組相依更容易出問題，應盡可能最小化。文件在分散式開發中也尤為關鍵，因為遠端團隊缺乏非正式的協調管道。

對架構師的意義#

分散式開發對架構和架構師意味著：

• 責任分配在分散式開發中比同地點開發更為重要
• 模組相依的關注度需要額外提升——全球分散團隊之間的模組相依更容易出問題，應盡可能最小化
• 文件在分散式開發中尤其關鍵——同地點團隊有多種非正式協調可能性，遠端團隊則必須依賴更正式的機制

COVID-19 的影響#

本書出版時，全球正因 COVID-19 學習適應遠端工作。這場大流行可能促使分散式開發成為常態——不再有走廊對話或自動販賣機旁的偶遇。所有人都在學習適應分散式開發範式，這是否會催生新的架構趨勢，值得持續關注。

本章小結#

架構師在開發專案中扮演技術方案的核心角色，與專案經理形成互補。架構應以增量方式發布，回應利害關係人的需求。Agile 與架構雖然起初關係緊張，但如今已成為不可或缺的夥伴——Iteration 0 方法在前期設計與敏捷迭代之間找到平衡。全球化分散式開發則要求更明確的協調策略，依賴更正式的機制（如文件和結構化溝通）而非同地點開發中的非正式互動。架構師需要理解這些專案脈絡，才能有效地發揮自身的技術領導角色。