How to cook Redmine? Set up the development process.

Redmine is a simple yet powerful tool to streamline the process of developing and tracking employees. Although the settings it seemed to be simple, think of them need carefully to make it easy, convenient, and the most important correct process.

I Do not like to use additional plugins, because laziness to look for, and then to support. Therefore, only the basic functionality of Redmine version 3.3.0. Stable is used when configuring.

I will not detail with the tablets to paint all the options and where to find them. The Redmine is simple. That's What he's bribing.

The example considers a small team from the following departments:

UI Designers-Develop application design.
Developers-Create an application for the design.
Testers-Test the application.
Sales managers-communicate with the customer.

Projects (Projects)

Projects in Redmine-a fundamental object. Subprojects and/or tasks (issues) Are created in projects. A Task cannot live without a project.
You can bind To projects:

Users by specifying their roles in the project. It is Appropriate for them to be displayed only those projects, which they have access to. I do not recommend explicitly adding users to the project. It is Better to use groups.
User Groups, indicating their roles in the project.
Trackers that allow users to display in the project only those trackers that are necessary.
Custom fields-This adds flexibility because you can display and show custom fields depending on your project.

In Our example there will be two projects Landing and LTG (internal processes). The Second project is needed for testing purposes.

Roles (Role and permissions)

Roles are created in the Administration-> Role and Permissions section. There will be many bindings To the roles in further customization. First of all, the role has access rights, and there are many of them in Redmine. On the rights I will not dwell in detail. Roles are created by the name of specialties in departments, so that it is clear without additional documentation:

Designer.
Developer.
Tester.
Sales Manager.

In rights for a role, you can specify whether it has access to the appropriate tracker (see below).

The sequence of status changes (workflow) is bound To the role and the tracker.

Members (Users)

Users are created in the Administration-> Users section. For a user, you can set:

The Group to which it is included on the Groups tab. Creating groups is a good practice because it simplifies administration.
Projects that participate in the Projects tab.
When you add a project, you must specify the role in which the employee will participate. In Fact, only here the employee's relationship with his role in the project is set.

The user's Binding to the group and the project with the role is also set in the Groups section (see below).

Accordingly, if a group has already been set to bind the user and its role in the project, the settings for the project will be taken from the groups when you change the group for the user.

The Moment that is convenient to use during testing is a quick change of the group for the user. I.e. Created a test user, and in the Group section, we put a list of which group the user belongs to. Then we go under the user (for example, in another browser) and can check the workflow for this role.

Groups (Groups)

In Redmine in Administration-> Groups You need to create groups for each department:

Enter the name of the group (by unit name) on the General tab.
Add from the list of employees who works in the created department on the Users tab.
Select the projects in which the Department will participate and specify which role the team will participate in the project.

You Should actively use groups instead of directly specifying the user.

Tracker (Tracker)

On The trackers I will stop in detail-this is a very important element of Redmine. The Tracker is how the task will be divided into stages.

Perhaps The main point of the tracker is that you can bind the selected Custom fields to it, specify which Standard fields you want to hide, or give access only in Reading mode (this allows you to minimize the errors Polzovatielej) and assign the tracker binding to Projects.

The User, going to a certain project, will see only those trackers that are attached to it. Having Chosen the necessary tracker it will display only the fields specified for it (Standard and Custom) and the States, and by default the state specified in the tracker settings is assigned.

For Example, there are several stages in the development process: Design, Front End Development, Testing, customer Approval. Create a name-friendly trackers in Administration-> Trackers. We put for trackers that they should appear in the created projects. Also in the settings specify the status in which the task will go when selecting the tracker.

The Important point is that when moving from tracker to tracker, data and statuses are common for a task (issue). For Example, added a custom field of list type named "Partner" and made this field available in the trackers Design, Development and Coordination with the customer. When you select the specified trackers, the user will see this field if its settings allow it to be displayed for all or for the role that the user is a member of. If the user has entered information in the Design tracker, all other trackers where this field is displayed will see the information.

If an employee has specified a certain status in one of the trackers, then when switching to another tracker the workflow will start with the last preset status, no matter in which tracker it was installed.

If the user logically refers to a certain tracker, for example, "Design", but he must by the completion of his work to indicate the status relating to the tracker layout, do not need to make it change the tracker. This is an unnecessary action. It is Enough in the Workflow settings to specify for the binding Role-Tracker that the status is logically related to the "Layout" tracker should be available in the "Design" tracker. In this case, the transfer of the task from the employee to the employee will be as smooth as possible: the designer put in his tracker status "Start development", and the developer in his tracker continued to develop the task from this status.

Naturally, since statuses are common for all trackers, you cannot use the same task status (with the same name) from the designer and developer, even if the workflow is set to bind to different trackers. I.e. You cannot make the status "In work" and use it to mark the status of taking a task in the work of a designer and a coder. It is Necessary to create separate statuses, for example "Design Development" and "In development".

The Tracker can be used in a slightly different interpretation. Instead of splitting a task into parts and attributing each stage to a appropriate tracker, you can create only one tracker for the entire task. This is normal if you do not need any flexible settings for workflow and data filling.

For example, there is some regular task "Development xxx". In This task are involved: the customer, product managers (communicate and coordinate with the customer TK), designers, developers, testers.

Create one tracker "Development xxx" and user roles according to the listed. Next, for the selected tracker, and for each role, the workflow is configured. This option is less flexible because, for example, you can bind a custom fields to a tracker, and if it is one, it will be shared by everyone. But, in most cases, it is normal.

Of The advantages of such a decision that employees do not need to change the tracker, ie To make superfluous body-carrying. In the implementation of Redmine and the breakdown of the task into several stages (trackers), the first time the employees have questions because they forget to translate the task to the correct tracker. If There are no stages, there is no error. 🙂

In General, Redmine has enough flexibility in this respect. You can choose whichever option you like.

Rights for Tracker

For roles, you can set access rights to the trackers. To do this, you need to go to Administration-> Roles and permissions and at the bottom find Issue tracker.

With This set of rights, the tester will be able to add the task to the Test tracker and view the tasks in the Development tracker. Other trackers He will not see, accordingly, he does not need to make a choice once, making a decision. The Brain is slightly but discharged, because the energy cost of making a decision at the brain is very large. Well, the main thing is decreasing the probability of error.

Carefully approach the assignment of rights. The Fact that the user does not need to work should be hidden: unnecessary projects, trackers, states, etc. This minimizes the likelihood of an error. If the rights are overused, it will come out and the right can be granulated. Well, the issue of safety in development should not be forgotten: "Less know, stronger sleep." 🙂

Issue statuses

The States for a task are set in a single list in Administration-> Issue statuses. States are common to all projects, however, by playing tracker bindings to projects and workflow, you can create different statuses for different projects.

What are the criteria for creating states:

Any employee should be able to start and finish his/her work phase (tracker) on the task.
Statuses should unambiguously tell the manager in what state is work on the task.
The Number of States must be minimal.
Any employee must be able to assign the task to the next step by assigning the desired status to the other team.
The possibilities of iterations Should be considered, i.e. Return to the previous steps for rework.

How to paint roles and transitions between them to reconcile with the performers?

It is Clear that there are different notations of the description of business processes: BPMN (It is the most attractive to me), IDEFx, Aris, etc. However, you can not be wise. 🙂 I use Excel table in which on the left are the statuses, on top of the role of employees, and color marked trackers.

For example, Designer:

Created a task in the Design tracker.
Indicated the status "New" to mark the time when the job was received from the producer and have a notebook of tasks to work on.
He Pointed out the status of "Design Development" at the moment when he started working on the task. In Fact it is the status of "In work", but for the designer.
Finished design and put some status "Design designed", noting the time of completion of the task.
Then the designer needs to agree on the design with the extension.
To mark the beginning of the reconciliation stage the designer changes the status to "Design Approval". In This status he will make changes on the feedback from the sale. If The changes are serious, it can change the statuses by reverting back to previous states.
Then There may be the status "Design agreed" to put the date of completion of work on the design. But This status is conditional, because immediately after this status is always followed by the status "Start development". Therefore, you can omit it, because the status of this state determines when the reconciliation is complete.
In logic, the "Start development" status refers to the "Development" tracker, but you can give access to this status in the Design tracker so that the employee does not have to do unnecessary actions, changing the tracker.
etc.

Custom fields

Very simple and powerful thing-custom fields. There are several types of fields for which you can specify a description that will be displayed as hint when you hover over the field label. But The coolest thing is that there are a number of bindings for these fields:

Fields can only be displayed to employees with a specific role.
They can be made mandatory.
You Can allow them to be used in filtering and searching.
You can link them to trackers and then they will be displayed only when you select the correct tracker.
You can bind them to specific projects, and then the fields will be displayed only for those projects.

Furthermore, when you configure workflow, you can bind the mandatory padding attribute and read-only to a specific tracker and role.

For Example, if an employee with the Designer role in the Design tracker has reached the "edit" status, you can specify that in this case the custom field "Type" will be read-only. It is Clear that if we allowed the designer to return to the status of "Design Development", then he can go to this status and change the field, but it will be fixed in the history.

Or, for example, you can oblige a designer to set the Customer field as a required input when the task is transferred to the Start development status.

It is a very simple but powerful feature for flexible configuration of forms displayed to the user at different stages of work on the task.

Tips & Tricks. If you want a field in which you can insert multiple URLS, you use the Long text field type with the "Text formatting" checkbox. In this case, you can enter references, for example, by commas.

Workflow

Allows you to set status changes for a user with a specific role and for a specified tracker.

Everything is very easy. For example, if the designer opened the card with a new task and chose the tracker "Design" (and available trackers can be limited, as we have seen before), when you select the status it will be available only options in the line "New issues": "New", "In progress".

And if the task is in the status "Resolved", only one status of "Making edits" is available for selection. In this way, you can specify the route by which the task can move to the closing state, minimizing the choices, and the probability of error.

Movement by statuses is set rather flexibly and conveniently in the form of a matrix of transition on States, where on a vertical-current status, and on a horizontal-a status where the chosen role can move from the current status.

You can extend the functionality by using, for example, the plugin http://www.redmine.org/plugins/custom-workflows.

Notifications

An Important point, as the staff at the next stage will learn about new tasks to be started. There are several options:

If the tasks are roughly equal to the priority, the employee can look in Redmine at the end of work on the previous task, filtering them by the necessary statuses.
In filters It is possible to use Atom, i.e. Periodic XML generation with information about new tasks. Any RSS Reader allows you to subtract this XML file and display the appearance of new records. For Example, in Chrome I use the RSS Feed Reader plugin.
If the employee's profile is correctly set up about what events to notify, the employee will be sent an e-mail with the information in the profile. Can be notified in a very granular manner, reducing spam. 🙂

E-mail Correspondence

I have not tested this functionality, but I guess it is typical.

If you configure Redmine to receive mail from a certain e-mail, you can correspond with it. I.e. User can send a letter to this e-mail, on the basis of it will create a issue with a unique number. And then when sending messages on a task, the user will be left with the answers in the subject line assigned to the task.

If the user responds to a message with such a topic, the answer will be assigned to the task. I.e. In history it will be possible to observe all correspondence, and it cannot be changed.

To extend the functionality you can use plugins like:

http://www.redmine.org/plugins/redmine_send_issue_reply_email

Reports

As such, there is no report generator in Redmine, but in the task sections it is possible to display them as a table with the selected fields, filtering them by the necessary criteria. The Created filter can be saved and then used Atom for use in RSS Reader.

For Example, you can filter tasks assigned to a specific user or group in certain statuses, and then copy the Atom link and add it to an RSS Reader. When new lines are displayed, RSS Reader will display the number of new records.