Книга: Agile Software Development

The Agile Alliance

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more."

Seventeen advocates of lightweight development processes gathered in Utah in early 2001 to discuss what they might have in common, or if they would just agree to disagree. I was one of them.

We agreed that the word "lightweight" too much of a reaction against something, and not enough of a belief in something. Agreeing on the importance of being able to respond to changing requirements within the project timeframe, we chose the word agile. We agreed on the above four values and on a dozen principles to support those values. We agreed that we were not interested in agreeing beyond that. We nicknamed the group the Agile Alliance. This appendix discusses that meeting, the values and the principles.

The Agile Alliance

The meeting happened at Snowbird, Utah, in February, 2001.

The 17 people were Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, and Dave "Pragmatic" Thomas. (If Dave A. Thomas from Object Technology International had been able to make it that week, we might have had two Dave Thomasses as signatories!)

Each person there saw their own version of the meeting. What follows in this appendix is mine (but I did pass this text in front of the others).

The reason we met was to see whether there was anything in common between the various light methodologies: Adaptive Software Development, XP, Scrum, Crystal, Feature Driven Development, Dynamic System Development Method (DSDM), and "pragmatic programming."

Kent Beck, Ward Cunningham, Ron Jeffries, James Grenning and Robert Martin brought their views of XP, along with their considerable other experiences and their own personal wishes.

Martin Fowler brought long experience in both XP and methodology evaluation in general.

Jim Highsmith represented Adaptive Software Development and ideas around the emergent properties of complex, adaptive systems.

I was there, protecting my interests in methodology-per-project and just-in-time methodology construction.

Jeff Sutherland, Ken Schwaber and Michael Beedle represented Scrum (Schwaber 2001).

Jon Kern of TogetherSoft represented Feature-Driven Development, the method described in Java Modeling in Color with UML (Coad 1999).

Arie van Bennekum, from the Netherlands, represented DSDM (Stapleton 1997).

Andy Hunt and Dave "Pragmatic" Thomas, authors of The Pragmatic Programmer, protected the interests of experienced programmers who have no affiliation to any one method.

Brian Marick represented the software testing perspective.

Stephen J. Mellor was there to protect his interests in model-driven development. He was perhaps the most surprised to find himself able to agree with most of what was said, and signed both the manifesto and the principles.

There were others who had been invited, and would certainly have contributed and signed, but those were the people who were there, argued, crafted and signed the agreements.

We hoped against hope that we would actually agree on something.

None of us was interested in merging the practices to create a "Unified Light Methodology (ULM)." Given the individualism in the room, it was actually surprising we agreed on anything.

We agreed on four things:

· We agreed at the first level, on the need to respond to change. We agreed that agile reflected our intent, and permits discussion of heavier-agile methodologies for larger and life-critical projects.

· We agreed at the second level, on four core values, as described in the manifesto.

· We agreed at the third level (just barely), on twelve more detailed statements consistent with those four values.

· It was clear we would not agree on the fourth level, detailed project tactics. We did agree that this was healthy for the industry, and that we should continue to innovate and compete in the world of ideas, to discover a larger set of agile software practices.

With those agreements and the adoption of the term agile, the 17 people created the Agile Alliance.

The Manifesto

Let's look at the wording of the manifesto more closely.

"We are uncovering better ways of developing software by doing it and helping others do it."

We (the people in the group) are software development practitioners, not merely onlookers making rules for others. We feel that we have "uncovered" practices more than invented them, and want to be clear that we will continue to work by helping as well as by telling.

"Through this work we have come to value..."

The ideas were not arrived at in a vacuum, but rather are an outcome of our direct experience and reflection on that experience.

Before listing the four choices, I'll skip ahead and look at the closing sentence:

"That is, while there is value in the items on the right, we value the items on the left more."

We are not interested in tearing down the house of software development. We recognize that tools, processes, documentation, contracts and plans have value. What we wish to express is that when push comes to shove (which it usually does), something has to give. We feel that people who hang onto the right hand choices in the list will not do as well as people who hang onto the left-hand choices.

We also want to recognize that some people disagree with one or all of our choices. One person said, on seeing our list: "I can agree with three of the four." We agreed that that sort of disagreement can lead to constructive conversations.

There is no "opposite" to agile methodology, just as there is no opposite to "Bengal tiger". There are alternatives to agile methodologies, phrased according to their own value systems: repeatable, deliberate, predictable, even capricious methodologies.

Understand, of course that all of these denote the successful version of the practices. Perhaps

better terms are: would-be-agile, would-be-predictable, and would-be-repeatable development.

It is important to me, personally, to leave room for disagreement on these matters. Our industry still disagrees about what is critical to successful software development. The best approach for the time being is simply to say what one stands for. Evidently, this point is important to the other signatories, too.

With that in mind, let's look at the four choices:

"Individuals and interactions over processes and tools."

The first value is attending to the people on the team as opposed to roles in the process chart. Although a process description is needed to get a group of people started, people are not plug-replaceable, as we have seen.

The second choice being highlighted there is attending to the interactions between the individuals. New solutions and flaws in old solutions come to life in discussions between people. The quality of the interactions matter.

Actually, improved community benefits process-centric development just as much as it does chaotic documented.

What this first value expresses is that we would rather use an undocumented process with good interactions than a documented process with hostile interactions.

"Working software over comprehensive documentation."

The working system is the only thing that tells you what the team has built. Running code is ruthlessly honest.

Documents showing the requirements, analysis, design, screen flows, object interaction sequences charts and the like are handy as hints. The team uses them as aids in reflecting on their own experience, to guess what the future will look like.

The documents serve as markers in the game, used to build an image of the unreliable future.

On the other hand, the composite act of gathering requirements, designing, coding, and debugging the software, reveals information about the development team, the development process, and the nature of the problem to be solved. Those things together with the runing final result provide the only reliable measure of the speed of the team, the shortcomings of the group, and a glimpse into what the team really should be building.

Documents can be very useful, as we have seen, but they should be used along with the words "just enough" and "barely sufficient."

"Customer collaboration over contract negotiation."

The third value describes the relationship between the people who want the software built and those building the software. The distinction is that in properly formed agile development, there is no "us" and "them," there is only "us."

Collaboration deals with community, amicability, joint decision making, rapidity of communication, and connects to the interactions of individuals. Attention to customer collaboration indicates an amicable relationship (which does not preclude conflict - see Chapter 3) across specialties and organizational boundaries. Saying, "there is only us" refers to the fact that both are needed to produce good software.

Although contracts are useful at times, collaboration strengthens development both when there is a contract in place and when there is none. Good collaboration can save a contract situation when it is in jeopardy. Good collaboration can sometimes make a contract unnecessary. Either way, collaboration is the winning element.

"Responding to change over following a plan."

The final value is about adjusting to fast-breaking project changes.

Building a plan is useful, and each of the agile methodologies contains specific planning

activities. They also contain mechanisms for dealing with changing priorities.

Scrum, DSDM and Adaptive Software Development call for timeboxed development with reprioritization after (not within) each timebox (XP allows reprioritization within the timebox). The timeboxed periods are in the 2 - 4 week range. The timeboxing guarantees that the team has the time and peace of mind to develop working software. The relatively short development phases, what Scrum calls "sprints," allow the project sponsors to change priorities to match their needs.

Building a plan is useful. Referring to the plan is useful until it gets too far from the current situation. Hanging onto an outdated plan is not useful.

Reflecting on the Manifesto

The need for different ways of working in different situations is not in the manifesto, but Jim Highsmith and I like to keep the point always in mind.

Being agile is different for a 100-person project than for a 10-person project. The agile 100-person project will use a heavier methodology than the agile 10-person project. This matches the methodology design principles in the Chapter 4.

Of course, also in keeping with the methodology design principles, it might be possible to drop 90 people from the 100-person project, keep the 10 best people, and then run an agile 10-person project that delivers the same system in the same time frame.

The point is that we agree that methodologies do not come in ones or twos, but in dozens, each tuned to the situation and project at hand, and each agile. This thought is not captured in the Manifesto.

Some of the people in the room recommend agile methodologies primarily for high-flux situations. My experience is that rude surprises pop up on even supposedly stable projects. I am still waiting to see an occasion when the agile value set

Supporting the Values

The group of 17 quickly agreed on those value choices. Developing the next level of statements proved more than we could settle on in the time left in the meeting. Those in this section are the current working set.

These statements should evolve as we learn people's perceptions of our words, and as we come up with more accurate words ourselves. I shall be surprised if this particular version isn't out of date shortly after the book is published. For the latest version, check www.AgileAlliance.org.

We expect not to agree on the next level of recommendations, which relate to project tactis: how much architecture to develop at what times, what tools to use or avoid, and so on. We each still have our own experiences, fears, wishes and philosophies, which color our practices and recommendations. We shall differ at some specificity of recommendation.

These are the sentences we agreed on, and my commentary on each.

1. Our highest priority is to satisfy the customer through early and frequent delivery of valuable software.

We are interested in delivering software that is fit for purpose. Oddly, some of the companies I visit don't seem to value actually delivering software. Agile development is focused on delivering.

Delivering early allows for quick wins and early feedback about the requirements, the team, the process, as we have seen throughout this book.

Delivering frequently allows for continued wins for the team, rapid feedback, and mid-project changes in project direction and priorities.

The duration used for deliveries needs to be negotiated on a project-by-project basis, because delivering updates on a daily or weekly basis can cause more disturbance to the users than it is is not appropriate the Values worth. When users can't absorb changes to the system as often as every three months, then the project team needs to arrange some other way to get that feedback and to make sure their process works all the way through test and integration.

Statement emphasizes delivering those items that have greatest value to the customers. With consumer mood changes, intensive competition, and stock market swings, it is nearly impossible to guarantee a revenue stream for a project that takes a year or longer to deliver.

This statement indicates that value will be delivered early, so that in case the sponsors lose funding, they will not be left with a pile of promissory notes, but with working software that delivers something of value to the buyers.

2. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This half to the "early and frequent" delivery specifies the lengths of the work cycles. I have encountered the occasional project that can run incremental development with four-month cycles, but most use one- to three-month cycles. Using shorter cycles is rare, because the users usually can't take in more frequent changes than that.

On project Winifred (Cockburn 1998), a fixed-price contract involving 50 people over 18 months, we fixed our cycles for deliveries to users at three months. Knowing that this was really too long to wait for feedback, we made sure that some expert users came and had two chances to review running code inside each cycle. These two user viewings were scheduled flexibly, usually around the 6-week and 8-week marks.

If the users can accept changes every month, and the development team can match the ongoing requests for changes, then the shorter feedback cycle is better.

3. Working software is the primary measure of progress.

This is the third reference to working software. This principle puts it firmly: rely on the honesty that comes with running code rather than on promissory notes in the form of plans and documents. You are welcome to use other measures of progress as well, but working code is the one to bank on.

Agile methodologies place a premium on getting something up and running early, and evolving it over time. Not all projects are equally amenable to tiny evolutionary steps. Deciding how to break up the giant architecture on a large project into smaller pieces that can be built and tested incrementally, does take some work. It can be done, however, and is worth the effort.

Stephen Mellor is careful to point out that in model-driven development, two pieces of working code must be demonstrated. One is the executable model, which is evaluated for fitness to the user needs. The other piece of working code to be demonstrated is the mapping algorithm that generates the final code. This one is more easily overlooked. A number of projects created a gorgeous executable model, and then couldn't get the code-generation algorithm to work properly in time.

4. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Agile processes can take on late-changing requirements exactly because of early and frequent delivery of running software, use of iterative and timeboxing techniques, continual attention to architecture, and willingness to update the design.

If your company can deliver quickly and respond to late-breaking information, and your competitor's company can't, then your company can out-maneuver your competitors on the software front. This often translates to a major difference in the marketplace.

All of the agile methodologies have some mechanism to incorporate late-breaking changes in requirements, as already discussed. The details differ by methodology.

5. Business people and developers work together daily throughout the project.

The industry is littered with projects whose sponsors did not take the time to make sure they got what they needed. Frakes and Fox reported a study showing a strong correlation between links to users and project success or failure (Frakes 1995).

The best links are through on-site business expertise and daily discussions, which is what the statement calls for. The word "daily" refers to the sweet spot, where discussions are ongoing and on-demand. Daily discussions are not practical on most projects, which means that the project is not sitting at the sweet spot. The statement indicates that the longer the time to get information to and from the developers, the more damage to the project.

6. Build projects around motivated individuals.

Give them the environment and support they need, and trust them to get the job done.

We would rather see motivated, skilled people communicating well, and no process at all, than a well-defined process and unmotivated individuals. Dee Hock's story about the early VISA system gives an extreme example of this.

Individuals make projects work. Their motivation relates to the pride-in-work, amicability and community on the project.

I first encountered the above statement in a project interview with Dave A. Thomas, then Presdent of the very successful company, Object Technology International. He said, "We hire good people, give them the tools and training to get their work done, and get out of their way." I keep finding evidence supporting his recommendation,.

7. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This falls directly out of Chapters 3 and 4 in this book. I won't repeat the discussion and caveats here. Review those chapters if you are just dipping into the book here.

8. The best architectures, requirements, and designs emerge from self-organizing teams.

We had some discussion around the choice of words in this principle. How self-organizing do we intend: completely self-organizing, or merely allowing good ideas to come from anyone on the project? Do we mean emerge mysteriously, emerge in small steps over time, or emerge as a logical consequence of the human-centric rules the team uses?

I prefer the middle of the three choices. Jim prefers the latter of the three. None of us intend the first of the three, which comes from a misunderstanding of the word emergent as "lucky." Our common point is recognizing that the details of system design surprise even the most experienced designers.

We insist that the architecture be allowed to adjust over time, just as the requirements and process are. An architecture locked down too hard, too early, will not be able to adjust to the inevitable surprises that surface during implementation and with changing requirements. An architecture that grows in steps can follow the changing knowledge of the team and the changing wishes of the user community.

9. Continuous attention to technical excellence and good design enhances agility.

A tidy, well-encapsulated design is easier to change, and that means greater agility for the project. Therefore, to remain agile, the designer shave to produce good designs to begin with - and -also have to review and improve their design regularly, to deal with the better understanding of their design that comes with time and clean up from when they cut corners to meet a short-term goal. Managing Technical Debt

Ward Cunningham sometimes compares cleaning up the design with paying off debts. Going further, he discusses managing the technical debt on the project.

Making hasty additions to the system corresponds to borrowing against the future, taking on debt. Cleaning up the design corresponds to paying off the debt.

Sometimes, he points out, it is appropriate to take on deb and make hasty changes, in order to take advantage of an opportunity. Just as debt accumulates interest and grows over time, though, so does the cost to the project of not cleaning up those hasty design changes.

Cut corners in the design, he suggests, when you are willing to take on the debt, and clean up the design to pay off the debt before the interest grows too high.

Given the deep experience present in the room, I found it interesting to see this attention to design quality at the same time as the attention to short time scales, light documentation, and people.

The conflicting forces are resolved by designing as well as the knowledge at hand permits, but designing incrementally.

10. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

There are two sides to this statement. One relates to social responsibility side, the other to project effectiveness. Not everyone at the meeting was interested in signing onto the social responsibility platform, but we all agreed on the effectiveness issue.

People tire as they put in long hours.Their rate of progress slows, not just during their overtime hours, but also during their regular hours. They introduce more errors into their work. Diminishing returns set in with extra hours. This is part of the non-linearity of the human component.

An alert and engaged staff is more agile than a tired, slogging staff, even leaving aside all of the social responsibility issues. Long hours are a sympton that something has gone wrong with the project layout.

11. Simplicity--the art of maximizing the amount of work not done--is essential.

Simplicity is essential. That much is easy to agree on. The notion of simplicity is so subjective, though, that it is difficult to say anything useful about it. We were therefore pleased to find we could all sign up for this statement.

In the design of development processes, simplicity has to do with accomplishing while not doing, maximizing the work not done while producing good software. Jon Kern reminds us of Pascal's remark: ?This letter is longer than I wish, for I had not the time to make it shorter.? That comment reveals the difficulty of making things simple. A cumbersome model is easy to produce. Producing a simple design that can handle change effectively is harder.

In terms of methodology and people, Jim Highsmith likes to cite Dee Hock:

?Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior.?

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

It is fitting to end where we began. How light is right for any one project? Barely sufficient, and probably lighter than you expect.

How do we do this on our project? Bother to reflect on what you are doing. If your team will spend one hour together every other week reflecting on their working habits, you can evolve your methodology to be agile, effective and fitting. If you can't do that, well ... you will stay where you are.

Reflecting on the Support Statements

Getting 17 people to agree on any set of words is difficult. The more detailed the advice, the more we different backgrounds and philosophies come into play.

We hope that the four leading value choices and the twelve supporting statements will give you enough information to build your own agile work habits.

Оглавление книги