Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 5. Agile and Self-Adapting Becoming Self-Adapting
-
Часть 3
-
Therefore, the purpose of this interview or meeting is to detect whether something is critically wrong and the first delivery will fail.
If you discover that the team's way of working isn't working, first consider reducing the scope of the first delivery.
Most teams overstate how much they can deliver in the first increment - to me, this is simply normal, and not a fault of the methodology. It is a result of overambitious management driving the schedule unrealistically, and overly optimistic developers, who overlook the learning to be done, the meetings to be held, the normal bugs they put into the code. It comes from underestimating the learning curve of new technology and new teammates. Overstating how much can be delivered in the first increment is actually quite normal.
Therefore, your first approach is to reduce scope.
You may, however, discover that reducing scope will not be sufficient. You may discover that the requirements are incomprehensible to the programmers, or that the architects won't get their glorious architecture specification done in time.
If this is the case, then you need to react quickly and find a new way of working, which, combined with drastically reduced functional scope, will allow you to meet that first delivery deadline.
You may introduce overlapped development, or put people physically closer together, cut down the ambition level for the initial architecture, or make greater use of informal communication channels. You may have to make emergency staff changes, or introduce emergency training, consulting or experienced contractors.
Your goal is to delivery something, some small, running, tested code in the first increment. This is a critical success factor on a project (Cockburn 1998). Once you deliver this first release, you will have time to pause and consider what is happening.
After each increment
Hold a team reflection workshop after each increment.
Bothering to reflect is a critical success factor in evolving a successful methodology, just as incremental development is a critical success factor in delivering software.
The length of this reflection workshop may vary from company to company or country to country. Americans like to be always busy, short of money and on the run. I see Americans allocating only two to four hours for this workshop. In other parts of the world, the workshop may be given more time.
I once participated in a two-day offsite version that combined reflection, team-building, and planning for the next increment. It took place in Europe, not surprisingly.
The dominant reason for delaying this workshop until after the first increment is that you can only properly evaluate the effects of each element in your methodology after you have delivered running, tested software to a user. Only then can you see what was overdone, and what was underdone.
There is a second reason for holding the workshop at the end of the increment: People are quite often exhausted after getting the software out the door. This meeting provides a chance to breathe and reflect. Done regularly, it becomes part of the project rhythm. After each increment, the staff benefit from a short shifting of mental and social gears.
Whether you take two hours or two days, the two questions you want to address are: "What did we learn? " "What can we do better? "
The responses may cross every boundary of the project, from management intervention, to timecards, group communication, seating, project reviews, standards, and team composition.
Very often, teams tighten standards after the first increment, get more training, streamline the work flow, increase testing, and reorganize the teaming structures.
The changes will be much smaller after the second and subsequent increments, since the team has already delivered several times.
In the Middle of the Subsequent Increments
After the first increment, the team has established one (barely) successful way of working. This is a methodology design to fall back on, if needed.
Having that as a fallback plan, you can be much more adventuresome in suggesting changes in the mid-increment meetings you hold in the second and later increments.
In those mid-increment meetings, and particularly after the second successful delivery, look to invent new and better ways of delivering.
See if you can do any of the following: Cut out entire sections of the methodology. Do more concurrent development Use informal communications more to bind the project information Introduce new and better testing frameworks Introduce new and better test-writing habits Get closer collaboration between the key groups in the project, between domain and usage experts, programmers, testers, training people, the customer care center, and the people doing field repair.
You might use interviews or a reflection workshop for these mid-increment adjustment. By this time, your team will have had quite a bit of practice with these meetings, and will have an idea of how to behave.
You may omit the mid-increment workshops if the project is using increments three weeks or shorter.
Why bother with mid-increment reviews, when the project is already delivering, and you already have post-increment reviews in place?
In the middle of the development cycle, those things that are not working properly are right in people's faces. The details of the problems will not be as clear four or six weeks later, at the post-increment meeting. Therefore, you can pick up more details in the middle of the increment, get feedback immediately about the idea, and try out a new idea the same day, instead in several weeks or months.
What if a new idea doesn't work out?
Sometimes the team tries a new idea on the second or third increment, and finds that the idea simply does not work well. Mid-Project Team Structure Changes
On one project, we went through three different team structures during the third increment.
A short way into the third increment, we decided that the team structure we had been using was weak. So we chose a new team structure to use on increment three.
It was catastrophically bad. We knew within two weeks that we had to change it immediately. Rather than revert to the original, awkward but successful team structure, we created a new suggestion and tried it out right away.
It turned out to be successful, and we kept it for the duration of the project. In inventing new ways of working in these later increments, you create the opportunity to significantly improve your methodology. This is an opportunity not to be missed.
The Post-Project Review
-
Закладки
The third problem is absence of feedback from the downstream…
After much coaching for six months, his programs still…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
For us as designers, it was possible to express both propositional…
It follows that on the Theory Building View, for the…
The group of 17 quickly agreed on those value choices.…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
Crystal Clear is the most tolerant, low-ceremony small-team…
Walk around your place of work. Notice · The convection currents…
The industry is littered with projects whose sponsors did not…
The chart shows the state of the user stories being worked…
In arguing for the Theory Building View, the basic issue is to…
The surprising thing about human success modes is how nebulous…
1. Project name, job of person interviewed (the interviewee…
Types of Methodologies Rechtin (1997) categorizes methodologies…
We see an example of needing these normalizing rituals…
That it is people who design software is terribly obvious.…