Geek asks and answers

Track internal development issues

We have a standard problem tracking system for tracking defects / improvements from an end-user perspective and project management. However, we also need to track internal team errors, which may include refactoring certain parts of the code or changing something in the application with which the end user has no interaction.

Is it better to track these weaknesses and improvements in the same tracking system? My reservation is that project managers who look at user defects will be confused by these internal requests, and this will cause unnecessary concern. Are we installing another defect tracking system for internal team use only?

+3
source share
1 answer

Smaller systems are (almost) always better if you don’t like the extra work of the administrator to remove the coding time.

I like the way the Pivotal Tracker separates them, to avoid the confusion you're talking about, and to pay particular attention to the client. User errors are “errors”, internal elements that do not have visible benefits for the client are “jobs” and are not displayed in many views, because they do not provide client value (there is no reference to the user's history This).

Therefore, I would think that most problematic trackers have ways to break down the types of problems, and I would single out "paying off technical debt" separately from errors.

, , . , , . " Refactor" " " - .

, , ( , " " ) .

+4

More articles:


All Articles