Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 5. Agile and Self-Adapting Agile
-
Часть 1
-
Agile implies being effective and manoeverable. An agile process is both light and sufficient. The lightness is a means of staying manoeverable. The sufficiency is a matter of staying in the game.
The question for using agile methodologies is not to ask, "Can an agile methodology be used in this situation" but "How can we remain agile in this situation? "
A 40-person team won't be as agile as a six-person colocated team. However, each can maximize its use of the agile methodology principles, and run as light and fast as they can creatively make their circumstances allow. The 40-person team will use a heavier-agile methodology, the six-person team will use a lighter-agile one. Each team will focus on communications, community, frequent wins and feedback.
If they are paying attention, they will reflect periodically about the fit of their methodology to their ecology, and keep finding where the point "barely sufficient" has moved itself to.
Sweet Spots
Part of getting to agile is identifying the sweet spots of effective software development and moving the project as close as possible to those sweet spots.
A team that can arrange to land on any of those sweet spots, gets to take advantage of some extra efficient mechanism. To the extent the team can't arrange to land in a sweet spot, it must use less efficient mechanisms. At that point, the team should think creatively to see how to get to the sweet spot, and to deal with not being there.
Here are a selection of five sweet spots:
Two to eight people in one room
Information moves the fastest in this sweet spot. The people ask each other questions without overly raising their voices. They are aware of when the other people are available to answer questions. They overhear relevant conversations without pausing their work. They keep the design ideas and project plan on the board, in ready sight.
People repeatedly tell me said that while the environment can get noisy, they have never been on a more effective project than when their small team sat in the same room.
With leaving this sweet spot, the cost of moving information goes up very fast. Every doorway, corner and elevator multiplies that cost.
The story, "e-Presence and e-Awareness" (Chapter 3), tells of one team not being able to land in this sweet spot. They used web cams on their workstations to get some of the presence and awareness of sitting in the same room. They used chat boxes to get answers to they very many small questions that constantly arise. They were creative in mimicking the sweet spot in an otherwise unsweet situation.
On-site usage experts
Having a usage expert available at all times means that the feedback time from imagined to evaluated solution is as short as possible, often just minutes to a few hours.
Such rapid feedback means that the development team grows a deeper understanding of the needs and habits of the users, and start making fewer mistakes coming up with new ideas. They try more ideas, making for a better final product. With a good sense of collaboration, the programmers will test the usage experts' ideas and offer counter-proposals. This will sharpen the customers' own ideas for the how the new system should look.
The cost of missing this sweet spot is a lowered probability of making a really useable product, and a much higher cost for running all the experiments.
There are many alternative, if less effective, mechanisms you can use when you can't land on this sweet spot. They have been well documented over the years: weekly interview sessions with the users; ethnographic studies of the user community; surveys; friendly alpha-test groups. There are certainly others.
Missing this sweet spot does not excuse you from getting good user feedback. It just means you have to work harder for it.
One-Month increments
There is no substitute for rapid feedback, both on the product and on the development process itself. Incremental development is perfect for providing feedback points. Short increments help the both the requirements and the process itself gets repaired quickly. The question is, how long should the delivery increments be?
The correct answer varies, but project teams I have interviewed vote for 1-3 months, with a possible reduction to two weeks and a possible extension to four months.
It seems that people are able to focus their efforts for about three months, but not much longer. People tell me that with a longer increment period, they tend to get distracted and lose intensity and drive. In addition, increments provide a team with chances to repair their process. The longer the increment, the longer between such repair points.
If this were the only consideration, then the ideal increment period might be one week. However, there is a cost to deploying the product at the end of an increment.
I place the sweet spot at around one month, but have seen successful use of two or three months.
If the team cannot deliver to an end user every few months, for some reason, it should prepare a fully built increment in that period, and get it ready for delivery, pretending, if necessary, that the sponsor will suddenly demand its delivery. The point of working this way is to exercise every part of the development process, and to improve all parts of the process every few months.
Fully automated regression tests
Fully automated regression tests (unit or functional tests, or both) bring two advantages: The developers can revise the code and retest it at the push of a button. People who have such tests report that they freely replace and improve awkward modules, knowing that the tests will help keep them from introducing subtle bugs. People report that they relax better on the weekends when they have automated regression tests. They run the tests every Monday morning, and discover if someone has changed their system out from under them.
In other words, automated regression tests improve both the system design quality and the programmers' quality of life.
There are some parts of the system (and some systems) that are difficult to create automated tests for.
-
Навигация [ Часть 1. Глава 24. ]
Закладки
Crystal Clear is the most tolerant, low-ceremony small-team…
For us as designers, it was possible to express both propositional…
Walk around your place of work. Notice · The convection currents…
It follows that on the Theory Building View, for the…
1. Project name, job of person interviewed (the interviewee…
The main question is, if you were funding this project, which…
Games are not just for children, although children also…
Using the planning game in this way, the sponsors can…
On a new project, I would use Crystal Orange as a base…
In arguing for the Theory Building View, the basic issue is to…
The complete discussion about when and where to apply concurrent…
The surprising thing about human success modes is how nebulous…
The group of 17 quickly agreed on those value choices.…
The industry is littered with projects whose sponsors did not…
The third problem is absence of feedback from the downstream…
We see an example of needing these normalizing rituals in…
Types of Methodologies Rechtin (1997) categorizes methodologies…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…