在UP项目中采用AM
For an UP project team to adopt AM they will need to overcome the common misconceptions that developers have about the UP as well as several cultural barriers that are common within organizations that instantiate the UP. they need to begin by thinking outside of the current UML-centric nature of the UP. To do this, you should:
对于一个要采用AM的UP项目团队，他们需要克服开发人员对UP的共同误解以及实现UP的组织内部存在的文化障碍，因为他们需要一开始就从当前UP的UML核心性质的外部来思考。他们应该：
1.Forget the term ：use-case driven. Yes, it’s a wonderful marketing term but the reality is that use cases aren’t sufficient to drive much of anything. Use cases are a good technique to document behavioral requirements but that’s only a small part of the functional requirements picture and an even smaller part of the total requirements picture，they aren’t very good at documenting business rules, user interface requirements, constraints, or non-functional requirements，which is why the UP includes something called a supplementary specification to contain all these other things. Requirements drive things, use cases don’t. Your modeling efforts will always remain hobbled if you don’t separate the UP’s software engineering wheat from its marketing-rhetoric chaff.
1.忘掉术语：用况驱动 是的，它是一个极好的市场术语，但实际上用况不足以驱动很多东西。用况是一种记录行动需求的好技术但它只是功能需求图甚至更小的全部需求图的一小部分。它们不适合记录业务规则、用户界面需求、约束或非功能需求。这就是为什么UP要包括称为辅助说明书以描述所有这些东西的原因。需求驱动着事物，而不是用况。如果你不把UP软件工程从它的花哨的市场用语中分离，你的建模工作会进展缓慢。
2.Recognize that there are more modeling artifacts than those described by the UML. AM’s principle Multiple Models tells you that you have many modeling artifacts at your disposal——change cases, user stories, business rules, UML activity diagrams, UML class diagrams, data models, and external interface specifications ——to name a few (these artifacts and more are described here). An interesting implication of this principle is that you have far more than just the diagrams of the UML at your disposal. The good news is that the UP recognizes that a wide range of models is needed to explore the complexities of modern software, recent versions do in fact include data modeling and user interface design activities that are currently outside the scope of the UML [1], the bad news is that it many people erroneously perceive that the UP is simply a process for using the UML.
2.认识到UML描述的之外还有很多建模工件 多重模型是AM的原则，它告诉你可以拥有受你控制的很多建模工件，变更情况、用户故事、业务规则、UML活动图、UML类图、数据模型以及外部接口规约等等。该原则的有趣含义是你可以在UML图之外拥有很多模型。有个好消息，UP认识到需要大量模型来探讨当今软件的复杂性，最近的版本也确实包含了在UML范围之外的数据建模和用户界面设计活动。但不好的消息是，很多人错误的认为UP就是使用UML的简单过程。
3.Recognize that the UP is not inherently documentation centric. The UP is actually very clear that you should only develop the artifacts that you actually need, however, this is good message is something that often gets missed by many software professionals so it is something that is worth repeating here. You should question every single model that the UP suggests creating because it purposely describes a wide variety of artifacts, many of which your project simply doesn’t need. The UP includes three major sets of modeling-oriented artifacts——the business modeling set, the requirements set, and the analysis & design set——each of which in turn is composed of several detailed artifacts. For example the business modeling set includes a business use-case model, business rules, a business architecture document, and a business supplementary specification. Do you actually need all of these things? Likely not. If you do need them, do you need them as formal documentation? Likely not. Communicate AM’s Travel Light and Model With a Purpose principles to your project stakeholders, as well as the practices Update Only When It Hurts and Discard Temporary Models.
3.认识到UP并不是天生以文档为中心的 UP实际上很明确地指出你应该只开发你实际需要的工件。但是，这条信息总是被很多软件专业人员误解，因此这里需要重新强调一下。你应该对每个UP建议的单个模型存疑，因为它的目的是描述很多种工件，而其中很多是你的项目不需要的。UP包括三种主要的面向建模的工件集——业务建模集、需求集和分析设计集。每一个又由若干详细的工件组成。比如，业务建模集包含业务用况模型、业务规则、业务架构文档以及业务辅助说明书。你真的需要所有这些东西吗？很可能不是。如果你确实需要，那你真的需要把它们作为正式文档吗？很可能也不是。与你的项目干系人沟通AM的轻装进行与有目的建模的原则，以及只在损害时更新与抛弃临时模型的实践吧。
4.Build a common process vision between developers and project stakeholders. Managers often tend towards a prescriptive software process, something that appears well defined and comprehensive such as the UP, one with a perceived focus on control. Developers, on the other hand, gravitate towards agile techniques such as XP and AM due to their perceived focus on what is important to developers: building software. Because management holds the purse strings many developers find themselves in a situation where their managers have chosen to adopt the UP and are now being required to follow it. Luckily the UP is flexible enough that it can be tailored to be reasonably agile, but to do so developers and project stakeholders will need to come to an agreement as to the extent of the tailoring.
4.在开发人员和项目干系人之间构建通用过程视图 管理者通常喜欢一个可描述的软件工程，它表现为定义良好和易于理解，比如，强调在控制上可感知的UP。另一方面，开发人员却喜欢敏捷技术，比如，XP和AM，因为它们强调对开发人员的重要的事情：构建软件。由于管理者掌握着实权，很多开发人员发现他们处于一个由他们的管理者选择采用UP而自己必须遵循的境地。幸好，UP是足够灵活的，它能被剪裁得适度敏捷。但要这么做的话，开发人员和项目干系人需要对剪裁程度达成一致。
5.Actively promote iterative and incremental development. Agile Modeling’s practices of Model in Small Increments, Iterate to Another Artifact and Create Models in Parallel can be tough ones for experienced modelers to adopt and chances are that your experienced modelers are already chaffing at the UP’s concepts of iterations, let alone an even greater emphasis on iterative and incremental modeling. Traditional modeling techniques often promoted a single artifact approach, such as use-case modeling or user-interface prototyping sessions, and often even modelers that focused, for example data modelers. Also, they often promoted a Big Design Up Front (BDUF) approach where you modeled everything in detail before you started coding. These concepts were great in theory, focusing on a single artifact at a time should have allowed the modelers to get it right quickly, but unfortunately practice shows this not to be the case. A good way to ease into these practices is instead of use-case modeling sessions instead run requirements modeling sessions where you work on use cases, Class Responsibility Collaborator (CRC) cards, business rules, and user interface prototypes simultaneously. Similarly, hold analysis sessions where you are use case modeling, sequence diagramming, user interface prototyping, and class modeling may make sense, and design sessions where you are class modeling, state chart modeling, data modeling, component modeling, user interface prototyping, and hopefully even developing business code. Once you are comfortable with these practices the next step is to then merge your modeling efforts in with your implementation efforts, applying multiple artifacts including all your potential models, source code, and test cases as needed ， truly iterative development. While you are doing this, keep their focus on the requirements that you are implementing in the current iteration, resulting in an incremental delivery of functionality each iteration.
5.积极促进迭代增量开发 敏捷建模有个实践，以小增量迭代的方式建模到另一个工件以及并行创建模型，它们被有经验的建模人员坚持采用，并成为有经验的建模人员嘲讽UP迭代概念的机会，而并不在意那甚至是一个更加强调迭代和增量建模过程。传统的建模技术通常采用单一工件方法，比如，用况建模或用户界面原型会谈，以及建模人员经常使用的方法，比如，数据模型。此外，它们通常采用预先大量设计(Big Design Up Front,BDUF)的方法在开发编码之前就对每件事物详细建模。这些概念在理论上很重要，它们一次只关注一个单独的工件，可以使建模人员迅速工作，但是不幸的实践表明这样做并不好。一种好的易于实践的方法取代了用况建模会谈，并且在你使用用况的地方不使用需求建模。它同时采用类-职责-协作(Class Responsibility Collaborator，CRC)卡，业务规则以及用户界面原型。类似地，在你进行用况建模、顺序图，用户界面原型设计的地方分析会谈，然后进行有意义的类建模，再在你进行类建模、表建模、数据建模、组件建模、用户界面原型设计的地方设计会谈，这样就甚至能开发出业务代码。一旦对这些实践满意了，下一步就是合并你的建模工作以及实现工作，应用多种工件包括所有潜在模型、代码以及测试用例。这才是真正的迭代开发。当你这么做时，把他们的关注保持在你正在实现的当前迭代的需求上，这样的结果就是每次迭代都能增量交付功能。
6.Actively promote simplicity. Simplicity is a fundamental value of AM, one that motivates several critical principles that can dramatically improve the effectiveness of your modeling efforts. Many experienced modelers want to specify everything they possibly can, for example, not only do they wish to model the overall structure of their software in UML class diagrams they also want to specify the scaffolding code needed to implement that structure. This is a lot of effort which provides very little actual value. A better approach is to create a class diagram that is just barely good enough for your purpose, to depict the likely structure of your classes, and then start coding from there. Agile modelers assume that the programmers, often themselves, can figure out the details at the time and instead will focus on issues that may not be so obvious. This approach implies less work for the modeler and less modeling noise for the actual programmer to wade through. When an agile modeler is creating a class diagram they realize that they don’t need to model all of the classes required to build the software, instead they focus on getting the core classes right and assume that the programmers are competent enough to handle the rest [2]. By keeping your models simple you are likely to work faster while at the same time create something that is actually of value to your programmers——models that focus on critical issues that are devoid of fluff.
6.积极促进简单化 简单是AM的基本价值。由此引出了若干关键原则，它们能极大地改进你的建模效率。很多有经验的建模人员想确定他们可以确定的每件事，比如，他们不仅想用UML类图做出软件整体结构的模型，还想确定实现这个结构的代码框架。这花了很多精力但实际价值却很小。一个更好的办法是创建一个仅仅够用的类图来描述类的结构，然后从这里开始编码。敏捷建模人员假定程序员能够自己在此时编写细节部分，而不关注现在还不明显的事情。这种方法减少了建模人员的工作量，也为程序员降低了读懂模型的难度。当敏捷建模人员开始创建类图时，他们应该意识到他们不需要为构建软件需要的所有类都建模，取而代之的是关注正确地得到核心类并假定程序员有足够能力处理剩余的类。通过使你的模型简单化，你会工作的更快，因为你创建的模型是对程序员实际有价值的东西。它们强调关键事物而没有多余的东西。
7.Staff projects with skilled generalists. Many organizations have separate positions for modelers, motivating their staff to focus on specialties, a practice that in my experience reduces your ability to be agile. Although the UP is very clear that individual developers can and should take multiple roles on a project my experience is that this is advice that falls on deaf ears within many organizations. Instead what happens is that organizations adopting the UP tend to introduce positions along the lines of UP’s modeling roles ,for example Requirements Specifier, System Analyst, User-Interface Designer, Database Designer , and therefore slots people into individual roles, going against the advice of both AM and the UP. If your only job on a software project is to produce models then there is a tendency for you to over model things, first because you naturally want to do a good job and second because if it’s your job to model then that means it’s likely someone else’s job not to model (e.g. their job is to program). Because there is a hand-off there is now greater motivation to add greater detail into your model, details that likely wouldn’t be needed if the people writing the code also developed the models that helped them to identify what needed to be coded in the first place.
7.让人员在项目中成为多面手 很多组织为建模人员设置单独职位，使他们的员工专注于工作。在我的经验中，这种实践其实降低了你的敏捷能力。尽管UP明确的指出单独的开发人员在项目中能够承担多种角色，但我是经验却是这个建议被很多组织置之不理。取而代之的是，他们采用UP倾向于比照UP的全程建模角色引入职位，比如需求确定人员、系统分析员、用户界面设计员、数据库设计员。因此，个人角色很狭窄，这就违反了AM与UP的建议。如果你仅仅在软件项目中做建模工作，那么你会有过分建模的倾向。首先，因为你很自然的想要做好工作。其次，因为如果建模是你的事，那就以为着它不是其它人的事(他们的事是编程)。由于建模是举手之劳，于是有更多冲动给你的模型添加细节。而如果写代码的人也是开发模型的人，这样就帮助他们在第一时间知道何处需要编码，因而这些细节也就不必要了。
8.Live AM’s principle of Open and Honest Communication. I’ve run into several situations where a development team was reluctant to follow the Display Models Publicly practice, one way to promote open and honest communication with people external to your team, often because they were afraid of what another political faction within the organization would do with the information. However, when they finally worked up the courage to display their models publicly they quickly discovered that the politicos they were so afraid of couldn’t find much to criticize, and when they did this was great input that the developers quickly acted on and benefited from.
8.生动的AM开放且坦诚沟通原则 我遇到过几次这样的情形，开发团队不情愿地遵循公开展示模型实践。改进的方法是与你团队之外的人进行开放且坦诚的沟通，因为他们通常会担心组织内的其它行政团体利用这些信息。然而，当他们最后鼓起勇气公开展示模型时，他们很快发现令他们那样担心的人其实很难做出批评，而且当他们这么做的时候，开发人员迅速也就从中受益了。
How Does This Work?
如何才会有效？
It is clearly possible to tailor the Unified Process (UP) with the practices of Agile Modeling (AM). To succeed, your organization’s culture must be receptive to both the UP and to AM, and therein lies the rub——the goal of organizations that adopt the UP is often to instantiate it as a fairly rigid and prescriptive process whereas organizations that adopt AM typically want to work in a more fluid manner (in fact, to be truly effective AM requires such an environment). Luckily the UP is flexible enough so that it can be instantiated to be reasonably agile: as Robert Martin (2001), Gary Evans (2001), and Craig Larman (2002) show with their instantiations of the UP. When this is the case, when you have instantiated a light-weight version of the UP, then the UP and AM fit together well. Both the UP and AM are based on the idea that the majority of software is best delivered iteratively and incrementally. Because the UP explicitly includes modeling disciplines it is very easy to identify where AM practices should be used to enhance your own tailoring of the UP. This works when your project team and your project stakeholders choose to make it work.
按AM的实践剪裁UP是有可能的。要想成功，你的组织的文化必须能同时接受UP和AM，也存在冲突——组织采用UP的目的通常是以一种非常严格和可描述的过程来实现它，而采用AM的典型目的是希望以更平滑的方式工作(事实上，真正有效的AM需要这样的一个环境)。正如Robert Martin (2001), Gary Evans (2001), and Craig Larman (2002)在他们的UP实现中展示的：幸运的是，UP是足够灵活的以至于它能够被相当敏捷的实现。当在这种情形下，当你已经实现过轻量级的UP版本时，UP和AM会配合的很好。UP和AM都基于同样的理念，软件的主体最好以迭代和增量的方式交付.因为UP显式地包括了建模律条,因此它非常容易确定在何处要应用AM实践以提升你对UP的剪裁。它会随着你的项目团队和你的项目干系人选择它而生效。
References and Suggested Reading
参考文献和推荐文章
· See the references page.
· Agile Modeling Home Page
· Agile Modeling Essays
文章来源于领测软件测试网 https://www.ltesting.net/
