Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 3
-
Whenever someone proposed a new object-centered / object-based / object-hybrid methodology for us to include in the methodology library, he would say, "Try it on a project, and tell us afterwards how it worked. " They would typically object, "But that will take years! It is obvious that this is great! " To my recollection, not one of these obvious new methodologies was ever used on a project.
Since that time, I use Wayne Stevens' approach and see the same thing happen.
How are new methodologies made? Here's how I work when I am personally involved in a project:
· I adjust, tune, and invent whatever is needed to take the project to success.
· After the project, I extract those things I would repeat again under similar circumstances and add them to my repertoire of tactics and strategies.
· I listen to other project teams when they describe their experiences and the lessons they learned.
But when someone sends me a methodology proposal, I ask him to try it on a project first and report back afterwards.
The successor to "untried" is "used once. " The methodology author, having discovered one project on which the methodology works, now announces it as a general solution. The reality is that different projects need different methodologies, and so any one methodology has limited ability to transfer to another project.
I went through this phase with my Crystal Orange methodology (Cockburn 1998), and so did the authors of XP. Fortunately, each of us had the good sense to create a "Truth in Advertising" label describing our own methodology’s area of applicability.
We will revisit this theme throughout the rest of the book: How do we identify the area of applicability of a methodology, and how do we tailor a methodology to a project in time to benefit the project?
Methodologically Successful Projects
You may be wondering about these project interviews I keep referring to. My work is based on looking for "methodologically successful" projects. These have three characteristics:
· The project was delivered. I don't ask if it was completed on time and on budget, just that the software went out the door and was used.
· The leadership remained intact. They didn't get fired for what they were doing.
· The people on the project would work the same way again.
The first criterion is obvious. I set the bar low for this criterion, because there are so many strange forces that affect how people refer to the "successfulness" of a project. If the software is released and gets used, then the methodology was at least that good.
The second criterion was added after I was called in to interview the people involved with a project that was advertised as being "successful. " I found, after I got there, that the project manager had been fired a year into the project because no code had been developed up to that time, despite the mountains of paperwork the team had produced. This was not a large military or life-critical project, where such an approach might have been appropriate, but it was a rather ordinary, 18-developer technical software project.
The third criterion is the difficult one. For the purpose of discovering a successful methodology, it is essential that the team be willing to work in the prescribed way. It is very easy for the developers to block a methodology. Typically all they have to say is, "If I do that, it will move the delivery date out two weeks. " Usually they are right, too.
If they don't block it directly, they can subvert it. I usually discover during the interview that the team subverted the process, or else they tolerated it once but wouldn't choose to work that way again.
Sometimes, the people follow a methodology because the methodology designer is present on the project. I have to apply this criterion to myself and disallow some of my own projects. If the people on the project were using my suggestions just to humor me, I couldn't know if they would use them when I wasn't present.
The pertinent question is, “Would the developers continue to work that way if the methodology author was no longer present? ”
So far, I have discovered three methodologies that people are willing to use twice in a row. They are
· Responsibility-Driven Design (Wirfs-Brock 1991)
· Extreme Programming (Beck 1999)
· Crystal Clear (Cockburn 2002)
(I exclude Crystal Orange from this list, because I was the process designer and lead consultant. Also, as written, it deals with a specific configuration of technologies and so needs to be reevaluated in a different, newly adapted setting. )
Even if you are not a full-time methodology designer, you can borrow one lesson from this section about project interviews. Most of what I have learned about good development habits has come from interviewing project teams. The interviews are so informative that I keep on doing them.
This avenue of improvement is also available to you. Start your own project interview file, and discover good things that other people do that you can use yourself.
Author Sensitivity
-
Закладки
For us as designers, it was possible to express both…
The main question is, if you were funding this project, which…
The third problem is absence of feedback from the downstream…
In arguing for the Theory Building View, the basic issue…
Figure 4-1. Elements of a methodology. Roles. Who you…
Accepting program modifications demanded by changing external…
The group of 17 quickly agreed on those value choices. Developing…
1. Project name, job of person interviewed (the interviewee…
While writing, reading, typing, or talking, we pick up…
That it is people who design software is terribly obvious.…
Crystal Clear is the most tolerant, low-ceremony small-team…
It follows that on the Theory Building View, for the primary…
Walk around your place of work. Notice · The convection…
The complete discussion about when and where to apply…
The surprising thing about human success modes is how nebulous…
The chart shows the state of the user stories being worked…
The industry is littered with projects whose sponsors did…