Handover.

In a typical and mature software company, Development Engineering and Sustaining/Support Engineering are kept separate. Separate teams, processes and procedures (there is usually plenty of overlap, especially around tools) and separate steps of the development process. While in most companies, there is a close relationship between these two, the minimal relationship is the handover agreement.

Without a set of handover criteria to govern the acceptance of new features and new applications into Support Engineering, there is bound to be an attitude in Development Engineering to just "toss it over the wall to Support", which, essentially, makes any issue that comes with the new development, someone else's problem.

Handover criteria are the Support Engineering team's safeguard against exactly this kind of attitude, but even with an amicable Development team, it's a necessary process. Any development team handing over, has to be aware that the Support person receiving handover can stop the handover for a long list of reasons, and this will mean more work for development.

Coming up with handover criteria is pretty straight-forward, and almost any list off the top of any support developer's head will do for starters. There are a few key concepts here, documentation, code, bugs and bug-count criteria.

As a suggestion, here is a simple list:

• Has there been a transfer of knowledge (TOK)?
• is there requirements documentation?
• is there design documentation?
• Does the code check out, compile and run without error?
• Does the code match the above documentation?
• Does the code meet your coding standard. 
• Essentially, you want to make sure that the code isn't a rabbit's warren of jumps/gotos, "TBD"'s and comments with swear words in it.
• does the new code match the bug-count criteria?
• Are there suitable unit tests for the new features?

Some key points:

TOK (Transfer of Knowledge):

There has to be some kind of overview and question/answer period for the developers receiving the handover. Depending on the size of the list of new features, this can be anywhere from 5 minutes of discussion to multi-day sessions. It's important that it contain an overview and some overview documentation that developers can read before going into the sessions. Preferably, this is done by a developer or tester who worked on the project/new features.

the bug-count criteria:

No software is bug free. However, if you've got a bug tracking system in place (and you should do this very early in the game), each bug will come with a severity, usually critical, serious, major, minor, enhancement (1, 2, 3, 4, 5). Only the first 4 are important for the handover criteria and you'll usually have an agree-upon number of bugs at each severity level for handover. 0-0-5-10 is a good number.

Ideally, it's 0-0-0-0, but this is hard to do, and the project team who is handing over may well argue about whether a bug existed before the project or not, which is fair enough (i.e. if the bug exists in project testing, but also exists in earlier software, then the bug itself has been handed to Support Engineering already some time in the past, and wasn't caused by the project team)

Coding standard:

I think that if you're going to run a team of developers, the group of them should have a coding standard. Similar to the handover criteria, you can start with anything at first and grow it over time. You can find them on line if you want a starting point. A coding standard makes your code output consistent from developer to developer. What kinds of names to give variables, how to format while/for loops, conventions for member functions and member variables inside objects/classes and so on. When following a coding standard, the developer has to think a little more about what they are doing before just spitting something out, which means that it will probably be more maintainable. Ideally, it addresses the code to a degree where it makes obfuscation and messy code harder to do. "No magic numbers" (i.e. int X = 5 for example), a few lines of comment per function/method describing the fuction's operation etc...

And there you have it - the importance and a short description of a handover agreement.