Better Software - June 2008 - (Page 23)

D espite what you may have heard, modeling is an important part of agile software development. Sadly, it doesn’t get a lot of attention, even though it’s a fundamental technique for scaling agile to meet the needs of the real-world situations in which project teams regularly find themselves. It pays to think before you act, and modeling enables you to think through the critical, high-level issues that other techniques struggle to address. This article overviews agile modeldriven development (AMDD), showing how modeling fits into the overall agile software development lifecycle. We also share industry statistics regarding modeling on agile projects and discuss three tooling strategies that you may want to consider. We walk through an example of modeling on the development of a business application and end with a discussion of the trade-offs of agile modeling. • At the beginning of each iteration. Agile teams are self-organizing by nature, with detailed project planning done at the beginning of each iteration. To accurately estimate the effort needed to implement a requirement, the team often will discuss its strategy for doing so, frequently using an inclusive modeling tool such as a whiteboard or paper. (Yes, sketching on whiteboards, writing user stories on index cards, or using sticky notes to lay out a screen or report are all modeling activities.) • Just in time (JIT) throughout the iteration. Developers, even when pair programming, will “model storm” on a JIT basis to think through an issue pertaining to what they’re about to build. These model-storming efforts are often short—usually fewer than ten minutes in length—and are focused on a specific issue. Figure 1 also shows how AMDD and test-driven development (TDD) work together. TDD is a detailed specification technique and a confirmatory testing technique and is proving to be incredibly effective. But TDD isn’t sufficient for all of your specification and testing needs; you also need to think through high-level issues and test beyond the confirmatory level. To scale TDD you need something like AMDD to think through the high- and medium-level requirements and design issues and independent, investigative testing efforts [3]. Agile MoDel-Driven DevelopMent The Agile Modeling (AM) method, introduced in late 2001, describes a collection of principles and practices for effective modeling and documentation on agile projects [1]. The AMDD lifecycle was introduced in 2004 [2], and newer updates have been published online since then. Figure 1 depicts the current AMDD lifecycle, showing that there are three fundamental modeling points throughout the development process: • At the beginning of the project. Someone is always going to ask you how much you think the project will cost, how long you think it will take, what you think you’re going to build, and how you think you’re going to do it. To answer these questions you’re going to need to do some initial requirements and architectural envisioning. This is done during the first iteration of the project, sometimes referred to as iteration 0 in methods without specific project phases, as the warm up iteration in the Eclipse Way, and as the Inception phase in the Unified Process. At this point in the project the goal is to understand the scope and technical strategy, not to document them in detail. www.StickyMinds.com Agilists MoDel, but they Don’t tAlk About it There seems to be a fear in the agile community that if we use terms such as “model” or “document” that suddenly the “evil bureaucrats” will dig their claws into our projects and force us to write detailed, big requirements specifications or to take a big-design-up-front approach. This fear isn’t completely unfounded, as there are a lot of traditional modelers out there who still believe in those concepts—regardless of the mounting evidence [4, 5] against those strategies. The strange thing is that agilists are, in fact, modeling on a regular basis, JUNE 2008 BETTER SOFTWARE 23 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - June 2008

Better Software - June 2008 Contents Mark Your Calendar Contributors Technically Speaking eLightenment Code Craft Test Connection Management Chronicles Agile Model-Driven Development The Myth of Risk Management Stop the Insanity! Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.