Agile Model Driven Development (AMDD): The Key to Scaling Agile Software Development
敏捷模型驱动开发（AMDD）：攀登敏捷软件开发的关键
Table of Contents 目录
- Overview 概述
-
Envisioning 展望
- Initial agile requirements modeling 初始化敏捷需求建模
- Initial agile architecture modeling 初始化敏捷架构建模
- Iteration Modeling 迭代模型
- Model storming 模型暴风
- Executable specification via TDD 通过测试驱动开发的可执行规范
- Reviews 评论
- How is AMDD different? 敏捷模型驱动开发有何不同？
- Why does this work? 它为何这样做？
- Approaches to AMDD 走进敏捷模型驱动开发
1. Overview 概述
As the name implies, AMDD is the agile version of Model Driven Development (MDD). MDD is an approach to software development where extensive models are created before source code is written. A primary example of MDD is the Object Management Group (OMG)’s Model Driven Architecture (MDA) standard. With MDD a serial approach to development is often taken, MDD is quite popular with traditionalists, although as the RUP/EUP shows it is possible to take an iterative approach with MDD. The difference with AMDD is that instead of creating extensive models before writing source code you instead create agile models which are just barely good enough that drive your overall development efforts. AMDD is a critical strategy for scaling agile software development beyond the small, co-located team approach that we saw during the first stage of agile adoption.
顾名思义，AMDD是敏捷模型驱动开发（MDD）的版本。 MDD是一个广泛的模型创建之前被写入源代码的软件开发方法。 MDD的一个主要的例子是对象管理组（OMG）的模型驱动架构（MDA）的标准。 MDD是串行的发展方针与MDD往往采取与传统主义者颇为流行，虽然RUP/ EUP指令表明它是可能采取的迭代与MDD方法。 AMDD差异，而不是建立广泛的模型，编写源代码之前，你只是勉强足够好来带动整体发展努力，而不是创造敏捷模型。 AMDD是攀登敏捷软件开发超越小规模的一个重要战略，共设团队接近于我们看到在第一阶段采用敏捷。
Figure 1 depicts a high-level lifecycle for AMDD for the release of a system. First, let’s start with how to read the diagram. Each box represents a development activity. The envisioning includes two main sub-activities, initial requirements envisioning and initial architecture envisioning. These are done during iteration 0, iteration being another term for cycle or sprint. “Iteration 0” is a common term for the first iteration before you start into development iterations, which are iterations one and beyond (for that release). The other activities – iteration modeling, model storming, reviews, and implementation – potentially occur during any iteration, including iteration 0. The time indicated in each box represents the length of an average session: perhaps you’ll model for a few minutes then code for several hours. I’ll discuss timing issues in more detail below.
图1描绘了一个发布系统AMDD高层次的生命周期。首先，让我们先从如何阅读图表。每个方块代表一个开发活动。构想包括两大子活动，最初的需求构想和初步的建筑构想。这些都是做在迭代过程中，迭代是另一个长期的循环或冲刺。 “迭代0”是第一次迭代之前，你开始进入开发迭代，这是迭代和超越（该版本）的常用词。 - 迭代建模，模型暴风，审核，和实施的其他活动 - 可能发生在任何迭代，包括迭代0。在每个方块中显示的时间平均会话长度：也许你几分钟，然后几个小时的代码模型。我将在下面更详细地讨论时机的问题。
Figure 1. The AMDD lifecycle: Modeling activities throughout the lifecycle of a project.
图1。AMDD的生命周期：建模活动，整个项目的生命周期。
Figure 2 depicts how the AMDD activities fit into the various iterations of the agile software development lifecycle. It's simply another way to show that an agile project begins with some initial modeling and that modeling still occurs in each construction iteration.
图2描绘了AMDD活动如何适应敏捷软件开发生命周期的各种迭代。它只是另一种方式表明，一个敏捷项目开始一些初步的造型，模型仍然出现在每一个构造迭代。
Figure 2. AMDD Through the Agile Development Lifecycle.
图2。AMDD通过敏捷开发生命周期。
2. Envisioning 展望
The envisioning effort is typically performed during the first week of a project, the goal of which is to identify the scope of your system and a likely architecture for addressing it. To do this you will do both high-level requirements modeling and high-level architecture modeling. The goal isn't to write detailed specifications, that proves incredibly risky in practice, but instead to explore the requirements and come to an overall strategy for your project. For short projects (perhaps several weeks in length) you may do this work in the first few hours and for long projects (perhaps on the order of twelve or more months) you may decide to invest two weeks in this effort. I highly suggest not investing any more time than this as you run the danger of over modeling and of modeling something that contains too many problems (two weeks without the concrete feedback that implementation provides is a long time to go at risk, in my opinion).
“构想的努力通常在第一周的一个项目，其中的目标是要找出解决您的系统的范围和可能的架构。要做到这一点，你会做高级别要求的造型和高层次的架构建模。我们的目标不是写的详细规格，在实践中证明了令人难以置信的冒险，而是探索的要求，来为您的项目的总体战略。对于短期项目（也许是在几个星期长度），你可以这样做这项工作，在最初的几个小时，长的项目（也许是十二个或更多个月的顺序），您可能会决定投资在这方面的努力两个星期。我强烈建议不投资任何超过这个时间，为您运行包含了太多的问题（两个星期没有具体的反馈，去的危险，在我看来，实施提供了建模和建模的东西如果是在很长时间的越有危险） 。
|
2.1 Initial Requirement Modeling 初始化需求建模
For the first release of a system you need to take several days to identify some high-level requirements as well as the scope of the release (what you think the system should do). The goal is to get a good gut feel what the project is all about. For your initial requirements model my experience is that you need some form of usage model to explore how users will work with your system, an initial domain model which identifies fundamental business entity types and the relationships between then, and an initial user interface modelwhich explores UI and usability issues.
你需要一个系统，需要几天的时间，以确定一些高层次的要求，以及发布（你认为应该做的系统）的范围为首次发布。我们的目标是获得良好的直觉感觉是什么项目。最初的要求为您的模型，我的经验是，你需要某种形式的使用模式，探索用户将如何与您的系统工作，初始域标识基本业务实体类型间关系的模型，和一个初始的用户界面模型探讨UI和可用性问题。
I cannot say this enough: your goal is to build a shared understanding, it isn’t to write detailed documentation. A critical success factor is to use inclusive modeling techniques which enable active stakeholder participation.
我不能说这就够了：你的目标是建立一个共同的理解，这是不写详细的文档。成功的关键因素是使用包容性的建模技术，使利益有关者积极参与。
2.2 Initial Architecture Modeling 初始化架构建模
The goal of the initial architecture modeling effort is to try to identify an architecture that has a good chance of working. This enables you to set a (hopefully) viable technical direction for your project and to provide sufficient information to organize your team around your architecture (something that is particularly important at scale with large or distributed teams).
最初的架构建模工作的目标是，试图找出一个架构，有一个良好的工作机会。这使您可以设置为您的项目（有希望的）可行的技术方向，并提供足够的信息来组织你的团队围绕你的架构（一些大型或分布式团队的规模，这一点尤其重要）。
On the architecture side of things I’ll often create free-form diagrams which explore the technical infrastructure, initial domain models to explore the major business entities and their relationships, and optionally change cases to explore potential architecture-level requirements which your system may need to support one day. In later iterations both your initial requirements and your initial architect models will need to evolve as you learn more, but for now the goal is to get something that is just barely good enough so that your team can get going. In subsequent releases you may decide to shorten iteration 0 to several days, several hours, or even remove it completely as your situation dictates. The secret is to keep things simple. You don’t need to model a lot of detail, you simply need to model enough. If you’re writing use cases this may mean that point-form notes are good enough. If you’re domain modeling a whiteboard sketch or collection of CRC cards is likely good enough. For your architecture a whiteboard sketch overviewing how the system will be built end-to-end is good enough.
架构上的东西方，我会经常创建*格式的图表，探索技术基础设施，最初的域模型，探讨的主要业务实体和它们之间的关系，并选择性地改变的情况下，以发掘潜在的架构级别要求您的系统可能需要支持一天。在以后的迭代中，您最初的要求和您最初的构建模型将需要发展，因为你了解更多，但现在的目标是要得到的东西，只是勉强地足够好来使你的团队可以得到。在以后的版本中，你可以决定缩短迭代0至数天，数小时，甚至完全消除它作为您的具体情况决定。秘诀是让事情变得简单。你不需要模拟了很多细节，你只需要足够的模型。如果你写的使用情况，这可能意味着点的形式说明是不够好。如果你是域建模白板草图或CRC卡的集合可能是足够好。白板草图概览系统如何将建成年底到年底，为你的架构是足够好的。
Many traditional developers will struggle with an agile approach to initial modeling because for years they’ve been told they need to define comprehensive models early in a project. Agile software development isn’t serial, it’s iterative and incremental (evolutionary). With an evolutionary approach detailed modeling is done just in time (JIT) during development iterations in model storming sessions.
因为多年来，他们已经被告知，他们需要在一个项目中定义的综合模型早期，许多传统的开发将努力与初步建模敏捷方法。敏捷软件开发是不是串行的，它是迭代和增量（进化）。随着进化的方法进行详细的建模模型在发展过程中迭代暴风session中实时（JIT）地被完成。
3. Iteration Modeling: Thinking Through What You'll Do This Iteration
迭代建模：思考你会做通过这个迭代做什么
At the beginning of each Construction iteration the team must plan the work that they will do that iteration. An often neglected aspect of Mike Cohn’s planning poker is the required modeling activities implied by the technique. Agile teams implement requirements in priority order, see Figure 3, pulling an iteration's worth of work off the top of the stack. To do this successfully you must be able to accurately estimate the work required for each requirement, then based on your previous iteration's velocity (a measure of how much work you accomplished) you pick that much work off the stack. For example, if last iteration you accomplished 15 points worth of work then the assumption is that all things being equal you'll be able to accomplish that much work this iteration. This activity is often referred to as the "planning game" or simply iteration planning.
在每个施工迭代开始时，团队必须规划的工作，他们会做迭代。 Mike Cohn的规划牌往往被忽视的一个方面是必要的建模技术所隐含的活动。敏捷团队中的优先顺序实施的要求，见图3，脱下堆栈顶部的一个迭代的工作值得。要成功地做到这一点，你必须能够准确地估计每个要求所需的工作，然后根据你上一次迭代的速度（衡量你有多少工作完成）你摘下堆栈的许多工作。例如，如果你最后一次迭代完成15分价值的工作，然后假设是，所有的事情都是平等的，你就可以完成许多工作，本次迭代。这一活动通常被称为“规划游戏”或简单迭代计划。
Figure 3. Agile requirements change management process.
图3。敏捷的需求变更管理流程。
To estimate each requirement accurately you must understand the work required to implement it, and this is where modeling comes in. You discuss how you're going to implement each requirement, modeling where appropriate to explore or communicate ideas. This modeling in effect is the analysis and design of the requirements being implemented that iteration.
要准确估计每个要求，你必须了解实施所需的工作，这就是建模。你讨论你打算如何实现每个需求，建模在适当探讨或交流思想。这实际上建模是正在实施的迭代需求的分析和设计。
|
4. Model Storming: Just In Time (JIT) Modeling
模型风暴：实时(JIT)模型
My experience is that the vast majority of modeling sessions involve a few people, usually just two or three, who discuss an issue while sketching on paper or a whiteboard. These “model storming sessions” are typically impromptu events, one project team member will ask another to model with them, typically lasting for five to ten minutes (it’s rare to model storm for more than thirty minutes). The people get together, gather around a shared modeling tool (e.g. the whiteboard), explore the issue until they're satisfied that they understand it, then they continue on (often coding). Model storming is just in time (JIT) modeling: you identify an issue which you need to resolve, you quickly grab a few team mates who can help you, the group explores the issue, and then everyone continues on as before. Extreme programmers (XPers) would call modeling storming sessions stand-up design sessions or customer Q&A sessions.
我的经验是，绝大多数的建模会议涉及几个人，通常只有两个或三个，讨论一个问题，而在纸上或白板素描。这些“模型风暴会议”通常是即兴的事件，一个项目团队成员将要求与他们的另一种模式，通常持续五到十分钟（这是罕见的模型风暴超过30分钟）。人们聚在一起，围绕一个共同的建模工具收集（如白板），探讨这个问题，直到他们满意，他们理解它，然后他们继续上（通常是编码）。模型风暴，是实时（JIT）建模：你确定你需要解决的一个问题，你快抓住几个队友可以帮助你的人，该组探讨的问题，然后大家继续像以前一样。 （XPers）极限编程人员，应该称为风暴会议建模在站立式设计会议或顾客问答环节中。
5. Executable Specification via Test Driven Development (TDD)
通过测试驱动开发的可执行的规范（TDD）
During development it is quite common to model storm for several minutes and then code, following common Agile practices such as Test-First Design (TFD) and refactoring, for several hours and even several days at a time to implement what you've just modeled. For the sake of discussion test-driven design (TDD) is the combination of TFD and refactoring. This is where your team will spend the majority of its time, something that Figure 1 unfortunately doesn’t communicate well. Agile teams do the majority of their detailed modeling in the form of executable specifications, often customer tests or development tests. Why does this work? Because your model storming efforts enable you to think through larger, cross-entity issues whereas with TDD you think through very focused issues typically pertinent to a single entity at a time. With refactoring you evolve your design via small steps to ensure that your work remains of high quality.
在开发过程中是很常见的几分钟，然后代码模型风暴后，如首先试验设计（TFD的）和重构几个小时，甚至几天，在一个时间来执行你刚刚仿照常见的敏捷实践。为了讨论测试驱动设计（TDD）是TFD的和重构相结合。这是你的团队会花大部分时间，图1遗憾的是没有很好的沟通。敏捷团队做的大多数可执行的规范，往往顾客测试或开发测试的形式详细的建模。为什么这项工作？因为你的模型风暴努力，使你想通过较大，跨实体问题，而与TDD，你认为非常集中的问题，通常一次一个单一的实体有关。与重构发展，通过小的步骤，以确保您的工作仍然是高品质的设计。
TDD promotes confirmatory testing of your application code and detailed specification of that code. Customer tests, also called agile acceptance tests, can be thought of as a form of detailed requirements and developer tests as detailed design. Having tests do “double duty” like this is a perfect example of single sourcing information, a practice which enables developers to travel light and reduce overall documentation. However, detailed specification is only part of the overall picture – high-level specification is also critical to your success, when it’s done effectively. This is why we need to go beyond TDD to consider AMDD.
TDD的推广验证测试您的应用程序代码，该代码的详细规范。客户测试，也称为敏捷验收测试，可以被看作是一个详细的要求和详细设计的开发人员测试的形式。有测试做这样的“双重责任”是一个单一的来源信息，这种做法使开发人员能够轻装上阵，降低整体文档的完美的例子。然而，详细的规范，是大局的一部分 - 高层次的规范，是你的成功，有效地完成时，它也很关键。这就是为什么我们需要超越TDD去考虑AMDD。
You may even want to "visually program" using a sophisticated modeling tool such as Rational Software Architect (RSA). This approach requires a greater modeling skillset than is typically found in most developers, although when you do have teams made up with people of these skills you find that you can be incredibly productive with the right modeling tools.
你甚至可能要“视觉方案”的Rational Software Architect（RSA）的使用，如先进的建模工具。这种方法比通常在大多数开发人员发现需要一个更大的建模基本功，虽然当你有这些技能的人组成的团队，你会发现你可以令人难以置信的是用正确的建模工具的生产。
6. Reviews
评论
You may optionally choose to hold model reviews and even code inspections, but as I write in Model Reviews: Best Practices or Process Smells? these quality assurance (QA) techniques really do seem to be obsolete with agile software development, at least in the small. On larger teams, or in very complex situations, reviews can add value because when they're done right they provide excellent feedback into your IT governance efforts.
你可以选择持有模型的评价，甚至代码检查，但正如我在写模型评论：最佳实践或过程的气味？这些质量保证（QA）技术确实似乎是过时的敏捷软件开发，至少在小的团对里。在较大的团队，或在非常复杂的情况下，评论可以增加价值，因为当他们做对他们到您的IT管理工作提供了极好的反馈。
7. How is AMDD Different?
AMDD如何不同？
From a design point of view the AMDD approach of Figure 1 is very different than traditional development approaches where you create a design model first then code from it. With AMDD you do a little bit of modeling and then a lot of coding, iterating back when you need to. Your design efforts are now spread out between your modeling and coding activities, with the majority of design being done as part of your implementation efforts – in many ways this was also true for many traditional projects, the developers would often do significantly different things than what was in the design models, but the designers would often blame the developers instead of question their overly serial processes.
从设计角度的查看图1 AMDD方法比传统的开发方法，你先创建一个设计模型，然后从它的代码是非常不同的。 AMDD为你做的建模一点，然后大量的编码，迭代，当你需要。您的设计工作，现在已经蔓延之间的建模和编码活动与广大设计完成，作为执行工作的一部分， - 这是在许多方面还适用于许多传统项目，开发人员往往会做的比什么显着不同的事情在设计模型，但设计师往往会责怪开发人员，而不是问题过于序列的过程。
AMDD is different from techniques such as Feature Driven Development (FDD) or the use case driven development (UCDD) styles of EUP and Agile Unified Process (AUP) in that it doesn’t specify the type of model(s) to create. All AMDD suggests is that you apply the right artifact but it doesn’t insist on what that artifact is. For example FDD insists that features are your primary requirements artifact whereas UCDD insists that use cases are. AMDD works well with both an FDD or a UCDD approach because the messages are similar – all three approaches are saying that it’s a good idea to model before you code.
AMDD是从不同的特征驱动开发（FDD）或驱动使用情况，如技术开发（UCDD）EuP与敏捷统一过程（AUP），它不指定模式创建类型的风格。 AMDD建议是，你申请的权利的的加工品，加工品是什么，但它不坚持。例如FDD坚持特点是你的基本要求加工品，而UCDD坚持用例。 AMDD工程以及一个FDD或UCDD的做法，因为类似的消息 - 所有三种方法，说这是一个好主意，你的代码前建模。
An interesting implication of Figure 1 is that it doesn’t make sense to have people who are just modeling specialists on your development team any more. What are they going to do, model for a few minutes and then sit around for hour or days until they’re needed again? What is really needed is something I call a generalizing specialist, someone with one or more specialties as well as general skills in the entire lifecycle, who can both code and when they need to model as well.
图1中的一个有趣的含意是，它没有任何意义，只是模拟您的开发团队的专家更多的人。他们做了几分钟的模型，然后坐几个小时或几天，直到他们再次需要什么？什么是真正需要的是东西，我称之为泛化的专家，与一个或多个专业的人，以及在整个生命周期的一般技能，以及代码和当他们需要模型。
8. Why Does This Work?
为什么这样做？
AMDD works for several reasons:
AMDD工作有以下几个原因：
1.You can still meet your "project planning needs". By identifying the high-level requirements early, and by identifying a potential architecture early, you have enough information to produce an initial cost estimate and schedule.
你仍然可以达到“项目规划的需要”。由年初，年初确定一个潜在的架构确定的高层次的要求，你有足够的信息来产生初始成本估计和进度。
2.You manage technical risk. Your initial architecture modeling efforts enable you to identify the major areas of technical risk early in the project without taking on the risk of over modeling your system. It's a practical "middle of the road" approach to architectural modeling.
您管理的技术风险。您最初的建筑造型努力使你确定没有风险接管您的系统建模技术风险的主要领域，在项目的早期。这是一个实际的方法，建筑造型“中间道路”。
3.You minimize wastage. A JIT approach to modeling enables you to focus on just the aspects of the system that you're actually going to build. With a serial approach, you often model aspects of the system which nobody actually wants.
你减少浪费。 JIT的建模方法，使您专注于只是该系统的各个方面，你实际上是要建立。一个序列的方法，你经常建模的系统，该没有人真正希望的方面。
4. You ask better questions. The longer you wait to model storm a requirement, the more knowledge you'll have regarding the domain and therefore you'll be able to ask more intelligent questions.
你问更好的问题。您等待的时间越长，模拟风暴的要求，更多的知识，你就的域名，因此，你就可以问更聪明的问题。
5. Stakeholders give better answers. Similarly, your stakeholders will have a better understanding of the system that you're building because you'll have delivered working software on a regular basis and thereby provided them with concrete feedback.
利益相关者提供更好的答案。同样，你的利益相关者，将有更好地理解你，因为你已经交付工作定期的软件，从而提供具体的反馈，他们的一个系统。
9. Approaches to AMDD
AMDD方法
There are three basic approaches to applying AMDD on a project:
应用项目AMDD有三种基本方法：
1. Manual. Simple tools, such as whiteboards and paper, and inclusive models are used for modeling. This is likely 70-80% of all business application modeling efforts.
手动。简单的工具，如白板纸，和包容性的模型，用于建模。这可能是70-80％的所有业务应用的建模努力。
2. Design Tool. Inclusive models are used to explore requirements with stakeholders, and to analyze those requirements. Developers then use sophisticated modeling tool for detailed design, (re)generating source code from the models. This is likely 20-30% of all business application modeling efforts.
设计工具。包容性模型用于探索与利益相关者的要求，并分析了这些要求。开发商，然后使用先进的建模工具的详细设计，（重新）从模型生成的源代码。这可能是20-30％的所有业务应用的建模努力。
3. Agile MDA. Very sophisticated, MDA-based modeling tools used to create extensive models from which working software is generated. At best this approach will be used for 5-10% of business application modeling efforts.
敏捷MDA。非常复杂的，基于MDA建模工具，用于创建工作的软件产生了广泛的模型。充其量，这种方法将被用于业务应用的建模努力的5-10％。
Reference site: http://www.agilemodeling.com/essays/amdd.htm