Software Development Cross Solution - Index of - Free

A good process delivers good software
Let’s say your team loves its process. But suppose your team has yet to deliver a project
on time, or deliver software that’s working correctly. If that’s the case, you may have
a process problem. The ultimate measure of a process is how good the software is
that the process produces. So you and your team might need to change a few things
around.
Before you go changing things, you need to be careful—there are lots of wrong ways to
change things. Here are a few rules to think about if you’re considering changing part
(or even all) of your process:
1
2
3
Unless someone is on fire, don’t change things mid-iteration.
Changes are usually disruptive to a project, no matter how well-planned they are.
It’s up to you to minimize disruptions to other developers. Iterations give you
a very natural breaking point. And good iterations are short, so if you need to
change your process, wait until the end of your current iteration.
Develop metrics to determine if your changes are helping.
If you’re going to change something, you’d better have a good reason. And you
should also have a way to measure whether or not your change worked. This
means every change is examined at least twice: first, to decide to make the
change, and then again—at least an iteration later—to measure if the change
was a good idea or not. Try to avoid touchy-feely measures of success, too. Look
at things like test coverage, bug counts, velocity, standup meeting durations. If
you’re getting better numbers and better results, you’ve made a good change.
If not, wait for the next iteration, and be willing to change again.
Value the other members of your team.
The single biggest determinant of success or failure on a project are the people
on your team. No process can overcome bad people, but good people can
sometimes overcome a bad process. Respect your fellow team members—and
their opinions—when evaluating your process and any changes you might want
to make. This doesn’t necessarily mean you have to run everything by committee,
but it does mean you should try and build consensus whenever possible.
the real world
If you could change one thing about your current software process,
what would it be? Why? How would you measure whether or not your
change was effective?
Download at WoweBook.Com
you are here 4 419