【IT168 技术文章】
个性通才还是专才?
敏捷建模者的个性
Alistair Cockburn指出：很多的方法学都定义了软件开发项目中开发人员所担任的角色，同时还定义个各个角色执行的任务，尽管入席，这些方法并没有定义这些角色最适合的人选。一个人要想成功的担任某个角色，他应当很好的适应它－－虽然这并不需要人们掌握所有的技能，但人们必须要慢慢的熟悉这些技术。我的经验告诉我，要成为一个成功的敏捷建模者，下面的列出的个性是必要的：
团队竞赛 第一点，也是最重要的一点，敏捷建模者总是积极的寻求协作，因为他们意识到他们不是万事通，他们需要不同的观点，这样才能做到最好。软件开发可不是游泳，单干是非常危险的。在敏捷的字典中没有“我”这个词。
畅所欲言 敏捷建模者都有良好的沟通技巧－－他们能够表达出他们想法，能够倾听，能够主动获取反馈，并且能够把需要的写出来。
脚踏实地敏捷建模者应当脚踏实地。他们的精力都集中在满足用户的需求上，他们不会在模型上画蛇添足，即便那双足是多么的好看。他们满足于提供可能的方案中最简单的一种，当然，前提是要能够完成工作。
好奇 敏捷建模者乐衷于研究问题，解决问题。
凡是都问个为什么 敏捷建模者看问题从不会至于表面，而是会打破沙锅问到底。他们从不会就想当然的认为一个产品或一项技术和它们的广告上说的那样，他们会自己试一试。
实事求是 敏捷建模者都非常的谦逊，他们从不认为自己是个万事通，所以他们会在建立好模型之后，用代码来小心的证明模型的正确。
勇气 敏捷建模者应当愿意去计划一个想法，然后做出模型，再想办法用代码来验证。如果结果不理想，他们就会返工，检查他们的方法，或是放弃原先的想法。把你的想法告诉你的同伴，再来验证它的正确，这是需要很大的勇气的。
根据实验 敏捷建模者应当愿意尝试新的方法，例如一项新的（或是已有的）建模技术。一般而言，他们也会接受敏捷建模开发技术，必要时，为了验证想法，他们愿意同传统的思想做斗争，例如在一个项目中减少文档数量。
有纪律 要坚持不懈的遵循敏捷建模的实践。对你来说，你可能会在不经意间说，“加上这个功能吧，无伤大雅。”或是，“我比project stakeholder更了解。”在AM的道路上要想不偏离方向，是需要一定的纪律性的。
如果你不具有上面列出的所有个性，那该怎么办呢，你是不是还想成为一个敏捷建模者呢？不用担心，你只需要少量的努力就能够胜任。相信我，我也没有办法做到100%的脚踏实地和实事求是，我也经常遇到沟通问题。没有人能够拥有所有的个性，大部分人都只能拥有一些个性。每个人都有不同点，这些不同点正是敏捷团队力量的源泉。某些人可能生来就好奇，另一些人的工作积极性可能比较强。人无完人嘛。
通才还是专才?
当你要增加团队成员时，所要处理的一个至关重要的问题是你希望保持的通才和专才的比率。要回答这个问题，你需要考虑现代软件开发环境。图1是企业统一过程（Enterprise Unified Process EUP） 的生命周期。（译注：原文中并没有提供这副图，根据我的猜测，应该就是RUP的概述部分的那张生命周期图，但是因为没有取得瑞理公司的授权，所以我暂时也不便引用这张图，大家可以参阅RUP的相关资料。）图左边的EUP的工作流程暗示着软件开发的复杂－－你需要进行业务建模，收集需求，分析和设计系统等等－－而这还只是冰山一角。就像图中列出的那样，从先启到产品化的各个阶段，预示着在项目的过程中，不同的时间需要你集中于不同的地方，这需要不同的技能。有一个观点是很明确的，软件开发非常的复杂，任何一项工作都需要高超的技能和丰富的经验。首要的，要认识到这种复杂性是软件开发与身俱来的，而不是EUP使然的，即便你的团队采用的是XP方法，抑或是DSDM（Stapleton, 1997）方法，或是SCRUM （Beedle & Schwaber, 2001）方法，这种复杂性也还是存在的。尽管这些方法的生命周期看上去并不像EUP那样的复杂，但它们仍然需要配置管理活动，需要管理活动等等，只是它们处理问题的态度不同而已。
很多的组织对此的第一反应就是建立一个专才的团队。专才的最基本的含义是指那些特别精通某一项任务的人，因此他们的效率也特别的高。这样一支团队，要想高效率的运作，你需要组合这些专才，让每人负责一块任务，解决之后就把手头的工作传给另一个人。这个概念就类似于“流水线”的想法，如果你是在大量的生产汽车，这种方式会非常的有效，但是以我的经验，在手工的软件中采用这种方式并不是太合适。而且，这种方式需要一个大团队的支持－－如果软件开发中有N中不同的任务，你至少就需要N位专才才能满足这种方法的要求。但N是多大？20？50？100？这取决于你对专业定义的细节程度，是吧？如果你倾向于每位开发人员只处理一种artifact，那单单处理建模工作，就需要20多位的专才，在modeling artifacts essay列出了各种的artifact。如果你倾向于每位开发人员只负责一种角色，那再一个EUP的项目中也需要11中角色才能完成所有的工作流程。专才通常都很难同人合作，他们缺少谦逊的品质，意识不到其它人的专项技能能够为他的工作增添价值，他们也意识不到他们的所作所为可能为给后续的工作造成麻烦，也许他们需要返工，也许他们现在的努力会白费。关于专才的另一个问题是，即使是在他们擅长的领域，他们的技能也可能根本就没有那么精熟。IT产业的技术高变动率，导致了开发人员使用了几个月的新技术，开始熟悉它，就声称自己已经是这方面的专家了，因为和他具有同样层次经验的人毕竟不多。要建立一个专才组成的团队，这也是一个很明显的问题。
那么，建立一支仅有通才的团队会怎样呢？每个人都对软件开发有不错的了解，但是都缺乏足够详细的必需知识，完成不了工作。项目需要那些对现阶段使用的技术和技巧都非常熟悉的人。如果你是在使用Enterprise JavaBeans (EJB)，那你既需要对Java编程精通的人，也需要对EJB开发精通的人。一个使用Oracle的团队，幕后肯定有一位Oracle数据库管理专家。一个开发经纪人业务软件的团队，就需要一位能够了解股票和债券之间的细微差别的人。
我的经验是，两种极端的方式都不可取，你应该取它们的中间点。一种方法是团队中一部分人是通才，一部分人是专才。通才能够起到团队的连接剂的作用，通才注重远景，专才注重项目的具体的难点。这样做的好处是通才的长处能够弥补专才的短处，反之也是一样，由于这种平衡性，通才和专才组对能够发挥出极大的优势。一个更好的方法是团队中主要是通才，仅有一两个专才。例如，我认为我应该算是一个通才，我擅长于处理项目中各项技能之间的配合，而且还精通业务应用软件建模，以及对象存储和Java编程。我的另一位同事也是位通才，特别擅长建模，EJB开发，以及测试。还有一位堪称通才的同事则精于网络通信和Java编程。这样一支由通才组成，但又有一项或多项特技的团队，优势是很明显的，他们能够迅速的找到共同点，因为他们毕竟都是通才，而且他们之间有能够做到优势互补。它的劣势在于这种人才一般都比较稀缺，动辄都需花费10年甚至20年的时间才能够培养出这种通才，因此是很难得到的。如果你的团队中有一些这种人，那你的运气真是太好了。 要认识到新手通常一开始都是专才，这很重要。软件开发的新手面对着需要消化的大量知识，往往不知所措，这很正常。大多数人一开始一开始会把精力集中在开发的一两个方面，也许是Java编程，也许是获取用户需求，然后以这方面的经验为基础，再逐渐的拓展知识的覆盖面。随着时间的增长，经验在不断的累积，他们会慢慢的完善自己的技能树，他们会软件开发中各个技能如何配合会更加了解，同时，他们还擅长于一两门特技。
还有一点也很重要，要明白很多的开发人员的专精反而害了这些人。由于软件开发的与身俱来的复杂性，开发人员经常会落入一个名为单一artifact开发者的陷阱中去，他们把自己定位为仅仅从事一种artifact的开发工作，例如代码，用例模型，或数据模型；开发人员还可能遇到的一个陷阱名为单一角色开发者，他们的定位是专门从事一种工作的人，例如建模，测试，或编码。换言之，这些人专精于某一个角色，这种倾向在一些的采用传统过程的大型组织中特别显著，问题就出现了，这些陷阱的落入者的视野往往过于狭窄，难以在一个采用敏捷方法的软件开发项目中作到高生产率。当然，如果他们原意扩展自己的视野，这个问题就容易得到解决。
译注：想必国内的程序员看到这篇文章会很开心吧。毕竟，中国的程序员向来都是以通才自封的。但是，要注意的一点是，这篇文章是针对国外的程序员的，因为国外的程序员通产都只关注于自己的领域，例如数据库的专家对数据库非常的熟悉，但他可能对测试一窍不通。但是他们对自己领域的了解是非常不得了的。可是中国的程序员一般是万金油，哪儿需要，哪儿就有我的丰姿。只要是软件领域的，都无所不能，无所不精。但是人的精力都是有限的，不可能什么都精通。样样都精，也就是样样都庸。这个道理大家务必要了解。国内的很多程序员都算不上是通才，而只能算是庸才。这句话可能不好听，但是事实如此。如果能够意识到这一点，好，我想你已经不是庸才了，而是在往通才迈进的途中了。 本来是不打算译这篇文章的，因为担心有些人看完它后会断章取义，反而成了一项罪过。但是这篇文章的很多思想值得借鉴，再加上为了保证译作的完整性，最后还是把它译了出来，并加上了一段废话，提醒大家注意。最后，我真诚的希望中国的程序员都能够成为作者在文中提到的那种既是通才，又是专才的人。
