那么，建立一支仅有通才的团队会怎样呢？每个人都对软件开发有不错的了解，但是都缺乏足够详细的必需知识，完成不了工作。项目需要那些对现阶段使用的技术和技巧都非常熟悉的人。如果你是在使用Enterprise JavaBeans (EJB)，那你既需要对Java编程精通的人，也需要对EJB开发精通的人。一个使用Oracle的团队，幕后肯定有一位Oracle数据库管理专家。一个开发经纪人业务软件的团队，就需要一位能够了解股票和债券之间的细微差别的人。
我的经验是，两种极端的方式都不可取，你应该取它们的中间点。一种方法是团队中一部分人是通才，一部分人是专才。通才能够起到团队的连接剂的作用，通才注重远景，专才注重项目的具体的难点。这样做的好处是通才的长处能够弥补专才的短处，反之也是一样，由于这种平衡性，通才和专才组对能够发挥出极大的优势。一个更好的方法是团队中主要是通才，仅有一两个专才。例如，我认为我应该算是一个通才，我擅长于处理项目中各项技能之间的配合，而且还精通业务应用软件建模，以及对象存储和Java编程。我的另一位同事也是位通才，特别擅长建模，EJB开发，以及测试。还有一位堪称通才的同事则精于网络通信和Java编程。这样一支由通才组成，但又有一项或多项特技的团队，优势是很明显的，他们能够迅速的找到共同点，因为他们毕竟都是通才，而且他们之间有能够做到优势互补。它的劣势在于这种人才一般都比较稀缺，动辄都需花费10年甚至20年的时间才能够培养出这种通才，因此是很难得到的。如果你的团队中有一些这种人，那你的运气真是太好了。 要认识到新手通常一开始都是专才，这很重要。软件开发的新手面对着需要消化的大量知识，往往不知所措，这很正常。大多数人一开始一开始会把精力集中在开发的一两个方面，也许是Java编程，也许是获取用户需求，然后以这方面的经验为基础，再逐渐的拓展知识的覆盖面。随着时间的增长，经验在不断的累积，他们会慢慢的完善自己的技能树，他们会软件开发中各个技能如何配合会更加了解，同时，他们还擅长于一两门特技。
还有一点也很重要，要明白很多的开发人员的专精反而害了这些人。由于软件开发的与身俱来的复杂性，开发人员经常会落入一个名为单一artifact开发者的陷阱中去，他们把自己定位为仅仅从事一种artifact的开发工作，例如代码，用例模型，或数据模型；开发人员还可能遇到的一个陷阱名为单一角色开发者，他们的定位是专门从事一种工作的人，例如建模，测试，或编码。换言之，这些人专精于某一个角色，这种倾向在一些的采用传统过程的大型组织中特别显著，问题就出现了，这些陷阱的落入者的视野往往过于狭窄，难以在一个采用敏捷方法的软件开发项目中作到高生产率。当然，如果他们原意扩展自己的视野，这个问题就容易得到解决。
译注：想必国内的程序员看到这篇文章会很开心吧。毕竟，中国的程序员向来都是以通才自封的。但是，要注意的一点是，这篇文章是针对国外的程序员的，因为国外的程序员通产都只关注于自己的领域，例如数据库的专家对数据库非常的熟悉，但他可能对测试一窍不通。但是他们对自己领域的了解是非常不得了的。可是中国的程序员一般是万金油，哪儿需要，哪儿就有我的丰姿。只要是软件领域的，都无所不能，无所不精。但是人的精力都是有限的，不可能什么都精通。样样都精，也就是样样都庸。这个道理大家务必要了解。国内的很多程序员都算不上是通才，而只能算是庸才。这句话可能不好听，但是事实如此。如果能够意识到这一点，好，我想你已经不是庸才了，而是在往通才迈进的途中了。 本来是不打算译这篇文章的，因为担心有些人看完它后会断章取义，反而成了一项罪过。但是这篇文章的很多思想值得借鉴，再加上为了保证译作的完整性，最后还是把它译了出来，并加上了一段废话，提醒大家注意。最后，我真诚的希望中国的程序员都能够成为作者在文中提到的那种既是通才，又是专才的人。
建模的误区
走出一般性的设计误区，迈向成功之途
英文原文版权由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)的基本原理。
文章来源于领测软件测试网 https://www.ltesting.net/
