Crystal Clear Applied: The Seven Properties of Running an Agile Project (转载)

Posted 2020-08-06 麦克*堂

作者Alistair Cockburn， Crystal Clear的7个成功要素，写得挺好。

敏捷方法的关注点，大家可以参考，太激动所以转载了。

 

原文：http://www.informit.com/articles/article.aspx?p=345009

 

 

Property 1. Frequent Delivery

The single most important property of any project, large or small, agile or not, is that of delivering running, tested code to real users every few months.

The advantages are so numerous that it is astonishing that any team doesn‘t do it:

•The sponsors get critical feedback on the rate of progress of the team.

•Users get a chance to discover whether their original request was for what they actually need and to get their discoveries fed back into development.

•Developers keep their focus, breaking deadlocks of indecision.

•The team gets to debug their development and deployment processes and gets a morale boost through accomplishments.

All of these advantages come from one single property: frequent delivery. In my interviews, I have not seen any period longer than four months that still offers this safety. Two months is safer. Teams deploying to the Web may deliver weekly.

Have you delivered running, tested, and usable code at least twice to your user community in the last six months?

 

Property 2. Reflective Improvement

The discovery that took me completely by surprise was that a project can reverse its fortunes from catastrophic failure to success if the team will get together, list what both is and isn‘t working, discuss what might work better, and make those changes in the next iteration. In other words, reflect and improve. The team does not have to spend a great deal of time doing this work—an hour every few weeks or month will do. Just the fact of taking time out of the helter-skelter of daily development to think about what could work better is already effective.

Did you get together at least once within the last three months for a half hour, hour, or half day to compare notes, reflect, discuss your group‘s working habits, and discover what speeds you up, what slows you down, and what you might be able to improve?

 

Property 3. Osmotic Communication

Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work.

Several people have related their experience of it much as this person did:

We had four people doing pair programming. The boss walked in and asked my partner a question. I started answering it, but gave the wrong name of a module. Nancy, programming with Neil, corrected me, without Neil ever noticing that she had spoken or that a question had been asked.

 

Property 4. Personal Safety

Personal safety is being able to speak when something is bothering you, without fear of reprisal. It may involve telling the manager that the schedule is unrealistic, a colleague that her design needs improvement, or even letting a colleague know that she needs to take a shower more often. Personal safety is important, because with it the team can discover and repair its weaknesses. Without it, people won‘t speak up, and the weaknesses will continue to damage the team.

Personal safety is an early step toward trust. Trust, which involves giving someone else power over oneself, with accompanying risk of personal damage, is the extent to which one is comfortable with handing that person the power. Some people trust others by default, and wait to be hurt before withdrawing the trust. Others are disinclined to trust others, and wait until they see evidence that they won‘t be hurt before they give the trust. Presence of trust is positively correlated with team performance (Costa 2002).

 

Property 5. Focus

Focus is first knowing what to work on, and then having time and peace of mind to work on it. Knowing what to work on comes from communication about goal direction and priorities, typically from the executive sponsor. Time and peace of mind come from an environment where people are not taken away from their task to work on other, incompatible things.

Do all the people know what their top two priority items to work on are? Are they guaranteed at least two days in a row and two uninterrupted hours each day to work on them?

 

 

Property 6. Easy Access to Expert Users

Continued access to expert user(s) provides the team with

•A place to deploy and test the frequent deliveries

•Rapid feedback on the quality of their finished product

•Rapid feedback on their design decisions

•Up-to-date requirements

Researchers Keil and Carmel published results showing how critical it is to have direct links to expert users (Keil 1995).

Surveying managers who had worked both with and without easy access to real users, they write

. . . in 11 of the 14 paired cases, the more successful project involved a greater number of links than the less successful project. . . . This difference was found to be statistically significant in a paired t-test (p < 0.01).

Their research led them to a specific recommendation: "Reduce Reliance on Indirect Links." In other words, get real access to real users.

Does it take less than three days, on the average, from the time you come up with a question about system usage to when an expert user answers the question? Can you get the answer in a few hours?

All very nice, but how many users, and how much time?

Even one hour a week of access to a real and expert user is immensely valuable. The more hours each week that an expert user is available to a team, the more advantage they can take of that proximity. The first hour, however, is the most crucial.

 

Property 7. Technical Environment with Automated Tests, Configuration Management, and Frequent Integration

The elements I highlight in this property are such well-established core elements that it is embarrassing to have to mention them at all. Let us consider them one at a time and all together.

Automated Testing. Teams do deliver successfully using manual tests, so this can‘t be considered a critical success factor.

However, every programmer I‘ve interviewed who once moved to automated tests swore never to work without them again. I find this nothing short of astonishing.

Their reason has to do with improved quality of life. During the week, they revise sections of code knowing they can quickly check that they hadn‘t inadvertently broken something along the way. When they get code working on Friday, they go home knowing that they will be able on Monday to detect whether anyone had broken it over the weekend—they simply rerun the tests on Monday morning. The tests give them freedom of movement during the day and peace of mind at night.

Configuration Management. The configuration management system allows people to check in their work asynchronously, back changes out, wrap up a particular configuration for release, and roll back to that configuration later on when trouble arises. It lets the developers develop their code both separately and together. It is steadily cited by teams as their most critical noncompiler tool.

Frequent Integration. Many teams integrate the system multiple times a day. If they can‘t manage that, they do it daily, or, in the worst case, every other day. The more frequently they integrate, the more quickly they detect mistakes, the fewer additional errors that pile up, the fresher their thoughts, and the smaller the region of code that has to be searched for the miscommunication.

 

Evidence: Collaboration across Organizational Boundaries

There is a side-effect from attending to personal safety, amicability within the team, and easy access to expert users: it becomes natural to include other stakeholders into the project, as well.

 

 

Reflection on the Properties

I don‘t believe that any prescribed procedures exists that can assure that projects land in the safety zone every time.

Nor, with the exception of incremental development, do I show up on a project with any particular set of rules in hand, even though I have my favorites. This is why Crystal Clear is built around critical properties instead of specification of procedures.

A Crystal team works to set the seven properties into place, using whatever group conventions, techniques, and standards fit their situation. The conventions may vary by project and by month. New techniques get invented with each new technology (and usually go out of style again a few years later). These seven properties, on the other hand, have been applied on good projects for decades.

My intention with Crystal is to not invade the natural workings of individuals on the project where possible, and to allow the most possible variation across different teams, while still getting those diverse projects into the safety zone. To allow variation, I must remove constraints. Removing constraints means finding broader mechanisms that provide a safety net. The ones I choose to rely on are these:

•People are by nature good at looking around and communicating.

•They take initiative when provided with information.

•They do better in an environment that is safe with respect to personal and emotional safety and particularly freedom from personal attacks.

•They do their best work if they can satisfy their need for contribution, accomplishment, and pride-in-work.

The Crystal Clear safety net is built on those things.

Personal safety gives people the personal courage to share whatever they discover.

Osmotic communication gives them the greatest chance to discover important information from each other and does so with very low communication cost. Reflective improvement gives them a channel to apply feedback to their working process.

Easy access to expert users gives them the opportunity to quickly discover relevant information from the user(s).

Frequent delivery creates feedback to the system‘s requirements and the development process.

The technical development environment including automated tests, configuration management, and frequent integration allows people to safely make changes to the system, synchronize the multiple minds that are in motion at the same time, and get feedback on the system‘s intermediate stages quickly. Focus allows the team to spend their energy well on the most important things.