第18章 每個人都是架構師，除非他們有其他身份

很多軟件團隊都朝著敏捷和自組織努力，在這種對現代軟件開發團隊的描述中，軟件架構角色如何融入并不是顯而易見的。

每個人都是架構師

在Extreme Programming Annealed中，格倫·范德堡（Glenn Vanderburg）討論了極限編程實踐適用的層次，他強調了架構和集體所有制之間的聯系。當我們談論集體所有制時，通常指的是集體擁有代碼，以便團隊中任何人都有權做出改動。這種方式奏效暗示團隊中每個人至少都對“大局”有一些基本的了解。想想你目前的項目，跳轉到代碼庫的任何一部分，你都明白發生了什么嗎？

想象一下，如果你有一隊經驗豐富、能夠在大局內外自如切換的軟件開發者，一隊真正會動手的架構師，這樣的團隊太棒了，所有通常會跟軟件架構聯系起來的元素（非功能需求、約束，等等）都會得到解決，不會漏掉任何一樣。從技術的角度來看，這就是一個自組織的團隊。

除非他們有其他身份

對自組織團隊的想法，我有一個大問題，我們在行業中談論了很多，但很少看到實踐。這可能是在咨詢的環境中工作的副作用，因為我的團隊總是隨著項目而變化，而且我不太可能跟某一個客戶在一起超過幾個月。或者，我懷疑，真正的自組織團隊非常少。把自組織作為努力方向是值得尊敬的，但對很多軟件團隊而言，這就像是還沒學會走就想跑了。

在“Notes to a software team leader”中，羅伊·奧謝洛夫（Roy Osherove）描述了他的“彈性領導”概念，這種領導風格需要根據團隊的成熟度有所變化。羅伊用一個簡單的模型對團隊成熟度做了分類，每個等級需要不同的領導風格。

(1) 生存型（混亂）：需要一種直接指揮和控制的領導風格。

(2) 學習型：需要一種指導的領導風格。

(3) 自組織型：需要簡易化來確保平衡不受影響。

就像我說的，團隊里每個人都是經驗豐富的軟件開發者和架構師，那就太棒了，但我還沒見過這樣的團隊。大多數項目的團隊連一個對“大局”之類的東西有經驗的人都沒有，一團亂的代碼庫、不明確的設計、很慢的系統，類似這些都是明證。從技術角度來看，這種情況最為多見，我建議團隊中由一個人來承擔軟件架構角色的責任。

羅伊舉了流程經理角色的例子。在成熟的初始階段，一個人承擔流程經理的角色來幫助團隊向正確方向前進，這將使團隊受益。另一方面，自組織團隊不需要別人告訴他們做什么。名字就是線索；從定義上，他們是自組織的，可以自己承擔這個角色。我想說，軟件架構的角色是同樣的，因此技術領導的角色也是。

敏捷需要架構嗎

可惜，許多團隊把“大局”上的技術技能看作一種不必要的邪惡，而不是重要的補充，可能是因為他們過去深受大型預先設計之害。有些人也過于渴望“敏捷”，以至于忽略軟件開發流程的其他方面。接踵而至的是混亂而非自組織，這樣的團隊也面臨著需要更直接的領導方式的挑戰。畢竟，他們在努力變得敏捷。單個點負責項目的技術層面，也跟他們對敏捷團隊的想象相沖突。這種沖突使人認為敏捷和架構是對立的：你只能擁有其中一個。與敏捷對立的不是架構，而是大型預先設計。

敏捷軟件項目仍然需要架構，因為那些圍繞復雜非功能需求和約束的棘手問題不會消失，只是對架構角色的執行不同。

集體代碼所有制，每個人都要能在架構的層次上工作，因此每個人某種程度上都是架構師。還不是自組織階段的團隊如果試圖跑太快，就會陷入掙扎。盡管人們的愿望是變得敏捷，集體代碼所有制和架構角色的分配都有可能阻礙混亂的團隊，而不是幫助他們。混亂的團隊需要更直接的領導方式，單個點負責軟件項目的技術層面，將使他們受益。換句話說，他們會受益于一個人負責軟件架構的角色。理想的話，這個人會指導別人，讓他們也能以這個角色產生幫助。

軟件架構師要一個還是多個？一個人承擔責任還是團隊共同分擔？不論敏捷與否，軟件架構的角色都是存在的。只有所處語境會告訴你正確的答案。