Now that we saw what the main values and practices
of XP are, I want to go back for a minute
to discussion of requirements engineering in XP. In XP, user
requirements are expressed as scenarios or user stories, as we already
discussed. These are written by customers on cards, and what
the development team does is to take these cards, take these
users stories and break them down into implementation tasks. And
those implementation tasks are then used as a basis for scheduling
cost estimates. So given these estimates, and based on their priorities,
the customer will choose the stories that will be included in
the next release, in the next iteration. And at this point,
the corresponding cards will be taken by the developers and the,
the task will be performed, and the relative, and the corresponding
card will be developed. And just to give an idea of
the order of magnitude, if you consider a few months project,
there might be 50 to 100 user stories for a project of
that duration. So, now let me give you an example of what
the story card might look like, and I'm going to do it using
a story card for document downloading and you can really do all of
this, basically as seeing what the
scenario is, downloading and printing an article.
And it describes basically what happens when you do that, what is
the scenario. First, you select the article that you want from a displayed
list. You then have to tell the system how you will pay for
it. This can either be through a subscription, through a company account or
by credit card, and so on. So what developers do, they take
this story card, and they break it down in to development tasks.
So, here I'm showing you some examples of task cards for the
user story that we just saw. In particular I'm showing three task cards
and if we look at the third one, there is a name
for the task, which is implement payment collection. So this is the development
task that we have the perform and here, there's a description of
what that developed code should do. And notice that, you know, the task
card can even be more. explicit than this, more
specific than this, and talk about actual development tasks.