Introduction
Byte-Vision recognises that each development project is different. It therefore
does not believe that a sole methodology should be applied to all
projects. The key is to choose the parts of methodologies that are
relevant and applicable to the individual project. Saying that, there are some
principles, techniques and best practices that Byte-Vision applies to all
projects.
Hire The Best People
The number one factor effecting success is the people on the
team. Waiting for and hiring the best people is key.
Attack Risk Early
Keep a risk and issues list and manage it daily. Attack risk early. Eliminating
risks as early as possible is key to achieving the project deadline.
Manage Project Goals and Requirements
Make sure the project goals and requirements are clear, unambiguous, are
agreed with all stakeholders and are measurable
.
Test Early and Often
Eliminating slack in a project increases the chances of hitting the deadline.
One common culprit for stealing project time are software bugs. The later they
are found in the project the more they cost to fix. By testing early, and
testing throughly we can reduce the number of bugs that appear later in the
project lifecycle.
Automated The Testing
Write automated tests at all levels of the testing, particularly for Unit
testing where a large normally a large amount of manual testing is
normally done. Doing Unit testing manually incurs a lot of wasted time.
Manual Unit testing is time consuming, often undocumented, and not exhaustive,
resulting in poor quality software being released. Often repeat bugs are found
later in the cycle. Extreme Programming strongly advocates writing automated
test harnesses, and is also promotes the concept of
Test Driven Development (TDD). These methods work, and provide an
enormous leap of productivity on a project. Our course Quality
By Design
teaches students how this can be done.
Keep It Simple
Make sure you keep the design simple. Techies often like to get carried away
and build solutions that are 'flexible' to meet future requirements. Don't do
this. If it is not a requirement now, and the business have not stated it is
going to be a requirement in the future, then do not spend time (and their
money) building a fully flexible OO framework to meet all future needs. Build
the simplest thing to meet the requirements. If later they wish to add future
enhancements, then you simply refactor the code to do that.
Do not Overwork
As Extreme Programming suggests, do not work more than a 40 hour week, and
certainly do not have more than 2 consecutive weeks where overtime is done. It
has been shown time and time again, that working longer hours does not get more
done, it just gets the same thing done, but it takes longer - and it is of
lower quality.
|
