團(tuán)隊設(shè)計
團(tuán)隊設(shè)計是敏捷方法論中很重要的一項實踐。我們這里說的團(tuán)隊，指的并不是復(fù)數(shù)的人。一群人就是一群人，并沒有辦法構(gòu)成團(tuán)隊。要想成為團(tuán)隊，有很多的工作要做。
我們之所以考慮以團(tuán)隊為單位來考慮架構(gòu)設(shè)計，是因為軟件開發(fā)本身就不是一件個人的事情，架構(gòu)設(shè)計更是如此。單個人的思維不免有考慮欠妥之處，單個人的學(xué)識也不可能覆蓋所有的學(xué)科。而組織有效的團(tuán)隊卻能夠彌補這些缺憾。
誰來負(fù)責(zé)架構(gòu)的設(shè)計？
在我們的印象中，總認(rèn)為架構(gòu)設(shè)計是那些所謂架構(gòu)設(shè)計師的專屬工作，他們往往擁有豐富的設(shè)計經(jīng)驗和相關(guān)的技能，他們不用編寫代碼，就能夠設(shè)計出理論上盡善盡美的架構(gòu)，配有精美的圖例。
問題1：理論上設(shè)計近乎完美的架構(gòu)缺乏程序的證明，在實際應(yīng)用中往往會出這樣那樣的問題。
問題2：設(shè)計師設(shè)計架構(gòu)帶有很大的主觀性，往往會忽視客戶的需求，導(dǎo)致架構(gòu)無法滿足需求。
問題3：實現(xiàn)的程序員對這種架構(gòu)有抵觸的情緒，或是因為不理解架構(gòu)而導(dǎo)致架構(gòu)實現(xiàn)的失敗。
問題4：架構(gòu)師設(shè)計架構(gòu)主要是依據(jù)自己的大量經(jīng)驗，設(shè)計出的架構(gòu)不能真實的反映目前的軟件需要。
解決辦法
團(tuán)隊設(shè)計的理論依據(jù)是群體決策。和個人決策相比，群體決策的大好處就是其結(jié)論要更加的完整。而群體決策雖然有其優(yōu)點，但其缺點也是很明顯的：需要額外付出溝通成本、決策效率低、責(zé)任不明確、等等。但是群體決策如果能夠組織得當(dāng)?shù)脑?，是能夠在架?gòu)設(shè)計中發(fā)揮很大的優(yōu)勢的。
避免象牙塔式的架構(gòu)設(shè)計
對軟件來說，架構(gòu)設(shè)計是一項至關(guān)重要的工作。這樣的工作交給某個人是非常危險的。即便這個人再怎么聰明，他也可能會遺漏部分的細(xì)節(jié)。組織有效的團(tuán)隊的力量是大大超過個人的力量的，因此團(tuán)隊的成果較之個人的成果，在穩(wěn)定性和思考的周密程度上，都要更勝一籌。
Scott W. Ambler在其著作中給出了象牙塔式架構(gòu)（ivory tower architecture）的概念：
An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).
中國現(xiàn)在的軟件開發(fā)行業(yè)中也逐漸出現(xiàn)了象牙塔式的架構(gòu)設(shè)計師。這些架構(gòu)師并不參與實際的程序編寫，他的工作就是為項目制作出精美的架構(gòu)模型，這種架構(gòu)模型在理論上是相當(dāng)完美的。
例1：在XP中，我們基本上看不到架構(gòu)設(shè)計的影子。并不是說采用XP技術(shù)的團(tuán)隊就不需要架構(gòu)設(shè)計。XP不存在專門的設(shè)計時期，它提倡使用一些簡單的圖例、比喻的方式來表達(dá)軟件的架構(gòu)，而這種的架構(gòu)設(shè)計是無時無刻不在進(jìn)行的。其實，XP中的設(shè)計采用的就是團(tuán)隊設(shè)計的方式，結(jié)隊編程（Pair Programming）和代碼的集體所有制（Collective Ownership）是團(tuán)隊設(shè)計的基礎(chǔ)，也就是基于口述的溝通方式。通過采用這樣的方式，XP幾乎不需要文檔來表達(dá)架構(gòu)的設(shè)計。
優(yōu)秀的架構(gòu)師能夠充分的利用現(xiàn)有框架，減少軟件的投入，增強(qiáng)軟件的穩(wěn)定性。這些都沒有錯，但是問題在于“過猶不及”。象牙塔式架構(gòu)師往往會出現(xiàn)文章開始指出的那些問題。架構(gòu)設(shè)計其實并不是非常復(fù)雜的工作，但它要求開發(fā)人員具備相關(guān)的技能、經(jīng)驗以及對問題域有一定的了解。開發(fā)人員往往都具有相關(guān)的技術(shù)技能（編程、數(shù)據(jù)庫設(shè)計、建模），而對問題域的理解可以從用戶和行業(yè)專家那里獲得幫助。因此，在理論上，我們要實現(xiàn)架構(gòu)設(shè)計的團(tuán)隊化是完全可能的。
在上面的象牙塔式架構(gòu)定義中，我們看到架構(gòu)師和日常的開發(fā)工作是隔絕的。這樣設(shè)計出的架構(gòu)有很大的局限性。在現(xiàn)實中，我們還會發(fā)現(xiàn)另外一種角色，他來自于開發(fā)團(tuán)隊外部，為開發(fā)人員提供相關(guān)的技術(shù)或業(yè)務(wù)的培訓(xùn)。這種角色稱為教練，在軟件開發(fā)中是非常重要的角色，不能夠和象牙塔式架構(gòu)設(shè)計師之間畫等號。
選擇你的設(shè)計團(tuán)隊
軟件的架構(gòu)在軟件的生命周期的全過程中都很重要，也就是說，軟件開發(fā)團(tuán)隊中的所有人員都需要和架構(gòu)打交道。因此，好的團(tuán)隊組織方式是所有開發(fā)人員都參與架構(gòu)的設(shè)計，我們稱這種方式為全員參與。全員參與的方式保證了所有開發(fā)人員都能夠?qū)軜?gòu)設(shè)計提出自己的見解，綜合多方面的意見，在全體開發(fā)人員中達(dá)成一致。這種方式尤其適合于一些小的團(tuán)隊。
還是會有很多的團(tuán)隊由于種種的原因不適合采用全員參與的方式。那么，組織優(yōu)秀的開發(fā)人員組成設(shè)計組也是比較好的方式。一般，我們選擇那些在項目中比較重要的，有較多開發(fā)經(jīng)驗，或是理論扎實的那些人來組成設(shè)計組。當(dāng)然，如果你考慮到為組織培養(yǎng)后續(xù)力量，你也可以讓一些新手加入設(shè)計組，或是你覺得自己的開發(fā)力量不足，邀請外部的咨詢力量介入，這完全取決于具體的情況。
設(shè)計組不同于我們之前提到的象牙塔式架構(gòu)設(shè)計師。設(shè)計組設(shè)計出來的架構(gòu)只能稱為原始架構(gòu)，它是需要不斷的反饋和改進(jìn)的。因此，在架構(gòu)實現(xiàn)中，設(shè)計組的成員將會分布到開發(fā)團(tuán)隊的各個領(lǐng)域，把架構(gòu)的思想帶給所有開發(fā)人員，編寫代碼來檢驗架構(gòu)，并獲得具體的反饋，然后所有的成員再集中到設(shè)計組中討論架構(gòu)的演進(jìn)。
團(tuán)隊設(shè)計中存在的問題
在團(tuán)隊設(shè)計的過程，我們會遇到各種各樣的問題，首當(dāng)其沖的就是溝通成本的問題。架構(gòu)設(shè)計時，需求尚未被充分理解，軟件的設(shè)計思路還處于萌發(fā)的狀態(tài)。這樣的情況下，團(tuán)隊的每位成員對軟件都有獨特的見解，這些可能有些是相同的，有些是互斥的。就好比盲人摸象一樣，他們的觀點都代表了軟件的一部分或是一方面，但是沒有辦法代表軟件的全部。
在敏捷方法論中，我們的每一個流程都是迅速進(jìn)行、不斷改進(jìn)的。架構(gòu)設(shè)計也是一樣，我們不可能在架構(gòu)設(shè)計上花費更多的時間。而團(tuán)隊決策總是傾向于較長的討論和權(quán)衡。
例2中的問題在架構(gòu)設(shè)計中時有發(fā)生，純技術(shù)的討論很容易上升稱為爭吵。這種情況幾乎沒有辦法完全避免。團(tuán)隊型的決策必然會發(fā)生觀念的沖突?？刂埔欢ǔ潭葍?nèi)的觀念的沖突對團(tuán)隊的決策是有益，但是如果超出了這個程度就意味著失控了，需要團(tuán)隊的調(diào)節(jié)。而更重要的，我們需要注意溝通的技巧。
團(tuán)隊溝通
團(tuán)隊進(jìn)行架構(gòu)設(shè)計的時候溝通是一個非常需要注意的問題，上述的情境在軟件組織中是經(jīng)常發(fā)生的，因為技術(shù)人員很自然認(rèn)為自己的技術(shù)比別人的好，如果自己的技術(shù)受到質(zhì)疑，那怕對方是抱著討論的態(tài)度，也無異于自身的權(quán)威受到了挑戰(zhàn)，面子是無論如何都需要捍衛(wèi)的。而溝通如果帶上了這樣一層主觀色彩，那么溝通信息的受眾就會潛意識的拒絕接受信息。相反，他會找出對方話語中的漏洞，準(zhǔn)備進(jìn)行反擊。因此，我們要注意培養(yǎng)一種良好的溝通氛圍。
在實際的觀察中，我發(fā)現(xiàn)團(tuán)隊溝通中存在兩種角色，一種是建議者，他們經(jīng)常能夠提出建議。一種是質(zhì)疑者，他們對建議提出否定性的看法。這兩種角色是可能互換的，現(xiàn)在的建議者可能就是剛才的質(zhì)疑者。質(zhì)疑者的發(fā)言是很能打擊建議者的積極性的，而在一個腦力激蕩的會議中，好是大家都能夠扮演建議者的角色，這就要求溝通會議的主持者能夠掌握好這一點，對建議給予肯定的評價，并鼓勵大家提出新的建議。
團(tuán)隊設(shè)計是敏捷方法論中很重要的一項實踐。我們這里說的團(tuán)隊，指的并不是復(fù)數(shù)的人。一群人就是一群人，并沒有辦法構(gòu)成團(tuán)隊。要想成為團(tuán)隊，有很多的工作要做。
我們之所以考慮以團(tuán)隊為單位來考慮架構(gòu)設(shè)計，是因為軟件開發(fā)本身就不是一件個人的事情，架構(gòu)設(shè)計更是如此。單個人的思維不免有考慮欠妥之處，單個人的學(xué)識也不可能覆蓋所有的學(xué)科。而組織有效的團(tuán)隊卻能夠彌補這些缺憾。
誰來負(fù)責(zé)架構(gòu)的設(shè)計？
在我們的印象中，總認(rèn)為架構(gòu)設(shè)計是那些所謂架構(gòu)設(shè)計師的專屬工作，他們往往擁有豐富的設(shè)計經(jīng)驗和相關(guān)的技能，他們不用編寫代碼，就能夠設(shè)計出理論上盡善盡美的架構(gòu)，配有精美的圖例。
問題1：理論上設(shè)計近乎完美的架構(gòu)缺乏程序的證明，在實際應(yīng)用中往往會出這樣那樣的問題。
問題2：設(shè)計師設(shè)計架構(gòu)帶有很大的主觀性，往往會忽視客戶的需求，導(dǎo)致架構(gòu)無法滿足需求。
問題3：實現(xiàn)的程序員對這種架構(gòu)有抵觸的情緒，或是因為不理解架構(gòu)而導(dǎo)致架構(gòu)實現(xiàn)的失敗。
問題4：架構(gòu)師設(shè)計架構(gòu)主要是依據(jù)自己的大量經(jīng)驗，設(shè)計出的架構(gòu)不能真實的反映目前的軟件需要。
解決辦法
團(tuán)隊設(shè)計的理論依據(jù)是群體決策。和個人決策相比，群體決策的大好處就是其結(jié)論要更加的完整。而群體決策雖然有其優(yōu)點，但其缺點也是很明顯的：需要額外付出溝通成本、決策效率低、責(zé)任不明確、等等。但是群體決策如果能夠組織得當(dāng)?shù)脑?，是能夠在架?gòu)設(shè)計中發(fā)揮很大的優(yōu)勢的。
避免象牙塔式的架構(gòu)設(shè)計
對軟件來說，架構(gòu)設(shè)計是一項至關(guān)重要的工作。這樣的工作交給某個人是非常危險的。即便這個人再怎么聰明，他也可能會遺漏部分的細(xì)節(jié)。組織有效的團(tuán)隊的力量是大大超過個人的力量的，因此團(tuán)隊的成果較之個人的成果，在穩(wěn)定性和思考的周密程度上，都要更勝一籌。
Scott W. Ambler在其著作中給出了象牙塔式架構(gòu)（ivory tower architecture）的概念：
An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).
中國現(xiàn)在的軟件開發(fā)行業(yè)中也逐漸出現(xiàn)了象牙塔式的架構(gòu)設(shè)計師。這些架構(gòu)師并不參與實際的程序編寫，他的工作就是為項目制作出精美的架構(gòu)模型，這種架構(gòu)模型在理論上是相當(dāng)完美的。
例1：在XP中，我們基本上看不到架構(gòu)設(shè)計的影子。并不是說采用XP技術(shù)的團(tuán)隊就不需要架構(gòu)設(shè)計。XP不存在專門的設(shè)計時期，它提倡使用一些簡單的圖例、比喻的方式來表達(dá)軟件的架構(gòu)，而這種的架構(gòu)設(shè)計是無時無刻不在進(jìn)行的。其實，XP中的設(shè)計采用的就是團(tuán)隊設(shè)計的方式，結(jié)隊編程（Pair Programming）和代碼的集體所有制（Collective Ownership）是團(tuán)隊設(shè)計的基礎(chǔ)，也就是基于口述的溝通方式。通過采用這樣的方式，XP幾乎不需要文檔來表達(dá)架構(gòu)的設(shè)計。
優(yōu)秀的架構(gòu)師能夠充分的利用現(xiàn)有框架，減少軟件的投入，增強(qiáng)軟件的穩(wěn)定性。這些都沒有錯，但是問題在于“過猶不及”。象牙塔式架構(gòu)師往往會出現(xiàn)文章開始指出的那些問題。架構(gòu)設(shè)計其實并不是非常復(fù)雜的工作，但它要求開發(fā)人員具備相關(guān)的技能、經(jīng)驗以及對問題域有一定的了解。開發(fā)人員往往都具有相關(guān)的技術(shù)技能（編程、數(shù)據(jù)庫設(shè)計、建模），而對問題域的理解可以從用戶和行業(yè)專家那里獲得幫助。因此，在理論上，我們要實現(xiàn)架構(gòu)設(shè)計的團(tuán)隊化是完全可能的。
在上面的象牙塔式架構(gòu)定義中，我們看到架構(gòu)師和日常的開發(fā)工作是隔絕的。這樣設(shè)計出的架構(gòu)有很大的局限性。在現(xiàn)實中，我們還會發(fā)現(xiàn)另外一種角色，他來自于開發(fā)團(tuán)隊外部，為開發(fā)人員提供相關(guān)的技術(shù)或業(yè)務(wù)的培訓(xùn)。這種角色稱為教練，在軟件開發(fā)中是非常重要的角色，不能夠和象牙塔式架構(gòu)設(shè)計師之間畫等號。
選擇你的設(shè)計團(tuán)隊
軟件的架構(gòu)在軟件的生命周期的全過程中都很重要，也就是說，軟件開發(fā)團(tuán)隊中的所有人員都需要和架構(gòu)打交道。因此，好的團(tuán)隊組織方式是所有開發(fā)人員都參與架構(gòu)的設(shè)計，我們稱這種方式為全員參與。全員參與的方式保證了所有開發(fā)人員都能夠?qū)軜?gòu)設(shè)計提出自己的見解，綜合多方面的意見，在全體開發(fā)人員中達(dá)成一致。這種方式尤其適合于一些小的團(tuán)隊。
還是會有很多的團(tuán)隊由于種種的原因不適合采用全員參與的方式。那么，組織優(yōu)秀的開發(fā)人員組成設(shè)計組也是比較好的方式。一般，我們選擇那些在項目中比較重要的，有較多開發(fā)經(jīng)驗，或是理論扎實的那些人來組成設(shè)計組。當(dāng)然，如果你考慮到為組織培養(yǎng)后續(xù)力量，你也可以讓一些新手加入設(shè)計組，或是你覺得自己的開發(fā)力量不足，邀請外部的咨詢力量介入，這完全取決于具體的情況。
設(shè)計組不同于我們之前提到的象牙塔式架構(gòu)設(shè)計師。設(shè)計組設(shè)計出來的架構(gòu)只能稱為原始架構(gòu)，它是需要不斷的反饋和改進(jìn)的。因此，在架構(gòu)實現(xiàn)中，設(shè)計組的成員將會分布到開發(fā)團(tuán)隊的各個領(lǐng)域，把架構(gòu)的思想帶給所有開發(fā)人員，編寫代碼來檢驗架構(gòu)，并獲得具體的反饋，然后所有的成員再集中到設(shè)計組中討論架構(gòu)的演進(jìn)。
團(tuán)隊設(shè)計中存在的問題
在團(tuán)隊設(shè)計的過程，我們會遇到各種各樣的問題，首當(dāng)其沖的就是溝通成本的問題。架構(gòu)設(shè)計時，需求尚未被充分理解，軟件的設(shè)計思路還處于萌發(fā)的狀態(tài)。這樣的情況下，團(tuán)隊的每位成員對軟件都有獨特的見解，這些可能有些是相同的，有些是互斥的。就好比盲人摸象一樣，他們的觀點都代表了軟件的一部分或是一方面，但是沒有辦法代表軟件的全部。
在敏捷方法論中，我們的每一個流程都是迅速進(jìn)行、不斷改進(jìn)的。架構(gòu)設(shè)計也是一樣，我們不可能在架構(gòu)設(shè)計上花費更多的時間。而團(tuán)隊決策總是傾向于較長的討論和權(quán)衡。
例2中的問題在架構(gòu)設(shè)計中時有發(fā)生，純技術(shù)的討論很容易上升稱為爭吵。這種情況幾乎沒有辦法完全避免。團(tuán)隊型的決策必然會發(fā)生觀念的沖突?？刂埔欢ǔ潭葍?nèi)的觀念的沖突對團(tuán)隊的決策是有益，但是如果超出了這個程度就意味著失控了，需要團(tuán)隊的調(diào)節(jié)。而更重要的，我們需要注意溝通的技巧。
團(tuán)隊溝通
團(tuán)隊進(jìn)行架構(gòu)設(shè)計的時候溝通是一個非常需要注意的問題，上述的情境在軟件組織中是經(jīng)常發(fā)生的，因為技術(shù)人員很自然認(rèn)為自己的技術(shù)比別人的好，如果自己的技術(shù)受到質(zhì)疑，那怕對方是抱著討論的態(tài)度，也無異于自身的權(quán)威受到了挑戰(zhàn)，面子是無論如何都需要捍衛(wèi)的。而溝通如果帶上了這樣一層主觀色彩，那么溝通信息的受眾就會潛意識的拒絕接受信息。相反，他會找出對方話語中的漏洞，準(zhǔn)備進(jìn)行反擊。因此，我們要注意培養(yǎng)一種良好的溝通氛圍。
在實際的觀察中，我發(fā)現(xiàn)團(tuán)隊溝通中存在兩種角色，一種是建議者，他們經(jīng)常能夠提出建議。一種是質(zhì)疑者，他們對建議提出否定性的看法。這兩種角色是可能互換的，現(xiàn)在的建議者可能就是剛才的質(zhì)疑者。質(zhì)疑者的發(fā)言是很能打擊建議者的積極性的，而在一個腦力激蕩的會議中，好是大家都能夠扮演建議者的角色，這就要求溝通會議的主持者能夠掌握好這一點，對建議給予肯定的評價，并鼓勵大家提出新的建議。