http://accurev.com/blog/2008/01/02/is-defect-tracking-dead-in-an-agile-world/ SCM and Agile Software Development Blog Wed, 04 Jan 2012 22:30:54 +0000 hourly 1 http://wordpress.org/?v=3.3 http://accurev.com/blog/2008/01/02/is-defect-tracking-dead-in-an-agile-world/comment-page-1/#comment-379 Scott Rosin Fri, 08 Feb 2008 21:27:12 +0000 http://blog.accurev.com/2008/01/02/is-defect-tracking-dead-in-an-agile-world/#comment-379 So, lets see... A bug gets reported, a programmer starts working on it. Then another bug is reported. The programmer writes it down on a piece of paper so he won't forget it. Then another one is reported. The programmer, says to himself "Ya know, instead of writing all these bugs down on a piece of paper, I'll put them in a database somewhere. And I'll write a web interface to it so I can get the bugs at home too." Thus a Defect Tracking System is born into an Agile World. So, lets see… A bug gets reported, a programmer starts working on it. Then another bug is reported. The programmer writes it down on a piece of paper so he won’t forget it. Then another one is reported. The programmer, says to himself “Ya know, instead of writing all these bugs down on a piece of paper, I’ll put them in a database somewhere. And I’ll write a web interface to it so I can get the bugs at home too.” Thus a Defect Tracking System is born into an Agile World.

]]> http://accurev.com/blog/2008/01/02/is-defect-tracking-dead-in-an-agile-world/comment-page-1/#comment-378 Cory von Wallenstein Mon, 07 Jan 2008 02:27:07 +0000 http://blog.accurev.com/2008/01/02/is-defect-tracking-dead-in-an-agile-world/#comment-378 I've heard of folks say the same... from my experience, it's often only when multiple reports in the issue tracking system come in that we have enough information to actually reproduce the problem and fix it. If we were to just dive right into the code on the first report of a problem, it would take multiple times the effort to fix the problem than if we were armed with a handful of scenarios that can be used to reproduce and isolate the problem. I’ve heard of folks say the same… from my experience, it’s often only when multiple reports in the issue tracking system come in that we have enough information to actually reproduce the problem and fix it. If we were to just dive right into the code on the first report of a problem, it would take multiple times the effort to fix the problem than if we were armed with a handful of scenarios that can be used to reproduce and isolate the problem.

]]>