Agile Model Driven Development (AMDD): The Key to Scaling Agile Software Development
靈活模型驅動開發（AMDD）：攀登靈活軟體開發的關鍵
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
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
顧名思義，AMDD是靈活模型驅動開發（MDD）的版本。 MDD是一個廣泛的模型建立之前被寫入源代碼的軟體開發方法。 MDD的一個主要的例子是對象管理組（OMG）的模型驅動架構（MDA）的标準。 MDD是串行的發展方針與MDD往往采取與傳統主義者頗為流行，雖然RUP/ EUP指令表明它是可能采取的疊代與MDD方法。 AMDD差異，而不是建立廣泛的模型，編寫源代碼之前，你隻是勉強足夠好來帶動整體發展努力，而不是創造靈活模型。 AMDD是攀登靈活軟體開發超越小規模的一個重要戰略，共設團隊接近于我們看到在第一階段采用靈活。
in more detail below.
圖1描繪了一個釋出系統AMDD高層次的生命周期。首先，讓我們先從如何閱讀圖表。每個方塊代表一個開發活動。構想包括兩大子活動，最初的需求構想和初步的建築構想。這些都是做在疊代過程中，疊代是另一個長期的循環或沖刺。 “疊代0”是第一次疊代之前，你開始進入開發疊代，這是疊代和超越（該版本）的常用詞。 - 疊代模組化，模型暴風，稽核，和實施的其他活動 - 可能發生在任何疊代，包括疊代0。在每個方塊中顯示的時間平均會話長度：也許你幾分鐘，然後幾個小時的代碼模型。我将在下面更詳細地讨論時機的問題。
Figure 1. The AMDD lifecycle: Modeling activities throughout the lifecycle of a project.
圖1。AMDD的生命周期：模組化活動，整個項目的生命周期。
initial modeling and that modeling still occurs in each construction iteration.
圖2描繪了AMDD活動如何适應靈活軟體開發生命周期的各種疊代。它隻是另一種方式表明，一個靈活項目開始一些初步的造型，模型仍然出現在每一個構造疊代。
Figure 2. AMDD Through the Agile Development Lifecycle.
圖2。AMDD通過靈活開發生命周期。
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
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).
“構想的努力通常在第一周的一個項目，其中的目标是要找出解決您的系統的範圍和可能的架構。要做到這一點，你會做進階别要求的造型和高層次的架構模組化。我們的目标不是寫的詳細規格，在實踐中證明了令人難以置信的冒險，而是探索的要求，來為您的項目的總體戰略。對于短期項目（也許是在幾個星期長度），你可以這樣做這項工作，在最初的幾個小時，長的項目（也許是十二個或更多個月的順序），您可能會決定投資在這方面的努力兩個星期。我強烈建議不投資任何超過這個時間，為您運作包含了太多的問題（兩個星期沒有具體的回報，去的危險，在我看來，實施提供了模組化和模組化的東西如果是在很長時間的越有危險）
。
Through initial, high-level modeling you can gain the knowledge that you need to guide the project but choose to wait to act on it.
通過初步的，高層次的模組化，你可以得到你需要的知識，引導項目，但選擇等待行事。
For the first release of a system you need to take several days to identify some
你需要一個系統，需要幾天的時間，以确定一些高層次的要求，以及釋出（你認為應該做的系統）的範圍為首次釋出。我們的目标是獲得良好的直覺感覺是什麼項目。最初的要求為您的模型，我的經驗是，你需要某種形式的使用模式，探索使用者将如何與您的系統工作，初始域辨別基本業務實體類型間關系的模型，和一個初始的使用者界面模型探讨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
我不能說這就夠了：你的目标是建立一個共同的了解，這是不寫詳細的文檔。成功的關鍵因素是使用包容性的模組化技術，使利益有關者積極參與。
最初的架構模組化工作的目标是，試圖找出一個架構，有一個良好的工作機會。這使您可以設定為您的項目（有希望的）可行的技術方向，并提供足夠的資訊來組織你的團隊圍繞你的架構（一些大型或分布式團隊的規模，這一點尤其重要）。
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
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
因為多年來，他們已經被告知，他們需要在一個項目中定義的綜合模型早期，許多傳統的開發将努力與初步模組化靈活方法。靈活軟體開發是不是串行的，它是疊代和增量（進化）。随着進化的方法進行詳細的模組化模型在發展過程中疊代暴風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
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.
要準确估計每個要求，你必須了解實施所需的工作，這就是模組化。你讨論你打算如何實作每個需求，模組化在适當探讨或交流思想。這實際上模組化是正在實施的疊代需求的分析和設計。
初始疊代模組化與你探索你所需要的建立，使您可以評估和規劃工作。
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
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）極限程式設計人員，應該稱為風暴會議模組化在站立式設計會議或顧客問答環節中。
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
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
modeling tools.
你甚至可能要“視覺方案”的Rational Software Architect（RSA）的使用，如先進的模組化工具。這種方法比通常在大多數開發人員發現需要一個更大的模組化基本功，雖然當你有這些技能的人組成的團隊，你會發現你可以令人難以置信的是用正确的模組化工具的生産。
You may optionally choose to hold model reviews and even code inspections, but as I write in
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管理工作提供了極好的回報。
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為你做的模組化一點，然後大量的編碼，疊代，當你需要。您的設計工作，現在已經蔓延之間的模組化和編碼活動與廣大設計完成，作為執行工作的一部分， - 這是在許多方面還适用于許多傳統項目，開發人員往往會做的比什麼顯着不同的事情在設計模型，但設計師往往會責怪開發人員，而不是問題過于序列的過程。
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的做法，因為類似的消息 - 所有三種方法，說這是一個好主意，你的代碼前模組化。
圖1中的一個有趣的含意是，它沒有任何意義，隻是模拟您的開發團隊的專家更多的人。他們做了幾分鐘的模型，然後坐幾個小時或幾天，直到他們再次需要什麼？什麼是真正需要的是東西，我稱之為泛化的專家，與一個或多個專業的人，以及在整個生命周期的一般技能，以及代碼和當他們需要模型。
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
你仍然可以達到“項目規劃的需要”。由年初，年初确定一個潛在的架構确定的高層次的要求，你有足夠的資訊來産生初始成本估計和進度。
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
你減少浪費。 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
利益相關者提供更好的答案。同樣，你的利益相關者，将有更好地了解你，因為你已經傳遞工作定期的軟體，進而提供具體的回報，他們的一個系統。
應用項目AMDD有三種基本方法：
手動。簡單的工具，如白闆紙，和包容性的模型，用于模組化。這可能是70-80％的所有業務應用的模組化努力。
application modeling efforts.
設計工具。包容性模型用于探索與利益相關者的要求，并分析了這些要求。開發商，然後使用先進的模組化工具的詳細設計，（重新）從模型生成的源代碼。這可能是20-30％的所有業務應用的模組化努力。
靈活MDA。非常複雜的，基于MDA模組化工具，用于建立工作的軟體産生了廣泛的模型。充其量，這種方法将被用于業務應用的模組化努力的5-10％。