August 17, 2011 at 15:26A bit of practice at Codebase
Surely, when the transfer to the fourth version of the engine is finished for all customers, here on Habré they will make a topic about it, and on the eve I want to share with you what I’ve come to in terms of task management in Codebase for a couple of years of its use. This will be relevant for any version.
Firstly, there are three types of tickets: a bug, an enhancement, and a task. By the way, the default is usually a bug, be careful.
We have a special attitude only to improvement tickets. Now they are most often used only to discuss some proposals and experiments. Then we close the enhancement and open the task, if the decision is made to do what we discussed.
Any ticket has five statuses (this can be configured). And here the most interesting begins. We took a few simple rules for ourselves, which greatly simplified the understanding of the state of the ticket:
New- the ticket is still being discussed and the decision to work on it has not yet been made. For example, information is collected on a ticket, there is a discussion of implementation (in the fourth version of the codebase, by the way, they made separate convenient discussions) or it is not clear which version of the product it will be made to.
Accepted - a ticket, the discussion on which is completed and all the data necessary for the implementation is ready, but the work has not yet begun. When one of us is looking for the next task, they look at such tickets.
In progress - obviously, tickets for which work is ongoing. They always have a performer. If the contractor has not yet been assigned in the accepted ticket, then the person who takes the ticket indicates himself in this field.
Completed- ticket, all conditions of which are implemented. We can reopen the ticket if the task is solved only according to the performer (for example, a tester can do this). Then the ticket is transferred to the New status , as there is something to discuss.
Invald - a ticket that closes for any reason other than the implementation of the task. We decided not to do it; it’s impossible to reproduce a bug or just a ticket that was created incorrectly.
If a ticket is tied to a milestone, then it must be finished by the milestone deadline and no later. But here what we have differences from traditional approaches, is how we relate to the lack of a deadline for the ticket. In this case, we believe that the ticket should be closed "as soon as possible", and not "whenever".
That’s our whole simple methodology, the efficiency of which we prove for about a year and a half by the fact that no one has questions and wants to change nothing.
If you have questions about Codebase - ask, I will answer them with pleasure (no, they don’t pay me, but quite the opposite.
Tickets
Firstly, there are three types of tickets: a bug, an enhancement, and a task. By the way, the default is usually a bug, be careful.
We have a special attitude only to improvement tickets. Now they are most often used only to discuss some proposals and experiments. Then we close the enhancement and open the task, if the decision is made to do what we discussed.
Any ticket has five statuses (this can be configured). And here the most interesting begins. We took a few simple rules for ourselves, which greatly simplified the understanding of the state of the ticket:
New- the ticket is still being discussed and the decision to work on it has not yet been made. For example, information is collected on a ticket, there is a discussion of implementation (in the fourth version of the codebase, by the way, they made separate convenient discussions) or it is not clear which version of the product it will be made to.
Accepted - a ticket, the discussion on which is completed and all the data necessary for the implementation is ready, but the work has not yet begun. When one of us is looking for the next task, they look at such tickets.
In progress - obviously, tickets for which work is ongoing. They always have a performer. If the contractor has not yet been assigned in the accepted ticket, then the person who takes the ticket indicates himself in this field.
Completed- ticket, all conditions of which are implemented. We can reopen the ticket if the task is solved only according to the performer (for example, a tester can do this). Then the ticket is transferred to the New status , as there is something to discuss.
Invald - a ticket that closes for any reason other than the implementation of the task. We decided not to do it; it’s impossible to reproduce a bug or just a ticket that was created incorrectly.
Milestones
If a ticket is tied to a milestone, then it must be finished by the milestone deadline and no later. But here what we have differences from traditional approaches, is how we relate to the lack of a deadline for the ticket. In this case, we believe that the ticket should be closed "as soon as possible", and not "whenever".
That’s our whole simple methodology, the efficiency of which we prove for about a year and a half by the fact that no one has questions and wants to change nothing.
If you have questions about Codebase - ask, I will answer them with pleasure (no, they don’t pay me, but quite the opposite.