|
Dissecting business failures: Allowing scope creep from clients |
||||||||
One of the most common forms of business failure that I have the misfortune to witness on a regular basis is the allowance of clients to instigate scope creep within projects.
I have never understood how some industries accept scope creep as part of everyday business; let me explain what I mean.
|
Ever had this conversation with a customer? |
||||||||
I saw this in my inbox this morning and just had to share it, it bears a striking resemblance to some of the conversations I've had with external and internal departments.
Made me chuckle so I thought I'd share it.
|
Three simple team-working rules |
||||||||
There are three relatively simple team working rules that I stick to within the office, and if you are in a team with me I expect you to adhere to them too.
These aren't just rules I just get team members to use, I do them myself as well, and I believe they make a massive difference to a team's ability to work well together as a cohesive unit.
|
Testing methodologies - Regression testing |
||||||||
One of the more overlooked forms of testing (you do test don't you?) is regression testing. I'm a big fan of scripted testing using both scripted tests to actually run against your code base (think cfUnit or Junit) and scripted testing as in a basic word doc of testing instructions.
This word doc can be as simple as 'click button N' - what displayed on screen? You can literally just list the actions, expected consequences and actual conqequences.
Regression testing is the practice of going back after a release and testing the functionality that was already present. IE did you break anything by releasing your new functionality. Often the business and IT focus is on the shiny new development, not the integrity of the existing application.
Developers in particular are guilty of zoning in on the specifc area that they are directly involved with. This can sometimes lead to other areas suffering, especially if you have an OO application layer. In just how many places is each individual object referenced? A change to it may work in one area, but have devastating consequences in another.
I've seen cases of this where its been months later before an error has reared its head, and without an accurate change log it can be difficult to track the root cause down. Needless error tracking and bug fixes take developers away from actually developing, and essentially cost the business money due to bad practice.
I mentioned scripted testing above as it has had unforseen beneficial consequences. If you have done anything like this in the past, your regression testing will be very easy. You will have a handy library of repeatable scripted tests, so it is very easy for you to measure the previous results against any new tests you might perform. Thus making it instantly obvious wether your functionality is still behaving as it was before the release.
