Agile Software Development The Cooperative Game

by Cockburn, Alistair

• ISBN13: 9780321482754
• ISBN10: 0321482751
• Edition: 2nd
• Format: Paperback
• Copyright: 2006-10-19
• Publisher: Addison-Wesley Professional

Summary

After years of implementation and refinement, the practice of developing software the agile way merits an updated look - this book is it.

Author Biography

Dr. Alistair Cockburn is an internationally renowned expert on all aspects of software development, from object-oriented modeling and architecture, to methodology design, to project management and organizational alignment. One of the pioneers who coined the term “agile software development,” he co-authored the 2001 Agile Software Development Manifesto and the 2005 Declaration of Interdependence. Since 1975, he has led projects and taught in places from Oslo to Cape Town, from Vancouver to Beijing. His work has covered topics from design to management to testing, in research, in government, and in industry. His most recent book is Crystal Clear: A Human-Powered Methodology for Small Teams. His books Writing Effective Use Cases and Agile Software Development won back-to-back Jolt Productivity Awards in 2001 and 2002.

Table of Contents

List of Figures	p. xi
List of Stories	p. xvii
Preface	p. xxi
Preface to 2nd Edition	p. xxxi
Unknowable and Incommunicable	p. 1
The Problem with Parsing Experience	p. 3
The Impossibility of Communication	p. 8
Three Levels of Listening	p. 14
So, What Do I Do Tomorrow?	p. 19
Unknowable and Incommunicable: Evolution	p. 21
Communication and Shared Experience	p. 23
Shu-Ha-Ri	p. 24
A Cooperative Game of Invention and Communication	p. 27
Software and Poetry	p. 29
Software and Games	p. 31
A Second Look at the Cooperative Game	p. 37
What Should This Mean to Me?	p. 44
A Cooperative Game of Invention and Communication: Evolution	p. 47
The Swamp Game	p. 49
Competition Within Cooperation	p. 50
Other Fields as Cooperative Games	p. 52
Software Engineering Reconstructed	p. 53
Individuals	p. 65
Them's Funky People	p. 67
Overcoming Failure Modes	p. 72
Working Better in Some Ways than Others	p. 79
Drawing on Success Modes	p. 91
What Should I Do Tomorrow?	p. 97
Individuals: Evolution	p. 99
Strategy Balancing	p. 101
Communication, Cooperating Teams	p. 105
Convection Currents of Information	p. 107
Jumping Communication Gaps	p. 121
Teams as Communities	p. 129
Teams as Ecosystems	p. 139
What Should I Do Tomorrow?	p. 141
Teams: Evolution	p. 143
A Sample Office Layout Revisited	p. 145
Methodologies	p. 147
An Ecosystem That Ships Software	p. 149
Methodology Concepts	p. 149
Methodology Design Principles	p. 175
XP under Glass	p. 199
Why Methodology at All?	p. 204
What Should I Do Tomorrow?	p. 206
Methodologies: Evolution	p. 207
Methodologies versus Strategies	p. 209
Methodologies across the Organization	p. 210
Process as Cycles	p. 212
Describing Methodologies More Simply	p. 214
Agile and Self-Adapting	p. 217
Light but Sufficient	p. 219
Agile	p. 222
Becoming Self-Adapting	p. 228
What Should I Do Tomorrow?	p. 239
Agile and Self-Adapting: Evolution	p. 241
Misconstruing the Message	p. 244
Evolution of the Agile Methodologies	p. 261
New Methodology Topics	p. 273
Persistent Questions	p. 290
Agile Outside Software Development	p. 311
The Crystal Methodologies	p. 335
Shaping the Crystal Family	p. 337
Crystal Clear	p. 340
Crystal Orange	p. 342
Crystal Orange Web	p. 344
What Should I Do Tomorrow?	p. 350
The Crystal Methodologies: Evolution	p. 351
The Crystal Genetic Code	p. 353
Crystal Clear	p. 358
Stretching Crystal Clear to Yellow	p. 361
The Agile Software Development Manifesto	p. 367
The Agile Alliance	p. 369
The Manifesto	p. 370
Supporting the Values	p. 373
The Agile Software Development Manifesto and the Declaration of Interdependence	p. 379
The Agile Manifesto Revisited	p. 381
The Declaration of Interdependence	p. 384
Naur, Ehn, Musashi	p. 391
Peter Naur, Programming as Theory Building	p. 393
Pelle Ehn, Wittgenstein's Language Games	p. 407
Musashi	p. 420
Naur, Ehn, Musashi: Evolution	p. 427
Naur	p. 429
Ehn	p. 429
Musashi	p. 429
Afterword	p. 431
Agile Software Development	p. 433
Business as a Cooperative Game	p. 434
Leadership	p. 435
Everyone	p. 435
Books and References	p. 437
Index	p. 453
Table of Contents provided by Ingram. All Rights Reserved.

Excerpts

Preface Preface Is software development an art, a craft, science, engineering, or something else entirely? Does it even matter? Yes, it does matter, and it matters to you. Your actions and their results will differ depending on which of those is more correct. The main thing is this: You want your software out soon and defect free, but more than that, you need a way to examine how your team is doing along the way. Purpose It is time to reexamine the notions underlying software development. The trouble is that as we look at projects, what we notice is constrained by what we know to notice. We learn to distinguish distinct and separable things in the extremely rich stream of experience flowing over us, and we pull those things out of the stream for examination. To the extent that we lack various key distinctions, we overlook things that are right in front of us. We anchor the distinctions in our memories with words and use those words to reflect on our experiences. To the extent that we lack words to anchor the distinctions, we lack the ability to pull our memories into our conversations and the ability to construct meaningful strategies for dealing with the future. In other words, to reexamine the notions that underlie software development, we have to reconsider the distinctions that we use to slice up our experience and the words we use to anchor our memories. This is, of course, a tall order for any book. It means that some of the earlier parts of this book will be rather abstract. I see no way around it, though. The last time people constructed a vocabulary for software development was in the late 1960s, when they coined the phrase software engineering, as both a wish and a direction for the future. It is significant that at the same time the programming-should-be-engineering pronouncement was made, Gerald Weinberg was writing The Psychology of Computer Programming . In that book, software development doesn't look very much like an engineering discipline at all. It appears to be something very human-centric and communication-centric. Of the two, Weinberg's observations match what people have reported in the succeeding 30 years, and software engineering remains a wishful term. In this book, I will Build distinctions and vocabulary for talking about software development Use that vocabulary to examine and anchor critical aspects of software projects that have been pushed to the sidelines too often Work through the ideas and principles of methodologies as "rules of behavior" Merge our need for these rules of behavior with the idea that each project is unique, and derive effective and self-evolving rules I hope that after reading this book, you will be able to use the new vocabulary to look around at your project, notice things you didn't notice before, and express those observations. As you gain facility, you should be able to Discuss Extreme Programming, the Capability Maturity Model, the Personal Software Process, or your favorite process Determine when each process is more or less applicable Understand people who have differing opinions, abilities, and experience Audience Each person coming to this book does so with a different experience level, reading style, and role. Here's how you might read the book to use it to your greatest advantage: by experience, by reading style, or by role. By Experience This book is written for the more experienced audience. The book does not contain procedures to follow to develop software; in fact, core to the book is the concept that every technique has limitations. Therefore, it is impossible to name one best and correct way to d