Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 9
-
He also has them start earlier in the requirements-gathering process, so that they can show intermediate results to the users sooner, again getting feedback earlier. He has them spend a bit more time drawing their designs so that the DBA can read them easily.
He does this knowing that he is causing them extra work. He is drawing on their spare capacity.
Figure 4-24 diagrams this second work strategy. In Figure 4-24, you see only one requirements person submitting information to one Smalltalk programmer, who is submitting work to the one DBA. The top two curves are used five times, for the five requirements writers and the five programmers.
Figure 4-24. Bottleneck station starts work higher on the completeness and stability curve than do non-bottleneck stations.
Notice in Figure 4-24 that the Smalltalker starts work as soon as the requirements person has something to hand him, but the DBA waits until the Smalltalker's work is almost complete and quite stable before starting.
Notice also that the DBA is completing work faster than the others. This is a reflection of the fact that the other groups are doing more rework, and hence reaching completeness and stability more slowly. This is necessary because four other groups are submitting work to the DBA. In a balanced situation, the DBA reaches completion five times as fast as the others.
People on a bottleneck activity need to work as efficiently as possible and cannot afford to do much rework. (I say "much rework" because there is always rework in software development; the goal is to reduce the amount of rework. )
Principle 7 has three consequences.
Consequence 1. Do whatever you can to speed up the work at the bottleneck activity.
That result is fairly obvious, except that people often don't do it.
Every project has a bottleneck activity. It moves during the project, but there is always one. In the above example, it is the DBA's work. There are four ways to improve a bottleneck activity. Principle 7 addresses the fourth.
1. Get better people doing that work.
2. Get more people to do that work.
3. Get better tools for the people doing that work.
4. Get the work that feeds that activity to a more complete and stable state before passing it along.
Consequence 2. People at the nonbottleneck activities can work inefficiently without affecting the overall speed of the project!
This is not obvious.
Of course, one way for people to work inefficiently is to take long smoking breaks, surf the Web, and spend time at the water cooler. Those are relatively uninteresting for the project and for designing methodologies.
More interesting is the idea of spending efficiency, trading it for stability.
The nonbottleneck people can spend some of their extra capacity by starting earlier, getting results earlier, doing more reword and doing it earlier, and doing other work that helps the person at the bottleneck activity.
Spending excess capacity for rework is significant for software development because rework is one of the things that causes software projects to take so much time. The users see the results and change their requests; the designers see their algorithm in action and change the design; the testers break the program, and the programmers change the code. In the case of the above example, all of these will cause the DBA rework.
Applying Principle 7 and the diagram of concurrent development (Figure 4-14) to the problem of the five Smalltalkers and one DBA, the project manager can decide that the Smalltalk programmers can work "inefficiently, " meaning "doing more rework than they might otherwise, " in exchange for making their work more stable earlier. This means that the DBA, to whom rework is expensive, will be given more stable information at the start.
Principle 7 offers a strategy for when and where to use early concurrency, and when and where to delay it. Most projects work from a given amount of money and an available set of people. Principle 7 helps the team members adjust their work to make the most of the people available.
Principle 7 can be used on every project, not just those that are as out of balance as the sample project. Every project has a bottleneck activity. Even when the bottleneck moves, Principle 7 applies to the new configuration of bottleneck and nonbottleneck activities.
Consequence 3. Applying the principle of expendable efficiency yields different methodologies in different situations, even keeping the other principles in place.
Here is a first story, to illustrate. Winifred and Principle 7.
Project Winifred did resemble the sample project above. It was the project on which I learned to apply the principle. In the middle of the project, there were about a dozen Smalltalk programmers, four COBOL programmers, and two DBAs. The Smalltalk programmers could revise their designs faster than any of the others. The two DBAs were overloaded, as in the example story. We arranged for the Smalltalkers to work very closely with the requirements writers, getting started as soon as there was information to work from. Applying osmotic and face-to-face communication, rather than documents between them, the Smalltalkers worked by word of mouth, changing their designs as they heard new information from the requirements writers.
The DBAs and COBOL programmers started their work only after the Smalltalkers had a "relatively stable" design that had passed its design review.
-
Навигация [ Часть 9. Глава 19. ]
Закладки
After much coaching for six months, his programs still looked…
The third problem is absence of feedback from the downstream…
Crystal Clear is the most tolerant, low-ceremony small-team…
Accepting program modifications demanded by changing…
It follows that on the Theory Building View, for the primary…
The complete discussion about when and where to apply concurrent…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
Games are not just for children, although children also play…
We see an example of needing these normalizing rituals in the…
The chart shows the state of the user stories being…
Types of Methodologies Rechtin (1997) categorizes methodologies…
For us as designers, it was possible to express both propositional…
Walk around your place of work. Notice · The convection…
That it is people who design software is terribly obvious.…
The industry is littered with projects whose sponsors did…
The surprising thing about human success modes is how…
1. Project name, job of person interviewed (the interviewee stays…
While writing, reading, typing, or talking, we pick…
Using the planning game in this way, the sponsors can…