[
采用迭代式、递增式的开发方式。做为AM的两项实践，有效的沟通（communication）和反馈（feedback）要求软件开发采用迭代和渐增的方法。
需求不确定或不稳定。Martin Fowler在他的新方法学中指出，如果你的项目就像是自然探险（大多数项目都如此），那最佳的选择就是采用敏捷方法来开发软件。当需求不明或易变时，你就应该采用一种能够适应这种情况的开发方式。AM拥抱变化，它采用递增的开发方式，寻求快速的反馈，并且一贯坚持Project Stakeholder的积极参与，这就是AM对付需求变化的法子。使用AM，你就能够迅速而有效地发觉客户的需求。
开发软件是你的主要目标。这是AM的核心原则之一，但对很多项目来说，这并不是他们的目标。例如，有时候一个项目团队的主要目标是从客户那里圈钱（在外部采购中时有发生），或是简单的制定系统规范，因为系统要交付给另一个团队去实现。更糟的是，一些项目仅仅是出于政治上的考虑，它的目的就是让别人感到他们正在做这件事，至于要做出来什么东西却根本没有考虑。软件开发的目标应该是生产出满足客户需求的有效的软件系统－如果你的目标不是这样，AM就不适合你。
你需要有stakeholder的积极支持和参与。Fowler同样认为，敏捷软件开发工作要想成功，需要有project stakeholder的积极支持和参与。Project Stakeholder是那些受软件项目的开发和/或部署潜在的影响的人。包括直接用户，非直接用户，经理，高级经理，操作人员，支持人员，测试者，和这个系统有关（整合或交互）的其它系统的开发人员，以及维护人员。AM要想成功，你需要了解你的Project Stakeholder是谁，你还要能够和Stakeholder保持日常的接触，Stakeholder能够及时的为你提供信息、做出决策。此外，还应该要有管理层的大力支持。
开发团队能够自我决策。敏捷软件开发，特别是敏捷建模，对大多数的组织来讲都是新生事物。接受敏捷方法对大多数的组织来讲都是一件很难的事，因为它对大多数人来说都是一种新的工作方式。想要成功，我的经验是，不管成功还是失败，要根据项目团队的优点，给他们机会。鼓励他们尝试新技术，给他们资源（包括时间），让他们开始学习。应该尽量杜绝玩弄权术的现象，这就意味着组织中的管理层和一些部门要改掉原来的做法。
要有真正的AM斗士。不论何时，接受新的事物总会面临着挑战。人们不愿意改变，他们喜欢、他们也习惯了以前那种繁琐的慢节奏的工作方式。他们和你看事情的角度不同，你希望引入敏捷方法来解决问题，而他们不认为那是问题。也许他们会改进自己喜爱的开发方法，但这些方法和AM格格不入。也许，AM威胁到他们在组织内的权力分配。即使不考虑这些情况，也还是会有人抗拒变化。要想成功的改变，必须要有真正的AM斗士。他们支持AM，为AM奋斗，他们愿意去收集Project Stakeholder的支持，他们愿意进行AM思想的宣传和培育，让AM能够在组织内生根发芽。改变需要时间，这些斗士就是在争取时间。
你需要负责、主动的开发人员。Fowler指出敏捷软件开发强调开发人员的纪律性，要求开发人员能够协同工作，开发高质量的软件。这意味着你需要一个健康的团队环境，人们能够相互信任，相互帮助，共同迈向成功。和那些敏捷开发方法的诋毁者告诉你的完全相反，你需要的人并不是一个个都要求能上天入地。根据我的经验，你的要求很简单：愿意完成工作，有合作精神，能够有效工作。
你需要有足够的资源。你现在知道了敏捷建模需要人们的紧密合作。就是说你需要“协同开发的空间”，例如能够使人专注于工作的建模室，一堵能够演示模型的公用墙，最好还能给每对开发人员配置一台共享工作站。除此之外，你还需要有足够的建模工具，例如白板、索引卡片、标记、和其它必须的CASE工具。我就曾经看过由于基本资源（像样的椅子，桌子，食物，饮料，和高端工作站）的缺乏，使软件开发工作的进展受到阻碍。如果你的项目团队因为这些锱铢之事导致失败，那我倒是想问问你这项目对你的组织是不是真的那么重要。如果不是，那就cancel它，把你的精力投入到其它更有价值的项目中去吧。
但这不是我的情况....
那么，当其上的一个或某些条件和你目前的情况有出入的时候，你该怎么办？试着去改变你目前的情况。缺乏AM的拥护者吗？那你自己就可以成为一个拥护者。不允许以迭代式和递增的方式工作，和你的老板们谈谈，让他们相信这是一种更好的工作方式，要求他们给你一个机会去证明。没有足够的资源？和你的头儿说明它们的重要性。如果你已经尽力改变了所有的情况，但是仍然还有一些条件是你无能为力的，你可以试试以下的选择：
部分的接受AM。你可以尽可能多的接受AM中的原则和实践，虽然你不会真正的实现AM，但你极有可能成为高效率的开发人员。一旦你的组织发现这确不失为一个软件开发的好方法，那就有可能会主动的去改变一些必需的要素，从而完全的接受AM。一言以蔽之，循序渐进的实现AM。
放弃让你的组织接受AM。从我个人的角度，我并不喜欢这种选择，但我不得不承认它是个正确的办法。现实就是这样，AM并不是适合每一个人的，也许你的组织确实是不适合接受AM的。
跳槽。看看外面的世界，还是有很多的组织期望能够从软件开发的竞赛中获胜，他们希望能有积极主动的软件开发人员加盟。
何时敏捷建模是不适合你的?
我猜想敏捷建模在遭遇如下的情形的时候你会陷入麻烦：
不满足以上列出的一个或多个条件。
你的组织文化适合采用传统的开发流程。许多组织对采用敏捷的软件开发方法毫无兴趣，他们对目前的状况感觉很好。这主要是那些政府部门、大型的公司（银行、保险公司、电信公司）以及专门为这些组织服务的咨询公司。这并不是说在这类组织中实施AM完全不可能，但要获得成功则要付出超乎寻常的努力才行。
你的团队很大，分布在各地。只有那些在同一个工作区域中相互协作的团队才能很好的进行敏捷建模的工作，特别是当开发人员在一个公共的工作室内合作的时候（通常我们称之为“tiger team”房间）。你可以尝试着在一个大型或分散的团队中应用敏捷方法，我在架构建模中讨论了这种情形，但你很快会发现你需要挑战这种方式带来的沟通问题。
我不同意将敏捷方法应用于性命攸关的系统上，例如航空管制系统或医疗监测系统，因为我并没有相关的项目经验，无法去研究AM应该怎样应用于这些系统。同样，我也没有嵌入式系统的相关经验，因此我也没有机会将AM技术应用于这种类型的项目。我很怀疑AM是否能够试用于嵌入式软件开发，这是我研究的一部分。我很期待你在敏捷建模的邮件列表中告诉我相关的经验。（详情请访问http://www.agilemodeling.com/feedback.htm）
AM的实践是如何组合的
AM的实践之间是相互促进的，因为他们彼此支持，彼此激发。为了使AM更有效率的工作，你需要了解它的实践是如何组合的。图1显示了AM的实践之间的关系，它们被分为七类。AM的核心实践集中在头四种类别中－验证，迭代和递增，团队协作，和简单，你需要完全接受它们才能真正理解敏捷建模。然后，才轮到属于辅助实践的文档，动机，生产率这三个类别。我们先针对核心实践的四个类别，讨论各类中的实践之间的关系，然后我们再针对辅助实践的三个类别，研究各类中实践之间的关系，最后我们来讨论类别之间的关系。
图1. AM的实践是如何组合的。
核心实践
在团队协作类别中有四项实践－－stakeholder的积极参与，和他人一起建模，公开展示模型，和集体所有制。stakeholder的积极参与对你的成功至关重要，因为你正是为了这些project stakeholder开发系统，正是为了了解和实现他们的需求。换言之，你需要和你的甲方们密切合作，这就自然的想到了和他人一起建模－－这个“他人”也包括你的stakeholder。当你的建模工作有多人参加时（至少一个project stakeholder和一个除你之外的开发人员），你就需要和众人共同协作，相互促进，取长补短。一个擅长于业务过程建模和业务规则定义的敏捷建模者看不到的方面，一个精通结构化建模技术（例如UML类图或数据模型）的人极有可能看得到。一样的道理，系统的直接用户给你的团队提供的信息极可能是高级经理提供不了的。所以，要有这样的观点：你要在项目甲方和开发团队中营造一种积极参与的氛围，只有这样，才能够收集各种不同的观点和经验。集体所有制能够提升协作性，因为一个人单独的进行建模的工作，他很快就会遇到瓶颈，而如果每个人都能够为建模工作献计献策，那么你们就能够成为一个团队，轻易的解决问题。公开展示模型能够使得人们对模型“瞻前顾后”变得容易了，能够立刻考虑模型传达的信息，从而提高团队的协作性。当然，我们是假设模型都在众人的视线之内，或者这些模型都是大家目前正在开发或相关的。这方面的主题我在Organizing an Agile Modeling Room中有详细的讨论。
迭代和递增类别中包括了使用合适的artifact，并行创建模型，切换到另外的artifact，小增量建模这几项实践。不论哪一个artifact，都有它的长处和短处，任何一个单独的模型都不足以充分的描述你的项目的各个主要方面（如需求、架构）。例如你会发现你为了识别系统的需求，常常需要组合使用用例、业务规则定义、和技术需求定义。单单靠用例就能令project stakeholder立马告诉你他们所有的使用需求吗？这恐怕不太可能。你可以试试换用诸如业务规则之类的artifact来捕获他们的所有业务政策，再换用诸如技术需求的artifact来捕获他们的非功能需求。否则，他们会想起点什么就告诉你什么，还会返回去讨论先前提过的细节，甚至是改变他们的原来的主意。你的需求识别工作通常是一个动态的过程，分析、架构、设计工作也是一样。 我相信物力论中指出了人们以此种方式思考的原因，我们思考的方式明显是杂乱的。敏捷建模者要认识到人们是以一种动态的方式在思考，特别是人们处于群体行为时，这样才能制定对策。敏捷建模者并行创建模型，从而能够最广泛的收集信息。这项实践又是由实践切换到另外的artifact和小增量建模来支持的－－你可能正在使用用例来捕获使用需求的相关信息，而当stakeholder开始讨论他们对编辑屏幕的要求时，你最好是使用基本用户界面原型或是传统用户界面原型来记录这些需求。你需要在不同的artifact之间来来回回，每一个artifact最好都需要编码来验证，这种方式可以由小增量建模的实践来实现－－最典型的方式就是在这个artifact上做一会儿工作，再换一个artifact，依此类推。
简单这个类别包括了创建简单的内容，简单地建模，使用最简单的工具这几项核心实践。创建简单的内容和简单地建模这两个实践集中于模型的简单性，在建模过程中这两项实践通产是密不可分的。把精力集中在如何简单描述，建模者常常会发现一些使得你手头的模型简单化的方法。举个例子，我曾经参加了一项存储层软件的开发工作，软件的概念类似于EJB的persistence container，封装了领域对象的一些存储操作。结果我们架构和设计非常的复杂，我们试着找到一种办法：建立一张简单的图表，帮助开发人员理解如何使用存储层来工作。其间我们还发现重构能够使我们的设计易于理解。实践使用最简单的工具能够使得过程变得简单。工具越简单就越容易使用，这就降低了他人在你的模型上工作的门槛，也就增加了实际中别人去这么做的机会，这也包括了你的project stakeholder。通过使用最简单的工具，简单描述模型也变得更自然了。此外，当你使用一些简单/低精度的工具，例如索引卡片，即时贴，白板的时候，你就能亲身体验这些简单工具的效力，你在不知不觉中已经强化了一些概念：最简单的解决方法实际上也能非常有效，对你正在开发的系统采用简单的设计。
验证类别包含了两个核心实践：测试性思维和用代码验证。有一条哲学，我常从中受益：“如果你无法测试它，你就不应该建立它，而你建立的一切都应该加以测试。”这使得我在系统建模时就考虑测试，也使得我积极的去获取我的模型的反馈－－实际上，我把该条哲学归纳为“考虑你创建的所有artifact的可测试性，以及验证所有种类的artifact。”但这并不仅仅局限于AM的范围之内。通过这种可测试性的考虑，在我建模时，我能够建立起可测试的模型，而且积极的通过编码来验证模型，这样，我就能够尽快的证实我的模型是真正可以测试的。
辅助实践
文档类别包括了三项辅助实践：丢弃临时模型，合同模型要正式，非到万不得已不更新。在项目的进行中，需求、对需求的理解、以及对可能的解决方案的理解，都在不断变化（回忆一下原则拥抱变化）。为了反映这种变化，你需要同步改进你大部分的项目artifact，包括模型和文档。就像在敏捷文档讨论的那样，比较好的方法是，不到万不得已不要更新你的模型和文档，这种做法才算是敏捷方法。遵循这项实践，如果你发现一个模型如果不再需要更新，那就是说这个模型对你的团队已经没什么价值了，一个没有价值的模型就可以视为临时模型，可以丢弃。不过，要注意合同模型。它定义了你的系统和其他系统之间的接口，不太可能经常改变，因为它们的重要性是勿庸置疑的。一言以蔽之，如果你有个非合同模型不再更新，那就意味着它已经没有用了。
为沟通建模和为理解建模这两项实践属于动机类别。实际上，这两项实践并没有太多的联系，有时候你创建模型的目的是为了研究和理解问题，有时候你的目的是为了和其他人交流你的想法，有时候你的目的包括了上述两者。就像你在图1中看到的，这两项实践常常会一起引出另两类的实践，这是下文要讨论的主题。
最后，生产率类别中包括使用建模标准，逐渐应用模式，以及重用现有的资源这几项实践。重用现有资源这个实践要求你尽量利用他人的工作成果并从中受益，这有很多种思考方向：一种是应用模式，根据经验，我认为它是所有重用方法中最有效率的一种，因为你重用的都是其它开发人员久经验证的解决方案 (Ambler, 1999)；另一种是遵循建模标准和指南，实际上，不论是标准还是指南，都能够提高你工作的一致性。是的，你可以自己写指南，有时你必须要这么做，因为你的实际环境中会有一些特别的情况。但是你只需要在Internet上稍做搜索就可以找到很多的开发指南。例如，你可javaCodingStandards找到Java的开发指南。
类别间的联系
让我们考虑团队协作类别。简单类别中的实践增强了实践stakeholder的积极参与的效果，因为简单性消除了参与的代沟。迭代和递增类别中的实践也使得参与成为可能，尤其是并行创建模型，因为它增大了stakeholder们参加的机会。动机类别中的实践可以提高集体所有制和和他人一起建模的效果，对问题的理解和沟通通常可以激发人们的协作精神，简单类别的实践也也坑达到激发协作效果，因为它降低了参与的门槛。公开展示模型的效果可以通过生产力类别中的实践得到提高。遵循标准，应用模式的做法可以增加一致性和可读性，而重用现有的资源（例如通用架构），则给别人开了一个好头，使别人能够在你模型的基础上继续。迭代和递增类的实践可以支持集体所有制的实行，特别是并行创建模型和切换到另外的artifact，它们使得人们在适当的模型上共同开发。
简单类别的实践由另外几类的实践来辅助。使用建模标准和逐渐应用模式这两项实践支持同一种建模语言（使用标准和容易理解的模式），从而支持了实践简单地建模。文档类别的实践也可以支持简单类别的实践－－只有到万不得已才更新模型，这样，你才不会给模型增加不必要的信息。才有可能创建简单的内容以及简单地建模。
现在再来看迭代和递增类别。很明显，团队协作类别的实践支持该类的实践，由于团队的参与，针对目前的情况选用正确artifact的机会就增大了，你就可以根据需要来切换使用不同的artifact。验证类实践能够赋予你使用递增方法的勇气，特别是在你用代码验证的时候。保证你想法的易测性，你就更有把握同时操作多个artifact，并在它们之间切换，因为测试问题要求你从多个方面来看待它。文档类实践同样可以促进递增方法，特别是非到万不得已不更新。但是合同模型要正式这个实践抑止了递增方法的应用，因为你总是希望能够尽早的建立和其他系统间的接口标准。切换到另外的artifact和丢弃临时模型之间也能产生正面的效果，因为一个模型完成目的之后就把工作切换到另一个模型上去。简单类实践对这个类别也很重要，通过使用最简单的工具，你在不同的artifact间来回切换就变得更容易了，你节省了熟悉工具的时间，只把精力集中在简单的内容和描述上，你也可以较容易记住模型要传达的信息。最后，动机类实践可以令你同时进行多个建模工作，因为对于复杂的系统，你需要从多个方面去沟通，去理解，因此你需要在适当的artifact间来回切换，这样才能有效的做到这一点。
验证类实践可由简单类实践来支持－－创建简单的内容和简单地建模能使你更容易进行测试性思维。迭代和渐增类实践也能提高验证类实践。例如，在你切换到另外的Artifact时，就可能切换到源代码，这样你就可以看到模型确实可以运行。
简单类实践可以推进生产力类实践。当你使用简单模型工作时，逐渐应用模式就更容易一些；当你简单地建模时，使用建模标准也会容易一些，而模型的简单、易懂，也会使你比较容易的重用现有的资源，例如企业需求模型或通用的架构模型。
简单类实践以及迭代和渐增类实践可以支持文档类实践的进行。文档越简单就越容易使用－－如果你的文档容易理解，这样你就有把握万不得已才更新你的文档，因为你知道做到这一点很简单；文档如果很复杂，你的项目风险就很大，因为没有把握什么时候文档需要更新。很明显，非到万不得已不更新和丢弃临时模型的运作环境可以其它的实践来改善，例如切换到另外的artifact、小增量建模。
那，你想成为一个敏捷建模者吗?
个性通才还是专才?
敏捷建模者的个性
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的开发工作，例如代码，用例模型，或数据模型；开发人员还可能遇到的一个陷阱名为单一角色开发者，他们的定位是专门从事一种工作的人，例如建模，测试，或编码。换言之，这些人专精于某一个角色，这种倾向在一些的采用传统过程的大型组织中特别显著，问题就出现了，这些陷阱的落入者的视野往往过于狭窄，难以在一个采用敏捷方法的软件开发项目中作到高生产率。当然，如果他们原意扩展自己的视野，这个问题就容易得到解决。
译注：想必国内的程序员看到这篇文章会很开心吧。毕竟，中国的程序员向来都是以通才自封的。但是，要注意的一点是，这篇文章是针对国外的程序员的，因为国外的程序员通产都只关注于自己的领域，例如数据库的专家对数据库非常的熟悉，但他可能对测试一窍不通。但是他们对自己领域的了解是非常不得了的。可是中国的程序员一般是万金油，哪儿需要，哪儿就有我的丰姿。只要是软件领域的，都无所不能，无所不精。但是人的精力都是有限的，不可能什么都精通。样样都精，也就是样样都庸。这个道理大家务必要了解。国内的很多程序员都算不上是通才，而只能算是庸才。这句话可能不好听，但是事实如此。如果能够意识到这一点，好，我想你已经不是庸才了，而是在往通才迈进的途中了。 本来是不打算译这篇文章的，因为担心有些人看完它后会断章取义，反而成了一项罪过。但是这篇文章的很多思想值得借鉴，再加上为了保证译作的完整性，最后还是把它译了出来，并加上了一段废话，提醒大家注意。最后，我真诚的希望中国的程序员都能够成为作者在文中提到的那种既是通才，又是专才的人。
建模的误区
走出一般性的设计误区，迈向成功之途
英文原文版权由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)的基本原理。
误区三：建模意味着需要一个重量级的软件开发过程
走入这个误区（经常与误区一有联系）的项目组常常是连建模都彻底地放弃了，应为这样的软件开发过程对他们来说太复杂太沉重了。这不亚于一场天灾。
事实分析：你可以用一种敏捷的方式取而代之。关于用简单的工具进行简单地建模的详细内容可参看Agile Modeling(AM)。而且，你可以丢弃你的模型当使命完之后，同样也可以很基本的方式进行建模（比如，从办公桌起来，来到白板前就开始构略草图）。只要你愿意，你就可以轻松地建模。
误区四：必须“冻结”需求
这个要求常常来自高级经理，他们确切地想知道他们从这个项目组能得到什么东西。这样的好处就是在开发周期的早期确定下需求，就可以确切地知道所要的是一个什么样的东西；缺点就是他们可能没有得到实际上所需要的（不全或错误的需求，译者）。
事实分析：变化总会发生的。由于优先级的变化和逐渐对系统有了更进一步的理解，都会引起需求的变化。与冻结需求相反，估计项目成功的风险，尽量去接受变化而且相应地采取行动，就象XP所建议的一样。
误区五：设计是不可更改的
如同误区四，要求每一个开发人员必须严格遵从“设计“，导致开发人员为了符合“设计“而作了错误的事情或以错误的方式作正确的事情。或者是简单地忽略了设计，否定了所有设计可能带来的好处。冻结了设计，你就不能从在项目进程中所学到知识进一步获益。另外一个很大的趋势就是开发出大量的文档而不是实际的软件，使用面向文档的CASE工具而不是能给项目带来实际价值的面向应用的工具。
事实分析：事实上，设计会经常根据开发人员和数据库管理员的反馈进行修改，因为他们是最接近实际应用的人，通常他们对技术环境的理解要好于建模者。我们必须的面对这样一个事实：人无完人，他们所作的工作也不可能尽善尽美。难道您真的想将一个并不完善的设计固定下来而不再去修改其中的错误吗？另外，如果需求并没有被冻结，其实就意味着你不能冻结你的设计，因为任何需求的修改势必影响设计。对之，正确的态度是：只要你的代码还在改动，涉及就没完。
误区六：必须使用CASE工具
建模常常被认为是一项复杂的工作，因此需要大量地使用CASE工具辅助进行。
事实分析：是的，建模可以是很复杂的。但你完全可以建立一个有效而简单的模型表述其中关键的信息，而不是将一些无关紧要的细节包括进来。
比如，我经常使用UML建立模型来表示类、它们的属性及一些关键的业务操作，但并不画出属性的存取操作(get和set)，以及维护与其它类关系的框架代码，或者其他一些琐碎的实现细节。我通过建模寻找解决问题的方法，让我和我的同事能继续前进去实现这个模型。以这样灵活的方式，大多数情况下我并不需要一个CASE工具来支持建模工作，一块白板，或者一台数字相机足以。这样，我就不用花时间去评估CASE工具，不用去和工具供应商讨论许可证的问题，也免去了人员培训开销。CASE工具只有当它能体现最佳性价比时（相对你自己的情况而言），才值得购买。大多数情况下，我都能不用它而达到目的（完成建模）。我经常使用的工具有Together/J(http://www.togethersoft.com/) – 因为它能产生数目可观的Java框架代码；还有ERWin（http://www.cai.com/） -- 因为它能规划数据库。这两个工具真正地帮助我实现了软件开发的目的 – 制造满足用户要求的软件。但我绝大多数得建模工作仍然使用的是简单的工具，而不是CASE工具。
误区七：建模是在浪费时间
许多新手都这样认为，这主要是因为他们所接受的教育仅仅局限于如何编写代码，对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码，就如初级程序员。他们放弃了提高效率和学习技能的机会，这些技能能够使他们很容易地适应不同的项目或组织。他们应该为此感到羞愧。
事实分析：在大多数情况下，在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进行建模工作。另外，建模是一种很好的在项目组成员与项目负责人之间沟通途径。你们在这个过程中探讨问题，从而对所要的是一个什么样的东西可以得到更好的理解，涉及到该项目中的每个成员也可得到对该项目有一个从分的了解。
误区八：数据模型(Data Model)就是一切
许多组织基于数据模型就蹒跚启动新的开发工作，也许正如你所在的组织：IT部门对于数据有非常严格的规定，控制着你的开发项目；或者你以前的数据库是一团糟，别无选择。
事实分析：数据模型是一个重要的但不是最重要的建模，它最好是建立在另外的模型之上。（参见“Extreme Modeling”，Thinking Objectively，Nov.2000）。这即使在象数据仓库这类面向数据的项目中也如此。如果没有很好的理解用户是如何使用该数据仓库的（在数据模型中没有表示出来），这些项目经常是以可悲的失败而告终。你可以使用的模型有很多 – 使用案例（use cases），业务规则（business rules），activity diagrams，类图（class diagrams），component diagrams，用户界面流程图（user interface flow diagrams）和CRC，等等。数据模型仅仅是其中的一种。每种模型都有其长处和短处，应该正确地使用。
误区九：所有的开发人员都知道如何建模
我们现在面临照这样一个严重的问题：许多不是开发人员的人，包括高级经理和用户，不知道软件是如何建成的。其结果，他们不能够区分开熟练的开发者和一般的程序员（当然也分不清高级程序员和一般程序员），他们想当然地认为所有的开发人员都具备从头到尾开发整个系统的技能。
事实分析：这肯定是不正确的。建模的技能，是只有当一个开发者通过学习它，并经过长期的实践才能够掌握。一些非常聪明的程序员常常相信自己无所不能，毕竟他们终究只是程序员。正因为这样的狂妄自大，他们承当的一些任务是他们根本就没有相应的技能去完成的。软件开发是如此的复杂，单单一个人是很难具备所有的技能去成功地进行开发，甚至也不可能去配置有一定复杂程度的系统。开发这应该有自知之明，明白他们自己的弱点，学无止境。通过互相取长补短，建模者可从程序员身上学到一项技术的具体细节，程序员也可从建模者那里学到有价值的设计和体系结构的技术。我个人认为所有的人，包括我自己，都是新手。
Agile Modeling
通过理解和避开建模的误区，你能够是得你自己、你的项目组和你的组织更加有效地进行软件开发。在揭示这些普遍存在误区的过程中，我已经表述了Agile Modeling(AM)的许多原则。Agile Modeling 以前叫做Extreme Modeling(XM)。我希望我所给于你的是精神上的食粮。
在此我要感谢Blueprint Technologies（http://www.blueprinttech.com/）的Doug Smith，Evanetics（http://www.evanetics.com/）的Gary Evans，以及在Agile Modeling邮件列表（可访问http://www.agilemodeling.com/加入）中对本文做出贡献的人们。我同样要感谢Martin Fowler，Ron Jeffries和其他一些XP社区中成员，因为我想我已经融入了一些他们的观点。
建模十条原则
仅有数据模型对于现代软件是不够的。
接收变化，并且允许你的模型能够随着时间进行改进。 你不能冻结它们，然后就期待着成功。
模型并不一定就是文档，文档也不一定就是模型。
大多数的模型可能也应该被丢弃。
只有代码才能与代码保持真正的同步。
一些简单的工具，比如白板，就完全足以应付大多数得建模工作。
思考，然后再编码。
你总能从别人身上学到东西。
建模可以用一种轻盈的方式。
设计直到代码发布以后才算完成。
[本文共有 2 页，当前是第 2 页] <<上一页 下一页>>
]
您的位置：
