Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 2
-
From this experience, I learned that the words "ought to" and "should" indicate embellishment. If someone says that people "should" do something, it probably means that they have never done it yet, they have successfully delivered software without it, and there probably is no chance of getting people to use it in the future.
Here is a sample story about that.
Discovering "Should"
Tester: "And then the developers have a meeting with the testers in which they describe the basic design. "
Me: "Really, do they do that? "
Tester: "What do you mean? Of course they do. "
Me: "Oh, yeah. They really do that, do they? "
Tester: "They've got to, or else the testers can't do their job! "
Me: "Right. Um. .. In that case, there was such a meeting, and I can interview those people to find out what happened in the meeting. Can you tell me the date of such a meeting, and who was in the room? "
Tester: "Well, we were going to have it. I mean, you really should have that meeting, it's really valuable. .. "
We didn't have to go much farther than that. Of course, no such meeting had taken place. Further, it was doubtful that we could enforce such a meeting in that company at that time, however useful it might have been.
There is another side to this embellishment business. Typically, the process owner has a distorted view of how developers really work. In my interviews, I rarely ever find a team of people who works the way the process owner says they work. This is so pervasive that I have had to mark as unreliable any interview in which I only got to speak with the manager or process designer.
The following is a sample, and typical, conversation from one of my interviews. At the time, I was looking for successful implementations of Object Modeling Technique (OMT). The person who was both process and team lead told me that he had a successful OMT project for me to review. I flew to California to interview this team, and the process and team lead told me that the team had a successful project for me to review. Uncovering Process Shortcuts
Me: "These are samples of the work products? .. . This is a state diagram? "
Leader: "Well, it's not really one. It's more of a flow diagram. I have to teach them how to make state diagrams properly. "
Me: "But these are actual samples of the work products produced. Did you use an iterative and incremental process? "
Developer nods.
Leader: "We used a modification of Boehm's spiral model. "
Me: "OK. And did the requirements or the design change in the second iteration? "
Developer: "Of course. "
Me: "OK. .. . How did you manage to update all these diagrams in the second iteration? " Developer: "Oh, we didn't. We just changed the code. .. "
Extreme Programming stands in contrast to the usual, deliverable-based methodologies. XP is based around activities. The rigor of the methodology resides in people carrying out their activities properly.
Not being aware of the difference between deliverable-based and activity-based methodologies, I was unsure how to investigate my first XP project. After all, the team has no drawings to keep up to date, so obviously there would be no out-of-date work products to discover!
An activity-based methodology relies on activities in action. XP relies on programming in pairs, writing unit tests, refactoring, and the like.
When I visit a project that claims to be an XP project, I usually find pair programming working well (or else they wouldn't declare it an XP project). Then, while they are pair programming, the people are more likely to write unit tests, and so I usually see some amount of test-writing going on.
The most common deviation from XP is that the people do not refactor their code often, which results in the code base becoming cluttered in ways that properly developed XP code shouldn't.
In general, though, XP has so few rules to follow that most of the areas of embellishment have been removed. XP is a special case of a methodology, and I'll analyze it separately at the end of the chapter.
Personally, I tend to embellish around design reviews and testing. I can't seem to resist sneaking an extra review or an extra testing activity through the "should" door ("Of course they should do that testing! " I hear you cry. Shouldn't they? !).
The way to catch embellishment is to have the directly affected people review the proposal. Watch their faces closely to discover what they know they won't do but are afraid to say they won’t do.
Most methodologies are untried. Many are simply proposals created from nothing. This is the fullblown "should" in action: "Well, this really looks like it should work. "
After looking at dozens of methodology proposals in the last decade, I have concluded that nothing is obvious in methodology design. Many things that look like they should work don't (testing and keeping documentation up to date, for example), and many things that look like they shouldn't work actually do work (pair programming and test-first development, for example).
The late Wayne Stevens, designer of the IBM Consulting Group's Information Engineering methodology in the early 1990s, was well aware of this trap.
-
Закладки
Types of Methodologies Rechtin (1997) categorizes methodologies…
Games are not just for children, although children also play…
After much coaching for six months, his programs still looked…
The group of 17 quickly agreed on those value choices. Developing…
The surprising thing about human success modes is how…
We see an example of needing these normalizing rituals…
Crystal Clear is the most tolerant, low-ceremony small-team…
Walk around your place of work. Notice · The convection…
13. (FIRST TECHNIQUE). .. your sword now having bounced…
The chart shows the state of the user stories being worked…
While writing, reading, typing, or talking, we pick up traces…
In arguing for the Theory Building View, the basic issue…
The complete discussion about when and where to apply…
Accepting program modifications demanded by changing external…
The main question is, if you were funding this project,…
That it is people who design software is terribly obvious.…
1. Project name, job of person interviewed (the interviewee…
The industry is littered with projects whose sponsors did…
It follows that on the Theory Building View, for the primary…
Agility implies maneuverability, a characteristic that is…