那么，建立一支僅有通才的團隊會怎樣呢？每個人都對軟件開發有不錯的了解，但是都缺乏足夠詳細的必需知識，完成不了工作。項目需要那些對現階段使用的技術和技巧都非常熟悉的人。如果你是在使用Enterprise JavaBeans (EJB)，那你既需要對Java編程精通的人，也需要對EJB開發精通的人。一個使用Oracle的團隊，幕后肯定有一位Oracle數據庫管理專家。一個開發經紀人業務軟件的團隊，就需要一位能夠了解股票和債券之間的細微差別的人。
我的經驗是，兩種極端的方式都不可取，你應該取它們的中間點。一種方法是團隊中一部分人是通才，一部分人是專才。通才能夠起到團隊的連接劑的作用，通才注重遠景，專才注重項目的具體的難點。這樣做的好處是通才的長處能夠彌補專才的短處，反之也是一樣，由于這種平衡性，通才和專才組對能夠發揮出極大的優勢。一個更好的方法是團隊中主要是通才，僅有一兩個專才。例如，我認為我應該算是一個通才，我擅長于處理項目中各項技能之間的配合，而且還精通業務應用軟件建模，以及對象存儲和Java編程。我的另一位同事也是位通才，特別擅長建模，EJB開發，以及測試。還有一位堪稱通才的同事則精于網絡通信和Java編程。這樣一支由通才組成，但又有一項或多項特技的團隊，優勢是很明顯的，他們能夠迅速的找到共同點，因為他們畢竟都是通才，而且他們之間有能夠做到優勢互補。它的劣勢在于這種人才一般都比較稀缺，動輒都需花費10年甚至20年的時間才能夠培養出這種通才，因此是很難得到的。如果你的團隊中有一些這種人，那你的運氣真是太好了。 要認識到新手通常一開始都是專才，這很重要。軟件開發的新手面對著需要消化的大量知識，往往不知所措，這很正常。大多數人一開始一開始會把精力集中在開發的一兩個方面，也許是Java編程，也許是獲取用戶需求，然后以這方面的經驗為基礎，再逐漸的拓展知識的覆蓋面。隨著時間的增長，經驗在不斷的累積，他們會慢慢的完善自己的技能樹，他們會軟件開發中各個技能如何配合會更加了解，同時，他們還擅長于一兩門特技。
還有一點也很重要，要明白很多的開發人員的專精反而害了這些人。由于軟件開發的與身俱來的復雜性，開發人員經常會落入一個名為單一artifact開發者的陷阱中去，他們把自己定位為僅僅從事一種artifact的開發工作，例如代碼，用例模型，或數據模型；開發人員還可能遇到的一個陷阱名為單一角色開發者，他們的定位是專門從事一種工作的人，例如建模，測試，或編碼。換言之，這些人專精于某一個角色，這種傾向在一些的采用傳統過程的大型組織中特別顯著，問題就出現了，這些陷阱的落入者的視野往往過于狹窄，難以在一個采用敏捷方法的軟件開發項目中作到高生產率。當然，如果他們原意擴展自己的視野，這個問題就容易得到解決。
譯注：想必國內的程序員看到這篇文章會很開心吧。畢竟，中國的程序員向來都是以通才自封的。但是，要注意的一點是，這篇文章是針對國外的程序員的，因為國外的程序員通產都只關注于自己的領域，例如數據庫的專家對數據庫非常的熟悉，但他可能對測試一竅不通。但是他們對自己領域的了解是非常不得了的�？墒侵袊某绦騿T一般是萬金油，哪兒需要，哪兒就有我的豐姿。只要是軟件領域的，都無所不能，無所不精。但是人的精力都是有限的，不可能什么都精通。樣樣都精，也就是樣樣都庸。這個道理大家務必要了解。國內的很多程序員都算不上是通才，而只能算是庸才。這句話可能不好聽，但是事實如此。如果能夠意識到這一點，好，我想你已經不是庸才了，而是在往通才邁進的途中了。 本來是不打算譯這篇文章的，因為擔心有些人看完它后會斷章取義，反而成了一項罪過。但是這篇文章的很多思想值得借鑒，再加上為了保證譯作的完整性，最后還是把它譯了出來，并加上了一段廢話，提醒大家注意。最后，我真誠的希望中國的程序員都能夠成為作者在文中提到的那種既是通才，又是專才的人。
建模的誤區
走出一般性的設計誤區，邁向成功之途
英文原文版權由Scott W. Ambler擁有
Original text is copyrighted by Scott W. Ambler
譯者：高繼榮| 原文出處：www.AgileModeling.com
無論你遵從的是重量級的方法,比如Enterprise Unified Process(EUP)，還是輕量級的開發過程，如Extreme Programming(XP)，建模在軟件開發中都是不可或缺的。但不幸的是其中充斥著各種謬誤與迷思。這來自于各個方面，有從理論家錯誤的研究、數十年來信息技術領域內的文化沉積、軟件工具開發商天花亂墜半的市場宣傳以及象Object Management Group (OMG)和IEEE這類組織的標準。這個月，我要揭示建模中的誤區，指出其相應的事實真相。
誤區一：建模就等于是寫文檔
這很可能是其中最具破壞力的一條，因為開發人員可以此為借口而完全放棄建模。許多優秀的軟件開發人員會說他們不想把時間浪費在這些“無用的“文檔上。他們沉溺于編碼之中，制造著一些脆弱而劣質的系統。另外，甚至于許多盡責的開發人員現在也認為建模是一件討厭的事，而不愿去學習相應的建模技術。
事實分析：“模型”與“文檔”這二者在概念上是風馬牛不相及的—你可以擁有一個不是文檔的模型和不是模型的文檔。一幅設計圖就是一個模型，而不論是被畫在餐巾紙的背面，或寫在一塊白板上，或在Class Responsibility Collaboration(CRC)卡片中，還是根據記錄在報紙和便簽紙上的流程圖而生成的一個粗略的用戶界面原型。雖然這些都不能說是文檔，但他們卻都是有價值的模型。
建模很象是作計劃：作計劃的價值在于計劃編制的過程中，而非計劃本身；價值體現在建模的活動中，而非模型本身。實際上，模型不是你系統中的一部分正式的文檔，而且在完成它們的使命后可以被丟掉。你會發現值得保留的只有很少的模型，而且它一定是非常完美。
誤區二：從開始階段你可以考慮到所有的一切
這種說法流行于二十世紀七十年代到八十年代早期，現今的許多經理都是在那個時候學習的軟件開發。對這一點的迷信會導致在前期投入可觀的時間去對所有的一切建模以期把所有一切都弄正確，試圖在編碼開始前就“凍結”所有的需求（見誤區四），以致于患上“分析期麻痹癥” – 要等到模型非常完美之后才敢向前進�；谶@個觀點，項目組開發了大量的文檔，而不是他們真正想要得到的—開發滿足需要的軟件。
事實分析：怎么才能走出這個誤區呢？首先，你必須認識到你不能考慮到所有的細枝末節。第二，認識到編碼員可能會對建模者的工作不以為然（這是可能的，事實上建模者所作的工作在實際價值中只占很少的部分），他們或許會說模型沒有反應出真實的情況。第三，認識到不管你的最初所作的規格說明書有多好，但注定代碼會很快地與之失去同步，即便是你自己建模自己編碼。一個基本的道理就是代碼永遠只會和代碼保持一致。第四，認識到迭代法（小規模地建模，編一些代碼，做一些測試，可能還會做一個小的工作版本）是軟件開發的準則。它是現代重量級的軟件開發過程（如EUP），以及輕量級（如XP)的基本原理。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
