Software Development Cross Solution - Index of - Free

Q: I noticed that the bug fixing tasks on page 406 both had
estimates. Where did those estimates come from?
A: Good catch! Bug fixing tasks are just like any other type of task;
they need an estimate, and there are a number of ways that you can
come up with that.
You can derive the estimate, dividing the total amount of days you’ve
calculated evenly by the number of bugs to fix, or you can play
planning poker with your team. Whichever approach you take, your
total planned tasks for bug fixes must never be greater than the
number of days calculated from your spike test.
Q: When fixing bugs, how much time should I spend on
cleaning up other problems I notice, or just generally cleaning
up the code?
A: This is a tough call. It would be great to fix every bug or
problem you see, but then you’ll likely finish all your tasks late or,
worse, end up refactoring your code indefinitely.
The best guideline is to get the code into a working, pretty decent
state, within the time allotted for your bug fixing task, and then move
on to the next task. First priority is to get the code working; second
is to make it as easily readable and understandable as possible so
that bugs are not accidentally introduced in the future. If there are
problems you found but couldn’t get to, file them as new bugs and
prioritize them into a later iteration.
Q: What did that five-day spike test period do to our iteration
length?
A: Right now, we’re getting ready for the next iteration so we’re
between iterations. If there’s a master schedule, the five days needs
to be accounted for there, but in terms of iteration time, it’s basically
off the clock. After you get your board sorted out and everything
approved by the customer, though, you should kick off a normal
iteration. If you’re forced to do a spike test in the middle of an
iteration, that’s a case where it’s probably OK to slip the iteration end
date by a week, assuming nearly everyone is participating.
If only a small number of developers are participating in the spike test
and everyone else is continuing the iteration, you probably want to
drop that five days’ worth of other work from the iteration, but still end
on time.
Remember, this is five days per
person, not five days total.
Download at WoweBook.Com
bugs
Q: You said try and get code into a “pretty decent” state.
What does that really mean?
A: This is really a judgment call, and in fact this is where you
get into the aesthetics of code, which is a whole book on its own.
However there are some rules of thumb that can help you decide
when your code is good enough and you can move on.
First, the code must work according to your tests. Those tests
must exercise your code thoroughly, and you should feel very
confident that the code works as it should.
Secondly, your code should be readable. Do you have cryptic
variable names? Do the lines of code read like Sanskrit? Are you
using too much complicated syntax just because you can? These
are all huge warning signs that your code needs to be improved in
readability.
And finally, you should be proud of your code. When your code is
correct and easily readable by another developer, then you’ve really
done your job. It doesn’t have to be perfect, but “pretty decent” starts
with your code doing what it should and ends with it being readable.
Q: This sounds like the same approach as the perfect-versusgood-enough
design stuff we talked about earlier, right?
A: Yes, it’s based on exactly the same principle. Just as you can
spend hours improving a design, trying to reach perfection, you can
waste exactly the same time in your coding. Don’t fall into the trap
of perfection. If you achieve it, then that’s great, but what you’re
aiming for is code that does what it should, and that can be read and
understood by others. Do that, and you’re coding like a pro.
Beautiful code is nice,
but tested and readable
code is delivered on time.
you are here 4 409