Software Development Cross Solution - Index of - Free

user stories capture what your software needs to do
Head First: Hello there, User Story.
User Story: Hi! Sorry it’s taken so long to get an
interview, I’m a bit busy at the moment...
Head First: I can imagine, what with you and your
friends capturing and updating the requirements for
the software at the beginning of each iteration, you
must have your hands pretty full.
User Story: Actually, I’m a lot busier than that. I
not only describe the requirements, but I’m also the
main technique for bridging the gap between what
a customer wants in his head and what he receives
in delivered software. I pretty much drive everything
from here on in.
Head First: But don’t you just record what the
customer wants?
User Story: Man, I really wish that were the case.
As it turns out, I’m pretty much at the heart of an
entire project. Every bit of software a team develops
has to implement a user story.
Head First: So that means you’re the benchmark
against which every piece of software that is
developed is tested?
User Story: That means if it’s not in a user story
somewhere, it ain’t in the software, period. As you
can imagine, that means I’m kept busy all the way
through the development cycle.
Head First: Okay, sure, but your job is essentially
done after the requirements are set, right?
User Story: I wish. If there’s anything I’ve learned,
requirements never stay the same in the real world. I
might change right up to the end of a project.
42 Chapter 2
User Story Exposed
This week’s interview:
The many faces of a User Story
Head First: So how do you handle all this pressure
and still keep it together?
User Story: Well, I focus on one single thing:
describing what the software needs to do from the
customer’s perspective. I don’t get distracted by the
rest of the noise buzzing around the project, I just
keep that one mantra in my head. Then everything
else tends to fall into place.
Head First: Sounds like a big job, still.
User Story: Ah, it’s not too bad. I’m not very
sophisticated, you know? Just three lines or so of
description and I’m done. The customers like
me because I’m simple and in their language,
and the developers like me because I’m just a
neat description of what their software has to do.
Everyone wins.
Head First: What about when things get a bit more
formal, like with use cases, main and alternate flows,
that sort of thing? You’re not really used then, are
you?
User Story: Heck, I can smarten myself up with
some more details to be a use case if that’s what you
need, and lots of people do dress me up that way
for their bosses. The important thing is that we all
describe what a piece of software needs to do, no
matter how we look. Use cases are more or less user
stories in a tuxedo.
Head First: Well, you heard it here first folks. Next
week we’ll be catching up with Test to see how he
guarantees that software does what a user story
requires. Until then, take care and remember, always
do only what your user story says, and not an ounce
more!
Download at WoweBook.Com