Flexible and not very software development management models. How to implement and combine in Redmine

In our company engaged in the development of software for the full cycle (from gathering requirements to implementation and technical support), a course has been adopted to maximize the optimization of resources. There are project teams, departments and services, and employees themselves are dynamically “rummaging” between different departments. Building a resource management process in such an environment, and even more so, its automation is not a trivial task.

As a taxi tracker and bug tracker, we use Redmine. In this article I want to talk about the implemented concept of working with tasks in Redmine.

As you know, now there are several approaches to project management: flexible, rigid, most often their combination. We set ourselves the task of providing such a tool for controlling the life cycle of a task in the tracker, which, on the one hand, will allow to take into account the technical aspects of software production, on the other hand, it will not impose a team or group of employees on a work method, and on the third, it will allow us to organize the internal process tasks (unified status states, identical metrics, etc.).

Consider the life cycle of the task to introduce new functionality (such stages are in our company):
')


In life, unfortunately, the task often returns to the previous stages more than once - the reverse arrows did not begin to draw, in order not to overload the scheme. Typically, the process of performing such a task is organized in the Redmine “head on”, similar to the diagram in the picture - a task (coupon) is created, then it is transferred from the contractor to the contractor with a change of status. Such a scheme is more suitable for a cascade management model when a permanent team performs a previously developed plan, or tasks are transferred in an organized manner from department to department (for example, from developers to testers). But for the agile approach, or when working with dedicated services, such a scheme is not very convenient. So, the advantages of the described scheme (let's call it “one task - one coupon”):

• A single entity that is easy to create, search, "understand";
• All history and comments in one place.

Disadvantages of the “one task - one coupon” scheme:

• It is difficult to assess the laboriousness and the planned time for execution by type of activity (many additional fields have to be entered, because it is impossible to estimate at least one stage of the assessment of the entire task as a whole);
• To make it clear at what stage of the task is now, you have to enter a bunch of additional statuses like "Ready for development", "On testing", etc. This complicates the design and use of metrics;
• It is impossible to parallelize actions (for example, documentation and testing), since a task at a given time can be assigned to only one executor;
• The executor, who accepted the task at the last stages (documentation or testing), is difficult to understand the current status, it is necessary to prescribe the problem statement in the comments, which is incorrect methodologically;
• When using sprints, it is inconvenient to plan long tasks in one coupon, since they are usually performed in several iterations.

A coupon in which work is performed according to the “one task - one coupon” scheme looks like this (for the case when one hard worker Vasya Pupkin does all the work):



The transition scheme for the “one task - one coupon” task (the tracker, without further ado, is called the “Task”) looks like this (not counting additional statuses like “Feedback”, “In coordination”, etc.):

New -> Ready for business analysis -> Business analysis -> Ready for systems analysis -> System analysis -> Ready for development -> Development -> Ready for testing -> Testing -> Ready for documentation -> Documentation -> Ready for implementation -> Implementation -> Completed -> Closed.

To solve the problems of the “one task - one coupon” scheme, a scheme was developed with the creation of separate coupons (subtasks) for each atomic activity performed by one performer. The general formulation in this case is formed in the parent task (the “General Task” tracker), and the atomic tasks as subtasks. Those. functional detail is replaced by life cycle detail. Let's call this scheme “one subtask - one coupon”.

Coupons for this scheme look like this:



The removal of the type of activity in the name of the tracker allows you to apply a single transition scheme:

New -> In Queue -> In Work -> Completed -> Closed.

The scheme is simple, understandable to both the manager and the performer, allows the use of unified metrics and agile tools (for example, virtual boards with stickers).

Advantages of the “one subtask - one coupon” scheme:

• The possibility of forming an individual task for a specific artist - reduces the risk of misunderstanding;
• The possibility of parallelization of subtasks - because each has its own ticket and its own performer;
• You can make accurate estimates of the time and the planned completion date for this particular subtask, regardless of the others;
• Uniformity and simplicity of the transition scheme;

Separately, I will say about the following advantage: when working with internal services, as well as with outsourcers, it is not entirely correct to transfer them a single coupon for a task both from a technical and a political point of view. So, if you outsource testing, it’s not necessary to know these guys about how you are doing, for example, documentation. Similarly with internal services - we, for example, have formed cross-project teams by occupation: technical writers, product development team. They do not know the specifics of the implementation of a project, so they are not interested in understanding the background, but need a well-formed task.

But there is such a scheme and disadvantages:

• It is necessary to create a lot of coupons in redmine (5-10 for each task), navigation on which in the future can be problematic;
• If the performer needs to know the background of the task, he will need to look for it in other coupons;
• Managing the life cycle of such a task is more difficult, since the manager will have to monitor and synchronize the states of different coupons.

Unfortunately, in theory, everything looks much more beautiful than in life. Starting work on the two proposed schemes, we quickly realized that they could not exist separately from each other, it was necessary to combine them. For example, in the case when a team working on the concept of “one task-one coupon” needs to transfer some subtask to an outsourcing or internal service. The solution was found quite simply - in the “Task” type coupon, it was suggested, if necessary, to add subtasks according to the “one subtask-one coupon” scheme, which could be executed in parallel and did not interfere with the sequential execution of the remaining subtasks.

Such a coupon is as follows:



What about practice? One of the divisions of our company went to work on the described concept about 3 months ago. 395 coupons are currently created, of which:

1. According to the concept “one task - one coupon” 248;
2. According to the concept “one subtask-one coupon” 147;

Despite the fact that while the concept of “one task - one coupon” is leading by a large margin, the numbers show that both of the proposed tools are in demand, which is good news.

There are more interesting ideas and implementations on operational planning in Redmine, right here .