The life cycle of tasks in Redmine for a small development team. Our experience and useful tips

I think this article should help people who first decided to automate the process of tracking tasks based on Redmine in the software development team. In the article I will talk about how this process is organized in our country, what new fields for the task we have brought and what problems these fields solve. I think the article will be useful to a wide range of people, in my opinion, setting up the life cycle of tasks is the work under the slogan "The obvious is not obvious."

Still! We work in a large corporate environment, mainly for internal customers (and there are several of them), and this situation is reflected in our life cycle.
')
Let's start.

It all starts with the fact that at one point a task appears and after its appearance, the task logically should fall on the author. Why?! Because a task should always have an employee who is responsible for its further execution, the one who is currently slowing down the task, the one on whose side the “ball” is, and he should “pass the ball to another”, do something like a football pass . Sometimes this person should not be. For example, when it is no longer necessary to perform actions on a task when it is closed.

What information do we ask to fill in the user creating the task?

Well, of course, this is the type of task, title and description, but also:

• "Customer" - the employee who is interested in this task and requested its execution. He will subsequently check the result of the work, and evaluate the performance.
• "Goal" - the ultimate goal, which should solve the problem. We did not immediately reach this field. On the one hand, why do we need a goal, if there is a detailed description in which it is written what to do? But if you think about it, then the goal is completely different. Task description says what needs to be done to achieve the goal, and if the goal is not fixed, then in the process of completing the task, the goal may be lost, and it will not be exactly that and not quite as needed.

For example, the goal might be:
"Implement the possibility of calculating the basic part of the RFP on the basis of an arbitrary mathematical formula."

And in the description will be more detailed key steps and requirements for achieving the goal. For example, “connecting the MathML library, the ability to associate a formula with a calculation period,” etc.

In general, the description may generally depend on the performer’s qualifications and in some cases may be just a couple of lines (if you have good communication with the performer, you have worked together and you understand each other well).

Where can the new task go?

Most often, it is sent to the plan, because we often have priority tasks (well, this is such a client orientation and unwillingness of customers to think about the future).

But it so happens that the task is not a priority and then it can go to the queue (or Backlog, as you like).

If the task is sent to the plan, then we will ask you to fill in the following fields from it:

• "Estimation of time" - how much, in the opinion of the development manager, this task will take the net time of the programmer. Almost never can accurately determine this value. But you need to determine approximately. Because this time is actually the price of the issue, i.e. This is not the time, this is the money for which the customer buys the execution of this task from the development group.
• Start date and due date. Everything seems logical here. We also have it, when a programmer unreasonably misses the time-based task, then it affects the RFP.
• "Stage" - the same plan or version or sprint, in which you plan to complete the task. Our stages coincide with the months. By stages and performers, we monitor the progress of work.
• “Who” - the employee responsible for the execution of the task.

At the time of putting into a plan, the value in the field “On whom” is always copied in the field “Executor”. The task will sooner or later leave the employee responsible for the execution, but the responsibility for the execution should not be gone, therefore, each performed task always maintains a performer.

And if in a queue, then the fields are less:

• "Priority", which would then be the first to pull out more priority tasks from the queue.
• “Estimation of time” so that it would be possible to decide what will fit into the future plan and what is not.

And of course, the task from the queue can always get into the plan, and it can close and get the status “Closed”. The status “Closed” is fundamentally different from “Completed” in that the task was not carried out.

What can a performer do with a task?

Two controversial, but having the right to life functions: “start” and “suspend”, which respectively change the status of the task from “Assigned” to “In Work” and vice versa. In small groups, this function has not really taken root, and in some large groups it has taken root. If there are a lot of programmers and they mark the tasks that they are performing at the moment, then you can build a slice on the tasks that are currently in the work of the performers (a kind of “Work in Progress”).

In almost any status, an employee who is currently in a task can request information from the author, manager, customer, etc. Of course, the performer is no exception.

Of course, the main function for the contractor is the ability to send the task for review and the button “For verification” of the same name. The button sends the task to the tester that the programmer must complete:

• The "How to check" field is a surprisingly simple and useful thing. For the first time I read about this field in a book on “Scrum”. The programmer, when submitting the task for verification, must write to the tester and the final customer what to do in order to take advantage of new features: which branch from the repository to take, what settings to do, where to go in the interface and what to poke. As a result, a lot of unnecessary questions leave the tester, customer and team leader.
• Field "What is done." The programmer does not always do what was originally written in the description of the problem. Sometimes it does something extra, sometimes the programmer is given freedom of action in execution. Through this field, the programmer tells the manager, customer and tester what exactly he did as a result of the execution. Among other things, we have introduced monetary motivation based on the estimates of tasks by the customer and in this field the programmer can draw additional attention of the customer to the features of the task that can lead to an increased assessment.
• The To Whom field is the tester who will check the task.
• Tick ​​"I put the task on the test server." Without filling this field you can not send a puzzle to check. The tester has his own test server to check the tasks, but before discarding the task for verification, the programmer must put it in working condition on the test server. First of all, in order for the manager to assess the quality of the task and he did not have to once again ask to post the task on the test server or do it himself.

After submitting the task for verification, its status is logically changed to “Under Review”. Now the tester is responsible for the further execution of the task.

What can a tester do with a task?

Well, of course: send the puzzle for revision (the “Return back” button) or skip further to the production server (the “Verified” button).

He can also change the verifier (and the button of the same name), and in our group it is administratively fixed that the tasks must pass a second check through the manager (in other groups there is not).

What is a manager's check for?

• First, this is the second check, and the second check is rarely superfluous.
• Secondly, I am tormented by perfectionism regarding design and usability. And I’m getting overwhelmed when I see that the interface could be made more harmonious, but the problem has already been crawled onto the worker.
• Third, laying out a task on a working server may require notifying a certain group of interested parties, and only the manager can decide whether to alert.

In any case, the transition of the task from the status “On checks” to the next status “In operation” is accompanied by filling in a handful of fields.

• “Validation Evaluation” and “Explanation of Valuation Evaluation”. The assessment can be made by a tester or a supervisor. This assessment allows you to influence the programmer's GP, including.
• "The desired date of the calculations." When it would be great to put the puzzle on the production-server (for the layout in our group is responsible for an individual).
• "Requires Alert." Do I need to notify employees about the availability of new functionality or something else. If required, the tester is required to do this before laying out.
• "Presentation". When the task will be presented to customers (this is an interesting procedure, but I will tell about it in another article).

There are also a bunch of ticks to check before sending the task to the work environment. I will list them, suddenly it will be useful for someone:

• I checked the absence of recursive and cyclic SQL queries through RaccMiniProfiler.
• I checked the layout on different browser resolutions.
• I checked the layout and performance in various browsers of the latest versions (Chrome, Firefox, Opera, Intenet Explorer).
• I checked the plug-in for various databases (MS SQL server, MariaDB, PostgreeSQL).
• I checked the execution of the assignment for compliance with the fundamental rules "Fundamental rules for writing plug-ins to Redmine".
• I analyzed the need to alert employees of the holding. Noted the need for alerts in the task.
• I analyzed the need to update the information in the instructions (if necessary, I got the task).
• The task is posted on the test server.
• Tasks for writing autotests were established.

This is such a simple verification procedure.

What can the Redmine administrator do with the task?

He can put it on a working server, thereby transferring the task from “To check” status to “In use” status. The task is assigned to the customer.

What can the customer do with the task?

The customer may accept the work or not accept. If he didn’t accept, then he sends the task to check the tester by writing a comment. If accepted, then presses the button "Done" and puts down the assessment of the implementation and an explanation of the assessment. These estimates affect the salary of the contractor and the manager.


Taken together, this is the scheme of the life cycle of the task.



There are much more transitions between statuses than described in the article. For the most part, these are preferred transitions for the manager, when he administratively needs to transfer the task to the next state without waiting for the tester or programmer.

Of course, this is not all that we have in the life cycle of tasks, but if I wrote about everything, then probably a little book would have turned out.

I would be glad if you share information about what life cycle is used for you? What fields do you ask the staff to fill out when you track the task and why?

Thanks to everyone who read to the end.