Agile Development with ICONIX Process: People, Process, and Pragmatism
Copyright 2005 by Doug Rosenberg, Matt Stephens, and Mark Collins-Cope
There are three major parts in this book. In Part 1, we examine what agility is and isn’t, explore the characteristics
of a good software process, introduce ICONIX Process and its core UML subset and, 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 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 3 presents some extensions to ICONIX Process related to persona-driven analysis and test-driven development.
This part complements the material presented in the first two parts, and it also contains some last-minute
innovations in the area of use case–driven testing that we hope you find as interesting as we do.
Part 1
ICONIX and Agility
The first part of this book lays the groundwork for the discussions and examples that follow. We begin in
Chapter 1 by trying to define what agility is and what it isn’t. In Chapter 2 we take a generic look at software
processes in general, with some specific focus on finding the “sweet spot” between agility and discipline, and
on the human-centric and communication issues that are strongly stressed in agile processes. In Chapter 3 we
summarize ICONIX Process (as defined in Doug’s first two books), and in Chapter 4 we attempt to define a
minimalist core-subset of agile practices, which we illustrate by example in Part 2.
Part 2
Agile ICONIX Process in Practice:The Mapplet Project
This part of the book features a running example project that will thread through the various chapters. We’ll
illustrate many of the points we made in Part 1 using this example project. The project is real — it’s not an academic
exercise — and we’ve taken snapshots during the various iterations of modeling, prototyping, and
coding.
This being a book about agile development (i.e., adapting to changing requirements over time), our idea is to
present the original project requirements and show that even though the requirements evolved over the course
of the project, we were still able to incorporate up-front modeling into the development process. The story that
unfolds is very much the story of how to approach this situation.
The use case text and diagrams shown in this part’s chapters were taken directly from the project, so you’ll
notice some (minor) inconsistencies at times between the use cases and the text in the diagrams. This also
reflects the “agile spirit”: the analysis and design artifacts need to be just good enough to get us to the next
stage of development. (Or, to put it another way, they need to be minimal yet sufficient. The team should always
try to avoid spending ages polishing the diagrams until they’re perfect.)
Part 3
Extensions to ICONIX Process
In this final section of the book, we define some extensions to ICONIX Process that two of this book’s authors
have tested and found to work well in an agile environment. Specifically, these extensions relate to adaptive
planning, persona analysis, and a combined usage of test-driven and use case-driven development.