My employer recently read the twelve steps to better code and wants me to write a protocol for how we should handle bugs and new features. We are a small company with just three programmers and we use OnTime from axosoft to administer our work. I am looking for a course in which best practices for bug tracking, work logging and project planning are taught. The only thing I have been able to find is axosoft's own six hour introductory course. Will that have enough depth? Please give recommendations!
closed as too broad by enderland, GlenH7, MichaelT, durron597, Dan Pichelman Jun 26 at 16:28
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.
If that's a little expensive Mike Gunderloy wrote a book.
* Disclaimer: I am that person.
First thing, what you're talking about isn't strictly Project Management, it's more a development or support process.
The industry standard for the support side of things is, in the UK at least, ITIL and there are courses on that which run into weeks but given your team size I suspect that's overkill.
If I were you I'd do some general reading around the subject and work out your own process internally. The first steps are likely to be:
1) A bug tracking tool. If your manager is willing to cough for FogBugz or Jira then great but if not then Bugzilla does the job for free at a basic level.
2) A basic process for ensuring that all bugs / change requests are logged in Bugzilla and a basic assessment carried out (impact, estimate to fix, is it a change or a defect) and so on.
3) A process for understanding how these then get prioritised and addressed.
These processes will have commonalities wherever you find them but will vary from company to company. I'd suggest that they key factors are:
1) That the logging and assessment process is rapid and happens as soon after the defect is raised as possible.
2) That the people involved in the prioritisation process have the authority to make those decisions. There's no point in developers working through this stuff and then management saying that they disagree.