Agile development with iconix process download pdf

Agile development with iconix process download pdf

agile development with iconix process download pdf

Detail Book Title: Agile Development with ICONIX Process People Process and Pragmatism by Doug Rosenberg 20050228 Format: PDF. Source code for 'Agile Development with ICONIX Process' by Don Download the files as a zip using the green button, or clone the repository. Downloads Agile Development with ICONIX Process: People, Process, Agile Scrum eBooks Collection [PDF]-OMNiSCiENT A» agile development with iconix process download pdf

Agile development with iconix process download pdf - that

Agile development with iconix process download pdf - thought

Agile Development with ICONIX Process: People, Process, and Pragmatism

162 downloads 1365 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

Agile Development with ICONIX Process—People, Process, and Pragmatism DOUG ROSENBERG, MATT STEPHENS, AND MARK COLLINS-COPE

Apress © 2005 by Doug Rosenberg, Matt Stephens, and Mark Collins-Cope Lead Editor: Jim Sumser Technical Reviewer: Dr. Charles Suscheck Editorial Board: Steve Anglin, Dan Appleman, Ewan Buckingham, Gary Cornell, Tony Davis, Jason Gilmore, Jonathan Hassell, Chris Mills, Dominic Shakeshaft, Jim Sumser Assistant Publisher: Grace Wong Project Manager: Tracy Brown Collins

Copy Manager: Nicole LeClerc Production Manager: Kari Brooks-Copony Production Editor: Beth Christmas Compositor: Diana Van Winkle, Van Winkle Design Group Proofreader: Elizabeth Berry

UNREGISTERED VERSION Indexer: Michael Brinkman OF CHM TO PDF CONVERTER By THETA-SOFTWARE Artist: Kinetic Publishing Services, LLC Interior Designer: Diana Van Winkle, Van Winkle Design Group Cover Designer: Kurt Krames UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE Manufacturing Manager: Tom Debolski Library of Congress Cataloging-in-Publication Data Rosenberg, Doug. Agile development with ICONIX process : people, process, and pragmatism / Doug Rosenberg, Matt Stephens, Mark Collins-Cope. p. cm. Includes index. ISBN: 1590594649 1. Computer software--Development. I. Stephens, Matt. II. Collins-Cope, Mark. III. Title. QA76.76.D47R666 2005 005.1--dc22 2005000163 All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Distributed to the book trade in the United States by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013, and outside the United States by Springer-Verlag GmbH & Co. KG, Tiergartenstr. 17, 69112 Heidelberg, Germany. In the United States: phone 1-800-SPRINGER, fax 201-348-4505, e-mail [email protected], or visit Outside the United States: fax +49 6221 345229, e-mail [email protected], or visit For information on translations, please contact Apress directly at 2560 Ninth Street, Suite 219, Berkeley, CA 94710. Phone 510-549-5930, fax 510-549-5939, e-mail [email protected], or visit The information in this book is distributed on an “as is” basis, without warranty. Although every precaution has been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work. The latest information on this book can be found at

Dedication To Irv, and in loving memory of Vivian —Doug Rosenberg For Michelle and Alanah —Matt Stephens To Oliver, Nathan, and Lewis —Mark Collins-Cope About the Authors

DOUG ROSENBERG is the founder and president of ICONIX Software Engineering, Inc. ( Doug spent the first 15 years of his career writing code for a living before moving on to managing programmers, developing software design tools, and teaching object-oriented analysis and design. Doug has been providing system development tools and training for nearly two decades, with particular emphasis on object-oriented methods. He developed a unified Booch/Rumbaugh/Jacobson design method in 1993 that preceded Rational’s UML by several years. He has produced more than a dozen multimedia tutorials on object technology, including “COMPREHENSIVE COM” and “Enterprise Architect for Power Users,” and is the co-author of Use Case Driven Object Modeling with UML (Addison-Wesley, 1999) and Applying Use Case Driven Object Modeling with UML (Addison-Wesley, 2001), both with Kendall Scott, and Extreme Programming Refactored: The Case Against XP (Apress, 2003), with Matt Stephens. A few years ago, Doug started a second business, an online travel website ( that features his virtual reality photography and some innovative mapping software, which you can read about in this book.

MATT STEPHENS is a senior architect, programmer, and project leader based in Central London. He has led a

number of agile projects through successive customer releases. He’s also spoken at several software conferences, and he regularly writes on software development, having written for magazines including Dr. Dobb’s Journal, Software Development magazine, Application Development Advisor, and Application Development Trends. His key interests include software agility, architecture, and interaction design. Check out his latest thoughts at Matt co-authored Extreme Programming Refactored: The Case Against XP (Apress, 2003) with Doug Rosenberg. In fact, Matt and Doug are collaborating on yet another book, Use Case Driven Object Modeling: Theory and Practice (Addison-Wesley, 2005).



MARK COLLINS-COPE is technical director of Ratio Group Ltd., a UK-based company undertaking development, training, consultancy, and recruitment in the object and component technology arena (see Collins-Cope has undertaken many roles in his 20 years in the software development industry, including analysis, design, architecture definition/technical lead; project manager; lecturer; and writer. His key interests include use-case analysis, software architecture, and component-based development and software process. About the Technical Reviewer DR. CHARLES SUSCHECK is an assistant professor of computer information systems at Colorado State University, Pueblo campus. He specializes in software development methodologies and project management, and has over 20 years of professional experience in information technology. Dr. Suscheck has held positions of process architect, director of research, principal consultant, and professional trainer at some of the most recognized companies in America. He has spoken at national and international conferences on topics related to project management. Acknowledgments Our thanks go to: All the folks from ESRI, including Dave Lewis, Amir Soheili, and Jim McKinney for getting the mapplet built; Jack Dangermond for approving the project; and the ESRI marketing team (Debra Van Gorden, Paige Spee, and friends) for providing us with technical information on ArcGIS Server. The fabulous Apress production team, including the “PM,” Tracy Brown Collins; “the world’s greatest copy editor,” Nicole LeClerc; our production editor, Beth Christmas; our editor, Jim Sumser; and, of course, “Mr. Apress,” Gary Cornell. Our technical reviewer, Chuck Suscheck. Our “unofficial” reviewer, David Putman of, for his extensive feedback on all the chapters (in particular the “agile core subset” and TDD chapters).

Geoff Sparks and Dermot O’Bryan from Sparx Systems. Andy Carmichael for the material on three-point estimation. Dino Fancellu and Robin Sharp from

Agile Development with ICONIX Process: People, Process, and Pragmatism byDoug Rosenberg, Matt StephensandMark Collins-Cope Apress 2005 (288 pages) ISBN:1590594649

Packed with how-to advice for avoiding common agile pitfalls, this comprehensive text describes how to apply ICONIX Process in an agile software project. The book also follows a .NET/C# project from UML modeling, to working code, through iterations.


Agile Development with ICONIX Process—People, Process, and Pragmatism Introduction—Rigor Without the Mortis Part 1 - ICONIX and Agility Chapter 1

- What Is Agility? (And Why Does It Matter?)

UNREGISTERED VERSION OF CHM TOProcess PDF CONVERTER By THETA-SOFTWARE Chapter 2 - Characteristics of a Good Software Chapter 3

- ICONIX Process—A Core UML Subset

Chapter 4

- A Core Subset of Agile Practices

Part 2 - Agile ICONIX Process in Practice—The Mapplet Project Chapter 5

- Introducing the Mapplet Project

Chapter 6

- Modeling the Mapplet (Release 1)

Chapter 7

- Synchronizing the Model and Code—One Small Release at a Time

Chapter 8

- Mapplet Release 2

Part 3 - Extensions to ICONIX Process Chapter 9

- Agile Planning

Chapter 10 - Persona Analysis Chapter 11 - A “Vanilla” Test-Driven Development Example Chapter 12 - Test-Driven Development with ICONIX Process

Introduction—Rigor Without the Mortis Many people (especially agilists) associate a high-ceremony software development process with a dead project (i.e., rigor mortis), and this association is not entirely incorrect. Our approach aims to put back the rigor while leaving out the mortis—that is, we can do rigorous analysis and design without killing the project with an excessively high-ceremony approach. The goal of this book is to describe that process in full detail. Agility in theory is about moving ahead at speed, making lots of tiny course corrections as you go. The theory (and it’s a good one) is that if you spend months or years producing dry specifications at the start of the project and then “set them in concrete,” this doesn’t necessarily (and in practice, doesn’t) lead to a product that meets the customer’s requirements, delivered on time and with an acceptably low defect count. It’s likely that the requirements will change over time, so we need to be prepared for that, and it’s likely that a lot of the original requirements will turn out to be wrong or new requirements will be discovered after the requirements “concrete” has set. Agile methods answer this problem in a number of different ways, but the overriding principle is to break things down into smaller chunks and not to go setting anything in concrete (least of all your requirements specs). That’s great in theory, but it might leave you wondering how to go about doing it in practice. There are plenty of agile books out there that set out to tell you how to “be agile” at a management or process level, but this book is different for a number of reasons. First, we look at each level of agility and show how it can be applied to a reallife project, from issues with team adoption of agile practices down to a specific logical design process. We also believe that being agile doesn’t mean you should have to abandon up-front analysis and design (although we do agree with agilists that too much up-front analysis and design can be a bad thing). So, in this book we define a core subset of UML diagrams and techniques, and show how to apply them to your own project using a core subset of established agile practices. Our goal is to show how to make your own process minimal yet sufficient.[1] Another reason this book is different is because we’re essentially “outsiders” in the agile world. We’ve been in the industry for a long time and have taken part in a number of agile projects, but we’re approaching agility from the standpoint of more traditional software engineering. We examine how agility can be applied in organizations that may approach “all-out, party-on extreme agility” with a heavy dose of caution and distrust. As a result, the process we describe in this book could well be more applicable to traditional or more disciplined organizations than other agile processes. In our attempt to find the “sweet spot” between agility and discipline, the spot we’ve landed on is probably far removed from where some agilists (most notably the creators of Extreme Programming [XP]) would expect it to be. For example, we place a higher emphasis on UML modeling than XP does. However, if you’re an XP practitioner, you may well find that the object modeling process this book demonstrates works very well in collaborative modeling workshops (in fact, we place a high emphasis on the value of collaborative modeling).

Plan Driven and Feedback Driven Agile ICONIX Process is plan-driven and feedback-driven, small-increment, short-iteration development, using the following artifacts: Use case model (including personas) Domain model Release plan Then for each release, we aim to produce the following: Robustness and sequence diagrams for each use case

An updated class diagram Source code Unit and acceptance tests as appropriate Using this process, we tie the persona modeling[2] into the iteration plan and drive the feature set, via the iteration plan, from the usage requirements. (This is similar in some ways to Feature-Driven Development [FDD], which we discuss in Chapter 4.) [1]This isn’t dissimilar UNREGISTERED VERSION OF CHMprinciple TO PDF CONVERTER By THETA-SOFTWARE to Agile Modeling’s of making documentation “just barely good enough,” though we distinguish it because there are some important differences in our guidance, as we describe in this book. [2]See

Chapter 10.


Recurring Themes Throughout this book, you’ll encounter the themes described in the sections that follow.

People, Process, and Pragmatism The ICONIX approach to software agility starts with a subtle but significant refactoring of the Agile Manifesto’s value of “individuals and interactions over processes and tools.” We have redefined this as “people and processes and pragmatism.” We believe that neither people nor processes are second-class citizens, and that both (in conjunction with a pragmatic approach) are equally important factors in a project’s eventual success.

Real Agility vs. Illusory Agility A software-engineering maxim that has fallen out of fashion lately is “There is no such thing as a shortcut.” (Another one that seems to have been abandoned recently is “Get it right the first time.”) In high-velocity projects that must be produced in “Internet time,” there is always pressure to cut corners, by skimping on testing, designing, reviews, and so on. This is not the same as agility (at least not in theory, although in practice it often gets justified in the name of agility). In fact, this approach almost invariably delays the project. We will explain how to distinguish between the elimination of practices that are weighing down the project (“excess fat”) and practices that are actually there to save time. Cutting out these latter practices might appear to save some time early on, but in reality doing so stores up trouble for later.

Cookbook Development A common view held in the agile world is that cookbook approaches to software development don’t work. We agree with this to an extent, because analysis and programming are massive, highly complex fields, and the number of different types of software project is roughly equal to the number of software projects. However, we firmly believe that the core “logical” analysis and design process can (and in fact should) be a specific sequence of repeatable steps. These steps aren’t set in stone (i.e., they can be tailored), but it helps to have them there. In a world of doubt and uncertainty, it’s nice to have a clearly defined, definitive sequence of “howto” steps to refer back to. Way back in the pre-UML days when Doug first started teaching a unified Booch/Rumbaugh/Jacobson modeling approach (around 1992/93), one of his early training clients encouraged him to “write a cookbook, because my people like following cookbook approaches.” While many have claimed that it’s impossible to codify object-oriented analysis and design (OOAD) practices into a simple, repeatable set of steps (and it probably isn’t possible in its entirety), ICONIX Process probably comes as close as anything out there to a cookbook approach to OOAD. While there’s still room for significant flexibility within the approach (e.g., adding in more state or activity diagrams), ICONIX Process lays down a simple, minimal set of steps that generally lead to pretty good results that have proven to be consistent and repeatable over the last 12 years.

So, Let’s Get Started There are three major parts in this book. In Chapter 4, introduce a core subset of agile practices. In Part 2, we illustrate our core subset in action by exploring the design and code of an example project, a C#/.NET mapping application for the travel industry, which we call “the mapplet.” The mapplet example represents “the authors practicing what they preach,” as this is the real-life story of a commercial application for UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE a website that’s owned by one of them. So, if you’ve ever wondered what one of those #%$%& methodologists would really do if they needed to get something built, and if they’d follow the methodology they preach, you’ll find this example interesting.


Part 1: ICONIX and Agility Chapter List Chapter 1: What Is Agility? (And Why Does It Matter?) Chapter 2: Characteristics of a Good Software Process Chapter 3: ICONIX Process—A Core UML Subset Chapter 4: A Core Subset of Agile Practices The first part of this book lays the groundwork for the discussions and examples that follow. We begin in .

Chapter 1: What Is Agility? (And Why Does It Matter?) Overview “What is agility?” is a simple question with a complex answer. The answer is complex because there is no central authority toVERSION dictate the “agile standard” define in legally binding terms what agility is or isn’t.[1.] While UNREGISTERED OF CHM TO and PDF CONVERTER By THETA-SOFTWARE many (including us) would argue that this is a good thing, the result is that not everyone will ever agree on a single definition. To some, agility is all about the people: emphasizing people over tools. To others, agility is all about the ability to change requirements late in a project (in fact, this is what most people mean when they talk about “being agile”). To the industry thought-leaders, agility is a combination of these things. But in true agile spirit, the very definition of agility evolves and warps over time.


To be honest, we’re glad that there isn’t a central standards authority for software agility, handing down the “agile spec” from on high and stipulating that all agile processes must conform to its ideals to be allowed to call themselves AGILE™, because that would stifle the exciting air of innovation and exploration of new development techniques that have ignited the industry over the past few years. Of course, with the excitement of new ideas and new frontiers, there’s always the danger that we will disappear down a blind alley or two in our search for better ways of doing things. There’s also a danger that previously learned lessons will be forgotten in the rush to discover new improvements. These lessons include the benefits of doing an up-front design and exploring requirements in sufficient detail before coding. We discussed the dangers of forgetting these important lessons in our previous book, Extreme Programming Refactored: The Case Against XP (Apress, 2003). The pendulum has swung from one extreme to the other. It’s gone from the inflexible, inefficient, old-guard, waterfall, high-ceremony methodologies to the highly fluid, trendy agile processes that we’re seeing today.[2.] As you might expect, the pendulum has already begun to swing back the other way, and it will hopefully come to rest somewhere between the two extremes. We’re hoping that this book will contribute toward finding the ideal middle ground. This book tells you how to create software using a small increment, short iteration, feedback-driven strategy while still modeling up-front and using that up-front thinking to avoid lots of rework (i.e., it has the benefits of agility but not the penalties of skipping up-front design). ICONIX Process is a use case–driven analysis and design methodology. Its main focus is on how to get reliably from use cases to code in as few steps as possible. In this book, we describe ICONIX Process and show how it was applied to a real-life project. We also describe in detail how to apply ICONIX Process to a broader agile project environment. This combination of process and practices is shown in Figure 1-1. Informally, we refer to this combined process as Agile ICONIX.

Figure 1-1: Agile ICONIX in a nutshell This book is all about how to be agile and accommodate the real-world situations of changing requirements, new technology baselines, and so on, without skipping analysis and design, using a small increment, short iteration, model-driven and feedback-driven approach. This book also teaches how to drive the development from UML models, and then shows how to adjust both the models and the code using an interleaved approach in a way that the model and code become more tightly linked over time. Although much of ICONIX Process can be considered agile, some parts of it stand in stark contrast to recent agile thinking. In particular, agile methods often tell us not to bother keeping design documentation and source code synchronized. The theory is that once code has been written, we don’t need the diagrams anymore.[3.] ICONIX Process, on the other hand, suggests exactly the opposite: the more tightly synchronized the design documentation is with the code, the faster, more maintainable, and more accurate (i.e., closer to the customer’s requirements) your project will be over successive releases. Luckily, ICONIX Process also aims to make this process easier (again in contrast to other agile processes). To achieve this tight synchronization between diagrams and code, we need to cut down on the number of diagrams that we have to draw (and therefore maintain). It’s also important to know which diagrams are going to be important to ongoing iterations and which can safely be discarded. “Minimal but sufficient” analysis and design is right at the core of ICONIX Process. Of course, there’s an ever-increasing number of development processes claiming to be agile. Project leaders may decide that the project they’re embarking on will be agile, or their existing project may not be working out too well, so they decide to introduce some agile practices. But what exactly does “agile” mean? What’s the yardstick by which agility is measured? Where’s the magic point of latitude when a project flips from being nonagile to being agile? In this chapter, we examine the somewhat nebulous term “agility” and attempt to disambiguate it. In doing so, we aim to answer the questions in the previous paragraph. [1.]Of course, there is the Agile Alliance (see, although this isn’t quite the same sort of thing. We discuss the Agile Alliance later in this chapter and in Chapter 4. [2.]If

we think of a big, high-ceremony process as elephantine, and an extremely minimal/agile one as mouselike, it’s amusing to note that some folks try to equate the mouse to the elephant because both are gray mammals with tails. In reality, however, there are significant differences between a mouse and an elephant, and neither of those animals does the work of a horse very well.


mind-set comes from thinking of diagrams as documentation rather than as tools that enable the design process and efficient communication about the design across the team. In our estimation, this is 100% backward. Modeling should be about doing design and communicating the design to the rest of the team, not about documentation.



What Software Agility Isn’t To better explain what software agility is, it’s worth beginning with a description of what it isn’t. Software agility isn’t about Big up-front requirements gathering and design Hacking High ceremony (i.e., lots of paperwork and bureaucratic hoops to jump through) Low levels of communication “Carrying” mediocre developers Politics and secrets Let’s take a quick look at each of these topics in turn.

Big Up-front Requirements Gathering and Design Up-front requirements gathering and design are, of course, vital parts of any software process, and they have their place in an agile project. What agile practitioners are generally opposed to is the “pure waterfall” concept of eliciting all requirements and modeling the architecture in detail for the entire project before starting on individual sections. Instead, you gather together everything you think you’ll need just for the next iteration, and proceed with that. This approach is similar to the iterative and incremental process that has been developed in the Rational Unified Process (RUP).

Hacking Adopting an agile process isn’t (or shouldn’t be) a license to hack. Agile processes are typically high-discipline, and it often takes hard work and patience for developers to get the full benefit.

High Ceremony Sometimes the organization requires a high level of paperwork (e.g., change requests to be signed off on by three levels of management). If your organization doesn’t, then why bury yourself out of choice?

Low Levels of Communication As with any process, agile processes benefit from teams that tell each other what’s going on, and that both talk and listen to the customer. Agile processes are very much opposed to “low-communication” environments—for example, environments that separate programmers into isolated cubicles.

“Carrying” Mediocre Developers Agile processes typically require high-caliber staff if they are to work at all. There is no place for slouchers and “bug jockeys” on such projects!

Politics and Secrets Agility places a big emphasis on increased transparency—that is, allowing the customer to see exactly what’s going on in the project at any time. If a project is behind schedule, the agile planning methods generally make it difficult to hide this from the customer. Although this might seem alarming at first, it has the very important

benefit that you don’t find yourself storing up nasty surprises for later—in particular, on the day before the delivery deadline, having to tell the customer that it’s going to be at least another 6 months before any working software can be delivered. Increased transparency also extends to individuals and teamwork. Because agile teams tend to work more closely together, it’s difficult for one team member to operate deviously (e.g., hanging on the coattails of more talented programmers and taking the credit for their work).



The Goals of Agility When deciding whether to adopt agile practices for your project, it’s important to take a step back from the hype and ask what’s in it for you (or, more accurately, for your project). So, what does your project stand to gain from adopting agile practices? What are the benefits, the goals, the problems that agility sets out to solve? And do these problems exist on your project? The Agile Manifesto website (see describes the principles and values that agile teams need to follow to describe themselves as “agile.” But oddly, it doesn’t describe the actual goals of software agility—that is, why you would want to make your project agile in the first place (although some goals are described by the group’s 12 principles, listed at We’ve interpreted the goals of agility as the ability to Respond to changing requirements in a robust and timely manner. Improve the design and architecture of a project without massively impacting its schedule. Give customers exactly what they want from a project for the dollars they have to invest. Do all this without burning out your staff to get the job done. These goals are sometimes overlooked in the rush to address the values. The agile values are important but, we feel, are really there to fulfill these goals. The overriding agile goal is responsiveness to changing requirements. This was the main problem out of which agile processes grew. Offset against responsiveness is the need for the project to be robust. Usually, robustness means contingency—that is, having safety nets in place to mitigate risk and provide a backup plan if (when) things do go wrong. Robustness implies more effort; more practices to put in place that, while reducing risk, can slow down the project’s overall pace (see Figure 1-2). (Sometimes, though, robustness can also mean simply using smarter practices to reduce risk).

Figure 1-2: The agile software dichotomy: responsiveness versus robustness Responsiveness in this context means the ability to react quickly (without regard for keeping all your safety nets in place, which is where robustness comes in). If you react to a change quickly but immediately introduce lots of defects as a result, that’s very responsive but not particularly robust! Safety nets include things like unit tests, customer acceptance tests, design documents, defect tracking software, requirements traceability matrices, and so on.

So, ironically perhaps, to be really responsive (and to not introduce lots of defects every time the code changes), you need to push the slider further toward robustness. But then, the more safety nets you have in place, the more difficult it becomes to react quickly (i.e., the project becomes less agile). Agility, then, is the ability to adapt to change in a timely and economic manner, or the ability to change direction while moving at speed. So a leopard is agile; an elephant isn’t. But an elephant can carry a lot more than a leopard. But a horse is a lot more agile than an elephant and can carry a lot more than a leopard. ICONIX Process, without the agile extensions we present in this book, can be thought of as a “workhorse” process. By adding in a core subset of agile practices, we’re aiming to create a “thoroughbred racehorse” process.


In other words, agile techniques work best for small projects but don’t always scale very well. The techniques we describe in this book scale better than those in some agile processes because they place a greater emphasis on up-front design and documentation. SCRIBBLED ON THE BACK OF A NAPKIN

UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE The screenshot in Figure 1-2 looks like it was drawn on a crumpled-up piece of paper, although it is actually from a “real” program. It uses a readily available Swing look and feel called Napkin Look & Feel (see; this page also includes a link to a Java WebStart demo). The idea behind this look and feel is that sometimes, when a developer shows a prototype GUI to a manager or customer, the customer assumes that what he’s seeing is working software. (Appearances are everything, after all…) On the other hand, if the working prototype was presented looking like a user interface mockup that had been scrawled on the back of a napkin, then the customer would be more likely to see it for what it actually is: a slightly working but mostly nonfunctional prototype that was cobbled together quickly so as to give the customer a rough idea of what the finished product will look like. Seems like a great idea to us!

Why Is Agility Important? Agile development has virtually exploded onto the software development world, bringing with it a shift in the way that software is developed. Agility makes a lot of sense because it addresses some of the common reasons why projects have failed over the years. Back in 1995, the Standish Group’s CHAOS Report[4.] (a commonly cited report focusing on reasons for project successes and failures) showed that the primary reason for project failure was “lack of user input.” The same study also found that the top element that dramatically increases the chance of success is “user involvement.” So it isn’t surprising that user involvement (and, in particular, user feedback, as early in the process as possible) is a hugely important driver behind agility. Another commonly recognized contributor toward project failure is the “big monolithic project” syndrome, where a project doesn’t get to see the light of day for a year or two. Finally, when this monstrosity rolls out of the programmers’ workshop, the customer grows purple-faced and demands to know what this has to do with his original specification. It’s quite likely that what the customer thought he was specifying was completely different from the way in which the programmers interpreted the spec, or the requirements might simply have changed beyond recognition in those 2 years, and somebody forgot to tell the programmers. It sounds absurd, but it happens—a lot. Agile development addresses these issues: it cuts down the amount of time before the customer sees working software, and it encourages increased communication among everyone involved in the project (the programmers, the analysts, the customer, the users, the managers, the tea lady, and so on). If business customers are concerned about trusting their millions of dollars to your IT consultancy, you need a pretty good story to convince them that you will deliver what they need, when they need it. In an ailing software industry in which it is still unacceptably common for projects to fail, the most visible (and probably the most often cited) reason for failure is unstable requirements. In other words, requirements that were thought to be “set in stone” are liable to change midproject, causing code to be hacked and the most insidious and time-consuming bugs to creep into the product. Often the requirements change so much, and the code becomes so hacked about as a result, that many of the bugs are not discovered until the software is released. Projects that follow heavyweight (or high-ceremony) methodologies may also suffer as a result, due to the amount of documentation that must be kept up to date (doubling the amount of work to be done), sent back and forth, reviewed, and signed off on to cover each and every change. Such projects face the danger of collapsing beneath their own weight. Another problem faced by many different project teams is that the design will warp and evolve over the course of a single project. In other words, the design that you began with will likely not be the same as the finished design; rather, it will change as the team’s understanding of the problem improves. The extent of this problem varies from project to project, depending on a number of factors such as how well understood the problem is, whether a similar project has been written before by anyone on the team, the skill level of the people involved, the quality of the design process and supporting environment and, sometimes, simply whether or not there is a prevailing wind to send the project on its way. Given this situation, it was inevitable that the industry would begin looking for ways to accommodate changing requirements and evolving designs more easily. A number of agile processes have grown out of this need, each taking a slightly different approach. We describe some of these agile processes in the next section. [4.]See

What Makes a Project Agile? A variety of practices, principles, values, and other factors go into making a project agile. In this section, we describe the more important ones (we also sum up these practices as a “top 10” list at the end of this chapter).

Tuning the Process As You Go Along

UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE A doomed project is one that fails to adapt its development process as it goes along. If a particular practice obviously isn’t working, it should be replaced with a practice that does work for your team.


Keeping a process low ceremony is the art of producing just enough documentation to proceed, and having just enough process hoops to jump through to provide some structure and coordination, without slowing down the team. For example, if a team is unable to start programming because another 100 pages of design documentation need to be written (using the extensive company template with 12 pages of “front matter,” of course), then that would classify as a high-ceremony project. ICONIX Process aims to keep the project low ceremony, by identifying a minimum set of UML diagrams that can be produced to get reliably from use cases to code with as few hoops to jump through as possible.

Enhancing Agility Through Good Design If sufficient time is spent on getting the architecture and design right near the start of the project, then it becomes a lot easier to extend and modify the design later on (when changes are traditionally more expensive). As we describe later in this chapter, Robert C. Martin identifies the need for continuous care—that is, constant attention to the design and the state of the source code. If the design begins to fray at the edges (e.g., because some functionality is being added that the design wasn’t originally intended to cope with), then time needs to be spent readjusting the design and tidying up the code through refactoring. The alternative—just shoehorning the new functionality in (also known as hacking)—means that the problem never goes away, and over time it just gets worse. However, a vital extra component can also help to keep the design extensible: time spent on up-front design. Contrary to popular belief, designing for change doesn’t mean adding layers of indirection to your code. Unless there’s a really good reason for it, this sort of design ultimately just produces more code, making it more difficult to modify later. Instead, designing for change (also known as defensive programming) means following sound, object-oriented (OO) design principles, the following in particular: Keep the code in a highly modular state. Make sure each class has just one responsibility, and that it handles that responsibility well. Also, make sure each method performs just one task (e.g., by delegating to other methods). Keep your classes highly cohesive and loosely coupled. Make sure everything in each class fits well and is there to fulfill the reason for the class’s existence. Try to reduce the number of dependencies between classes. Don’t overcomment your code. Any code that you have control over should be made self-explanatory (see the next point), reducing the need for comments. The exception is with calls to library code that you have no control over; often, some deftly placed comments can help a lot here. Use method names that describe the method’s purpose, not how the method achieves that purpose. For example, instead of calling a method addToList(String str), call it addToCatalog(String

productID). Use class names that are closer to the problem domain than the implementation details. We’ll explore this in more detail when we talk about domain models in Chapter 3. Don’t overcommit. That is, don’t use a concrete type where a more abstract type would suffice. For example, if you’ve declared a return type as a java.util.ArrayList, you might find it’s better to declare the return type as a Collection interface instead. And speaking of interfaces… Use interfaces as return types and parameter types wherever possible.

Improving Communication and Teamwork One of the most important factors separating agile development methods from traditional development methods is the focus on people. For example, Agile Modeling promotes communication and teamwork through the following practices: Active stakeholder participation Modeling with others Displaying models publicly Collective ownership You build systems for your stakeholders. It is their requirements that you need to fulfill, they are the source of critical information, and they need to make important decisions such as the setting of priorities. For iterative and incremental development to succeed, your stakeholders must be available to provide information, to work with you to explore their requirements, and to make decisions in a timely manner. In other words, your stakeholders must be actively involved with your project. Software development is a lot like swimming: it is very dangerous to do it alone. Whenever you work on something by yourself, you risk going in an inappropriate direction and not realizing you’re doing so. Furthermore, you risk making a common mistake due to lack of experience with or knowledge of a technique or technology. This is why it’s so important for design work to be collaborative: by modeling with one or more people, the quality of your work is likely to be much greater, you’re likely to get the job done faster, and the information gained during the modeling effort is communicated to everyone involved. BUT WHAT ABOUT RESPECTING YOUR CO-WORKERS? Agile processes do place a greater emphasis on the people factor, but it’s debatable whether this is intrinsically what makes a project agile. Respecting your co-workers is equally important on nonagile projects, for example. If people feel valued, they’ll be more productive, and more willing to participate and contribute actively to the project.

Reducing Exposure to the Forces of Change The premise behind this idea is simple: making changes halfway through an iteration is expensive and can cause bugs as the new requirements get shoehorned into an unsuspecting design. So to reduce the likelihood of requirements being introduced halfway through an iteration, keep the iterations short. This is like a boxer creating a smaller target by turning side-on to his opponent. We can also reduce the likelihood of requirements changing at the most inopportune moment by getting from use cases to code in as short a time frame as possible. We do this by spending a little extra time focusing on the requirements and the design modeling (when a change in the requirements is welcomed), so that we cut a straight line to the source code, developing short iterations in short spaces of time.

Measuring Progress with Working Software If working software has been delivered to the customer, then we know we’ve made at least some progress (even delivering a small amount of working functionality to the customer is a lot further than some projects get). Working software can also be used to measure (in precise terms) how near to completion the project is (see Chapter 9 for more on agile planning). But how do we know that the software is working? “Working” doesn’t just mean “doesn’t crash”; it means that the software matches up with the is, it does what it’s meant to do. Testing the UNREGISTERED VERSION OFcustomer’s CHM TOrequirements—that PDF CONVERTER By THETA-SOFTWARE software against the requirements (often referred to as customer acceptance testing or functional testing) is generally how we verify that the software works. During analysis and design, you should constantly ask yourself, “How am I going to test this?” If you can’t test something, then you should seriously consider whether you should be building it. Considering testability while modeling is important because OF it keeps theTO team focused on realistic designs. Furthermore, it gives the team a UNREGISTERED VERSION CHM PDF CONVERTER By THETA-SOFTWARE head start on writing the test cases, as some thought has already been put into them. Model reviews, described in Chapter 3, are also a good option for validating both the requirements and the design.

Agile Project Management As with improving communication and teamwork, the people factor plays a large part in agile project management. In many ways, this is no different from the “traditional” project management role: it’s about managing groups of people and keeping them at their optimum efficiency without burning them out. In practical terms, this might simply involve seating people near appropriate colleagues so that they’re more inclined to communicate well, moving individuals across teams so that the correct skill sets are applied to individual problems, and so on.

Agile Planning The very term “agile planning” might strike some people as oxymoronic. How can you create a plan for something that by its very nature keeps changing? In fact, the more volatile a project’s requirements, the more agile planning is needed. Agile planning operates at two levels: Adaptive planning: This involves planning ahead, tracking changes, and adapting the plan as the project progresses. Predictive planning, on the other hand, involves making predictions such as “On June 14, we’ll start doing module A, and it will take 4 days for Eric to write it.” Adaptive planning stands in stark contrast to predictive planning, because adaptive planning involves synchronizing the plan with reality as we go along.[5.] Planning for agility: This entails preparing for the unknown so that when changes take place, their impact is kept to a minimum. Agile planning is a way of anticipating and controlling change. Typically, agile planning consists of various practices, including performing short, fixed-length iterations (usually of 1 to 2 weeks); regularly reviewing the project plan; time boxing (i.e., specifying a fixed amount of time in which to deliver a variable amount of functionality); and tracking velocity (i.e., the rate at which new working software is being delivered).

Managing Change While some agile methodologies tell us to “embrace change,” we prefer to see change as something that should be actively managed—controlled, even. This doesn’t mean discouraging change (that wouldn’t be very agile, after all), but instead keeping a pragmatic focus on the costs involved in making a change to the requirements at a late stage in the project.

If the customer is made aware that change isn’t free, and that the cost to fix a requirements defect increases exponentially the longer it’s left, she might prefer to take the hit and leave a requirement as is, at least until the next release. For the customer to make an objective decision, she needs accurate planning data, including cost estimates. So a big part of managing change is tracking project velocity (see Chapter 9).

Delivering the System That the Customer Wants at the End of the Project, Not What He Thought He Wanted at the Start This goal is probably the most intrinsically agile of the agile factors listed here. The customer might, in all good faith, specify a set of requirements at the start of the project, believing them to be correct. During the project, however, things change. The business changes, causing the goalposts to shift; our understanding (and the customer’s understanding) of the problem domain grows; our understanding of the required solution increases; and the design evolves, meaning a better solution is sometimes found. Agility is all about recognizing that these things happen in just about every software project and, rather than trying to suppress them (e.g., by “freezing” requirements with another 8 months to go before the deadline), we use change to our advantage to drive the project toward the working system that is the most optimal for the user’s needs. We can use a variety of practices to achieve this goal. In fact, pretty much all of the agile practices contribute to this goal in some way. [5.]See Martin Fowler’s paper “The New Methodology” at

Challenges of Being Agile Often, introducing agility into your project can involve a trade-off. For example, certain levels of documentation and modeling may be scrapped so that the team can “travel light.” Striking the right balance can be difficult. Here, in our view, are the top 10 challenges of being agile.


10. Sticking to the Path

Many agile processes, though low ceremony, are high discipline and require consistent effort from the whole team to keep the project on track. You may well find that you start to do certain practices less (e.g., if you’re using pair programming, team members might start to pair up less). Agile processes put various safety nets in place to lessen theVERSION impact whenOF youCHM fall. (Of course, processes have more safety nets than others, as we UNREGISTERED TO PDF some CONVERTER By THETA-SOFTWARE discuss in Extreme Programming Refactored: The Case Against XP.) If you’re finding it increasingly difficult to maintain certain practices, it’s time to review the process. Perhaps a particular practice is too difficult because it simply doesn’t fit your project. There may be an equivalent practice (or group of practices)—something easier—that you could do instead and that your team is more likely to stick to.

9. Keeping Releases Short Short releases (i.e., releasing working code to the customer on a rapid turnaround) can be difficult to keep on doing, for a number of reasons. Examples include interface changes, database changes, user retraining, and help file rewriting. Similarly, it’s tempting to stop doing short releases simply because they’re so difficult. Funnily enough, the answer in many cases is to release more often (a similar solution to difficulties associated with continuous integration; see the section titled “Continuous Integration” later in this chapter for more information).

8. Keeping Entropy at Bay Even in nonagile projects, software designs degrade over time because new requirements emerge, and the software needs to be made to do things it wasn’t originally supposed to. In agile projects the risk is higher, because requirements are analyzed in smaller groups; releases and iterations are smaller, so the team isn’t looking ahead quite as far. While this approach solves many problems, it does mean that agile practitioners must keep a closer eye on the design, regularly refactoring to keep it in trim. In short, unit test your code and have a realistic strategy to manage change, or watch your project “decompose” in all the wrong ways!

7. Doing Less Without Increasing Risk Cutting down on the wrong things increases risk (e.g., design, testing, and drawing certain types of diagrams). So it’s important to know which practices you can safely do less of (see Figure 1-2). These practices can also vary from project to project. Reducing contingency (i.e., removing safety-net practices such as testing and code inspections) can save time in the short term, but it also increases risk. Make sure your agile process gives you more options for when things go wrong, not fewer.

6. Discovering Your True Master Always remember that the “customer” is not one person—not even one role—but is usually several people

covering the roles of end user, domain expert, decision maker, and project sponsor. Similarly for product development, different groups of people will try to pull the project in different directions: the marketing department, customers, the QA department, the company directors, and so on. Losing track of this important fact increases the risk of project failure, because requirements can be flung at you from unexpected quarters, or a key project stakeholder might become disgruntled because her interests aren’t being upheld in the project.

5. Keeping the Customer Involved Increasing the customer’s involvement may not seem like a challenge, but it certainly can be. Active stakeholder participation is a key principle in agile development, and it can greatly increase the chances of your project succeeding. However, not all customers want the additional responsibility that certain agile processes give them. They might prefer to “rule from afar,” signing off on requirements and waiting for the finished project to be delivered. Your team might interpret this as aloofness, but it’s more likely that the customer, like most people, is just incredibly busy. Even agile projects (or should that be especially agile projects) need to tailor their process to suit the customer. While there’s no silver bullet solution to this difficult situation, ICONIX Process can help because of its emphasis on requirements exploration and disambiguation.

4. Managing Change While some agile processes positively encourage change (rightly seeing a change in requirements as an increased business opportunity for the customer), it’s easy to lose sight of the risks and expense that change can cause. Without controlling change, we forget to do our utmost to get the requirements right early in the project, and the result may be requirements churn.

3. Training Introduction of a new way of developing software can potentially cause misunderstandings (e.g., programmers who wrongly see agility as an invitation to hack: “Woo hoo—no design!”). In some sense, the way that some agile approaches have been marketed makes this problem worse than it should be. (For example, telling programmers that they can skip documentation is a bit like selling catnip to cats.)

2. Avoiding the Other Extreme Agility brings with it many promises and possibilities. There may be a temptation to throw the whole organization onto the agile bandwagon. Transitioning to an entirely agile process just can’t be done overnight—it must be taken in stages (depending on how deeply ingrained the “big monolithic high-ceremony development” culture is in the company).

1. Facing Resistance to Change Speaking of development culture, you may find that your organization is stuck in high-ceremony gear: every “i” must be dotted and every “t” crossed. This deeply ingrained attitude is possibly the single biggest challenge to running an agile project. In organizations that are traditionally high-ceremony, ICONIX Process should be a more acceptable agile process than others because of its core emphasis on requirements gathering, UML, and up-front design. Enterprising developers or managers may see ICONIX Process as a “way in” for agile processes in such organizations.

Agile Methodologies To give you a flavor of the variety and amount of activity going on in the agile world, in this section we briefly describe some of the most popular (or certainly the most talked about) of the agile methodologies: Extreme Programming (XP)

UNREGISTERED VERSION (TDD) OF CHM TO PDF CONVERTER By THETA-SOFTWARE Test-Driven Development Agile Modeling (AM) Agile Database Techniques (AD) Adaptive Software Development (ASD)TO PDF CONVERTER By THETA-SOFTWARE UNREGISTERED VERSION OF CHM Crystal methodologies Feature-Driven Development (FDD) Dynamic Systems Development Method (DSDM) Scrum Some processes are designed to complement other methodologies (such as RUP or XP) with additional practices, for example: AM adds high-level, people-oriented practices, plus guidance for the amount of up-front modeling that should take place, which models to maintain, and so on. Scrum adds agile project management and planning in an effort to control the chaos of conflicting interests and needs from which many projects suffer. ICONIX Process can be applied to agile projects, to help disambiguate the requirements and the design before coding begins. This can add a vital element of up-front analysis and design to processes that might otherwise be lacking in such areas. Whatever such practices add, their primary goal is to reduce the level of risk involved in driving the project forward while the requirements take shape. Let’s look at each of these agile processes in turn. You won’t need to know all (or indeed any) of these processes to be agile, but it helps to know what’s out there and the various directions that agile methods are taking. Note To be agile, you also don’t have to follow all of the practices that we describe in this chapter. You should always tailor a process to suit your project and do just the practices that fit. In Chapter 4, after analyzing what it really means to be agile, we’ll present a core subset of agile practices. Of course, you should tailor even this core subset to suit your project.

Extreme Programming Extreme Programming (XP) is the most popular (certainly the loudest) of the agile methodologies. For more information, see or the book Extreme Programming Explained: Embrace Change by Kent Beck (Addison-Wesley, 2000). For a detailed analysis of how XP can be high risk without extensive tailoring, see our book, Extreme Programming Refactored: The Case Against XP. In this section, we briefly describe the agile practices in XP and some of the thinking behind them.

Test-Driven Development

This practice involves designing the code by writing unit tests. Each test proves that a particular feature of the design either works or doesn’t work. You sometimes hear test-driven programmers shouting “Green bar!” or “Red bar!” when running the tests. This is because the popular xUnit family of test frameworks[6.] shows either a green or a red bar to indicate whether the tests passed or failed. In XP, the TDD practice also covers writing customer acceptance tests (often using an acceptance testing framework such as FitNesse) to define the requirements. We cover TDD in more detail in Chapters 12.

The Planning Game XP has two planning games: the release planning game and the iteration planning game. Planning in XP involves breaking the project into very short, 1- to 3-week iterations and taking the project one iteration at a time. For each iteration, the customer needs to decide which user stories to include and which to leave until a future iteration. Any piece of work that takes time is written up as a user story and written on a story card. User stories must be testable and estimable. To aid this goal, stories are often broken down into estimable tasks. Each task is assigned an arbitrary value to indicate how long the programmers think it will take. Over time, these values (and the number of tasks completed) are measured to give an indication of the project velocity.

Whole Team This practice involves trying to squeeze as many people as possible (including the customer or business analysts) into one room. That may sound like a recipe for a noisy, stinky room on a hot summer’s day, but the thinking behind it is quite pragmatic: the more barriers (e.g., walls) there are between team members, the more expensive it becomes to share information, and the less likely it is that team members will actually communicate. So putting all these people into one room increases not only the amount but also the quality of communication—at least that’s the theory.[7.]

Small Releases The aim here is to get feedback from the user as quickly as possible, primarily by releasing working software often. In XP, this may mean releasing as often as once every couple of weeks, though you would, of course, modify this time frame depending how feasible it would be to achieve on your project. The thinking behind small releases is that valuable functionality is placed into the user’s hands as soon as possible and that the system never gets too far removed from what the customer really wants.

System Metaphor The system metaphor is a simple shared story of how the system works. All naming and design theories stem from that one story. Lately, XPers have begun to adopt domain-driven design (i.e., driving the design from a domain model) as an important method of keeping the design consistent and sharing a common vocabulary. Domain-driven design is also a fundamental part of ICONIX Process (as we’ll see in Chapter 3).

Simple Design An important lesson in all aspects of software design (including designing the user interface) is to keep it simple. This doesn’t mean removing all software layers so that your JSP pages are littered with SQL code, for example. In fact, sometimes adding a slightly more complex design can ultimately make the software much simpler to write. It’s a judgment call—but when in doubt, keep it simple.

Refactor Mercilessly In any project, as time marches on, the design inevitably starts to fall apart. New requirements (which were never thought of when the software was first designed) need to be hacked in, so the design starts to become

crufty (i.e., more fragile and increasingly difficult to extend). In XP, this common effect is countered by constant attention to the design: so-called merciless refactoring. Refactoring is the practice of improving the design of existing code while still passing all of the unit tests. Improving the design generally means simplifying it—making your classes more cohesive and less tightly coupled. It’s a constant process, something that XP author Robert C. Martin describes as “continuous care.”[8.]

Collective Ownership UNREGISTERED VERSION OF CHM TO PDF By THETA-SOFTWARE With collective ownership, everyone is responsible forCONVERTER the entire code base. If a programmer sees something in the code that she doesn’t like, she (and her pair-programming buddy) can go in and change it, regardless of who originally wrote it. (XP’s safety nets here are comprehensive unit and acceptance test harnesses, and constant mandatory pair programming.)

Pair Programming UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE In XP you can code on your own for “nonproduction” code such as prototypes. However, for all production code (i.e., code that will be used on a live system by “real” end users), XP recommends that everyone on the team program in pairs. Pairing up is an effective way of catching errors and helping each other identify methods to further improve the design.

Continuous Integration By integration, we mean putting your latest changes to the source code into a central source control system (e.g., PVCS, Visual SourceSafe, and CVS). Continuous integration means doing this as often as possible (at the very least once per day). This practice is often also supplemented by a dedicated “build” PC that regularly gets all the latest source code, builds it (in the Java world, typically using an Ant build script), and runs all the unit tests. If this is done often (e.g., once per hour), then build or test errors are caught very quickly, almost as soon as they are introduced. In the nonagile world, many teams either forget to integrate their code for weeks at a time or hold back on doing it because they know that it’s a major headache. And it’s no surprise, really: if several programmers are working on different parts of the same system in parallel, they’re bound to diverge over time and will produce incompatible code. So, though it may seem counterintuitive, the answer to the integration issue is not to do it less, but to integrate your code more often.

Sustainable Pace The more tired a programmer is, the more mistakes he’ll make. Many of us have experienced the horrors of late-night coding, up against some perilously important deadline or other. XP makes the point that on projects where this is the norm, programmers simply burn out and end up as near-catatonic dropouts propping up street corners and smelling heavily of stale beer. (Perhaps this is why XP talks about “coder smells”? [9.]) Sustainable pace (which used to be called “40-hour week”) will result in higher productivity levels in the long run than making frequent mad dashes that quickly burn out your programmers.

Coding Standards Coding standards are important in any programming project, and more so in an XP project because there’s no specialization: any programmer pair can dive in and work on any part of the code base. The thinking is that we spend five to ten times as much time reading code as we do writing code, so if we all write it to the same conventions, it should improve our productivity.

Test-Driven Development Test-Driven Development (TDD) is an integral part of XP, but it can also be extracted in its entirety and applied to non-XP projects. For example, in Chapter 12 we show how TDD can be used in conjunction with ICONIX Process to good effect.

Using TDD, you design code by writing code. While this sounds circular, it means that you write client test code that serves as both an example and a definition of what you want the object code to do. For example, if you were writing a hotel booking system, you would write tests for placing a booking, adding customer details, retrieving the details, and so on, and then assert that the correct results are returned.

Agile Modeling The Agile Modeling (AM) methodology[10.] is a “chaordic”[11.] collection of practices, guided by principles and values, that should be applied by software professionals on a day-to-day basis. AM is not a prescriptive process—in other words, it does not define detailed procedures for how to create a given type of model. Instead, it provides advice for how to be effective as a modeler. Think of AM as an art, not a science.

Overview of Agile Modeling An agile modeler is anyone who models following the AM methodology, applying AM’s practices in accordance with its principles and values. An agile developer is someone who follows an agile approach to software development. An agile modeler is an agile developer. Not all agile developers are agile modelers. AM has three goals: To define and show how to put into practice a collection of values, principles, and practices pertaining to effective, lightweight modeling. What makes AM a catalyst for improvement isn’t the modeling techniques themselves—such as use case models, robustness diagrams, sequence diagrams, or class diagrams—but how to apply them productively. To address the issue of how to apply modeling techniques on projects following agile software development methodologies. Sometimes it is significantly more productive for a developer to draw a sketch while thinking through an idea, or to compare several different approaches to solving a problem, than it is to simply start writing code. There is a danger in being too code-centric; a quick sketch can often avoid significant churn when you are coding. To address how you can improve your modeling activities following a “near-agile” approach to software development. In particular, this applies to project teams that have adopted an instantiation of the Unified Process such as the Rational Unified Process (RUP) or the Enterprise Unified Process (EUP). Sometimes it is more productive for developers to spend less time writing documentation and creating complex models, and more time creating models that are just barely good enough. In short, AM strives to find the “sweet spot” between too little and too much modeling. Because this sweet spot changes from project to project, you will need to tailor your application of AM each time.

Agile Modeling Practices AM consists of a variety of core principles, secondary principles, core practices, and secondary practices, not to mention values. You can find full descriptions of these at the AM website ( However, to give you an idea of what AM is about, here are the core practices: Active Stakeholder Participation Apply the Right Artifact(s) Collective Ownership Consider Testability Create Several Models in Parallel Create Simple Content Depict Models Simply

Display Models Publicly Iterate to Another Artifact Model in Small Increments Model with Others Prove It with Code

UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE Use the Simplest Tools The top 10 points to remember for AM are as follows: 10. You should create several models in parallel, iterating back and forth as required. 9. Models aren’t necessarily documents, documents aren’t necessarily models. UNREGISTERED VERSION OF CHM TOand PDF CONVERTER By THETA-SOFTWARE 8. Modeling is a lot like swimming: it’s very dangerous to do alone. 7. Sometimes the simplest modeling tool is a whiteboard; sometimes it’s a complex CASE tool. 6. Keep your models as simple as possible. 5. Travel light and update documentation only when it hurts. 4. Models don’t need to be perfect—they just need to be barely good enough. 3. Create the right models for the job, even if they’re not defined by the UML (e.g., data models). 2. Your project stakeholders must be actively involved in modeling. 1. The three secrets to successful modeling are feedback, feedback, feedback.

Agile Database Techniques Agile Database Techniques (AD) applies refactoring and emergent design principles to database models. It correctly recognizes that as a project develops, it isn’t just the design of the code that changes—the database model also evolves. AD provides a number of techniques for evolving databases while keeping a close eye on the integrity of your data. It’s a difficult subject because we’re dealing with live customer data, but it’s an important one to keep in mind. This methodology is described in the book Agile Database Techniques: Effective Strategies for the Agile Software Developer (John Wiley & Sons, 2003) by Scott W. Ambler (creator of AM). Also see

Adaptive Software Development Adaptive Software Development (ASD) consists of the following: Adaptive Conceptual Model: The theoretical foundation Adaptive Development Model: A software development life cycle for complex projects Adaptive Management Model: Principles for managing complex projects ASD places an emphasis on adaptive development cycles (basically iterations). Adaptive cycles are mission driven, component based, iterative, time boxed, risk driven, and change tolerant. A project is also divided concentrically into versions, cycles, and builds. This approach to software development is described in the book Adaptive Software Development: A

Collaborative Approach to Managing Complex Systems by James A. Highsmith III (Dorset House Publishing Company, 2000).

Crystal Methodologies According to Alistair Cockburn’s Crystal Methodologies site at Crystal collects together a self-adapting family of “shrink-to-fit,” human-powered software development methodologies based on these understandings: Every project needs a slightly different set of policies and conventions, or methodology. The workings of the project are sensitive to people issues, and improve as the people issues improve, individuals get better, and their teamwork gets better. Better communications and frequent deliveries reduce the need for intermediate work products. We’ll look at the Crystal methodologies and practices in more detail in the sections that follow.

Overview of the Crystal Methodologies The Crystal methodologies are delineated according to factors such as project size, proximity of team members, and project risk. For example, Crystal Clear[12.] is targeted at small projects, whereas Crystal Orange is targeted at projects with up to 40 people sitting in one building, working on a system that might cause loss of discretionary monies. The Crystal methodologies were created by Alistair Cockburn, and are described in his books Agile Software Development (Addison-Wesley, 2001) and Surviving Object-Oriented Projects (Addison-Wesley, 1997). A key point about the methodologies in the Crystal family is that they are self-adapting—that is, you need to keep reviewing and tailoring the methodologies throughout the project. You should find that there are many similarities (not least in the philosophy behind software development) between Cockburn’s work and James Highsmith’s ASD work. In fact, Highsmith and Cockburn have begun combining their efforts. See for the latest developments.

Crystal Practices Crystal Clear is targeted at similar projects to XP (small projects with up to 12 people located in the same room), so we’ll describe it briefly here. The key person in a Crystal Clear project is the senior designer-programmer. Other roles (which require separate people) are the sponsor, designer-programmer, and user (part-time at least). The policy standards are that[13.] Software is delivered incrementally and regularly, every 2 to 3 months. Progress is tracked by milestones consisting of software deliveries or major decisions, as opposed to written documents. There is some amount of automated regression testing of application functionality. There is direct user involvement. There are two user viewings per release. Downstream activities start as soon as upstream is stable enough to review. Product and methodology-tuning workshops are held at the start and middle of each increment.

Crystal Clear includes some mandatory work products, including a release sequence, a schedule of user viewings and deliveries, use cases or feature descriptions, design sketches and notes as needed, screen drafts, a common object model, running code, migration code, test cases, and a user manual. By contrast, Crystal Orange scales up to meet the challenge of larger projects. For example, it includes 14 roles over Crystal Clear’s 4, and more formal work products (such as a requirements document, a user interface (UI) design document, interteam specs, and status reports).


UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE Dynamic Systems Development Method (DSDM) has been around for at least a decade. It predated the agile movement and was originally marketed as a Rapid Application Development (RAD) methodology. However, DSDM is continuously evolving, so its definition today is still up to date with current software knowledge. DSDM differs from the other agile processes described here in that it is commercially driven. Companies that use DSDM pay a membership fee. The DSDM Consortium also offers training and certification.

UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE The DSDM “spec” is released as a specific version (much like software). At the time of this writing, the Consortium is on version 4.2. For more information, see

Scrum Scrum is an agile development process aimed primarily at managers. Its focus is on helping project leaders to manage teams of highly skilled developers, and get the best from them without treading on their toes. As such, Scrum can be “wrapped” around more technical development processes such as XP or ICONIX Process. Scrum divides projects into monthly “sprints,” with an incremental amount of new functionality delivered at the end of each sprint. Uniquely in an agile process, the customer is not allowed to change the requirements during the monthly sprint. If the requirements are discovered to be off base once the sprint is under way, the customer must wait until the 30-day sprint has ended before instigating a change. While this can help to stabilize development (and to make project stakeholders very focused on getting the requirements right), most other agile processes (including ICONIX Process) make the point that if a requirement is discovered to be wrong, you should take steps to correct it as soon as possible. The book Agile Software Development with Scrum by Ken Schwaber and Mike Beedle (Prentice-Hall, 2001) contains useful advice on how to introduce agile methodologies into large organizations. Also see

Feature-Driven Development Of the agile methodologies described here, Feature-Driven Development (FDD) is in many ways closest at heart to ICONIX Process. FDD places an emphasis on up-front design techniques and driving the design from “features” described using a domain object model. FDD is closely linked with the Together CASE tool/development environment (originally from Peter Coad’s company TogetherSoft, which was bought by Borland). FDD can, of course, also be used with other software tools if needed. FDD was originated by Peter Coad, and later the methodology was described in much more detail by Stephen R. Palmer and John M. Felsing. Also see

Feature-Driven Development Practices As previously mentioned, FDD places a strong emphasis on up-front design modeling, driving the development effort from self-contained functional requirements, or features. FDD consists of five processes, each one providing the input into the next: 1. Develop an overall model. 2. 3.

1. 2. Build a features list. 3. Plan by feature. 4. Design by feature. 5. Build by feature. Let’s look at each process in turn. Develop an Overall Model The domain and development team members work together to create a high-level walk-through of the system. Then the domain members present more detailed walk-throughs of each area of the problem domain. Build a Features List Building on the knowledge gathered during the initial modeling activity, the team next constructs as complete a list of features as it can. A feature is defined as a small, client-valued function expressed in the form: (e.g., “calculate the total of a sale”). Existing requirements documents (use cases or functional specs) are also used as input. Within each domain area (also called a major feature set), the features are grouped into feature sets, where a feature set reflects a particular business activity. Then the users and customer review the feature list for validity and completeness. Plan by Feature The feature sets are sequenced into a high-level plan and assigned to chief programmers (aka team leaders). The classes identified in the modeling activity are assigned to individual developers; the owner of a class is responsible for its development. In large projects, DSDM-style time boxing may be used (e.g., a time box of 3 months might be set to complete the first few feature sets and demonstrate the working software to the customer). Design by Feature and Build by Feature These two processes are highly iterative and are where the serious development work goes on. The team leader selects a small group of features to develop over the next iteration (ranging from a few days to 2 weeks). He identifies the classes likely to be involved and matches these up with the class owners. In this way, he selects his feature team for this iteration. The feature team creates detailed sequence diagrams for the features, and writes class and method skeletons. The team then conducts a design inspection. After a successful inspection, the class owners add the actual code for their classes, unit test, integrate, and hold a code inspection. Once the team leader is satisfied, the completed features are promoted to the main build, and the designing and building processes repeat for the next group of features. As you might gather from reading this description (and especially after reading Chapter 3), FDD and the ICONIX object modeling process are a very suitable match for each other. As ICONIX Process places an emphasis on sequence diagrams, it can fit into FDD’s design-by-feature process, and it can also complement FDD’s review stages with its own critical design review techniques. Similarly, FDD’s concepts of organizing use cases into features and planning by feature can be applied to an ICONIX Process project. FDD is described in lots more detail in the book A Practical Guide to Feature-Driven Development by Stephen R. Palmer and John M. Felsing (Prentice-Hall, 2002).

Agile ICONIX To provide a fair comparison with the agile methodologies described here, we finish up with a brief description

of Agile ICONIX, described in a similar style to the previous methodologies.

Overview of Agile ICONIX Agile ICONIX takes ICONIX Process (a minimal object-modeling process) and describes how to use it in an agile project. Agile ICONIX retains the core philosophy of ICONIX Process, which is that less is more. The less we have to do to safely achieve our goal, the quicker and more effectively we’ll do it. The agile practices that Agile ICONIX uses are a combination of current agile thinking and some practices of its own, which create a core subset of agile practices—the bare minimum that you’d need to do in order to achieve the goals of agility.


In Chapter 4, we describe ICONIX Process’s agile practices, and then in the rest of the book we show how they’re applied by example. For now, here’s an overview of how ICONIX Process differs from the agile methods described here.


With ICONIX Process, an emphasis is placed on getting the requirements right up front. This is done through a variety of practices that root out ambiguity in the requirements and uncover gaps in the use cases and domain model. With ICONIX Process, design is not something that you “quickly do a bit of” before coding (where the real design work happens). Instead, design modeling and coding are tightly interleaved, each providing feedback to the other. Essentially, in ICONIX Process, we “model like we mean it”—that is, we intend to drive the coding of the system from the model. This in turn means that… With ICONIX Process, the design and the code don’t diverge over time. Instead, they converge, with the design model and the code becoming more in sync. For more about Agile ICONIX, see … well, the book you’re reading at the moment. Modeling Question

Does this mean that you do all of your use cases, then go back and reanalyze the use cases, and then write all the code? Although we place a big emphasis on getting the requirements right up front, ICONIX Process isn’t by any means a “waterfall” process. It’s actually highly iterative (as we describe in Chapter 4). One way to describe it is with an example of iteratively painting your house. You can primer the whole house, then sand the whole house, then primer it again, then sand it again, then primer it again, then sand it again, then primer it again. That’s one type of iterative process: doing the whole thing over and over. The other way is to primer the front of the house, sand the front, primer the front, paint the front, and then move to the right side of the house and repeat. The first way is more of a repetitive waterfall; the second way is repetitive, but in small chunks. ICONIX Process (and most other agile methods) take the “repetitive small chunks” approach. [6.]jUnit, nUnit, cppUnit, and so on. [7.]For

a different perspective, see Matt and Doug’s other collaboration, Extreme Programming Refactored: The Case Against XP (Apress, 2003). [8.]See


we know, it’s really “code smells”….


W. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process (Hoboken, NJ: John Wiley & Sons, 2002). [11.]The

term chaordic describes a self-organizing, adaptive system, the behavior of which exhibits characteristics of both order and chaos.


Alistair Cockburn’s Crystal Clear: A Human-Powered Methodology for Small Teams (New York: Addison-Wesley, 2004). [13.]Alistair

Cockburn, Agile Software Development (New York: Addison-Wesley, 2001), p. 202.

Agile Fact or Fiction: What Does “Being Agile” Mean? We’ve gone some way toward answering this question throughout this chapter, but we thought it would be kind of fun to get our three coauthors’ separate opinions on the subject. So in this section (which also continues in Chapters 4), we discuss some of the myths and misconceptions that have grown up around agile software development.

UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE Mark: A dictionary definition of agility would be something like “the ability to change direction while moving at speed,” and this motivation is at the heart of software agility. I see agility as a logical extension of moving away from waterfall-style software development (i.e., do all analysis, then all design, then all coding, then all unit testing, then integrate the software, then system test it, etc.) to iterative and incremental development, whereby systemsBy areTHETA-SOFTWARE delivered in a number of stages. UNREGISTERED VERSION OF CHM TO PDF CONVERTER Functionality is prioritized, and a self-contained useful subset of functionality is delivered on a regular basis. Agility takes this idea further and puts additional emphasis on the ability to be able to change direction—and by “direction” I mean the direction in which business requirements are pulling us—while still moving at some speed toward our number one goal of a working software system. In order to move at speed, agile development approaches downplay the importance of nonsoftware deliverables to varying degrees, certainly when compared to very heavyweight, documentation-oriented processes like RUP or those used in many conventional software houses. Matt: Hey, Mark, a quick search on defines agility as “being nimble.” But somehow I don’t think “software nimbleness” would have caught on in quite the same way as “software agility”! Seriously, though, what defines software agility is really the goals of agility—that is, why you’d choose to apply agile practices to your project—and the agile practices themselves. Short iterations, test-driven development, interleaved modeling/testing—these are all practices that help us to achieve agility, but they aren’t themselves agility. Agility, in my mind, is an increased ability to change direction without causing excessive expense, with the end result being a system that closely matches the customer’s needs (which might not have been fully understood at the start of the project). However, changing direction without excessive expense is something of a Holy Grail, because changing the requirements (or the design) midproject is never going to be free. But it’s an ideal that we strive toward on each project, by applying various agile practices. Knowing which practices to apply—tailoring the process for each project—is, of course, the difficult part. So it’s best to start with a core subset (hey, like the one we define in this book!) and build on top of that. Doug: Well, the nebulous use of the term “agility” is one of our main motivations for writing this book. In general, there’s probably a consensus that agility is about being able to respond to changing requirements, and there probably aren’t too many people that would argue that avoiding long, drawn-out periods of specification and design without doing any coding is agile. Going a step further, we probably wouldn’t be controversial if we claimed that small increments, short iterations, and frequent releases are near the core of agility, and that getting early and frequent feedback from customers is agile. Beyond that, there’s a plethora of advice, practices, and guidance that purport to be agile—some of it’s good, some of it’s bad, some of it’s interesting but not particularly relevant to achieving “agile goals,” and some of it’s just plain awful. What we’re trying to do in this book is define a core subset of agile concepts and practices, and then illustrate it by example. My earlier books define a core subset of UML modeling techniques to support use case–driven development, and I’m hoping that between that subset and the subset we define in this book, we’ll be able to give people a really useful set of techniques to apply on their projects.

Summary Taking an agile approach to your project does not have to mean abandoning up-front requirements gathering or up-front architecture and design. Often, spending the time to get the design right, based on what the customer really wants, can actually increase a project’s agility. We aren’t suggesting that, taking this approach, requirements won’t change later on: they will. However, the UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE

level of “requirements churn” should be much lower, and what changes there are will have a lower probability of forcing a big, costly, high-risk change to the architecture.

The most visible (and probably the most often cited) reason for project failure is lack of effective user involvement, which often results in unstable requirements. One approach to fix this problem is to make the project as malleable (or agile) to the forces of change as possible. Another approach is to improve the UNREGISTERED VERSION OF CHM TO PDF CONVERTER By THETA-SOFTWARE requirements elicitation process (in other words, talk to the customer; find out what the customer really needs; use effective requirements elicitation techniques [as we describe in this book]; ask the customer hard, detailed questions; and hit the brakes if the customer doesn’t have the answers) and to model these requirements in the form of use cases. Contrary to popular opinion, these two approaches are not mutually exclusive. In fact, combining the two approaches (traditionally seen as diametrically opposite—agile versus nonagile) should drastically reduce the risk that requirements churn places on your project.

Top 10 Practices and Values That Make a Project Agile Here are the top 10 practices and values: 10. Tune the process as you go along. 9. Make the process low ceremony (i.e., produce just enough documentation to proceed). 8. Enhance agility through good design (with tried and trusted techniques). 7. Improve teamwork and communication. 6. Reduce exposure to the forces of change (e.g., by getting from use cases to code in the shortest time possible, and by short iterations). 5. Measure progress with working software. 4. Implement agile project management (identifying and delivering customer value). 3. Implement agile planning (use short iterations and review the plan regularly). 2. Manage change (a more controlled form of adapting to change, which is an important agile principle). 1. Aim to deliver the system that the customer wants at the end of the project, not what he thought he wanted at the start.

Chapter 2: Characteristics of a Good Software Process Overview How much process is enough, and how much is too much? That question has been the subject of intense debate for several VERSION years now, and debate been carried out most by the agile UNREGISTERED OFthe CHM TOhas PDF CONVERTER Byvociferously THETA-SOFTWARE community—especially by the extreme elements within that community. Barry Boehm described the problem graphically in his 2002 article titled “Get Ready for Agile Methods, with Care.”[1.] In that article, he shows the increasing costs due to both excessive planning and inadequate planning on either side of the “sweet spot” (see Figure 2-1).


Figure 2-1: Searching for the sweet spot between agility and discipline In a more lighthearted vein, two of the authors (Doug and Mark) were thinking about this problem a couple of years prior to the publication of Boehm’s article when Mark published Doug’s “Goldilocks and the Three Software Processes”[2.] article in Ratio Group’s ObjectiveView magazine back in 2000. Specifically referring to RUP, XP, and ICONIX Process, “Goldilocks” makes the case that “one’s too big, the other’s too small, and the third one is just right.” We’ll let you guess for yourself which process was which (or you can download the article). The authors of this book believe that the Agile ICONIX approach is certainly in the near vicinity of the sweet spot between plan-driven and feedback-driven processes, if not dead-center in the bull’s-eye. In the remaining chapters of this book, we describe that sweet spot both in theory and in practice (by example), although the exact sweet spot will vary among organizations and projects. But as a basis for that discussion, we’d like to first examine exactly what the components of a software process are, and then we’ll discuss trade-offs that can be made within each of these process components to help you find the appropriate level of process for your project. [1.]Barry Boehm, “Get Ready for Agile Methods, with Care,” IEEE Computer, January 2002, pp. 64–69. [2.]Doug

Rosenberg and Kendall Scott, “Goldilocks and the Three Software Processes,” ObjectiveView, Issue 5, p. 35. (This article is available for download from and also from

What’s in a Software Development Process? There are many different aspects to running a software development process. We could choose to adopt a rigorous, highly defined process in a pure waterfall fashion, with a hierarchically organized team distributed over three sites. We could choose a minimalist logical process like ICONIX, and phase it in highly iterative and incremental fashion (i.e., locating our team in a single room with lots of whiteboards to assist in discussion of issues, having daily standup meetings, etc.). And so on. If we examine the decisions made when running a collaborative (multiperson) software development project, looking back over the last 30 years in particular, it is possible to discern a number of categories of the decisions to be made. These consist of the logical process, if any, adopted; the planning and phasing strategy adopted; the approach to human-centric and communication-related issues; and the regular working practices adopted. We discuss these categories in more detail in the sections that follow (also see Figure 2-2).

Figure 2-2: Like a good sandwich: layers of a development process

Источник: []

Agile development with iconix process download pdf

1 thoughts to “Agile development with iconix process download pdf”

Leave a Reply

Your email address will not be published. Required fields are marked *