Alistair Cockbur - Agile Software ...

[ Pobierz całość w formacie PDF ]
Agile Software Development
page 1
Agile
Software
Development
Draft version: 3b
The Agile Software Development Series
Cockburn * Highsmith Series Editors
Alistair Cockburn
copyright Alistair Cockburn, 2000 - 2001
©Alistair Cockburn 2000
Agile Software Development
page 2
©Alistair Cockburn 2000
Agile Software Development
page 3
TABLE OF CONTENTS
INTRODUCTION Unknowable and Incommunicable
13
The Problem with Parsing Experience
14
The Impossibility of Communication
17
Three Levels of Listening
22
Chapter 1 A Cooperative Game of Invention and Communication 28
Software and Poetry
29
Software and Games
30
A Second Look at the Cooperative Game
35
Chapter 2 Individuals
43
Them's Funky People
44
Overcoming Failure Modes
47
Working Better in Some Ways than Others
52
Drawing on Success Modes
61
Chapter 3 Communicating, Cooperating Teams
69
Convection Currents of Information
70
Jumping Communication Gaps
81
Teams as Communities
88
Teams as Ecosystems
95
What should I do tomorrow?
97
Chapter 4 Methodologies
100
An Ecosystem That Ships Software
101
Methodology Concepts
101
Methodology Design Principles
120
XP Under Glass
139
Why Methodology at All?
142
What Should I Do Tomorrow?
144
Chapter 5 Agile and Self-Adapting
146
Light But Sufficient
147
Agile
149
Becoming Self-Adapting
153
What Should I do Tomorrow?
161
Chapter 6 The Crystal Methodologies
164
©Alistair Cockburn 2000
 Agile Software Development
page 4
Shaping the Crystal Family
165
Crystal Clear
167
Crystal Orange
168
Crystal Orange / Web
170
What Should I do tomorrow?
173
Appendix A: The Agile Software Development Manifesto
175
The Agile Alliance
177
The Manifesto
178
Supporting the Values
180
Appendix B: Naur, Ehn, Musashi
184
Peter Naur, Programming as Theory Building
186
Pelle Ehn, Wittgenstein's Language Games
196
Musashi
207
Books and References
212
Books by Title
212
References by Author
214
©Alistair Cockburn 2000
Agile Software Development
page 5
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 relatively defect-
free, but more than that, you need a way to examine how your team is doing
along the way.
Purpose
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.
Four Goals
In this book, I shall
•
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
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
©Alistair Cockburn 2000
  [ Pobierz całość w formacie PDF ]