敏捷思維: 架構設計中的方法學(xué)(4)團隊設計  |
 | 級別: 初級 2002 年 3 月 01 日 團隊設計是敏捷方法論中很重要的一項實(shí)踐。我們這里說(shuō)的團隊，指的并不是復數的人。一群人就是一群人，并沒(méi)有辦法構成團隊。要想成為團隊，有很多的工作要做。 我們之所以考慮以團隊為單位來(lái)考慮架構設計，是因為軟件開(kāi)發(fā)本身就不是一件個(gè)人的事情，架構設計更是如此。單個(gè)人的思維不免有考慮欠妥之處，單個(gè)人的學(xué)識也不可能覆蓋所有的學(xué)科。而組織有效的團隊卻能夠彌補這些缺憾。
誰(shuí)來(lái)負責架構的設計？
在我們的印象中，總認為架構設計是那些所謂架構設計師的專(zhuān)屬工作，他們往往擁有豐富的設計經(jīng)驗和相關(guān)的技能，他們不用編寫(xiě)代碼，就能夠設計出理論上盡善盡美的架構，配有精美的圖例。 問(wèn)題1：理論上設計近乎完美的架構缺乏程序的證明，在實(shí)際應用中往往會(huì )出這樣那樣的問(wèn)題。 問(wèn)題2：設計師設計架構帶有很大的主觀(guān)性，往往會(huì )忽視客戶(hù)的需求，導致架構無(wú)法滿(mǎn)足需求。 問(wèn)題3：實(shí)現的程序員對這種架構有抵觸的情緒，或是因為不理解架構而導致架構實(shí)現的失敗。 問(wèn)題4：架構師設計架構主要是依據自己的大量經(jīng)驗，設計出的架構不能真實(shí)的反映目前的軟件需要。
團隊設計的理論依據是群體決策。和個(gè)人決策相比，群體決策的最大好處就是其結論要更加的完整。而群體決策雖然有其優(yōu)點(diǎn)，但其缺點(diǎn)也是很明顯的：需要額外付出溝通成本、決策效率低、責任不明確、等等。但是群體決策如果能夠組織得當的話(huà)，是能夠在架構設計中發(fā)揮很大的優(yōu)勢的。 避免象牙塔式的架構設計
對軟件來(lái)說(shuō)，架構設計是一項至關(guān)重要的工作。這樣的工作交給某個(gè)人是非常危險的。即便這個(gè)人再怎么聰明，他也可能會(huì )遺漏部分的細節。組織有效的團隊的力量是大大超過(guò)個(gè)人的力量的，因此團隊的成果較之個(gè)人的成果，在穩定性和思考的周密程度上，都要更勝一籌。 Scott W. Ambler在其著(zhù)作中給出了象牙塔式架構（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). 中國現在的軟件開(kāi)發(fā)行業(yè)中也逐漸出現了象牙塔式的架構設計師。這些架構師并不參與實(shí)際的程序編寫(xiě)，他的工作就是為項目制作出精美的架構模型，這種架構模型在理論上是相當完美的。 優(yōu)秀的架構師能夠充分的利用現有框架，減少軟件的投入，增強軟件的穩定性。這些都沒(méi)有錯，但是問(wèn)題在于“過(guò)猶不及”。象牙塔式架構師往往會(huì )出現文章開(kāi)始指出的那些問(wèn)題。架構設計其實(shí)并不是非常復雜的工作，但它要求開(kāi)發(fā)人員具備相關(guān)的技能、經(jīng)驗以及對問(wèn)題域有一定的了解。開(kāi)發(fā)人員往往都具有相關(guān)的技術(shù)技能（編程、數據庫設計、建模），而對問(wèn)題域的理解可以從用戶(hù)和行業(yè)專(zhuān)家那里獲得幫助。因此，在理論上，我們要實(shí)現架構設計的團隊化是完全可能的。 在上面的象牙塔式架構定義中，我們看到架構師和日常的開(kāi)發(fā)工作是隔絕的。這樣的設計出的架構有很大的局限性。在現實(shí)中，我們還會(huì )發(fā)現另外一種角色，他來(lái)自于開(kāi)發(fā)團隊外部，為開(kāi)發(fā)人員提供相關(guān)的技術(shù)或業(yè)務(wù)的培訓。這種角色稱(chēng)為教練，在軟件開(kāi)發(fā)中是非常重要的角色，不能夠和象牙塔式架構設計師之間畫(huà)等號。 選擇你的設計團隊。 軟件的架構在軟件的生命周期的全過(guò)程中都很重要，也就是說(shuō)，軟件開(kāi)發(fā)團隊中的所有人員都需要和架構打交道。因此，最好的團隊組織方式是所有開(kāi)發(fā)人員都參與架構的設計，我們稱(chēng)這種方式為全員參與。全員參與的方式保證了所有開(kāi)發(fā)人員都能夠對架構設計提出自己的見(jiàn)解，綜合多方面的意見(jiàn)，在全體開(kāi)發(fā)人員中達成一致。這種方式尤其適合于一些小的團隊。 還是會(huì )有很多的團隊由于種種的原因不適合采用全員參與的方式。那么，組織優(yōu)秀的開(kāi)發(fā)人員組成設計組也是比較好的方式。一般，我們選擇那些在項目中比較重要的，有較多開(kāi)發(fā)經(jīng)驗，或是理論扎實(shí)的那些人來(lái)組成設計組。當然，如果你考慮到為組織培養后續力量，你也可以讓一些新手加入設計組，或是你覺(jué)得自己的開(kāi)發(fā)力量不足，邀請外部的咨詢(xún)力量介入，這完全取決于具體的情況。 設計組不同于我們之前提到的象牙塔式架構設計師。設計組設計出來(lái)的架構只能稱(chēng)為原始架構，它是需要不斷的反饋和改進(jìn)的。因此，在架構實(shí)現中，設計組的成員將會(huì )分布到開(kāi)發(fā)團隊的各個(gè)領(lǐng)域，把架構的思想帶給所有開(kāi)發(fā)人員，編寫(xiě)代碼來(lái)檢驗架構，并獲得具體的反饋，然后所有的成員再集中到設計組中討論架構的演進(jìn)。 團隊設計中存在的問(wèn)題
在團隊設計的過(guò)程，我們會(huì )遇到各種各樣的問(wèn)題，首當其沖的就是溝通成本的問(wèn)題。架構設計時(shí)，需求尚未被充分理解，軟件的設計思路還處于萌發(fā)的狀態(tài)。這樣的情況下，團隊的每位成員對軟件都有獨特的見(jiàn)解，這些可能有些是相同的，有些是互斥的。就好比盲人摸象一樣，他們的觀(guān)點(diǎn)都代表了軟件的一部分或是一方面，但是沒(méi)有辦法代表軟件的全部。 在敏捷方法論中，我們的每一個(gè)流程都是迅速進(jìn)行、不斷改進(jìn)的。架構設計也是一樣，我們不可能在一次架構設計上花費更多的時(shí)間。而團隊決策總是傾向于較長(cháng)的討論和權衡。 例2中的問(wèn)題在架構設計中時(shí)有發(fā)生，純技術(shù)的討論很容易上升稱(chēng)為爭吵。這種情況幾乎沒(méi)有辦法完全避免。團隊型的決策必然會(huì )發(fā)生觀(guān)念的沖突?？刂埔欢ǔ潭葍鹊挠^(guān)念的沖突對團隊的決策是有益，但是如果超出了這個(gè)程度就意味著(zhù)失控了，需要團隊領(lǐng)導者的調節。而更重要的，我們需要注意溝通的技巧： 團隊溝通 團隊進(jìn)行架構設計的時(shí)候溝通是一個(gè)非常需要注意的問(wèn)題，上述的情境在軟件組織中是經(jīng)常發(fā)生的，因為技術(shù)人員很自然認為自己的技術(shù)比別人的好，如果自己的技術(shù)受到質(zhì)疑，那怕對方是抱著(zhù)討論的態(tài)度，也無(wú)異于自身的權威受到了挑戰，面子是無(wú)論如何都需要捍衛的。而溝通如果帶上了這樣一層主觀(guān)色彩，那么溝通信息的受眾就會(huì )潛意識的拒絕接受信息。相反，他會(huì )找出對方話(huà)語(yǔ)中的漏洞，準備進(jìn)行反擊。因此，我們要注意培養一種良好的溝通氛圍。 在實(shí)際的觀(guān)察中，我發(fā)現團隊溝通中存在兩種角色，一種是建議者，他們經(jīng)常能夠提出建議。一種是質(zhì)疑者，他們對建議提出否定性的看法。這兩種角色是可能互換的，現在的建議者可能就是剛才的質(zhì)疑者。質(zhì)疑者的發(fā)言是很能打擊建議者的積極性的，而在一個(gè)腦力激蕩的會(huì )議中，最好是大家都能夠扮演建議者的角色，這就要求溝通會(huì )議的主持者能夠掌握好這一點(diǎn)，對建議給予肯定的評價(jià)，并鼓勵大家提出新的建議。 良好的溝通有助于架構設計工作的開(kāi)展。一個(gè)成員的能力平平的團隊，可以藉由良好的溝通，設計出優(yōu)秀的架構，而一個(gè)擁有一個(gè)優(yōu)秀成員的團隊，如果缺乏溝通，最后可能連設計都出不來(lái)。這種例子現實(shí)中可以找到很多。 標準和風(fēng)格 我們總是在不知不覺(jué)之中使用各種各樣的標準和風(fēng)格。在團隊設計中，我們?yōu)榱颂岣邲Q策的效率，可以考慮使用統一的標準和風(fēng)格。統一的標準和風(fēng)格并不是一朝一夕形成的。因為每個(gè)人都有自己不同的習慣和經(jīng)歷，強制性的要求開(kāi)發(fā)人員使用統一的標準（風(fēng)格）容易引起開(kāi)發(fā)人員的不滿(mǎn)。因此在操作上需要注意技巧。對架構設計而言，比較重要的標準（風(fēng)格）包括以下的這些類(lèi)別：
在我的經(jīng)驗中，有一些組織平時(shí)并不注意標準（風(fēng)格）的積累，認為這種積累屬于雕蟲(chóng)小技，但正是這些小技，能夠非常有效的提高溝通的效率和降低開(kāi)發(fā)人員的學(xué)習曲線(xiàn)。試想一下，如果一個(gè)團隊中所有人寫(xiě)出的代碼都是不同標準和風(fēng)格的，那么理解起來(lái)肯定會(huì )困難許多。當然，我們沒(méi)有必要自己開(kāi)發(fā)一套標準（風(fēng)格）出來(lái)，現實(shí)中有很多可以直接借用的資料。最好的標準是UML語(yǔ)言，我們可以從UML的官方網(wǎng)站下載到最新的規范，常用的編碼標準更是隨處可見(jiàn)。不過(guò)雖然有了統一的標準，如果風(fēng)格不統一，同樣會(huì )造成溝通的障礙。例如下圖顯示的類(lèi)圖，雖然它們表示的是同一個(gè)類(lèi)，但是由于版型、可視性、詳細程度的差別，看起來(lái)又很大的差別。而在其它的標準中，這種差別也是普遍存在的。因此，我們在使用了統一的標準之后，還應該使用同樣的風(fēng)格。Scott W. Ambler專(zhuān)門(mén)成立了 一個(gè)網(wǎng)站討論UML的建模風(fēng)格的相關(guān)問(wèn)題，有興趣的讀者可以做額外的閱讀。 圖 4. 兩種風(fēng)格的類(lèi)圖  在統一的風(fēng)格的基礎上更進(jìn)一步的是使用術(shù)語(yǔ)。使用溝通雙方都了解專(zhuān)門(mén)的術(shù)語(yǔ)，可以代表大量的信息。最好的術(shù)語(yǔ)的范例就是設計模式的模式名。如果溝通的雙方都了解設計模式，那么一方只需要說(shuō)這部分的設計可以使用工廠(chǎng)模式，另一方就能夠理解，而不用再詳細的解釋設計的思路。這種的溝通方式是最高效的，但它所需要的學(xué)習曲線(xiàn)也會(huì )比較陡。 團隊設計的四明確 為了最大程度的提高團隊設計的高效性，可以從4個(gè)方面來(lái)考慮： 1、明確目標 泛泛的召開(kāi)架構討論會(huì )議是沒(méi)有什么意義的，一個(gè)沒(méi)有鮮明主題的會(huì )議也不會(huì )有什么結果。在源自需求的模式中，我們談到說(shuō)可以有非功能需求的架構，可以有功能需求的架構。因此，在進(jìn)行團隊設計之前，我們首先也需要確定，此次要解決什么問(wèn)題，是討論業(yè)務(wù)邏輯的架構，還是技術(shù)架構；是全局性的架構，還是各模塊的架構。 2、明確分工 我們之所以重視團隊，很重要的額一個(gè)原因就是不同的成員有不同的擅長(cháng)的區域。有些成員可能擅長(cháng)于業(yè)務(wù)邏輯的建模，有的擅長(cháng)于原型設計，有的擅長(cháng)于數據庫設計，有的則擅長(cháng)于Web編程。你能夠想象一個(gè)軟件沒(méi)有界面嗎？（有些軟件可能是這種情況）你能夠想象一個(gè)軟件只有數據庫，而沒(méi)有處理邏輯嗎？因此，架構設計就需要綜合的考慮各個(gè)方面，充分利用成員的優(yōu)勢。這就要求團隊的各個(gè)成員都能夠明確自己的分工。 3、明確責權 除了明確自己的分工，每位成員都需要清楚自己的責任。沒(méi)有責任，分工就不會(huì )有任何的效力。每位成員都需要明確自己要做些什么。當然，和責任相對的，沒(méi)有成員還需要知道自己的權力是什么。這些清楚了，進(jìn)行高效的溝通的前提就具備了。每次架構的討論下來(lái)，每個(gè)人都清楚，自己要做些什么，自己需要要求其他人做些什么，自己該對誰(shuí)負責。如果這些問(wèn)題回答不了，那這次的討論就白費了。 4、明確溝通方式 這里使用溝通方式可能有一點(diǎn)點(diǎn)不恰當，為了明確的表達意思，大家可以考慮信息流這個(gè)詞。一個(gè)完整架構包括幾個(gè)方面，分別都由那些人負責，如何產(chǎn)生，產(chǎn)生的整個(gè)過(guò)程應該是什么樣的？這樣的一個(gè)信息流程，囊括了上面提到的三個(gè)明確。如果團隊的每一個(gè)人都能夠為架構的產(chǎn)生而努力，并順利的設計出架構，那么這樣的流程是完美的。如果你發(fā)現其中的一些人不知道做些什么，那么，這就是流程出問(wèn)題的現象了。完美的流程還會(huì )有一個(gè)額外的副產(chǎn)品，架構產(chǎn)生之后，團隊對于軟件的設計已經(jīng)是非常的清晰了。因為我們提倡的是盡可能多的開(kāi)發(fā)人員參與架構的設計。 不僅僅是架構 討論到這里，其實(shí)有很多的內容已經(jīng)脫離了架構設計了。也就是說(shuō)，很多的原則和技巧都是可以用于軟件開(kāi)發(fā)的其它活動(dòng)的。至于哪一些活動(dòng)能夠利用這些方法呢？大家可以結合自己的實(shí)際情況，來(lái)思考這個(gè)問(wèn)題。提示一點(diǎn)，關(guān)鍵的入手處在于目前效率較低之處。 |
聯(lián)系客服
