Agile Software Development
| Since the first edition of this book was published, the agile approach to developing systems has become popular, and rightly so. Agility refers to product development where the team's development process is based on the principles of the Agile Manifesto. We reproduce it here and, throughout this book, will show its relevance to the requirements activity.
Sadly, like many advances, some followers and acolytes have overhyped this manifesto and misapplied its sensible principles. The important point to keep in mind is that there is no conflict between discovering the right requirements and engaging in agile development. No matter which method you use to build your product, you have to build the right product. The only effective way of doing so is if you correctly understand what the product has to do, how it will be used, by whom it will be used, how it fits into the larger picture of the organization, and so on. These things are the requirements. Unfortunately, some proponents of agile development believe that agility and requirements are not compatible. This view is both wrong and dangerous. Let's consider the Agile Manifesto and the values it proposes.
In Chapter 3, Project Blastoff, we show you how to determine the stakeholders for your project. Stakeholders are people who have an interest in the product, and they are your sources for requirements. In Chapter 5, Trawling for Requirements, we discuss techniques for determining the requirements. All of these techniques involve some kind of personal interaction with the appropriate stakeholders. Requirements come from humans, so the better you are at interacting with humans, the better you will be at gathering requirements. There is no tool or process that, as far as we can see, will ever replace the effectiveness of the requirements analyst and the stakeholder sitting down eyeball-to-eyeball and talking about what is needed. The skill of the requirements analyst here is to introduce tools, models, and other measures that can help the stakeholder discover and explain his needs.
All too often, the requirements process is seen as a long-winded process that eventually delivers an unreadable (and often unread) specification that the client is asked to sign off. We urge you not to see it this way. In Chapter 2, The Requirements Process, we discuss iterative development of products and consider how the requirements for just the next release are gathered and implemented. It is only when there is a need for a complete specification such as when you are outsourcing your technical design and programming that we would advocate building a complete specification before beginning construction. Otherwise, the delivered version of the correct software is the best way of satisfying the client's needs.
We speak often in this book about the need for collaboration with the stakeholders. A collaborative approach is by far the most effective way of determining the needs for the product and ensuring the stakeholders understand what they are asking for. Sometimes, however, there is a need for a contractoutsourcing or complying with departmental responsibilities are examples that spring to mindand you cannot avoid creating a contractual requirements specification. The courts are jammed with lawsuits between software suppliers and clients where the source of disagreement is not whether the software works, but whether it does what is needed. Astonishingly, in many of these lawsuits, the requirements specification is sketchy and vague, and in some cases it is nonexistent.
Do not ask the client to sign off on the requirements; instead, ask the client to sign on to them and make them a collaborative effort. You are not writing the requirements to serve as a contract with your client. Rather, you are writing them to ensure that both of you share the same, and demonstrably correct, understanding of what is needed. Do not ask the client to sign off on the requirements; instead, ask the client to sign on to them and make them a collaborative effort.
The first thing you have to ask about change is why it happens. Our experience is that most change comes from software being delivered and the users discovering that it fails to do what they need. This happens even when the users acknowledge that what is delivered is what they asked for. Good requirements practices encourage change as early as possible in the cycle, when the changes are cheapest to make. By using interactive models such as scenarios and prototypes, the requirements analyst encourages the stakeholder to make changes before building the software.
There is every reason to make your requirements activity as agile as possible. We say "as possible" because in some situations the degree of agility is compromised by factors beyond your control. For example, you may be developing software using contracted outsourced development. In this case, there is a clear need for a complete requirements specification. To help you relate to the agile way of thinking, we have devised agility ratings to represent your situation. We will use these ratings as we proceed through the chapters. The intention is to help you decide how you would undertake each of the activities in such a way as to be as agile as you can, and get the correct result. Rabbitthe most agile of projects. You are a rabbit when you have the luxury of frequent iterations, with each iteration delivering a small increment to the working functionality. Rabbit projects will not spend a great deal of time writing the requirementsthat is not the same thing as not learning the requirementsand probably will use scenarios and prototypes for delivering the requirements to the developers. In a rabbit project the sources of domain knowledge are colocated with the developers. Rabbit projects, like their namesake, have relatively short lives. Horsefast, strong, and dependable. Horse projects are probably the most common corporate projects. There is a need for some documentation, because requirements likely must be handed from one department to another. Horse projects usually involve more than a few stakeholders (often in a variety of locations), thus necessitating the need for some consistently written documentation. The organization in this case has a culture that expects a degree of formality, or order, in its development process. If you cannot categorize your own project, think of it as a horse. Horse projects have medium longevity. Elephantsolid, strong, long life, and a long memory. The elephant project has a need for a complete requirements specification. This can happen when you are undertaking some contractual arrangement such as outsourcing. It also happens in certain industries, such as pharmaceuticals or aircraft manufacture, where regulators demand that not only full specifications be produced, but also the process used to produce them be documented and auditable. Elephant projects typically have a long duration, and they involve many stakeholders and stakeholder representatives in diverse locations. There is also a large number of developers, necessitating more formal ways of communicating. The authors of this book are well aware that we are not the first to use animals to categorize agility. Barry Boehm and Richard Turner refer to elephants and monkeys in their excellent book, Balancing Agility and Discipline: A Guide for the Perplexed. Todd Little uses a menagerie that includes skunks in his article for IEEE Software. Each author, including the current ones, categorizes agility by looking at different aspects of product development and using an animal to represent each category. We do not claim the idea of using animals as an original one, but we persist with it, as we believe it to be a simple indicator of your aspirations for agility. A confession: We chose the rabbit as the most agile symbol because of its misleading association with agility. Several years ago Steve Martin had a play on Broadway called Picasso at the Lapin Agile, the latter being a bar in Paris where Picasso meets an imaginary Albert Einstein. Anybody who has eaten lapin at a restaurant knows it is rabbit; French speakers also know that agile means "active," not "agile." Despite the discrepancies, the idea of an agile rabbit was too attractive to resist. Projects vary according to their sociology and organizational framework. If you are guided by the agile principles, you will avoid doing things just because they are prescribed and you will look for opportunities to deliver useful functionality more quickly. Throughout this book, we will point out the relevancy of parts of each chapter to rabbits, horses, and elephants. In other words, we will guide you to select the parts of the requirements process that return the best value for the effort expended. The intention is to give you the opportunity to be as agile as possible.
If you are guided by the agile principles, you will avoid doing things just because they are prescribed and you will look for opportunities to deliver useful functionality more quickly. Over the years we have discovered that good requirements practices simply make agile development more effective. Our goal in this book is to provide you with a structure for discovering and managing requirements so that you can make choices about how much requirements work you need to do before you can deliver your product. |
EAN: 2147483647
Pages: 371