Software Development Cross Solution - Index of - Free

oken code happens
�
�
�
�
Q: Things seem to be in a really
bad shape right now. What good is our
process if we still end up in crappy
situations like this?
A: The problem here is that when you
reused Mercury Meals’ software, you
and your team brought in code that was
developed under a different process than
yours, with an entirely different result—
broken code.
Not everyone developing software is going to
test first, use version control and continuous
integration, and track bugs. Sometimes, it’s
up to you to take software you didn’t develop
and deal with it.
380 Chapter 10
When you’re gearing up for the next iteration,
always check back with the customer to make
sure that the work you are planning is the work
that they want done.
You and your team’s velocity is recalculated at
the end of every iteration.
Let your customer reprioritize your user stories
for a new iteration, based on the working days
you’ve got available for that iteration.
Whether you’re writing new code or reusing
someone else’s it’s all still just software and
your process remains the same.
Q: So how common is this situation?
Couldn’t I just always use my own code?
A: Most software developed today is
created on really tight timelines. You have
to be productive and deliver great software
quicker and quicker, and often with success,
so the tempo rises as your customers
demand even more.
One of the best ways to save time in those
situations is to reuse code—often code that
your team didn’t write. So the better you get
at development, the more reuse will be part
of your normal routine.
And when you start to reuse code, there’s
always that crucial time when you encounter
code that simply does not work, and it’s
easier to fix that code than to start over. But
hold on...Chapter 11 is all about just how to
do that, without abandoning your process.
Download at WoweBook.Com
�
�
�
�
Every piece of code in your software, whether it
be your own code or a third party’s like Mercury
Meals, should be represented by at least one user
story.
Never assume anything about code you are
reusing.
A great interface to a library of code is no
guarantee that the code works. Trust nothing
until you’ve seen it work for yourself.
Code is written once but read (by others)
many times. Treat your code as you would any
other piece of work that you present to other
people. It should be readable, reliable, and easy
to understand.
Dealing with
code that doesn’t
work is part
of software
development!
In Chapter 11,
you’ll see how
your process can
handle the heat.