Agile Software Development
Автор: Alistair Cockburn /
INTRODUCTION The Impossibility of Communication
-
Часть 1
-
People who sponsor software development can get from this book an understanding of how various organizational, behavioral, and funding structures affect the rate at which they receive value from their development teams. Project sponsors may pay less attention to the details of methodology construction than people who are directly involved in the projects. They should still understand the consequences of certain sorts of methodology decisions.
Team leads and project managers can see how seating, teaming, and individuality affect their project's outcome. They can also learn what sorts of interventions are more likely to have better or worse consequences. They will need to understand the construction and consequences of their methodology and how to evolve their methodology—making it as light as possible, but still sufficient.
Process and methodology designers can examine and argue with my choice of terms and principles for methodology design. The ensuing discussions should prove useful for the field.
Software developers should come to know this material simply as part of being in the profession. In the normal progression from newcomers to leaders, they will have to notice what works and doesn't work on their projects. They will also have to learn how to adjust their environment to become more effective. "Our methodology" really means "the conventions we follow around here, " and so it becomes every professional's responsibility to understand the basics of methodology construction.
This book is far from the last word in methodology construction, but it does contain some first words.
Organization of the Book
The book is designed to set up two nearly impossible questions at the beginning and derive answers for those questions by the end of the book:
· If communication is fundamentally impossible, how can people on a project manage to do it?
· If all people and all projects are different, how can we create any rules for productive projects?
To achieve that design, I wrote the book a bit in the "whodunit" style of a mystery. I start with the broadest and most philosophical discussions: "What is communication? " and "What is software development? "
The discussion moves through still fairly abstract topics such as "What are the characteristics of a human? " and "What affects the movement of ideas within a team? "
Eventually, it gets into more concrete territory with "What are the elements and principles of methodologies? " This is a good place for you to start if you are after concrete material early on.
Finally, the discussion gets to the most concrete matter: "What does a light, sufficient, self-evolving methodology look like? " and "How does a group create a custom and agile methodology in time to do the project any good? "
The two appendixes contain supporting material. The first contains the "Manifesto for Agile Software Development, " signed by 17 very experienced software developers and methodologists.
The second appendix contains extracts from three pieces of writing that are not as widely read as they should be. I include them because they are core to the topics described in the book.
Heritage of the Ideas in This Book
The ideas in this book are based on 25 years of development experience and 10 years of investigating projects directly.
The IBM Consulting Group asked me to design its first object-oriented methodology, in 1991. I looked rather helplessly at the conflicting "methodology" books at the time. My boss, Kathy Ulisse, and I decided that I should debrief project teams to better understand how they really worked. What an eye-opener! The words they used had almost no overlap with the words in the books.
The interviews keep being so valuable that I still visit projects with sufficiently interesting success stories to find out what they encountered, learned, and recommend. The crucial question I ask before the interview is, "And would you like to work the same way again? ". When people describe their experiences in words that don't fit my vocabulary, it indicates new areas in which I lack distinctions and words.
The reason for writing this book now is that the words and distinctions finally are correlating with descriptions of project life and project results. They are proving more valuable for diagnosis and intervention than any of the tools that I used previously.
The ideas in this book have been through dozens of development teams, eight methodology designs, and a number of successful projects on which I participated.
I am not the only person who is using these ideas:
· Kent Beck and Ward Cunningham worked through the late 1980s on what became called Extreme Programming (XP) in the late 1990s.
· Jim Highsmith studied the language and business use of complex adaptive systems in the mid-1990s and wrote about the application of that language to software development in his Adaptive Software Development.
· Ken Schwaber and Jeff Sutherland were constructing the Scrum method of development at about the same time, and many project leaders made similar attempts to describe similar ideas through the same years. When a group of us met in February 2001 to discuss our differences and similarities, we found we had a surprising number of things in common. We selected the word agile to describe our intent and wrote the Manifesto for Agile Software Development (Appendix A).
We are still formulating the principles that we share and are finding many other people who could have been at that meeting if they had known about it or if their calendars had permitted their presence.
Core to agile software development is the use of light-but-sufficient rules of project behavior and the use of human- and communication-oriented rules.
-
Навигация [ Часть 1. Глава 1. ]
Закладки
For us as designers, it was possible to express both propositional…
Agility implies maneuverability, a characteristic that is…
Crystal Clear is the most tolerant, low-ceremony small-team…
The complete discussion about when and where to apply…
The chart shows the state of the user stories being worked…
The group of 17 quickly agreed on those value choices.…
It follows that on the Theory Building View, for the primary…
On a new project, I would use Crystal Orange as a base…
Types of Methodologies Rechtin (1997) categorizes methodologies…
That it is people who design software is terribly obvious.…
The surprising thing about human success modes is how nebulous…
After much coaching for six months, his programs still…
In arguing for the Theory Building View, the basic issue…
Walk around your place of work. Notice · The convection…
Using the planning game in this way, the sponsors can properly…
Games are not just for children, although children also…
While writing, reading, typing, or talking, we pick up traces…
The main question is, if you were funding this project,…
Accepting program modifications demanded by changing…
We see an example of needing these normalizing rituals in the…