The great thing about agile projects, is that you don't have to have ALL the requirements up-front, just enough to get started. Once you see the software working (minimally), you can change your mind about the requirements that are not yet implemented or have been implemented.
Consider a non-XP project, one that is not incrementally implementing features. If the customer decides in the middle of the project to change some requirements, the project may have to throw away lots of partially-completed code.
In the middle of an XP project, a requirement is either implemented or not -- the only time a requirement may be partially implemented is during the two-week iteration it was schedule for. Any requirements that haven't been implemented yet can be changed at zero cost. A change for requirements that have already been implemented is essentially the same as adding a new requirement -- it will cost something to be re-implement, and an equivalent amount of other non-implemented requirements should be dropped to keep the project on schedule.
Developers are the genie in the magic lamp - delivering any features that the customer wishes - so long as the customer is willing to pay the price (time and money). With this power comes rights and responsibilities.
In Extreme Programming, rights and responsibilities are divided between "business" and "developers". The "business" side has the business analysts, the QA testers, domain experts, users, stakeholders, and so on. All wrapped up in the single word "Customer". They are all involved in defining, specifying, and creating tests for the requirements. If you have business analysts in your team, it is the job of business analysts to help the stakeholder come up with requirements.
The "developer" side has the programmers, DBA, and so on. They translate requirements into code, databases, web servers, and so on. User interface experts may be either side, depending on whether they do programming as well as user interface design.
The business side is responsible for the requirements, the wishes they make of the genie, because they are responsible for running their business. To avoid this responsibility is to let the developers run your business. Unless the business is making tools for other software developers, it's unlikely that the developers have the expertise to satisfy your customers and make a profit.
The responsibilities of the two sides are clearly divided to reduce risks: if the business guys (who are not programmers) start telling the developers how to do programming, they risk technical failure. If the programmers tell the business guys what features should be implemented, there is a risk that project will not meet business needs.
When talking about what to ask the genie in the magic lamp, I've never seen anyone with a lack of ideas. They may not know HOW to get what they want, but they always know enough of what they want to start a conversation. Like the following:
In XP a requirement is expressed as one or more stories. I've heard that one UML Use Case, RUP style, can translate into 40 XP stories, of which 20 stories could be optional. An XP story is a promise for future conversation about the details of that requirement. You don't have to think them up all at once, you don't have to have all the details up-front, you don't have to write up a thick document. You do talk with the developers, other stakeholders, and business analysts if you have them.
Recommended reading:
Exploring Requirements: Quality Before Design by Gause and Weinberg
Planning Extreme Programming by Beck and Fowler
Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.
No comments:
Post a Comment