Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 11
-
Over the course of the project, we eventually had four experts and 20 other programmers with mixed experience. We got our 24 programmers.
We reviewed our assessment at several times during the project, and at the end. Yes, six good Smalltalk programmers would have been sufficient. No, 12 programmers, even 16 programmers of the mixed experience levels we were seeing would not have been sufficient.
The correct jump was from 6 good programmers to 24 programmers of mixed ability.
Consequence 3. Teams should be improved, not enlarged
Here is a common problem: A manager has a ten-person team that sits close together and achieves high communication rates with little energy.
The manager needs to increase the team's output. He has two choices: add people or keep the team the same size and do something different within the team.
If he increases the team size from 10 to 15, the communications load, communications distances, training, meeting, and documentation needs go up. Most of the money spent on this new group will get spent on communications overhead, without producing more output.
This group is likely to grow again, to 20 people (which will add a heavier communications burden but will at least show improvement in output).
The second strategy, which seems less obvious, is to lock the team size at 10 people (the maximum that can be coordinated through casual coordination) and improve the people on the team.
To improve the individuals on the team, the manager can do any or all of the following:
· Send them to courses to improve their skills.
· Seat them closer together to reduce communications cost.
· Improve their amicability and teamwork.
· Replace some of the people on the team with more talented (and more highly paid) people.
Repeating the strategy over time, the manager will keep finding better and better people who work better and better together.
Notice that in the second scenario, the communications load stays the same, while the team becomes more productive. The organization can afford to pay the people more for their increased contribution. It can, in fact, afford to double their salaries, considering that these 10 are replacing 20! This makes sense. If the pay is good, bureaucratic burden is low, and team members are proud of their output, they will enjoy the place and stay, which is exactly what the organization wants them to do.
Consequence 4. Different methodologies are needed for different projects.
Figure 4-21 shows one way to examine projects to select an appropriate methodology. The attraction of using grid in this figure is that it works from fairly objective indices:
· The number of people being coordinated
· The system criticality
· The project priorities
You can walk into a project work area, count the people being coordinated, and ask for the system criticality and project priorities.
In the figure, the lettering in each box indicates the project characteristics. A "C6" project is one that has six people and may cause loss of comfort; a "D20" project is one that has 20 people and may cause the loss of discretionary monies.
Figure 4-21. Characterizing projects by communication load, criticality, and priorities.
In using this grid, you should recognize several things:
• Communication load rises with the number of people. At certain points, it becomes incorrect to run the project in the same way: Six people can work in a room, 20 in close proximity, 40 on a floor, 100 in a building. The coordination mechanisms for the smaller-sized project no longer fit the larger-sized project.
• A project potentially causing companies to go out of business or causing loss of life need more careful checking than systems only causing loss of comfort or discretionary monies.
• Projects that are prioritized with legal liability concerns will need more care and tracking in the work.
Here is how I once used the grid: Changing Grid Cells Mid-Project The banking project I was asked to coordinate at the Central Bank of Norway started as a three-person effort, using the same three people who had done the previous system. I characterized it as a D6 type of project, and planned to more or less just trust the programmers to do a good job. After a month or so, though, it became clear that we were coordinating large amounts of money and that we should perhaps be more careful about the mistakes we let slip. I moved the project rating to E6, and we spent a week
or two fixing the design with respect to fault tolerance, recovery, and race conditions. After the architect and lead programmer went on paternity leave, we got two new programmers and two testers. At this point, we had seven people, two in Lillehammer, two on the first floor, and one each on the second, third, and fourth floors in Oslo (remember the cost of communicating across floors? ). It turned out that this system was actually being developed by two companies, and our team was coordinating its work with a group of 35 developers at a different location in Oslo who were using a different (waterfall) methodology. It was at this moment that the grid came in handy. I reclassified our project as an E20 project (some mix of the number of people and the geographic dispersion). Paying attention to the methodology principles, I did not add more paperwork to the project but stepped up personal communications, using phone calls and the video link, and increased personal study of the issues affecting the outcome of the project.
The grid characteristics can be used in reverse to help discuss the range of projects for which a particular methodology is applicable.
This is what I do with the Crystal methodology family in Chapter 6. I construct one methodology that might be suitable for projects in the D6 category (Crystal Clear), another that might be suitable for projects in the D20 range (Crystal Yellow), another for D40 category projects (Crystal Orange), and so on. Looking at methodologies in this way, you would say that Extreme Programming is suited for projects in the C4 to E14 categories.
Consequence 5. Lighter methodologies are better, until they run out of steam.
What we should be learning is that a small team with a light
-
Навигация [ Часть 11. Глава 19. ]
Закладки
The main question is, if you were funding this project, which…
The complete discussion about when and where to apply concurrent…
Crystal Clear is the most tolerant, low-ceremony small-team…
The third problem is absence of feedback from the downstream…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
It follows that on the Theory Building View, for the primary…
Accepting program modifications demanded by changing external…
The chart shows the state of the user stories being…
That it is people who design software is terribly obvious.…
The group of 17 quickly agreed on those value choices.…
While writing, reading, typing, or talking, we pick…
After much coaching for six months, his programs still…
On a new project, I would use Crystal Orange as a base…
The surprising thing about human success modes is how nebulous…
The industry is littered with projects whose sponsors did not…
Agility implies maneuverability, a characteristic that is…
Figure 4-1. Elements of a methodology. Roles. Who you…
In arguing for the Theory Building View, the basic issue…