Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 2. Individuals Drawing on Success Modes
-
Часть 1
-
The surprising thing about human success modes is how nebulous and improbable they seem, based as they are on these kinds of characteristics:
· Being able to learn
· Being malleable
· Being good at looking around
· Taking pride in work
· Liking to be a good citizen
· Taking initiative
Are these the mechanisms that consistently pull projects through to safety?
They produce running, tested code every few weeks. The on-site customers evaluate the new parts of the system and give feedback on the usefulness of the system while the work is still fresh in everyone's minds.
They review their own working habits every few weeks, reflecting on how well they worked in buycheapdvd.ru the previous iteration.
Actually, every development team should review its working habits every few weeks, whether or not it uses pair programming or XP. The project "post-mortem" that some teams hold at the end of a project happens too late to help the project. Holding regular reflection sessions during the project is much more effective. The team has a chance to incorporate feedback along the way and to work in the time needed to benefit the project.
Periodic mid-project reflection sessions are the single practice common across all of the Crystal methodologies described in Chapter 7 [insert automatic cross-ref]. Every two –to six weeks, depending on the project's cycle duration, the team gathers to discuss what went well, what didn't, and what to try out during the next period.
With regular feedback reflection periods in place, the team can construct methods to gain feedback about other aspects of the project, such as Highsmith's product review sessions (Highsmith 2000).
Success Modes
In my interview notes, I find that one answer showed up repeatedly when I asked what caused a project to succeed in the end:
"A few good people stepped in at key moments and did whatever was needed to get the job done. "
For the first eight years of my interviews, I assumed that the speakers meant that they had messed up, and only personal heroics had saved the project. Slowly, though, as I kept hearing it, I realized that I could not explain why people did that or the overall role of this sort of action on the project. It was by investigating this sentence that I started to see the powerful effects of the human success factors just mentioned, effects that are relevant no matter whether a tight or loose process is being used.
Let's look at these success factors.
People Learn
Novices don't stay novices forever. People who are novices on one project become experienced by the end of the same project and often are senior designers a few projects later.
This ability to learn along the way helps many projects. Within a single project's time frame, the people learn new technology, new problem domain, new process, and how to work with new colleagues.
Often, a team struggles through the first two increments, becoming stronger and stronger until successful results at the end are almost a given. In long-running projects and in situations where there is a steady flow of small initiatives, senior people leave and junior people—who have become senior— take their places.
We take advantage of people's ability to learn within a project by splitting it into subprojects (incremental development again). This provides not only the small wins and feedback discussed earlier but also the opportunity for people to learn how the process works. "Oh! " they might say, "That's why we had to write the input validation fields in the data structures table. " They use their ability to look around to detect what needs improvement, and then they invent new ways of working to try out in the next increment.
People are remarkably able to act differently given new motives and new information. This is the mechanism in the two stories at the start of the “Overcoming Failure Modes section”: the small-goods shop and the C3 project.
In the story of the small-goods shop, we don't have enough information to know why the girls changed their work habits.
In the story of the Chrysler Comprehensive Compensation (C3) project, Kent Beck needed to shift the team's cultural values away from creating clever code to creating simple solutions, a notoriously difficult task.
One way he accomplished this was through peer-pressure rituals. In one such ritual, the group formed a procession, placed a propeller beanie on the head of someone with an overly clever solution, and then spun the propeller on the beanie, commenting on the "cleverness" of the solution. The negative attention from peers caused people to move away from clever solutions; appreciation for simple designs drew them to simple solutions.
True to people being different, not everyone on the team was "malleable" enough to adopt XP. One person did not enjoy the new working style or the requirements for conformity and close cooperation, and eventually left the project.
Good at Looking Around
That people are good at looking around is reflected in the ways they organize the paper in their lives: books, reports, addresses, and so on. A common, human way of sorting is to use the "shell sort" algorithm: We build piles ordered according to the sorting criterion (for example, alphabetically, or by date) but leave things unsorted within any pile. We then break each pile into smaller piles and repeat until each pile is small enough to sort by eye and by hand. Except. .. we often don't do that final sort. When the pile is small enough to sort by eye and by hand, we often just leave it like that and find any item of interest just by scanning the contents of the pile.
The standard address book is a perfect example of this. An address book is sorted into sections by starting letter, but the entries within a section are not sorted. They are just written in any order, and we scan the section to find the entry of interest.
-
Навигация [ Часть 1. Глава 10. ]