Is it useful to track the history of tasks and bugs in projects developed by one person?_问答_开发者

I have trac set up for my private and job projects and I have an ability to define tasks or describe bugs there. As most of the time I work at those projects alone, I usually choose to write the TODO lists on sheets of paper. When a task is done, I just strike it out from the sheet. When the full page of tasks is finished, the sheet is thrown away.

I know that I could link svn commits and track tickets by mentioning the ticket number in the commit log, but for me it seems more practical just to write full explanations in the commit messages. What do I miss by not keeping the track of tasks and bugs?

Just for statistics, in the last 4 years of extensive usage of svn, I had to revert back my own projects about 4 times and to look a开发者_Python百科t the history of third-party projects about 20 times, but there was no single case when I had to check already closed tasks and bugs in my own development.

I dont see any compelling reason to use a tracking tool for a single person development. However let me list my thoughts and let you decide on it.

If a particular bug/feature has multiple commits. If it is recorded in a tracking tool it will help group the multiple commits in one place. It will also help implement similar feature in the future. However you can argue you can have the prevhious commits details in the commit message itself.
While working on multiple bugs/features. There are some editors which allow you to preserve the state you are working in the editor. Like say if you are debugging a bug which involves 3 different files, when you open this particular bug, all of the three files will be opened with all break points and stuffs you had. This will allow you to multitask between different bugs/features.
By using a tracking tool you can get statistics like rate at which bug fixes happen, record milestones, associations of different bugs.
Tracking tool can be shared with customers to create bugs. Also they can know the status of the bugs from the same.
Also by tracking electronically it would be more easier to edit it when you have updates, which will become a mess maintaining it in papers in the long run.

I use Trac, even for my one-person projects. The milestones and priorities are helpful for figuring out what I should be working on now and what I should work on later. And when projects get interrupted by "real life" for a number of months, it helps to have that record to refresh my memory of what I was doing and why.

As for tracking the history of tickets, have you ever had a bug or feature you wanted to do, but after doing some work on it discovered that it was a bad idea to do it at all? That doesn't necessarily result in a net change to the source tree, but having that information recorded in the bug tracker helps you when you later wonder why the feature you remember working on last year isn't in the code.

Essentially: There's no such thing as a one-person project. There is always at least 1) you, and 2) you a year older. That second guy knows more than you, but has also forgotten a lot of things...

_{Disclosure: I'm one of the Trac devs}

I work alone on some customer projects using Trac, and I have added the timingandestimationplugin as well as the TracBurndown plugin. I can then enter the customer requirements/changes as tickets with an estimated time of work on that issue.

For a particular milestone I can by a keypress see how many hours of work I have left before I'm finished, and it is shown as a graph which sometimes grows (!) (i.e discovery of new defects/requirements that must be fixed to complete another ticket).

Gives me a good control of when I might be able to deliver the next release and also a list of what I have spent my time on in projects. Both of these issues are sometimes very critical to have a good and fast answer to when customers calls about a month after I have sent the bill and need an answer for their boss of what they have actually paid for.

JIRA together with websvn tells you months after the fix, what files have been touched with full diff. You will never forget an issue and have release planning almost for free. While tracking time your estimates will improve, making development more predictable.

After brainstorming a little, I realized that by tracking the history of tasks and bugs, one can later measure the stability of the project as well as his/her own productivity and correctness of coding in the long run. This can later be used for marketing purposes and/or self-branding and/or as triggers to improve some methodologies in development.