Sunday, November 3, 2013

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.

1 comment:

  1. WHY QUOTE THE BIBLE?

    Is it not ironic that those who claim that the Bible is filled with errors, contradictions, and is, in general an unreliable book, are the first ones to quote the Bible to support their doctrinal positions concerning God and His commandments?


    Is it credible to quote from the Bible to support a doctrinal position, if your primary source of authority is a creed book, a catechism, a so-called book of new revelation, or a statement of faith? If the Bible is not your authority for faith and practice; how rational would it be to quote from it to support your position?


    If the Bible and the Bible alone is not your authority and your authority alone, for faith and practice, then, to make a practice of quoting Scripture to prove a doctrinal point would not only be unreasonable and irrational, it would in fact, be dishonest.


    Either the Bible is your authority or it is not. You cannot have it both ways.


    SATAN QUOTED THE BIBLE


    The devil quoted Scripture when he temped Jesus in the wilderness. The problem was God's word was not his authority.(Matthew 4:1-11)


    Even though Satan knew God's word he was not obedient to it and lied about God's word, starting in the Garden of Eden. (Genesis 3:1-13)


    To quote from the Bible to support or refute a position of faith or practice and not believe that the Bible is trustworthy and is the sole authority from God, is not only disingenuous, but irrational, and does not offer credibility to any position of faith expressed.


    WHY QUOTE THE BIBLE IF YOU DO NOT BELIEVE IT IS GOD'S INERRANT WORD AND IT IS THE SUPREME AUTHORITY AND THE SUPREME AUTHORITY ALONE?


    YOU ARE INVITED TO FOLLOW MY BLOG. http://steve-finnell.blogspot.com

    ReplyDelete