你所不知道的康威定律

很多人聽過康威定律(Conway Law)

它主要是要強調:

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations

也就是系統架構會這樣設計, 是因為受制於這個組織的溝通結構

你可以在這邊找到康威定律的出處

Conway, Melvin E., How do Committees Invent?, Datamation, April 1968, 14 (5): 28–31 [2015-04-10]

https://web.archive.org/web/20150318044559/http://www.melconway.com/Home/Committees_Paper.html

但是不知道有多人看過康威定律論文的最後
因為就像 Royce 那篇瀑布式開發的論文,
最後 Royce 寫說循序開發不好, 需要多次迭代比較好
文章往往最後才是重點,
但是大家只看前面, 就只記住前面說的,
然而前面往往是錯的事情

所以, 我們就來看看康威定律最後的結論是什麼:

(1) 組織的設計需要根據溝通的需求

The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.

組織在設計系統(此處使用廣義的定義)時,其設計成果必然會反映該組織的溝通結構。我們已經看到這個事實對系統設計管理有重要的影響。最主要的是,我們找到了一個設計組織結構的準則:設計工作的組織安排應該基於溝通的需求。

這邊提到:

a design effort should be organized according to the need for communication.

組織的設計, 是為了溝通的需求.
那你覺得你們目前組織結構的設計是為了 (1) 夠有調適性 ? (2) 交付價值?, 還是 (3) 做得更快呢?
在 LeSS 中組織的設計是為了跨元件, 跨角色的溝通
如果你想要做得快一點, 不能夠只是局部快, 需要整體快才有用
而 component team 就只是局部優化
讓單一小組或是元件團隊比較好做, 但是對整體來說幫助有限

(2) 組織的靈活性對於有效的設計來說非常重要

This criterion creates problems because the need to communicate at any time depends on the system concept in effect at that time. Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.

這個準則會產生一些問題,因為在任何時候的溝通需求都取決於當時正在實施的系統概念。由於最初的設計幾乎永遠不是最佳方案,主導的系統概念可能需要改變。因此,組織的靈活性對於有效的設計來說非常重要。

這段的重點在於, 一開始設計出來的組織結構往往不是最好的
後面會是需要調整改變
因此, 組織結構需要有彈性, 才能讓你容易去調整改變

這段含義很明顯打臉元件團隊,
元件團隊固定只負責一個或是某幾個元件
他的彈性度是非常非常固定和局限的
當日後這個元件沒有需求, 或者是不在需要這個元件
這個元件團隊就會沒事做

此外, 元件團隊是依據架構設計來產生相對應的團隊
可是你也知道架構常常會修改
當架構修改時, 你的元件團隊也能拿掉, 或者是去處理另一個元件嗎?
所以團隊不該跟架構設計綁約,
因為架構是會改是不完美的
我們需要讓團隊設計和架構設計是脫鉤的

(3) 獎勵去設計出精實和有彈性的組織

Ways must be found to reward design managers for keeping their organizations lean and flexible. There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity. The development of such a philosophy promises to unearth basic questions about value of resources and techniques of communication which will need to be answered before our system-building technology can proceed with confidence.

我們必須找到方法來獎勵那些能夠保持組織精簡和靈活的設計管理者。我們需要一種系統設計管理的理念,這種理念不應建立在「增加人力就能提高生產力」的假設之上。發展這樣的理念將會揭示一些關於資源價值和溝通技術的基本問題,在我們的系統建構技術能夠充滿信心地向前發展之前,這些問題都需要得到解答。

這邊提到設計組織的人, 需要盡量讓組織結構比較精實 (lead) 和有彈性(flexible)
而不是認為加人就可以增加生產力

所以根據康威定律的想法, 它是贊成這些做法的

a. Feature Team
讓團隊可以處理端到端, 或者是較多的元件, 以增加彈性或是適應性

b. 擴大學習
為了要彈性, 開發人員需要了解更多元件的相關知識

c. 程式碼共享
為了要彈性, 程式碼不該只有某些人能改, 而是大家都可以

Craig Larman 對康威定律的解讀是
evolving flexible architecture by flexible communication in flexible organization
透過在靈活的組織中有彈性的溝通, 來演進出有彈性的軟體架構

想法來源: Myths of Software Management: Conway’s Law, by Craig Larman

發表迴響

探索更多來自 轉念學 - 敏捷三叔公的學習之旅 的內容

立即訂閱即可持續閱讀,還能取得所有封存文章。

Continue reading