Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 5. Agile and Self-Adapting Becoming Self-Adapting
-
Часть 1
-
Bother to Reflect
The trick to fitting your conventions to your ever-changing needs is to bother to think about what you are doing.
Individually and as a team, do two things:
Bother to think about what you are doing.
Have the team spend one hour together every other week reflecting on its working habits.
If you do these two things, you can make your methodology effective, agile, and tailored to your situation. If you can't do that, well. .. you will stay where you are.
Although the magical ingredient is remarkably simple, it is quite difficult to pull off, given people's funky nature. People usually resist having the meeting. In some organizations, the distrust level is so high that people will not speak at such a get-together.
There is only one thing to do:
Do it once, post the results, and then see if you can do it again.
You may need to find someone within your organization who has the personal skills to make the meeting work. You may need to go outside your organization for the first few times, to get someone with the right personal skills, and whom everyone in the room can accept.
A Methodology-Growing Technique
Here is a small technique for on-the-fly methodology construction and tuning. I present it as what to do at five different times: Right now
At the start of the project In the middle of the first increment Between each increment In the middle of subsequent increments.
After that, I describe a sample one-hour reflection workshop.
Discover the strengths and weaknesses of your organization through short project interviews.
You can do this at the start of the project, but you can also do this right away, regardless of where you are in any project. The information will do you good in all cases, and you can start to build your own project interview collection.
Ideally, have several people interview several other people each, and start your collection with six or ten interview reports. It is useful but not critical to interview more than one person on one project. For example, you might talk to any two of the following: the project manager, the team lead, a user interface designer, a programmer. Their different perspectives on the same project will prove informative. Even more informative, however, will be the common responses across multiple projects.
The important thing to keep in mind is that whatever the interviewee says is relevant. During an interview, I don't speak my own opinions on any matter, but use my judgement to select a next question to ask.
In my interviews, I follow a particular ritual:
I ask to see one sample of each work product produced.
Looking at these, I detect how much bureaucracy was likely to be on the project, and see what questions I should ask about the work products.
I look for duplicated work, places where they might have been difficult to keep up to date.
I ask whether iterative development was in use, and if so, how the documents were updated in following iterations.
I look, in particular, for ways in which informal communication was used to patch over inconsistencies in the paperwork. Work Product Redundancy
On one project, the team lead showed me 23 work products.
I noticed a fair degree of overlap across them, so I asked if the later ones were generated by tools from the earlier ones. The team lead said, no, the people had to reenter them from scratch. So I followed up by asking how the people felt about this. He said, they really hated it, but he made them do it anyway.
After looking at the work samples, I ask for a short history of the project: date started, staff changes (growing and shrinking), team structure, the emotionally high and low points of the project life. I do this mostly to calibrate the size and type of the project, and to detect where there may be interesting other questions to ask.
Discovering Incremental Development
That is how I learned the fascinating story about the project I call "Ingrid" (Cockburn 1998).
During just the project inception phase, the team had hit most of the failure indicators I knew at the time. That their first four-month increment was a catastrophe came as no surprise to me. I even wondered why I had traveled so far just to hear about such an obvious failure. The surprise was in what they did after that.
After that first increment, they changed almost everything about the project. I had never seen that done before. Four months later, they rebuilt the project again - not as drastically, but enough to make a difference.
Every four months, they delivered running, tested software, and then sat down to examine what they were doing, how to get better (just as I am asking you to do).
The most amazing thing was that they didn't just talk about changing their way of working, they actually changed their way of working.
The value of this interview lay, not in our discussing deliverables, but in my hearing their phenomenal determination to succeed, their willingness to change, every four months, whatever was necessary to get the success they wanted.
After hearing the history of the project and listening for interesting threads of inquiry to pursue, I ask, "What were the key things you did wrong, that you wouldn't want to repeat on your next project? "
I write down whatever they say, and I fish around for related issues to investigate.
After hearing the things not to repeat, I ask, "What were the key things you did right, that you would certainly like to preserve in your next project? " I write down whatever they say. If the person says, "Well, the Thursday afternoon volleyball games were really good, " I write that down. Getting Seriously Drunk Together Once when I asked this question (in Scandinavia), a person said, "Getting seriously drunk together. "
We went out and practiced that night, and I did, indeed, see improved communication between the people the next day.
In response to this question, people have named everything from where they sit, to having food in the refrigerator, to social activities, communication channels, software tools, software architecture and domain modeling. Whatever you hear, write it down.
I revisit the issues in the conversation by asking,
"What are your priorities with respect to the things you liked on the project - which is most critical to keep, and which most negotiable? "
I write those down.
It is useful to ask at this point, "Was there anything that surprised you about the project? "
Finally, I ask whether there is anything else I should hear about, and see where that goes. At one company, we constructed a two-page interview template on which to write the results, so we could exchange them easily. That template contained the following sections:
-
Навигация [ Часть 1. Глава 25. ]
Закладки
On a new project, I would use Crystal Orange as a base…
Accepting program modifications demanded by changing…
That it is people who design software is terribly obvious.…
The complete discussion about when and where to apply concurrent…
Types of Methodologies Rechtin (1997) categorizes methodologies…
We see an example of needing these normalizing rituals…
In arguing for the Theory Building View, the basic issue is to…
While writing, reading, typing, or talking, we pick up traces…
The third problem is absence of feedback from the downstream…
The chart shows the state of the user stories being worked on…
Using the planning game in this way, the sponsors can properly…
Crystal Clear is the most tolerant, low-ceremony small-team methodology…
Agility implies maneuverability, a characteristic that…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
For us as designers, it was possible to express both propositional…
After much coaching for six months, his programs still…
1. Project name, job of person interviewed (the interviewee…