1.软件是你的首要目标
软件开发的首要目标是运用有效的方式制造出满足项目关系人要求的软件。这条原则在敏捷联盟（2001b）中的另一种诠释叫做“能够运转的软件是衡量进展的首要标准”。不管怎样，首要的目标并不是制造无关的文档或者无关的管理制品，甚至不是创建模型。撰写那些无关的文档会给人一种欣慰的错觉，因为它让你误认为自己正在前进，而事实并非如此。相反，你实际上是在逃避一个有难度的任务，比如说开发和测试代码，或许你会发现所选择的方法实际上并不像想像中那样有效。写汇报，向所有的人鼓吹成就，或更有甚者，掩盖失败，所有这一切会让你感觉良好，但绝不会让你更接近最终目标。鼓起勇气来专注于那些关键的东西吧，那就是创造客户需要的系统。我们不是来开发文档的，也不是来开发模型的，我们是软件开发人员。好好想想这一点。任何一项活动，如果它既不能直接地有助于创造高质量系统这一目标，又没有充分的依据，那么它都应该受到审慎的对待或者干脆被取消。
2.支持后续工作是你的第二目标
有时候虽然团队已经将一个可以运行的系统提交给用户，但项目仍可能是失败的--因为确保系统有足够的健壮性，以便日后能够扩展，这也是项目关系人对系统要求的一部分。就像Alistair Cockburn（2001b）常说的那样，当在进行软件开发的“比赛”时，第二个目标就是为下一场赛事做好准备，接下来或许将开发系统的下一个重要版本，或许只是为当前开发版本做好运行和支持工作。要做到这一点，需要的不仅仅是开发高质量的软件，还必须撰写足量的文档以便于参与下一场比赛的队员能有效地展开工作，让软件开发人员将技巧传授给他人，激励那些现有的成员留下来应战下一个版本，或者更简单，想办法留住团队的成员吧。要考虑的方方面面的因素包括：开发人员的特质，下一个问题的实质，以及这个问题对组织机构的重要性。总而言之，当还在开发系统的时候，请着眼于未来。本原则支持了敏捷建模的价值观之一：交流。
3.轻装前进
轻装前进的意思是在前进的时候只创建刚好足够的模型和文档。你建立的而且决定保留的任何一个制品随着时间的流逝都必须得到维护、这些制品包括模型、文档和日程安排、测试工具、源代码这样的项目管理材料。打个比方，假设决定保留七个模型，一旦有变化发生（产生了新的需求、原有需求更新了、团队采用了新方法或接纳了新技术），就必须考虑这一变化对七个模型带来的影响并采取相应的措施。如果只保留了三个模型，那么对于同样的变化，要花的功夫显然就少多了，从而变得更加敏捷，因为你在更加轻装地前进。
同样的道理，模型越复杂、越详细，要实现任何给定的变化就越困难（每个模型都“更重”，因而维护的负担也更重）。每次当决定保留一个模型时，都是在做一个交易，得到的是模型所载有的抽象形态的信息给团队带来的便利（因为潜在地增强了团队内部及与项目关系人的交流），而失去的是敏捷性。千万不要小看这种交易的严重性。Jim Highsmith（2000）指出，一幅地图、一顶帽子、一双结实的靴子和一壶水对跋涉荒漠的一队人来说非常重要。然而，假设他们身背几百加仑的水，，能够想到的所有的求生工具，一大堆有关沙漠的书籍，他们还可能去征服沙漠吗？但是，也有可能会装备过于简单--在没有基本的物质保障的条件下去横跨沙漠无疑是愚蠢的。同样的道理，如果一个开发团队决定要开发并维护一份详细的需求文档、一组详细的分析模型、一组详细的架构模型和一组详细的设计模型，那他们很快就会发现，他们所花的大部分时间并不是在编写源代码的工作上，而是在更新文档上。一个好的经验法则是，直到非常清楚地知道需要某个模型时才开始维护它。
要能做到有效地轻装前进，团队内部需要有良好的交流。如果开发人员不能理解需求或是架构方法，或者最起码当他们在工作中有问题却没有人能及时回答这些问题时，麻烦就大了。显然，良好的交流对轻装前进来说是必需的。轻装前进还需要勇气，相信自己并不需要那份制品，但同时做好创建它的准备，以防万一事实证明假设是错的。轻装前进使得开发方法变得简单，因为开发过程中制品维护的工作量显著降低了。
4.主张简单
在开发工作中，应当假定最简单的解决方案就是最好的解决方案，从标题可以看出，该原则源于敏捷建模中称为“简单”的价值观及敏捷联盟的简单原则，Kent Beck（2000）指出，在绝大多数情况下，最简单的方法都工作得很好，而且因为简单，所以易于实现，这样的好处之一是，不会花大量额外的时间去实现复杂的方案，因为它们往往是费时和费力的。好处之二是，如果在极少数的情况下最简单的方案被证明不能工作，因为资源从未浪费过，所以仍有时间来实现更复杂的解决方案，而且，最简单的方案也是最易于维护和增强的。
该原则的一个含意是不要过度构建软件。拿建模来说，如果现在不需要某项额外功能，那就不要在模型中描述它，不要过度建模今天的系统，基于今天已有的需求进行建模，当日后需求有变更时再来重构这个系统：这意味着尽可能保持模型的简单性。这个原则正式建模中的Occam剃刀--在拿不准的时候采用可能的最简单的方法。
最简单的方法是否每次都管用呢？可能不是，但它在绝大多数情况下是管用的。在它不起作用的时候，你却已经学到了一些东西，而且往往是在很早期的工作中失败，拿它和采用复杂方法比较一下，复杂的方法也会失败，这时你已花费了大量的资源，结果是发现自己的想法不行。
5.包容变化
接受这一事实吧，变化永远在发生。反应出来吧，变化正是软件开发激动人心的要素之一。需求随着时间在发展，项目关系人对于需求的理解也随着时间在变。在项目进行过程中，项目关系人可能变化，会有新人加入，也会有旧人离开。项目关系人的观点也可能变化，这可能导致你努力的目标和成功标准发生变化。此外，随着项目的进行，业务和技术的环境也在变化，而且发生的事情往往超出控制范围，这就意味着项目环境在不停地变化。
敏捷建模人员包容变化，他们理解变化对软件项目来说是常事一桩。敏捷联盟（2001b）建议，及时在项目生命周期的后期也仍然要对需求的变化敞开大门，敏捷建模人员知道变化将影响他们的工作；他们积极地努力与项目关系人交流，寻求他们的反馈，从而找出变化并采取相应的措施。他们并不因变化而职责项目关系人，相反，他们积极地和项目关系人并肩工作，理解和交流变化所带来的后果，以便于帮助项目关系人做出有效的决定，即将在何时以及怎样通过开发工作支持这些变化。而且，他们知道模型仅仅是模型而已，开发人员可以将它们重新分解并组装得更好，他们接受这一事实：自己的工作可以被他人改进。
敏捷建模人员也认识到在包容变化中固有的危险--在做预备工作如需求建模时有粗心大意的倾向。既然需求肯定会发生变化，为什么还要在理解它们方面花费大量的时间呢？还不如简单地弄一堆代码出来，然后等着项目关系人告诉你去修改它？不是吗？错！最好从现在开始就花时间尽自己的最大能力去理解需求，然后按这些需求来实现软件。有些需求的确会变化，你必须接受这一事实，但很多需求是不会改变的（至少不是马上改变）。注意，马马虎虎是与敏捷建模中“高质量的工作”和“最大化项目关系人的投资”的原则背道而驰的。
6.递增的变化
要做到包容变化，需要在开发工作中采用一种增量的方法，每次只改动系统的一小部分，而不是试图在一个大的发布版本中完成一切。可以通过一系列小的增量变化来完成一个大的改变。事实上，敏捷联盟的第三条原则就说应该经常性地递交可运转的软件，时间间隔可以从数周到几个月，但应优先考虑短的时间周期。敏捷建模时的一个重要概念就是不需要第一次就保证一切都是对的，事实上，即便想这么做也不太可能。而且，不用在模型中记录每一个细节，只要它对当时而言足够好就够了。试图在一开始就建立一个囊括一切的模型是徒劳的，只要打下一个基础，开发一个小的详细的模型或者概要模型，然后随着时间以增量的方式来改进这个模型（或是在不在需要的时候干脆丢弃它）。接受自己在第一次（甚至第N次）不能保证它完全正确需要谦虚的态度，同时也需要勇气。Kent Beck（2000）说得很好，“让它运行起来，让它正确，然后再让它更快。”
7.有目的地建模
如果连为什么建模和为谁建模都不清楚，为什么还要在这个模型上劳心费力呢？对于自己的软件制品，如模型、源代码、文档，很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确。他们没有做的是回头想想，问问为何当初要建立这个制品，是谁需要它。做到这些需要谦虚的态度，因为建模并不是仅仅为了自己的个人满足感，相反建模的目的是满足项目关系人的需求。
建立一个模型的正当的理由是什么呢？或许你经常需要更好地理解软件的某个方面，或许你需要与高级管理层交流你的方法以证明项目是正确的，也许你需要创建描述系统的文档，使将来其他人能够操作、维护、改进系统。总之，要么为理解而建模，要么为交流而建模。
以下则不是建模的正当原因：
指令性过程告诉你应这么做，因此你老老实实地做而从未想过这样是否有意义。
某些人需要这个模型，但是说不出除了要你建模以外的原因。
你建立了一个模型，并交给那些原本可以直接面对面交流的人。
建模的第一步是确定建模的目的以及模型的读者，目的和读者确定了以后，再把模型开发到刚刚足够正确和刚刚足够详细。一旦一个模型达到了目标，就应该结束建模工作，你已经完成了！然后把精力转移到其他工作上去，例如，编写代码以检验模型的运作情况。这样的好处是使用模型保持简单，因为并未把不需要的细枝末节都堆积进来。该项原则也可适用于对现有模型的修改：如果要做一些修改，也许是应用一个熟知的模式，应该有做出修改的正当理由，例如，是为了支持一项新的需求，或是为了重构以保证简洁。关于该项原则的一个重要隐含意义是应了解读者，即便读者就是你自己。例如，如果是为维护开发人员建立模型，那么他们到底需要些什么呢？是厚达500页的详细文档呢，还是10页的系统总览就够了？如果不清楚，就去和他们谈谈，找出想要的答案吧。
从另一个角度来看这个问题：一个模型在刚刚满足它的目标的时候，也就是这个模型带来的回报开始减少的时候，当开始着手建模的时候，你总是带着一种成就感，因为你在仔细考虑某件事情，要么对需要做的事情获得更好的理解，或者对应该如何构建它有更深的认识。然后在接下来的工作中，你越来越接近模型开发的目标，不管这个目标是什么，直到最后达到这个目标，正是从这个点开始，在模型上更进一步的工作所带来的收益越来越少。对了，你可能在填充一些细节，你可能在加强模型的一致性和准确性，但是原本应该继续前进，原本可以找些其他的事情，最理想的是为项目编写能带来更多效益的源代码。
8.多种模型
有范围广阔的建模制品可以选择，它们中大多数在附录A中进行了总结。这些制品包括统一建模语言（UML）（Object Management Group 2001）中的各种图、数据模型等结构化开发制品，以及一些低技术模型，例如，基本用户界面模型。每种模型都有它的优缺点，都适用于某些情形而不适于其他的情形。现代的软件很复杂，以至于没有哪个单个的制品能够适用于所有的情形，甚至UML制品家族也不能。也就是说，为了有效地工作，必须使用多种模型来描述软件系统，因为每种模型只能描述软件的一个方面。比如说，图3-1展示了在线下订单的逻辑，而图3-2的用户界面流程图则展示了用户如何浏览SWA在线的用户界面。有趣的是，顺序图是UML指定的制品之一，而用户界面流程图则不是（现在不是），两种图描述了SWA在线系统中不同的但都很重要的方面。
通过把每种模型都用在它适宜的地方，而避免用在不适合的地方，可以用几个简单的模型而不是一两个相当复杂的模型来描述正在构建的系统的复杂性。对于一个开发人员来说，当在数据库上开发时采用数据模型，当在做用户界面设计时采用面向用户界面的模型，如用户界面流程图，这样事情会变得更简单。对于那些需要与你进行交流的人来说这样做也更简单，因为他们一次只需关注一个模型，而不是一下子理解一切。很明显，这项原则支持敏捷建模的简单和交流价值观。
注意，虽然有范围广阔的模型可用，但对任何指定的系统并不需要开发它们的全部，根据所开发的软件的特性，以及与采用的敏捷建模一起的软件过程，你将至少需要它们的一个子集，例如，XP的项目小组会把用户故事作为它主要的需求建模制品，而统一过程的项目小组则可能把用例、业务规则、约束及技术需求等结合起来使用，一个EJB应用可能会需要UML等所描述的面向对象设计制品，而数据仓库项目则需要数据模型，不同性质的项目需要不同的制品子集。作为一个有效的敏捷建模人员，应该学习各种各样的模型，以便能够根据实际情况运用正确的模型类型。为了能够一直有效地工作，你需要谦虚（这是AM的另一个价值观）地承认自己总是应该学习新的技术，经常是从刚刚出学校大门的年轻开发人员那里，或者从那些理解业务的项目关系人那里学到新知识。
你需要一个技术知识工具箱
本书中一直使用的一个类别是：开发人员应该有一个技术知识工具箱以备使用，这就像木匠有自己的工具箱一样。工具越多，并且知道如何使用，开发工作就越有效率，因为在需求出现的时候才更有可能拥有正确的工具，这正如家里的修理工作，每种工作不是要求你用遍工具箱里的每一个工具，每项开发任务也不需要你运用所知道的所有技术。家里修理工作的多样性会使你在某个时间段内用遍每一个工具，同样地，你所参与的各个开发项目也会随着时间的推移让你用遍你知道的各种建模技术。最后，正像你会更多地使用某些工具一样，你会相对更频繁地运用某些模型。
9.高质量的工作
没有人喜欢乱糟糟的工作，做这项工作的人不喜欢，是因为没有成就感，日后负责重构这项工作的人（可能是你自己，因为数周后需求发生了变化）或可能是某个被指定来改进系统的维护工程师也不喜欢，是因为乱糟糟的工作难以理解，因而难以更新。换句话说，高质量的工作改善了项目的交流。最终用户不喜欢乱糟糟的工作，是因为它太脆弱和/或不符合他们的期望。高级管理层也不喜欢，是因为他们认为从给你工作的投资中并未得到什么收益。
敏捷开发人员知道他们应该花力气使得永久制品（例如，源代码，用户文档和系统技术文档）具有足够好的质量。站出来说你需要时间来好好干一番工作是需要胆识的。同样的道理，敏捷开发人员不会为那些他们要抛弃的制品而花费大量精力，尤其是草图或低精度的制品，如基本的用户界面原型。换言之，他们在如何明智的花费时间上是谨慎的，因为他们知道如果不那样做的话，将是在浪费项目关系人的资源。这个建议矛盾吗？我认为不矛盾，如果有些东西值得保留，那么也值得正确地构建它，否则就花最少的工作量在上面。
10.快速反馈
反馈是AM的五大价值观之一，因为从采取行动到行动反馈之间的时间至关重要，相比拖拖拉拉的反馈，敏捷建模人员只要可能的话更喜欢快速反馈。通过和其他人一起开发模型，特别是当采用共享建模技术的时候，你的想法可以立刻获得反馈，例如，白板、CRC卡片或即时贴之类的基本建模材料。它能帮你指出你的方法是否有可能解决手头的问题，也为你提供了演化和改进模型的机会。和客户机密合作，去了解他们的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了获得快速反馈的机会。基于模型编写代码是另一个获取反馈的机会，它能说明模型是否可能，而且经常会暴露出方法中的错误，原因很简单：你不可能考虑到所有的一切。获取对工作的反馈是一个需要屈尊但却能获得很多信息的经历，应尽早得到反馈，以便可以在事情变得严重之前着手处理。
快速反馈之所以重要有两个原因：我们所犯的错误中大部分是在开发的前期出现的，而在后期用来修正它的开销却是成指数级增长。技术人员对像设计和编码之类的技术活很拿手，这也就是为什么他们是技术人员。不幸的是，同时他们往往不擅长于非技术的工作，如需求收集和展开分析，或许这也正是他们被称为技术人员的另一个原因吧。结果如图3-3所示，开发人员往往在需求定义和分析阶段犯的错多于设计和编码阶段。并且，在非敏捷的项目中修正这些问题的开销随着发现得越来越晚而呈现上升的趋势，如图3-4所示。这是因为软件开发的本性--工作是一环套一环而决定的。例如，设计建模依赖于需求，编码依赖于设计模型，测试又是在编好的源代码上进行。如果一个需求理解错了，所有基于它的建模决策都可能不正确，所有基于这些模型的代码也值得怀疑，而且测试是在用错误的条件来进行验证。如果得到的唯一反馈是项目后期发现的错误，那么在大规模测试中，或者是在产品发布之后，修正的代价将相当昂贵。但是如果能在错误地理解信息后立即得到反馈，处理这些误解的代价就笑多了。
11.最大化项目关系人的投资
项目关系人为了开发出满足他们需要的软件，正在投入时间、金钱、设备等各种资源。他们理应用可能的最好的方式去投资，不让资源被团队浪费掉。并且，他们就是否投入以及如何投入这些资源理应有最后的发言权。假设是你的钱，难道你不希望这样吗？
提示 系统文档是一个业务上而非技术上的决策
认识到这一点很重量，每次当决定保留一个模型或一份文档时，你都在完成一次认真的权衡--是否为了编写文档而放弃新的功能。在停下来想这一点时，这种权衡是业务上而非技术上的决策，你舍弃了业务功能，换来的是潜在的降低风险的收益--因为有了描述系统的永久制品。因此，你应该去问项目关系人，向他们描述这样做带来的好处和坏处，请他们同意这样进行投资。有时他们会像你建议的那样决定保留这份制品，有时他们也会接受冒着没有这些文档的风险而轻装前进。那是他们的决策，不是你的。
12.为什么需要核心原则
为什么我总是强调需要采纳敏捷建模的所有核心原则才能真正宣称你在进行AM？我想避免碰到XP所遇到的问题--有人自称在进行XP而实际上没有，然后失败了却归咎于XP。正如XP一样，AM的原则和实践是互动的，如果删除了其中的一些，那么互动性也就不存在了。不采纳AM中的某一条核心原则或实践，就降低了整个方法的有效性。是的，只采纳AM中的一部分也会让你受益，但是你不大可能在有效性方面获得引人注目的提升，因为互动性丢了。简而言之，如果认为AM中有可以借鉴的地方就用吧，只是不要在仅仅部分采纳的时候就声称自己已经在进行AM了。
作者：银月莲
出处：http://www.cnblogs.com/moonsilvering
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，包括文章，代码，图片等本站内所有资源，否则保留追究法律责任的权利。
