Category list

agile development with iconix process: people, process, and pragmatism

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.

Table of Contents
	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?)
	Chapter 2	-	Characteristics of a Good Software Process
	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 real-life 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 to Agile Modeling’s principle 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.