When using any issue tracking software, it's important to know which issues should take priority. Issues that are high priority should, obviously, be dealt with first. Issues of lower priority can wait.
Usually, this means assigning a number to a particular issue, perhaps with a descriptor of some sort. Some go from one to ten, some go from one to seven. They might go from "Must fix" to "Don't Fix". This is, however, not always intuitive. What does a six mean? What does a one mean? Are people just going to mark everything as a 10? Does the description of the issue say "Not a huge priority", but the rank says "Must fix"?
If you couldn't tell, I've had some bad experiences with priority systems.
Showing posts with label management. Show all posts
Showing posts with label management. Show all posts
Friday, February 8, 2013
Friday, January 11, 2013
Not How, But What
A happy developer is a productive developer. That fact should be obvious to everybody who interacts with a developer of any sort.
Developer happiness is affected by a lot of things. The work environment, the projects they are given, their managers, the flexibility of their schedules, and the quality of their tools. This last one is very important. If a developer doesn't like the tools they are using, it's a safe bet they won't be happy, and thus won't be as productive as they could be.
Developer happiness is affected by a lot of things. The work environment, the projects they are given, their managers, the flexibility of their schedules, and the quality of their tools. This last one is very important. If a developer doesn't like the tools they are using, it's a safe bet they won't be happy, and thus won't be as productive as they could be.