Agile Software Development
Автор: Alistair Cockburn /
APPENDIX A: The Agile Software Development Manifesto Supporting the Values
-
Часть 1
-
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 http://www.o-modern.ru 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.
-
Навигация [ Часть 1. Глава 31. ]