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

by Rosenberg, Doug; Collins-Cope, Mark; Stephens, Matt

• ISBN13: 9781590594643
• ISBN10: 1590594649
• Format: Hardcover
• Copyright: 2005-02-21
• Publisher: Springer Verlag

Summary

This book describes how to apply the ICONIX Process (a minimal, use-case driven modeling process) in an agile software project. It's full of practical advice for avoiding common "agile" pitfalls. Further, the book defines a core agile subset-so those of you who want to "get agile" need not spend years learning to do it. Instead, you can simply read this book and apply the core subset of techniques. The book follows a real-life .NET/C# project from inception and UML modeling, to working code-through several iterations. You can then go on-line to compare the finished product with the initial set of use cases. The book also introduces several extensions to the core ICONIX Process, including combining Test-Driven Development (TDD) with up-front design to maximize both approaches (with examples using Java and JUnit). And the book incorporates persona analysis to drive the project's goals and reduce requirements churn.

Table of Contents

About the Authors	xv
About the Technical Reviewer	xvii
Acknowledgments	xix
Introduction	xxi
PART 1 ICONIX and Agility
What Is Agility? (And Why Does It Matter?)	3	(22)
What Software Agility Isn't	5	(1)
Big Up-front Requirements Gathering and Design	5	(1)
Hacking	5	(1)
High Ceremony	5	(1)
Low Levels of Communication	5	(1)
``Carrying'' Mediocre Developers	5	(1)
Politics and Secrets	5	(1)
The Goals of Agility	6	(1)
Why Is Agility Important?	7	(1)
What Makes a Project Agile?	8	(3)
Tuning the Process As You Go Along	8	(1)
Keeping It Low Ceremony	8	(1)
Enhancing Agility Through Good Design	8	(1)
Improving Communication and Teamwork	9	(1)
Reducing Exposure to the Forces of Change	10	(1)
Measuring Progress with Working Software	10	(1)
Agile Project Management	10	(1)
Agile Planning	10	(1)
Managing Change	11	(1)
Delivering the System That the Customer Wants at the End of the Project, Not What He Thought He Wanted at the Start	11	(1)
Challenges of Being Agile	11	(2)
Sticking to the Path	11	(1)
Keeping Releases Short	11	(1)
Keeping Entropy at Bay	12	(1)
Doing Less Without Increasing Risk	12	(1)
Discovering Your True Master	12	(1)
Keeping the Customer Involved	12	(1)
Managing Change	12	(1)
Training	12	(1)
Avoiding the Other Extreme	13	(1)
Facing Resistance to Change	13	(1)
Agile Methodologies	13	(9)
Extreme Programming	14	(2)
Test-Driven Development	16	(1)
Agile Modeling	16	(2)
Agile Database Techniques	18	(1)
Adaptive Software Development	18	(1)
Crystal Methodologies	18	(1)
DSDM	19	(1)
Scrum	19	(1)
Feature-Driven Development	20	(1)
Agile ICONIX	21	(1)
Agile Fact or Fiction: What Does ``Being Agile'' Mean?	22	(1)
Summary	23	(1)
Top 10 Practices and Values That Make a Project Agile	23	(2)
Characteristics of a Good Software Process	25	(14)
What's in a Software Development Process?	26	(2)
Logical Process	26	(1)
Planning and Phasing Strategy	26	(1)
Human-Centric and Communication Issues	27	(1)
Working Practices	27	(1)
Guiding Philosophy	27	(1)
What Makes a Good Agile Logical Process?	28	(3)
We Need an Obvious Logical Flow	28	(1)
We Don't Want Unnecessary Dependencies Slowing Us Down	29	(1)
We Want Each Step to Clearly Move Us Toward Our True Goal of Working Software	29	(1)
We Want Guidance That Will Reduce Unnecessary Work Later On	29	(1)
We Want Help Prioritizing, Scoping, Planning and Estimating, and Monitoring Work	30	(1)
We Want Broad Steps That Provide General Guidance	30	(1)
We Don't Have to Do Every Step (to the Nth Degree)	30	(1)
We Can Undertake Additional Activities (Coding, in Particular) at Any Point	30	(1)
Human Factors	31	(3)
Choosing the Right Team	31	(1)
Team Buy-in	31	(1)
Motivation	31	(1)
Levels of Ability	32	(1)
Feedback	32	(1)
Communication	32	(2)
Agile Fact or Fiction: Team Structure and Human Factors	34	(4)
Being Agile Means Placing a Strong Emphasis on Human Factors	35	(1)
Being Agile Means There Are No Role Divisions (Architect, Senior Developer) Within the Development Team---Everyone Is Equal	35	(1)
Being Agile Means the Team Must ``Collectively Own'' the Code Base (with No Room for Specialization)	36	(1)
Being Agile Means Your Entire Team Must Program in Pairs for All Production Code	36	(1)
Being Agile Means There Is No Need for Testers---the Developers Can Test the System Themselves	36	(1)
Being Agile Means You Can Get Top Results with Mediocre Developers	37	(1)
Being Agile Means You Can Work Only with Top Developers	37	(1)
Being Agile Means There Is Never a Role for Analysts	37	(1)
Being Agile Means You Must Work in a Single Office with a Good Seating Arrangement and Lots of Whiteboards	38	(1)
Summary	38	(1)
ICONIX Process: A Core UML Subset	39	(22)
A Brief History of ICONIX Process	40	(1)
What Can ICONIX Process Do for My Project?	41	(1)
ICONIX Process in Theory (aka Disambiguation and Prefactoring)	41	(3)
What Is a Use Case?	42	(1)
What Is an Actor?	43	(1)
ICONIX Process in a Nutshell	44	(9)
Step 1: Identify Your Real-World Domain Objects	45	(2)
Step 2: Define the Behavioral Requirements	47	(1)
Step 3: Perform Robustness Analysis to Disambiguate the Use Cases and Identify Gaps in the Domain Model	48	(2)
Step 4: Allocate Behavior to Your Objects	50	(1)
Step 5: Finish the Static Model	51	(1)
Step 6: Write/Generate the Code	52	(1)
Step 7: Perform System and User-Acceptance Testing	52	(1)
More About Disambiguation	53	(3)
Do the Domain Model First to Avoid Ambiguity in the Use Cases	53	(1)
Using Robustness Analysis to Disambiguate the Use Cases	54	(2)
More About Prefactoring and Model Refactoring	56	(1)
Key Points to Remember	56	(3)
Key Terms	56	(1)
Core Analysis Modeling Practices	57	(1)
Core Design Modeling Practices	57	(1)
Putting It All Together	57	(2)
Summary	59	(2)
A Core Subset of Agile Practices	61	(28)
Why Define a Core Subset of Agile Practices?	61	(1)
Agile ICONIX: The Core Subset of Agile Practices	61	(10)
Agile/ICONIX Practices	63	(6)
Agile Values That Drive the Agile Practices	69	(2)
Refactoring the Agile Manifesto	71	(4)
The Agile Values	71	(2)
Boiling Down the Values to Their Essence	73	(1)
Giving the Customers What They Want	73	(1)
Refactored Manifesto Summary	74	(1)
Agile Fact or Fiction (Continued)	75	(10)
Modeling and Documentation	75	(3)
Change and Change Management	78	(1)
Customer- and Contract-Related Issues	79	(1)
Working Practices	80	(3)
Planning and Design	83	(2)
Concluding Fact or Fiction	85	(1)
Summary	85	(4)
PART 2 Agile ICONIX Process in Practice: The Mapplet Project
Introducing the Mapplet Project	89	(12)
So, What's a Mapplet, Anyway?	89	(3)
Mapplet Goals	92	(1)
Mapplet Requirements	92	(3)
Project Inception: A JumpStart Workshop in Action	95	(1)
Mapplet Architecture	96	(1)
Initial Use Case Modeling for the Mapplet	97	(1)
First Release Plan	98	(1)
More Information on ArcGIS As Used by the Mapplet	99	(1)
ArcGIS Software Developer Kit	99	(1)
ArcGIS Server Terminology	100	(1)
Summary	100	(1)
Modeling the Mapplet (Release 1)	101	(22)
Beginning with a Prototype (and Just a Little Bit of Modeling)	101	(1)
Visual Acceptance Testing	102	(1)
First Pass Modeling Efforts (and Some Typical Modeling Mistakes)	103	(5)
Tightening Up the Model	108	(5)
The ``Generate Hotel Map for AOI'' Use Case	109	(4)
Let's Take a Look at Some Code	113	(8)
Source Code for the ``Generate Hotel Map for AOI'' Use Case	115	(5)
The Class Diagram	120	(1)
Et Voila! The First (Working Prototype) Release	121	(1)
Summary	122	(1)
Synchronizing the Model and Code: One Small Release at a Time	123	(26)
Keeping It Agile	123	(1)
Divergence of Code and Design over Time	124	(1)
Design Review	125	(22)
``Display Rollover Information'' Robustness Diagram Revisited	125	(5)
``Display Rollover Information'' Sequence Diagram Revisited	130	(6)
Class Diagram	136	(1)
Source Code for the Refactored Design	137	(9)
When to Keep the Model and the Code Tightly Interwoven	146	(1)
``And Today's Lesson Is . . .''	147	(1)
Summary	147	(2)
Mapplet Release 2	149	(24)
Customer Feedback on the First Release	149	(1)
How Persona Analysis Was Used to Drive the Requirements	150	(2)
Using Personas to Identify Requirements	150	(1)
Was This the Right Time for Persona Analysis on the Mapplet Project?	151	(1)
Planning the Second Release	152	(5)
High-Level Requirements for Release 2	152	(1)
The ``Uber'' Use Case	152	(1)
Updated Domain Model	153	(1)
Updated Use Case Diagram	154	(2)
Release 2 Plan	156	(1)
Analysis Review	157	(1)
Robustness Diagrams	157	(1)
Designing Release 2	158	(2)
Sequence Diagrams	158	(1)
Class Diagram	159	(1)
Source Code: Refactoring Is Still Useful After Doing Use Case--Driven Modeling	160	(7)
Screenshots of the Finished Product	167	(1)
Agile Scorecard for the Mapplet Project	168	(1)
Summary	169	(4)
PART 3 Extensions to ICONIX Process
Agile Planning	173	(16)
Why Agile Planning?	173	(2)
Balancing Flexibility and Perception	173	(1)
How Agile ICONIX Differs from Other Agile Methods	174	(1)
Example: Agile Planning in Action	174	(1)
Agile Planning Terminology	175	(1)
Agile Planning Building Blocks	176	(7)
Prioritizing Requirements	176	(1)
Estimating	177	(1)
Release Planning	178	(1)
Tracking Project Velocity	179	(1)
Timeboxing	180	(1)
Tracing Requirements Back to Goals	181	(1)
Minimizing the Use of Gantt Charts	181	(2)
Agile Planning Phases	183	(1)
Modeling: Analysis and Design	183	(1)
Planning: Inception	183	(1)
Planning: Construction	184	(1)
Agile Planning Principles	184	(4)
Three Types of Plan	184	(1)
Feedback Is Vital	185	(1)
Three Types of Release	186	(1)
Rotting Software	186	(1)
No Free Lunches	187	(1)
All Changes Are Not Equal	187	(1)
Does Size Matter?	187	(1)
Summary	188	(1)
Persona Analysis	189	(14)
Extending ICONIX Process with Persona Analysis	189	(1)
The Three Pieces of the Jigsaw Puzzle	190	(2)
Interaction Design	190	(1)
Personas	190	(1)
Interaction Scenarios	190	(2)
Building the Ul Around a Target User	192	(3)
Writing Interaction Scenarios to Validate the Existing System	192	(1)
Using Interaction Scenarios to Describe New Features	193	(2)
Using Interaction Design to Identify Alternate Scenarios	195	(1)
Keeping a Tight Rein on Complexity	196	(1)
Using Interaction Design to Identify Actors and Use Cases	196	(1)
The Finished Use Case	197	(1)
Visual Acceptance Test for Release 2	198	(3)
Summary	201	(2)
A ``Vanilla'' Test-Driven Development Example	203	(24)
A Brief Overview of TDD	204	(1)
A Vanilla TDD Example	205	(20)
Our First Test: Testing for Nothingness	206	(5)
Making CustomerManager Do Something	211	(1)
Our First BookingManager Test: Testing for Nothingness	212	(2)
Adding a Vector: Testing for Something	214	(1)
A Quick Bout of Refactoring	215	(1)
Retrieving a Booking	216	(3)
Testing for Bookings by More Than One Customer	219	(2)
One Last User Story and We're Done (So We're 90% Complete, Then!)	221	(3)
Leave It for the Next Release	224	(1)
Summary of Vanilla TDD	225	(1)
Summary	225	(2)
Test-Driven Development with ICONIX Process	227	(26)
How Agile ICONIX Modeling and TDD Fit Together	227	(1)
The ``Vanilla'' Example Repeated Using ICONIX Modeling and TDD	227	(21)
Implementing the ``Create a New Customer'' Use Case	230	(18)
Summarizing ICONIX+TDD	248	(1)
Stop the Presses: Model-Driven Testing	249	(2)
Summary	251	(2)
Index	253