Overview of Agile Development
- What Is Different about an Agile Project?
- Introduction to Extreme Programming
- Isn't XP Just Hacking?
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
What Is Different about an Agile Project?
The thing that most surprises people when they first encounter an Agile project is the absence of traditional phases such as design-code-test. In a traditional project, these activities are performed separately over weeks or months, but in an Agile project, they are repeated many times each hour as part of test-driven development (TDD), as we will explain in Section 5. Another thing that surprises people is the Agile approach to analysis, which is done throughout the project by developing short stories rather than attempting to capture all requirements upfront and then putting them in large documents. In the next few pages, we'll explain why Agile teams approach software development in this way and perhaps encourage you to adopt these ideas on your own team.
No Separate Development Phases
The trouble with phased development processes such as Waterfall1 is that teams typically spend many months working exclusively on each phase so that their feedback loops are too long. For example, only when the analysis is complete do they proceed to design, and only when the design is done do they move into the coding phase. Although exhaustive checks at the end of each phase attempt to validate the work, it is only during the testing phase that anyone actually knows whether the program meets its objectives. Therefore, the only real feedback about your work comes many months, even years, after it was completed. Waterfall treats software development like a production line, requiring perfection at each stage of the process. If there is any mistake or if the requirement changes during the process, the resulting software will not be correct. This may work when you're maintaining or adapting a mature software product, but not when you're developing new products in the face of changing or unknown requirements. In these sorts of circumstances, you need to increase the amount of feedback by drastically reducing the time between code creation and its validation.
The emphasis on perfecting a design before it is put into code results from people's fear that cost of change will rise steeply as the project progresses. In a traditional Waterfall project, this fear is justified because the long feedback loop between design and test means that any mistakes will result in a significant amount of rework. However, as Scott Ambler3 points out, in an Agile project, the feedback loop between design and test is very short, so mistakes can be corrected much more cheaply.
An Agile team eschews the whole idea of phases so that it can get valuable feedback continuously from the very start of the project by producing the only thing that really counts: working code. Indeed, by the end of the first week, many teams will have demonstrated running software to the customer with some feature that has business value. The price paid for this rapid delivery of working code is that the team doesn't produce thick documents or detailed models of the system. Instead, it just concentrates on writing the tests and code necessary to implement its customer's stories, as summarized on 6-by-4-inch index cards.
Specifying Requirements with Customer Stories
A customer story (also known as a user story4) defines a feature of the software that has value to the business funding your project. It takes the form of some executable acceptance tests and a written memo that aims to summarize the various discussions about the feature that are held between a developer and someone representing the interests of the business—in other words, the customer. In this way, a story provides a specification for a particular requirement in terms of what Ron Jeffries5 calls card, conversation, and confirmation:
-
Card—The most important information about what a feature must do is captured as bullet points on an index card; see Figure 3-1. The intention is to remind people about the general issues rather than to write some legally binding contract.
Figure 3-1 Story from OSPACS project: front and reverse sides of 6-by-4-inch index card
- Conversation—The customer and developer must talk to each other if they are to really understand the requirement. The customer usually writes the card during this conversation.
- Confirmation—Executable acceptance tests are written as a formal specification of the feature and define it when it has been successfully implemented. These tests contain the actual details of the requirement; see Section 7.
)
The customer owns the stories (what the software must do) and the developer owns the tasks necessary to implement them (how the software will work). At the beginning of the project, the customer will come up with a few initial stories, the ones that seem at the time to give the most value. More stories are generated as the project progresses. Sometimes stories will also be discarded as a consequence of changes to the business environment or due to the customer acquiring a better understanding of the requirement. This flexibility is the source of the Agile team's strength; it is able to respond to change. There is no need to identify all the requirements upfront, and the feedback given by working code allows the product to evolve in a way that is driven by fitness for purpose within the confines of a simple architecture.
In the next part of the chapter, you will see how customer stories are used in an XP project. However, they can also be used in a similar way by other types of Agile approaches, such as Scrum.