Software Development Cross Solution - Index of - Free

Q: Isn’t less formality better? Can’t I
convince my customer that index cards
are all I need?
A: It’s not about more formal versus
less formal. It’s about what works to get
the right software written. The board with
stories and tasks works well for lots of teams
because it’s simple, visual, and effective
at communicating what needs to be done.
It’s not effective at lining up external teams
that might be relying on your software or for
when marketing should schedule the major
release events and start shipping leaflets.
Don’t add formality for the sake of being
formal, but there are times when you will
need more than index cards.
Q: If we have to use a project planning
tool, should I keep the board too?
A: Yes. There’ll be some duplication of
effort, but the board works so well with small
teams that it’s very hard to get anything
more effective. The tangible tasks hanging
on the board that team members physically
move around just keeps the team in sync
better than a screenshot or printout does.
Q: My customer wants design
documentation and just doesn’t get that
my design just “evolves”...
A: Be careful with this one. Refactoring
and evolutionary design work well with
experienced teams who know their product,
but it’s very easy to get something wrong.
On top of that, not giving your customer
the design documentation they want is
asking them to take a huge leap of faith
in what you’re doing—and that leap might
not be justified yet. Most successful teams
do at least some up-front design each
iteration. You need to make sure the design
documentation they’re asking for is providing
value, but design material is usually pretty
useful for both you and the customer. Just
make sure you account for the work in your
estimates. Don’t let TDD or “evolutionary
design” be an excuse for “random code that I
typed in late last night.”
Q: My customer wants a requirements
document, but user stories are working
really well for my team. Now what?
A: If your customer has a history with
more formal requirements documents, it
may be very difficult to make the shift to
user stories. In general, you don’t want more
than one requirement document directing
how things should be implemented. It’s very
difficult to keep a document and user stories
in sync, and someone always gets stuck
resolving the conflicts.
Download at WoweBook.Com
the real world
Instead, try starting with a user story and
at the end of the iteration break up the user
story into “the user shall” statements that
can fit into a formal requirements document.
Or, if the customer wants nothing to do with
user stories, you can try going the other
direction: pull several “The user shall” type
statements into a user story and work from
the stories. But watch out—those “the user
shall” type requirements often don’t give you
a lot of context about the application as a
whole, and what it’s doing.
Neither approach is ideal, but one may be
a compromise that’s workable. You need to
be absolutely diligent about changes in both
directions, though.
Choose a process
that works for
YOUR team and
YOUR project...
...and then tailor
the artifacts
it produces to
match what
YOUR customer
wants and needs.
you are here 4 425