Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 1
-
Designing a methodology is not at all like designing software, hardware, bridges, or factories. Four things, in particular, get in the way:
· Variations in people. People are not the reliable components that designers count on when designing the other systems.
· Variations across projects. The appropriate methodology varies by project, nationality, and local culture.
Long debug cycles. The test and debug cycle for a methodology is on the order of months and years.
Changing technologies. By the time the methodology designer debugs one methodology design, the technologies, techniques, and cultures have changed and the design needs updating.
Common Design Errors
People who come freshly to their assignment of designing a methodology make a standard set of errors:
One size for all projects
Here is a conversation that I have heard all too often over the years: "Hi, Alistair. We have projects in many technologies all over the globe. We desperately need a common methodology for all of them. Could you please design one for us? "
"I'm afraid that would not be practical: The different technologies, cultures, and project priorities call for different ways of working. "
"Right, got that. Now, please do tell us what our common methodology will be. " ". .. !! ?" This request is so widespread that I spend most of the next chapter on methodology tailoring.
The need for localized methodologies may be clear to you by now, but it will not be clear to your new colleague who gets handed the assignment to design the corporation's common methodology. Intolerant
Novice methodology designers have this notion that they have the answer for software development and that everyone really ought to work that way.
Software development is a fluid activity. It requires that people notice small discrepancies wherever they lie and that they communicate and resolve the discrepancies in whatever way is most practical. Different people thrive on different ways of working.
A methodology is, in fact, a straightjacket. It is exactly the set of conventions and policies the people agree to use: It is the size and shape of straightjacket they choose for themselves.
Given the varying characteristics of different people, though, that straightjacket should not be made any tighter than it absolutely needs to be.
Techniques are one particular section of the methodology that usually can be made tolerant. Many techniques work quite well, and different ones suit different people at different times.
The subject of how much tolerance belongs in the methodology should be a conscious topic of discussion in the design of your methodology.
We have developed, over the years, an assumption that a heavier methodology, with closer tracking and more artifacts, will somehow be "safer" for the project than a lighter methodology with fewer artifacts.
The opposite is actually the case, as the principles in this section should make clear. However, that initial assumption persists, and it manifests itself in most methodology designs.
The heavier-is-safer assumption probably comes from the fear that project managers experience when they can't look at the code and detect the state of the project with their own eyes. Fear grows with the distance from the code. So they quite naturally request more reports summarizing various states of affairs and more coordination points. The alternative is to. .. trust people. This can be a truly horrifying thought during a project under intense pressure. Being a Smalltalk programmer, I felt this fear firsthand when I had to coordinate a COBOL programming project.
Fear or no fear, adding weight to the methodology is not likely to improve the team's chance of delivering. If anything, it makes the team less likely to deliver, because people will spend more time filling in reports than making progress. Slower development often translates to loss of a market window, decreased morale, and greater likelihood of losing the project altogether.
Part of the art of project management is learning when and how to trust people and when not to trust them. Part of the art of methodology design is to learn what constraints add more burden than safety. Some of these constraints are explored in this chapter.
Embellished
Without exception, every methodology I have ever seen has been unnecessarily embellished with rules, practices, and ideas that are not strictly necessary. They may not even belong in the methodology. This even applies to the methodologies I have designed. It is so insidious that I have posted on the wall in front of me, in large print: "Embellishment is the pitfall of the methodologist. " Embellishing a Methodology
I detected this tendency in myself while designing my first methodology. I asked a programmer colleague, a very practical person freshly returned from a live project, to double-check, edit, and trim my design. He indeed found the embellishments I was worried about. However, he then added one chapter to the methodology, calling for the production of contract-based design and deliverables he had just read about. I phoned him. "Surely you don't mean to say you used these on your last project? " I asked.
He replied, "Well, no, not on that project. But it's a really good idea and I think we ought to do it. "
-
Навигация [ Часть 1. Глава 19. ]
Закладки
After much coaching for six months, his programs still…
That it is people who design software is terribly obvious. ..…
The complete discussion about when and where to apply concurrent…
The chart shows the state of the user stories being worked…
We see an example of needing these normalizing rituals in…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
In arguing for the Theory Building View, the basic…
On a new project, I would use Crystal Orange as a base…
The group of 17 quickly agreed on those value choices.…
1. Project name, job of person interviewed (the interviewee…
Crystal Clear is the most tolerant, low-ceremony small-team…
Figure 4-1. Elements of a methodology. Roles. Who you…
Using the planning game in this way, the sponsors can properly…
Agility implies maneuverability, a characteristic that is…
The main question is, if you were funding this project,…
It follows that on the Theory Building View, for the primary…
For us as designers, it was possible to express both propositional…
Walk around your place of work. Notice · The convection currents…
The industry is littered with projects whose sponsors did not…