Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Design Principles
-
Часть 10
-
I described this use of the principle as the Gold Rush strategy in Surviving Object-Oriented Projects (Cockburn 1998). That book also describes the related use of the Holistic Diversity strategy and examines project Winifred more extensively.
Here is a second story, with a different outcome.
eBucks. com and Principle 7
The company eBucks. com had 15 developers and a dozen business specialists. They also had a backlog of six dozen work initiatives. The programmers were being distracted away from their work several times each day and consequently were making little headway against their backlog.
Gold Rush was exactly the wrong strategy to use in this situation. The programmers had no spare capacity. In fact, programming was the bottleneck activity.
We first took several steps to reduce the distractions hitting the programmers. That was still not enough, given their backlog.
We decided, therefore, that the business specialists would write use cases, business rules, and data descriptions to hand to the programmers.
Note that this strategy appears at first glance to go against a primary idea of this book: maximizing face-to-face communication. However, in this situation, these programmers could not keep information in their heads. They needed the information to reach them in a "sticky" form, so they could refer to it after the conversations.
After the programmers work through the backlog, the bottleneck activity will move, and the company may find it appropriate to move to a more concurrent, conversation-based approach.
Just what they do will depend on where the next bottleneck shows up.
Here is a third story. Udall and Principle 7
Project Udall had become stuck, with dozens of developers and a large, unworkable design. Four of the senior developers decided to ignore all the other developers and simply restarted their work. They added people to their private workgroup slowly, inviting only the best people to join them.
They reasoned (correctly, as it turns out) that the two bottleneck activities were getting political alignment on design decisions and transferring information from the senior designers' heads to the others.
They decided that it would be more effective for them to let the others do anything other than program on the system than to spend key design resources convincing and training the others.
This was a most surprising and effective application of the principle of expendable efficiency.
When I interviewed one of the team leads, I asked, "What about all those other people? What did they do? "
The team lead answered, "We let them do whatever they wanted to. Some did nothing, some did small projects to improve their technical skills. It didn't matter, because they wouldn't help the project more by doing anything else. "
The restarted project did succeed. In fact, it became a heralded success at that company.
Consequences of the Principles
The above principles work together to help you choose an appropriate size for the team when given the problem, and to choose an appropriate size for the methodology when given the team. Look at some of the consequences of combining the principles:
Consequence 1. Adding people to a project is costly.
People who are supposed to know this sometimes seem unaware of it, so it is worth reviewing.
Imagine forty or fifty people working together. You create teams and add meetings, managers, and secretaries to orchestrate their work.
Although the managers and secretaries protect the programming productivity of the individual developers, their salaries add cost to the project. Also, adding these people adds communication needs, which call for additional methodology elements and overall lowered productivity for the group (Figure 4-19).
Figure 4-19. Reduced effectiveness with increasing communications needs (methodology size).
Consequence 2. Team size increases in large jumps.
The effects of adding people and adding methodology load combine, so that adding "a few" people is not as effective an approach as it might seem. Indeed, my experience hints that to double a group's output, one may need to almost square the number of people on the project! Here is a story to illustrate. Mythical Man-Month Revisited
Fred Brooks, in the Mythical Man-Month, writes that one may have a project that cannot be delivered in time by even the ten best people in the world. As a consequence, he writes, one may have to use 200 or 300 people.
He explains that there are two effects driving the need for extra people. One is that more people are needed to handle the communications load on the project. The other is that it will not be possible to hire 200 people of the same caliber as the proposed 10. The communications load is compounded by a decrease in talent.
Here is a second, more recent story, with a similar outcome.
Six to 24 Programmers
At the start of one fixed-priced project, we estimated that we could deliver the project with six good Smalltalk programmers. That wasn't an option, though. At that time, we couldn't get our hands on six good Smalltalk programmers. To make matters worse, we were given ten novices to train and only two expert programmers to both train them and create code.
During our estimation process, we concluded we would need a staff of 24 programmers of mixed abilities.
-
Навигация [ Часть 10. Глава 19. ]
Закладки
The group of 17 quickly agreed on those value choices.…
On a new project, I would use Crystal Orange as a base…
For us as designers, it was possible to express both propositional…
In arguing for the Theory Building View, the basic issue…
The chart shows the state of the user stories being worked…
Agility implies maneuverability, a characteristic that…
Crystal Clear is the most tolerant, low-ceremony small-team…
Games are not just for children, although children also…
The industry is littered with projects whose sponsors did not…
After much coaching for six months, his programs still looked…
13. (FIRST TECHNIQUE). .. your sword now having bounced…
The surprising thing about human success modes is how nebulous…
While writing, reading, typing, or talking, we pick up…
The third problem is absence of feedback from the downstream…
That it is people who design software is terribly obvious. ..…
The complete discussion about when and where to apply concurrent…