Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 4
-
A methodology's principles are not arrived at through an emotionally neutral algorithm but come from the author's personal background. To reverse the saying from The Wizard of Oz, "Pay great attention to the man behind the curtain. "
Each person has had experiences that inform his present views and serve as their anchor points. Methodology authors are no different.
In recognition of this, Jim Highsmith has started interviewing methodology authors about their backgrounds. In Agile Software Development Ecosystems (Highsmith 2002), he will present not only each author's methodology but also his or her background.
A person's anchor points are not generally open to negotiation. They are fixed in childhood, early project experiences, or personal philosophy. Although we can renormalize a discussion with respect to vocabulary and scope, we cannot do that with personal beliefs. We can only accept the person's anchor points or disagree with them.
When Kent Beck quipped, "All methodology is based on fears, " I first thought he was just being dismissive. Over time, I have found it to be largely true. One can almost guess at a methodology author's past experiences by looking at the methodology. Each element in the methodology can be viewed as a prevention against a bad experience the methodology author has had.
· Afraid that programmers make many little mistakes? Hold code reviews.
· Afraid that users don't know what they really want? Create prototypes.
· Afraid that designers will leave in the middle of the project? Have them write extensive design documentation as they go.
Of course, as the old saying goes, just because you are paranoid doesn't mean that they aren't after you. Some of your fears may be well founded. We found this in one project, as told to us over time by an adventuresome team leader. Here is the story as we heard it in our discussion group: Don't Touch My Private Variables
A team leader wanted to simplify the complex design surrounding the use of not-quite-private methods that wrote to certain local variables.
Someone in our group proposed making all methods public. This would simplify the design tremendously.
The team leader thought for a moment and then identified that he was operating on a fear that the programmers would not follow the necessary programming convention to keep the software safe. He wanted the programmers to use those public methods only for the particular programming situation that was causing trouble.
He was afraid that in the frenzy of deadlines, they would use them all the time, which would cause maintenance problems. He was willing to try the experiment of making them public and just writing on the team's whiteboard the very simple rule restricting their use.
I said, "Maybe your fears are well founded. How about if you don't just trust the people to behave well, but also write a little script to check the actual use of those methods over time? This way you will discover whether your fears are well founded or not. "
The team leader agreed. The team leader went on vacation for two weeks. When he returned, he ran the script and found that the programmers had, in fact, been using the new, public methods, ignoring the note on the whiteboard.
(One person at the table chimed in here, "Well, sure, those were the only documented methods! ")
This story raises an interesting point about trust: As much as I love to trust people, a weakness of people is being careless. Sometimes it is important to simply trust people, but sometimes it is important to install a mechanism to find out whether people can be trusted on a particular topic.
The final piece of personal baggage of the methodology authors is their individual philosophy. Some have a laissez-faire philosophy, some a military control philosophy. The philosophy comes with the person, shaping his experiences and being shaped by his experiences, fears, and wishes.
It is interesting to see how much of an author's methodology philosophy is used in his personal life. Does Watts Humphreys use a form of the Personal Software Process when he balances his checkbook? Does Kent Beck do the simplest thing that will work, getting incremental results and feedback as soon as he can? Do I travel light, and am I tolerant of other people's habits?
Here are some key bits of my background that either drive my methodology style or at least are consistent with it.
I travel light, as you might guess. I use a small laptop, carry a small phone, drive a small car, and see how little luggage I need when traveling. In terms of the eternal tug-of-war between mobility and armor, I am clearly on the side of mobility.
I have lived in many countries and among many cultures and keep finding that each works. This perhaps is the source of my sensitivity to development cultures and why I encourage tolerance in methodologies.
I also like to think very hard about consequences, so that I can give myself room to be sloppy. Thus, I balance the checkbook only when I absolutely have to, doing it in the fastest way possible, just to make sure checks don't bounce. I don't care about absolute accuracy. Once, when I built bookshelves, I worked out the fewest places where I had to be accurate in my cutting (and the most places where I could be sloppy) to get level and sturdy bookshelves.
When I started interviewing project teams, I was prepared to discover that process rigor was the secret to success. I was actually surprised to find that it wasn’t. However, after I found that using light methodologies, communicating, and being tolerant were effective, it was natural that I would capitalize on those results.
-
Закладки
We see an example of needing these normalizing rituals in the…
Accepting program modifications demanded by changing external…
Using the planning game in this way, the sponsors can properly…
Walk around your place of work. Notice · The convection currents…
Agility implies maneuverability, a characteristic that…
After much coaching for six months, his programs still…
In arguing for the Theory Building View, the basic issue is…
The third problem is absence of feedback from the downstream…
Types of Methodologies Rechtin (1997) categorizes methodologies…
The main question is, if you were funding this project,…
The complete discussion about when and where to apply concurrent…
While writing, reading, typing, or talking, we pick up traces…
The group of 17 quickly agreed on those value choices.…
Figure 4-1. Elements of a methodology. Roles. Who you…
The chart shows the state of the user stories being worked…
It follows that on the Theory Building View, for the primary…
Crystal Clear is the most tolerant, low-ceremony small-team…
That it is people who design software is terribly obvious.…
1. Project name, job of person interviewed (the interviewee…