敏捷建模定义了四个实践，用来促进团队内部以及与项目关系人之间有效的团队协作和交流：
- 与他人一起建模
- 项目关系人的积极参与
- 集体所有
- 公开展示模型
1.与他人一起建模
软件开发同游泳很相似，单干是很危险的。当有目的地建模时，你会发现自己建模是为了去理解一些东西，或者是为了同他人交流你的想法，从而建立起关于项目的共同愿景。这些活动作为团体活动是最合适不过的了，因为你需要的是几个人一起有效地工作。你会发现开发团队必须共同协作，才能建立起模型的一个核心集，而这对项目是至关重要的。例如，为了建立系统的映象和架构，你需要和同组成员一起建模，找到每个人都赞同的解决方案，同时还要尽可能使它保持简单。大多数时候，做这件事的最好方法是同一个或更多的人一起深入讨论所面对的问题。自己先画一张简单的草图把事情考虑周全，这并没有什么错。但是一旦完成了它，一定要把想法告诉某个人来看看你是否走对了方向，三个臭皮匠胜过一个诸葛亮。这项实践能够帮助增进项目的交流，在你和同事之间帮助建立起一个共同的词汇表，使你有可能完成高质量的工作，并且提供了同事间相互学习的机会。
在有着下列文化的组织机构中，采用这个实践最初会遇到一些困难：一种是“分治”文化，这种文化的重心在于把工作分配给个人；另一种是高度竞争的文化，这种文化使个人陷于和他人的争斗。要防止此类问题发生，需要让大家知道协同工作的好处，也许可以采用这种方法：“新的方法学意味着新的工作方式，所以让我们现在就试试它，看看会发生什么吧。”还需要一个工作区域来支持整体的团队协作，参见第11章。这可以是一些很简单的东西，比如某人工作间墙上的一块白板，或者是小组的专用工作区。
2.项目关系人的积极参与
项目的关系人是指：任何直接用户、间接用户、用户的经理、高级经理、运行人员、支持（帮助）人员、测试人员、与正在开发的系统进行集成和交互的其他系统的开发人员或者收到软件项目开发和实施影响的专业维护人员。出于敏捷建模的原因，在这个定义中我排除了项目中的开发人员--尽管对敏捷建模而言开发人员显然是项目的一个至关重要的因素，“项目关系人”这个词将被用来指除开发人员以外的每一个与项目有关的人员。由此，我将开发人员和项目关系人看作两个分离的团体。当然还有一个选择是使用诸如开发类项目关系人和非开发类项目关系人这样的词汇（这可真烦人）。
这项项目关系人的积极参与的敏捷建模实践和它的另一个实践与他人一起建模是紧密联系的。而且，它是极限编程（XP）中现场客户实践（Book 2000）的一个扩充，该实践谈到了与客户和客户代表保持现场接触的重要性，因为他们有足够的权威和能力来提供与在建系统相关的信息，及时而中肯地作出和需求及其优先次序相关的决策。为了使软件开发工作更加有效率，这种层次的参与是必要的，然而在很多组织机构中这一点做得还很不够，特别是那些以政治为流行时尚而不是对建造可用系统进行投入的组织机构。项目的成功往往需要项目关系人更深程度的参与：高级经理需要公开和私下地对项目进行支持；运行和支持人员需要和开发团队积极协作，以使软件的生产环境准备好接受系统；其他系统的团队必须要和你的团队一起工作以支持集成工作；而从事产品维护的开发人员则需要熟练掌握系统所使用到的技能和技术。这项实践是由快速反馈和开发和诚实的交流这两项原则所激发和推动的。
很明显，为了使项目成功，所有的项目关系人必须与团队积极协作以达到这些目标。以下是这项实践的一些深层含义（蕴含意义）：
- 用户必须充分做好准备和团队分享业务知识，并且做出关于项目范围和需求优先次序的及时而中肯的决策。
- 要使高级经理能有效地支持项目。他们必须首先理解团队所使用的技术和技能所能产生的好处和增添的价值，理解为何要采用这些技术，更要理解使用这些技术隐含的意义。有了这些知识，他们才有可能在组织机构的政治竞技场中使工作变得更有成效，而且是在正确的时间以正确的方式进行。而仅仅通过阅读每周一次的项目状况报告或者参加每月一次的项目决策会议、高级经理们是不能获得这些必需的知识的。他们需要投入更多的时间来了解他们所管理的事务，他们需要积极地参与到项目的开发当中去。
- 运行和支持组织必须投入必要的人力，来理解系统及其所使用的技术。支持人员要花时间了解系统的细微差别，这意味着他们需要在系统开发阶段就操作系统，或者由团队给予他们必要的培训。而且，运行人员对系统的安装和运作必须很精通。可以选择一到两个运行工程师，把他们包括到开发团队中，如果需要也可以投入项目的人力物力培训运行人员。除了这些手段，运行和支持人员本身还需要积极地参与到项目团队中去。
- 如果你的系统需要和其他系统集成，那么其他项目团队就需要和你们一起工作。例如：也许你的系统需要访问一个遗留系统的数据库、与一个在线系统交互、操作外部系统生成的数据文件，或者提供一个供其他系统使用的XML数据摘录。如果没有这些开发人员的积极参与，集成工作要么是变得不可能要么就会非常困难。想像一下，如果数据库的所有者拒绝提供任何相关的信息，访问一个遗留系统的数据库将会有多么困难啊！不过记住，交流可是双行道，你也要和其他团队分享有关你的系统的信息。
- 维护开发人员需要和团队一起工作以了解系统。因为你的意图是要把系统的维护工作部分或全部地移交给其他的开发人员。引进一些擅长于维护和增强现有系统的软件专家就很自然了。这样就能释放出最初的开发团队中的一些成员；而后你的团队将要和这些人一起工作，以使他们能从你手中接过这个系统。当原来的团队成员还在的时候，就应该采取措施把知识传递给新成员。一个成功的例子是：让那些原来的团队成员指导新来者，或者在开发系统新特性的时候，让他们结对工作。
3.集体所有
如果有必要的话，每个人都应该能够修改项目中的任何模型和任何制品。如果把一个数据流图画在白板上，这种方法就会带来很多好处：第一，参与该制品开发的人越多，发现相关潜在问题的可能性就越大，这就顺应了快速反馈的原则；第二，它提供了一个机会，使人们从各类模型的开发中获取经验，从而充实他们的知识工具箱，并由此使它们成为高效的敏捷建模人员--这也顺应了每个人都可以向别人学习的原则，因为他们能看到别人的工作并做出改进；第三，它使团队成员不再会情不自禁地说出这种话：“你的模型错了”，这是由于如果他们发现什么地方错了，他们就应当会去改正它，而不是抱怨了事；第四，它使人们不再有机会把某个铁定的制品加以个人化，比如说出“这个类图模型是我的小宝贝，这里面不可能有错”之类的话，这是由于没有一个制品是仅仅属于他们个人的；第五，它促进了团队成员对于系统的理解，减少了额外的文档维护工作，你也不必再依赖于某个人或者团队中的某几个人。在项目管理中有一个称为“撞车人数”的概念，它的意思是：估计一个最小人数，项目团队一旦失去这些人员，就会使自己陷入麻烦之中（例如，被卡车撞倒的人数）。如果撞车人数是一，那就是一个严重的问题；撞车人数大于或等于团队的人数则是理想的情况。集体所有能够帮助你增加项目中的撞车人数。
在那些个人的重要性超过团队的组织机构中，以及在那些强调狭隘的项目小组角色的组织机构中，采用这个实践是相当有挑战性的。人们需要接受这样的观点：他们所开发的制品是整个项目组的财富。他们还应当从事广泛的工作--不要只停留在用户界面上，或者是单个子系统上，抑或是系统集成的代码上。
4.公开展示模型
你应当公开展示模型，通常是在“建模之墙”或“奇迹之墙”（Gottesdicner 2001）上展示。这就在团队中遵循了开放和诚实的交流这一原则，因为当前所有的模型对他们都是伸手可及的。这对项目关系人也是一样的，因为你没有向他们隐藏什么。建模之墙是张贴自己的模型提供大家查看的地方，所有的开发人员和项目关系人都应该能够看到。建模之墙可以是实际存在的，也许是一块专门用来绘制架构图的白板，或是用于粘贴打印出来的物理数据模型的地方；建模之墙也可以是虚拟的，例如一个随时更新的、存放着扫描图片的内部网页。
这项实践还有进一步的好处：能向项目关系人展示你正在进行一项很有价值的工作--这一切就在他们眼前。当第一次开发简单模型并且担心可能不能够增添同以往一样的价值（由于缺乏数量）的时候，这样做就特别有益处。把几个简单模型展示在公用的墙面上，长此以往就能体现出你的贡献。
对某些公司而言，实施者项实践可能有些困难。有些公司的可用墙面不多；有些公司中开发队伍使用者相对开发的区域，公司的客户甚至竞争对手都可能从墙旁走过，而你又不希望他们看到工作进度；或者在某些情况下，公司对墙壁装饰进行了重大投资（比如那些装饰着像木护墙板的法律事务所），而你又不想损坏它。如果发生了上述情况，最好考虑把队伍搬到另一个地方去。此外，文化因素（比如不愿意和团体以外的人分享信息）也会妨碍这项实践。如果是这种情况，建议要鼓足勇气去实施这项实践。
作者：银月莲
出处：http://www.cnblogs.com/moonsilvering
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，包括文章，代码，图片等本站内所有资源，否则保留追究法律责任的权利。
