在第一次读到《Extreme Programming Explained》（Beck 2000）这本书的时候，XP给我印象最深的是Kent起先为他的方法定义基础，他是通过描述交流、简单、反馈和勇气这四个价值观来做的。这让我着迷，因为对于在软件开发竞争中导致成功的一些根本因素，他找到了一种描述的方法，并且设法以一种针对开发人员个人的方式来表达，妙极了！因此在开始整理敏捷建模的时候，我就决定采用一种类似于Kent在XP中的方法、我将从一组高层的价值观开始，首先基于这些价值观定义一组明确的原则，随后从价值观和原则出发，阐明敏捷建模人员应该应用到工作中的实践。
因为我完全同意XP的价值观，所以把他们全都采纳了--在能复用的时候为什么要去重新发明这个价值观“轮子”呢？但我还是觉得缺了些什么，却又说不出来。有一天，我在客户那里和一个开发人员讨论需求，用户已经说明了他们是怎样工作的，但这个开发人员不同意用户描述的内容，尽管用户已经向他解释了好几次，他确实能这样做并且这样做过，但他还是坚持不能这样做，他有另外一种做事的方式，认为那样做更好，从技术上讲也许是这样，但用户只不过对此不感兴趣而已，他们希望按照自己的方式去做事情（用户可能就是这样奇怪），我觉得这是非常合理的，但这个开发人员不这样认为，他认为自己是对的，用户错了，尽管他们争论的是用户需求。就是这样，我最终不得不坚持我们必须按照用户告诉我们的做，并在后来花了一些时间让他理解这样一个概念：需求来自项目关系人，而不是开发人员。虽然这件事作为我们团队的一个成长之痛已经过去，但它却向我揭示了一个敏捷建模人员需要具有的价值观：谦虚。综上所述，敏捷建模的价值观是：
交流
简单
反馈
勇气
谦虚
1.交流
什么是交流？第10版的《Merriam WebSter’s Collegiate Dictionary》将其定义为“一个多程，在这个过程中信息通过一个共同的符号、标记或行为的系统在个体之间进行交换。”交流是一个双行道，交流的结果是既提供了信息又得到了信息。我的经验是，每个涉及项目的人之间的有效交流对软件开发的成功是比不可少的，这里的每个人既包括项目关系人也包括开发人员。在一个软件项目中，当交流不畅时问题就会出现。例如，由于一个开发人员没有告诉同事代码工作不正常，而导致另一个开发人员花费额外的时间去寻找问题；由于用户没有解释清楚各个需求的相对重要程度，而导致开发人员将精力集中到一些不重要的特征上，却忽略了几个对企业很关键的特征；由于项目经理没有重视为开发团队购买新工作站的重要性，造成未能得到进行必要的升级所需的资金；开发人员向项目关系人演示了一个模拟真实系统的用户界面原型，结果项目关系人误以为他们已经看到了真实的系统，从而坚持要在原来同意的交付时间基础上提前六个月交付，软件开发团队遇到的很多问题都可以归结为交流上的错误。
停下来想一想，其实建模的一个重要原因就是帮助进行交流。比如在用户描述一个复杂的业务过程的时候，可以大致画一张展示其逻辑的数据流图来帮助理解。情况经常是这样，花五分钟的时间通过和用户一起画一张图所学到的东西，要比花五个小时讨论或者阅读相关的公司手册所学到的还要多。在与别的开发人员一起探索系统某个部分的设计的时候，你可能会决定一起对其中一些地方进行建模，可能是画一张UML类图以理解类的结构。你们一起研究这个设计，讨论各种实现方法可能会带来的后果，商量怎样去构建它。建模能够帮助你表达想法，理解别人的想法，并且共同探讨这些想法，最终达到共同的理解。
2.简单
我相信现在很难找到一本一次也没有提到过KISS（Keep It Simple Stupid，使其简单而愚蠢）规则的软件工程著作。IT产业宣扬简单性已经有很多年，但出于某些原因“唱诗班”却没有在听。同样是这些软件工程著作，它们建议你采取的行动会使软件越来越复杂，越来越难以开发、测试和维护。常见的复杂化有：
过早使用复杂的模式。如果需要实现客户的电话号码引流，使用Contact Point分析模式（Ambler 2001a）很可能是大材小用了。没错，实现这个模式很有趣，但是与简单的电话号码类相比，它的类层次构建、测试和维护要苦难得多。最好一直等到还需要实现电子邮件地址系统和邮件地址系统的时候，证明使用Contact Point模式有道理。别误解，我是模式的坚定信徒，常常第一个承认有时候使用模式实际上是可用的最简单的方法，问题的关键在于实际情况并不总是这样。
为支持未来可能的需求而过渡地架构系统。现在正在开发的银行信息系统有可能某一天需要支持销售保险单，设计一种能处理各种金融产品的通用方法难道不是更好吗？是的，那样建模会很有去，但会是软件比今天实际需要的更为复杂。两种开发人员常常会过度设计软件：对自己处理未来变更的能力没有信心的开发人员；受自负驱使想创造“终极”系统的开发人员。敏捷建模人员不过度建造系统，他们相信自己能用可能的最简单的方式构造今天的系统，并且能在真正需要的时候，还是用可能的最简的方式去添加新功能。为什么要这样呢？Martin Fowler（2001b）在讨论YAGNI（You Ain’t Gonna Need It，你其实根本不需要它）原则时对这一点有一个最好的描述。他指出，不可能总是能预测未来的需要，预测错误和预测正确的可能性是一样的，因此，为什么还要去开发、测试、维护这些额外的功能？这些功能现在肯定不需要，将来也可能永远不需要！集中精力满足项目关系人当前的需要，从而使他们高兴（这总是好事），并且有勇气相信自己明天能够解决明天的问题，这样难道不是更好吗？如果今天集中精力建造可能的最简单的系统，当明天需要增添新功能的时候，就会知道要处理的是一个简单的系统。在明天确实需要新功能的时候修改系统，和在今天还不知道是否需要新功能的时候修改，这两者难道不是一样简单吗？或者前者更简单。
开发复杂的基础设施。项目团队常犯的一个错误是在项目的前期投资开发基础设施--比较典型的是构件、框架、类库等。他们想用这些基础设施作为建造系统的材料，他们的想法是初期的投资将在后来某个时候得到补偿。可是，这个方法有几个严重的缺点。首先，你在使用项目关系人的资源，却没能还给他们任何能实际使用的东西。项目关系人问你要的可能是某些能帮助他们工作的功能，而你首先提交的却是错误处理了系统。结果是由于没有迅速地提交有用的功能，增加了项目的风险。其次，很有可能忽略YAGNI原则。而在基础设施中开发很可能不需要的功能。更好的方法是，在项目的整个过程中，到需要的时候再去开发基础设施。例如对于上面的例子，应该等到确实需要错误处理子系统的时候再去逐步开发它。
那么这些与敏捷建模到底有什么关系呢？最基本的一点是尽可能保持模型的简单性，今天建模满足今天的需要，明天再去考虑明天的建模需要。换句话说，不要过度建模，遵循KISS规则而不是KICK（Keep It Complex Kamikaze，使之复杂而操之过急）规则。
提示 别让“假如”把你弄得痛苦不堪
我常常看到软件开发人员因为古怪的“假如”情景而偏离他们真正的任务，即通过有效的方式建造满足用户需要的软件。他们过度地建模以期能够处理所有想像中将出现的问题，而项目关系人很可能根本不关心这些问题，或者认为这些问题发生的可能性很小，他们愿意承担风险。过度建模的结果是过度构造。没错，工作时不应该太幼稚，预计数据库和网络故障等问题会发生是合理的，但应该在建模的时候现实一点。
模型对简化软件和软件过程都是非常重要的。在研究一个想法以及随着理解的深入而改进它的时候，通过画一两张图要比通过编写几十行甚至几百行代码进行工作要容易得多。
3.反馈
唯一能确定工作是否正确的办法是获得反馈，这包括对模型的反馈，模型是一些抽象，例如，用例是人们怎样使用系统的抽象，构件图是系统内部结构的抽象，怎样知道抽象是正确的呢？有很多得到对模型的反馈的方法：
作为一个团队来开发模型。软件开发和游泳一样，单独一个人是很危险的。和别人一起工作能及时得到对你的想法的反馈。
和所针对的听众一起检查模型。在理想情况下，针对的所有听众都应该参加模型的开发。需求模型应该和用户一起开发，详细设计模型应该和将来编程的人员一起开发。如果达不到这样的理想情况，一个最好的选择就是和他们坐到一起，让他们仔细检查模型，可能是把各种使用情境走查一遍。非正式评审可以按非正式的方式进行，可能是和某些人开一个短会听取他们对工作的意见，正式的评审（Glib and Graham 1993）则需要花费更多的精力来组织。
实现模型。最可靠的得到反馈的方法是用软件实现模型，并且让项目关系人使用它。时间是检验真理的唯一标准。
验收测试。模型从根本上说应该满足项目关系人对系统的要求，项目关系人对需求的验证是在验收测试期间进行的，这意味着验收测试也在同时验证模型。
不同反馈方法的及时程度也值得关注一下。在团队一起工作的时候，反馈几乎立刻就可以得到，只需要几秒钟到几分钟的时间；非正式的评审可以在几分钟到几小时内进行，尽管如果有人能参加非正式评审，为什么他们不能一开始就参加建模？在另一方面，正式评审根据参加者的到席情况可能要等几天、几个星期甚至几个月才能进行；在理想情况下，实现模型而得到的反馈可以在几个小时到几天内得到（别忘了是在用敏捷的方式开发）；验收测试通常会在几周到几个月后提供反馈。
为什么及时程度这么重要呢？因为反馈越及时，模型偏离实际需要的可能性越小虽然每种反馈方式都有它们适用的地方，但在可能的情况下应该首选通过团队工作来提供反馈，因为立刻就可以得到。说到这里，值得提一下用代码来验证模型，因为在实际尝试之前，纸上的东西看起来总是好的。
4.勇气
敏捷建模和一般的敏捷软件开发对大部分人员和他们工作的组织机构来说都是一个新东西。正如在第1章中看到的，敏捷软件开发的原则挑战现状，这对很多人来说是危险的。不采取行动，接受现状，不尝试进行任何改进，或者等待有人出现把什么都收拾好，这样做要容易得多。这中恐惧产生的瘫痪症是导致IT产业当前悲哀现状的一个主要原则。
在我曾工作过的一家组织机构中，它的数据管理小组牢牢地控制着软件开发小组。不首先经过数据小组，开发人员不能使用公司数据进行工作；不经过数据小组，开发人员不能建立自己的开发数据库；没有数据小组的应允，他们当然也不能发布软件上线。如果数据小组工作有效的话这也许不算坏，但不幸的是情况不是这样。我的小组正在做一个Enterprise JavaBeans（EJB）项目，也是这家公司第一个这样的项目，它的后端使用Oracle数据库。在了解到请数据小组派人为我们建立开发数据库需要几个星期时间的时候，我们就决定自己干，做这件事开始花了几个小时，并在后面几天里在需要的时候花时间进行调整。数据小组需要几个星期的原因是他们坚持按照他们的过程来设置数据库大小（我们已经做了）、确保我们的机器有足够的磁盘存储空间（我们已经把机器发挥到了最大限度）、当然还要填无数除了他们没人想要的表格。结果他们被激怒了，他们的经理把我们的精力批了一顿，我们的经理又随即把我们批了一顿。我们坚守自己的阵地，解释说我们没有时间去迎合数据小组官僚主义的奇想。在这之前没有人能成功地抵抗这个小组。我小组里的人都挺担心，但因为我们的首要任务是按时完成这个系统，所以只好斗争解决。这需要勇气，为了使事情顺利一点，我们说非常累一和他们一起管理数据库和不断改进数据模式、事实确实是这样。这却让我们遇到了第二个问题，他们不是为我们提供一个数据库管理员（DBA），而是想把好几个人加到我们小组中：一个管理数据库、一个负责逻辑数据模型（在开发面向对象软件时这绝对没有任何价值）、一个负责物理数据模型（我们需要这个）。而且，他们希望他们做这件事情与我们的开发活动平行进行，而不是作为小组的一个积极组成部分。换句话说，他们提供的大部分内容是没事找事。对我们来说，与这样独立的一组人一起工作所花费的精力比我们自己进行物理数据建模还要大。我们有几个人绝对能胜任这件事，以及生成和在数据库中建立模式（我们中几个人做这件事已经好几年了）。我们再一次和他们进行了斗争，鉴于过去从来没有人这样做过，并且他们已经在攻击我们，这又是另外一个勇敢的举动。所有的事情最终在一次我们和他们经理都参加的大型会议上到达了顶点、事实上我们和数据小组内的几个DBA关系很好，他们私下都同意我们的做法，并且希望我们能打破机构内部这样一种死锁的状态。在会议上，数据小组的头宣称我们对生产率会降低的担心是不切实际的，他的人能很快在几个星期内让我们继续前进，并在此后的几个月中继续帮助我们。就在这个时候，我说我们的数据库已经建立起来并正在运行，我还提议向与会的所有人展示正在运行的数据库。我们有勇气做正确的事情，勇敢地抵抗工作不正常的小组。这是很困难的，但从长远来看，不但项目会从中受益，整个组织机构也会受益，因为它给了其他小组也来抵抗数据小组的勇气，从而促使他们理顺（虽然在我看来这还不够）他们的过程。
敏捷方法要求与其他人紧密合作，信任他们，也相信自己，这需要勇气；XP和AM等方法要求做能做到的最简单的事，相信明天能解决明天的问题，这需要勇气；AM要求只有在绝对需要的时候才创建文档，而不是只要觉得舒适就去创建，这需要勇气；XP和AM要求让业务人员制定业务决策，例如排定需求的优先级，而让技术人员制定技术决策，例如软件怎样去满足各个需求，这需要勇气；AM要求用可能的最简单的工具，例如白板和纸，只有在复杂建模工具能提供可能的最好价值时才去使用它们，这需要勇气；AM要求不要只是为了推迟如用代码验证模型等困难任务，而把图加工得更漂亮来拖延时间，这需要勇气；AM要求信任你的同事，相信程序员能制定设计决策，因此不需要给他们提供过多的细节，这需要勇气；AM要求决心去成功，去结束IT产业中接近灾难和彻底失败的循环，这需要勇气。
我认为勇气是敏捷软件开发基本的必备条件。首先，勇气之所以重要是因为需要下决心采取敏捷的方式，并在情形变得艰难时（肯定会的）仍然坚持这个方式。组织机构里会有人有其他的想法--需要使用XYZ工具、需要采纳一种重量级的过程、管理层需要施加更强的控制需要外包全部的IT、需要听从其他部门的命令--在前进道路上的每一步他们都会和你的努力进行斗争，这就是政治。其次，在开发过程中需要勇气来做出重要的决定，比如选择某种架构而不是另外一个，或者是选择开发语言。在开发过程中，有时候你的决定被证明是不恰当的，需要有勇气通过丢弃或重构现有的工作来改变方向。
还有，需要勇气来承认自己是会犯错误的。
最后，需要勇气来相信自己明天能克服明天出现的问题。勇气，不再只是提供早餐使用了。
5.谦虚
最好的开发人员是谦虚的，承认自己不是无所不知。坦率地说，无所不知是不可能的。你可能是最好的Java程序员，却仍然不知道每个Java API的每一个细节。而且，仅仅因为你是一个优秀的Java程序员，并不意味着你就是一个优秀的用户界面设计员、一个优秀的数据库设计员或者一个优秀的音乐家--它只意味着你是一个优秀的Java程序员。仅仅因为你是一个优秀的Java程序员，并不意味着就不必从其他Java程序员那里学到东西，包括团队中的初级成员。事实上，我经常从初级成员那里学到比从高级成员那里更多的东西，因为初级成员会问为什么，并很可能会用新的做事方式挑战我自己的信仰。
敏捷建模人员理解与他们共事的开发人员和项目关系人都有其各自的专长，都能为项目作出贡献。有的开发人员比你更擅长于编写代码，或者更擅长于测试，或者更擅长于需求建模，或者更擅长于架构建模。用户可能比你更了解业务的不同方面；高级经理对产业的发展方向有更好的领会，运营人员知道在生产环境里什么行得通什么行不通。敏捷建模人员谦虚地承认他们需要帮助以成功完成自己的工作，也要谦虚地承认他们要与别人一同工作。
谦虚在你和别人打交道的方式上也有重要的作用。敏捷建模人员的谦虚使他们尊重和他们一起工作的人，他们认识到其他人可能有与自己不同的处理事情的优先顺序和经历，因此会有不同的观点。他们不会把自己的经理称为“愚蠢粗暴的老板”来污蔑他们，也不会称其他部门的人为“推纸机器”，或者称用户/客户为“愚蠢”或“一塌糊涂”。污蔑别人不是一种谦虚的行为，而是一种自大的表现。自大会导致交流上的问题，最终会使项目遇到麻烦，因为它会导致别人不愿与你合作。敏捷建模人员是谦虚的，其结果是工作更加富有成效。
6.老生常谈之后
敏捷建模人员是勇敢的：他们追求简单，寻求反馈和很好的交流。还有最重要的--谦虚。如果成为了一个敏捷建模人员，你似乎都可以被提名作为圣徒了。显示情况是敏捷建模人员也是人，他们会犯错误，他们在有效的建模实践之外还有其他生活上的事情需要关心，他们根据自己的意愿思考和行动，我定义这些价值观的原因不是经理过于充沛，我自己可能还没达到这个目标，我是想建立一个基础，从这个基础开始个人能建立一个敏捷的思维方式，团队和组织机构能够建立一种支持敏捷有效的开发工作的文化、这些价值观也和第1章介绍的敏捷联盟（2001a，2001b）的原则和价值观一起，作为第3章和第4章定义AM原则的基础。
作者：银月莲
出处：http://www.cnblogs.com/moonsilvering
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，包括文章，代码，图片等本站内所有资源，否则保留追究法律责任的权利。
