Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 5. Agile and Self-Adapting Agile
-
Часть 2
-
One of those is the graphical user interface. Experienced developers know this, and allocate special effort to minimize the portions of the system not amenable to automated regression tests.
When the system itself does not have automated regression tests, experienced programmers find ways to create automated tests for their own portion of the system.
Experienced developers
In an ideal situation, the sweet spot, the team consists of only experienced developers. Teams like this that I know report much different, and better, results compared with the average, mixed team.
Since good, experienced developers may be two to ten times as effective as their colleagues, it would be possible to shrink the number of developers drastically if the team consists entirely of experienced developers.
On project Winifred, we estimated before and after the project that six good Smalltalk programmers could develop the system in the needed timeframe. Not being able to get six good Smalltalk programmers at that time, we used 24 programmers. The four experienced ones built most of the hard parts of the system, and spent much of their time helping the inexperienced ones.
If you can't land in this sweet spot, consider bringing in a half-time or full-time trainer or mentor to increase the abilities of the inexperienced people
The Trouble with Virtual Teams
"Virtual" is a euphemism meaning "not sitting together. " With the current popularity of this phrase, project sponsors excuse themselves for imposing enormous communication barriers on their teams.
We have seen the damage caused to a project by having people sit apart. The speed of development is related to the time and energy cost per idea transfer, with large increases in transfer cost as the distance between people increases, and large lost opportunity costs when some key question does not get asked. Splitting up the team is just asking for added project costs.
I categorize geographically distributed teams into three sorts, some of them more damaging than others. My terms for them are multi-site, offshore, and distributed development.
Multi-site Development
Multi-site is when a larger team works in relatively few locations, each location contains a complete development group, and the groups are developing fairly decoupled subsystems.
Multi-site development has been performed successfully for decades.
The key in multi-site development is to have full and competent teams in each location, and to make sure that the leaders in each location meet often enough to share their vision and understanding. Although many things can go wrong in multi-site development, it has been demonstrated to work many times, and there are fairly standard rules about getting it to work, unlike the other two virtual team models.
Offshore development
Offshore development is when "designers" in one location send specifications and tests to "programmers" in another location, usually in another country.
Since the offshore location lacks architects, designers and testers, this is quite different than multi-site development.
Here's how offshore development looks, using the words of cooperative games and convection currents.
The designers at the one site have to communicate their ideas to people having a different vocabulary, sitting several time zones away, over a thin communications channel. The programmers need a thousand questions answered. When they find mistakes in the design, they have to do three expensive things: first, wait until the next phone or video meeting; second, convey their observations; and third, convince the designers of the possible mistake in the design. The cost in erg-seconds per meme is staggering, the delays enormous. Testing Off-shore Coding
One designer told me that his team had to specify the program to the level of writing the code itself, and then had to write tests to check that the programmers had correctly implemented every line they had written. The designers did all the paperwork they considered unpleasant, without the reward of being able to do the programming. In the time they spent specifying and testing, they could have written the code themselves, and they would have been able to discover their design mistakes much faster.
I have not been able to find methodologically successful offsite development projects. They fail the third test: The people I have interviewed have vowed not to do it again.
Fortunately, some offshore software houses are converting their projects into something more like multi-site development, with architects, designers, programmers and testers at the programming location. While the communications line is still long and thin, they can at least gain some of the feedback and communication advantages of multi-site development.
Distributed development
Distributed development is when a team is spread across relatively many locations with relatively few, often only one or two, people per location.
Distributed development is becoming more commonplace, but it is not becoming more effective. The cost of transferring ideas is great, and the lost opportunity costs of undetected questions greater. Distributed development model works when it mimics multi-site development, with meaningful subteams of one or two people each person's assignment is clear and contained.
However, the following is more common: Criss-Crossed Distribution
A company was developing four related products in four locations, each product having multiple subsystems.
A sweet spot would be to have all systems of one product developed at the same location, or one subsystem for all products. With either of these, the people would be physically proximate to the people they needed to exchange information with. Instead, the dozens of people involved were arranged so that people working in the same city worked on different subsystems of different products. They were surrounded by people whose work had little to do with theirs, and separated from those with whom the needed to communicate with!
Occasionally, people tell of developing software effectively with someone at a different location. What this tells me is that is something new to discover: What permits these people to communicate so well over such a thin communications line? Is it just a lucky alignment of their personalities or thinking styles? Have they constructed a small multi-site model? Or are they drawing on something that we haven't learned to name yet?
-
Закладки
Agility implies maneuverability, a characteristic that…
It follows that on the Theory Building View, for the…
The chart shows the state of the user stories being worked…
We see an example of needing these normalizing rituals in the…
For us as designers, it was possible to express both propositional…
The surprising thing about human success modes is how…
Accepting program modifications demanded by changing external…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
1. Project name, job of person interviewed (the interviewee…
Figure 4-1. Elements of a methodology. Roles. Who you…
In arguing for the Theory Building View, the basic issue is…
The complete discussion about when and where to apply concurrent…
Games are not just for children, although children…
Walk around your place of work. Notice · The convection currents…
Crystal Clear is the most tolerant, low-ceremony small-team…
The industry is littered with projects whose sponsors did…
Using the planning game in this way, the sponsors can…
On a new project, I would use Crystal Orange as a base…