Как готовить Redmine? Настройка процесса.

Redmine — простой, но достаточно мощный инструмент для упорядочивания процесса разработки и отслеживания работы сотрудников. Хотя настройки у него, казалось-бы несложные, продумывать их нужно тщательно, чтобы получился легкий, удобный, а главное корректный процесс.

Не люблю использовать дополнительные плагины, ибо лень искать, а потом саппортить. Поэтому при настройке используется только базовый функционал Redmine version 3.3.0.stable.

Я не буду подробно со скринами расписывать все опции и где их найти. В Redmine все просто. Именно этим он и подкупает.

В примере рассмотрена небольшая команда из следующих спецов (отделов):

  • Дизайнеры — разрабатывают веб дизайн приложения.
  • Верстальщики — верстают приложение по дизайну сделанному дизайнером.
  • Тестировщики — тестирут верстку на адаптив под разными устройствами.
  • Согласованты — те, кто согласуют верстку с заказчиком. Они-же постановщики задачи и формируют ТЗ для дизайнера.

Разработчики занимаются разработкой платформы и в рассматриваем процессе не участвуют.

Проекты (Projects)

Проекты в Redmine — основополагающий объект. В проектах создаются подпроекты и/или задачи (issues). Задача не может «жить» без проекта.
К проектам можно привязать:

  • Пользователей, указав их роли в проекте. Соотвественно, при авторизации им будут отображаться только те проекты, к котоорым у них есть доступ. Не рекомендую явно добавлять пользователей к проекту. Лучше использовать группы.
  • Группы пользователей, обозначив их роли в проекте.
  • Трекеры, что позволяет отображать пользователям в проекте только те трекеры, котоорые необходимы.
  • Custom fields (настраиваемые поля) — это добавляет гибкости, поскольку можно отображать и показывать кастомные поля в зависимости от проекта.

В нашем примере будет два проекта Landing и LTG (internal processes). Второй проект нужен для целей тестирования.

Роли (Role and permissions)

Роли создаются в разделе Administration -> Role and permissions. К ролям в дальнейшей настройке будет много привязок. В первую очередь с ролью связаны права доступа, а их в Redmine много. На правах я не буду останавливаться подробно. Роли создаем по названию специальностей в отделах, чтобы было предельно понятно без дополнтельной документации:

  • Дизайнер.
  • Верстальщик.
  • Тестировщик.
  • Согласовант.

В правах для роли можно задать имеет ли она доступ к соответствующему трекеру (см. ниже).

К роли и трекеру привязывается последовательность смены статусов (workflow).

Пользователи (Users)

Пользователи создаются в разделе Administration -> Users. Для пользователя можно задать:

  1. Группу в которую он входит на закладке Groups. Создание групп — хорошая практика, поскольку упрощает администрирование.
  2. Проекты в которых участвует на закладке Projects.
  3. При добавлении проекта необходимо в обязательном порядке указать роль в которой будет участвовать сотрудник. Собственно, только здесь происходит установка связи сотрудника с его ролью в проекте.

Привязка пользователя к группе и проекту с ролью устанавливается также в разделе Группы (см. ниже).

Соответственно, если в группе уже задана привязка пользователя и его роли в проекте, то при смене группы для пользователя настройки для проекта будут браться из групп.

Момент, который удобно использовать при тестировании — быстрая смена группы для пользователя. Т.е. создали тестового пользователя и в разделе Группа проставляем галку к какой группе относится пользователь. Далее заходим под пользователем (например, в другом браузере) и можем проверять workflow для этой роли.

Группы (Groups)

В Redmine в Administration -> Groups нужно создать группы для каждого отдела:

  1. Ввести название группы (по названию подразделения) на закладке General.
  2. Добавить из списка сотрудников тех, кто работает в созданном отделе на закладке Users.
  3. Выбрать проекты в которых отдел будет участвовать и указать с какой ролью эта группа будет участвовать в проекте.

Стоит активно использовать группы, вместо прямого указания пользователя.

Трекер (Tracker)

На трекерах остановлюсь подробнее — это очень важный элемент Redmine. Трекер — это то, как будет делится задача на этапы.

Пожалуй, основной смысл трекера — это то, что к нему можно привязать выбранные Custom fields, указать какие Standard fields нужно скрыть, либо дать доступ только в режиме чтения (это позволяет минимизировать ошибки пользоватиелей) и назначить привязку трекера к проектам.

Пользователь, зайдя в определенный проект, увидит только те трекеры, которые к нему привязаны. Выбрав нужный трекер ему отобразятся только заданные для него поля (Standard и Custom) и состояния, причем по умолчанию будет назначено состояние, заданное в настройках трекера.

Например, в процессе разработки есть несколько этапов: Дизайн, Верстка, Тестирование, Согласование. Создаем одноименные трекеры в Administration -> Trackers. Проставляем для трекеров, что они должны появляться в созданных проектах. Также в настройках прописываем статус в который перейдет задача при выборе трекера.

Важный момент, что при переходе от трекера к трекеру данные и статусы общие для задачи (issue). Например, добавили custom field списочного типа с названием «Партнер» и сделали это поле доступным в трекерах Дизайн, Верстка и Согласование. При выборе указанных трекеров пользователь увидит это поле, если в его настройках разрешено его отображения для всех, либо для роли в которую входит пользователь. Если пользователь внес информацию в трекере Дизайн, то во всех остальных трекерах, где это поле отображается, сотрудники увидят эту информацию.

Если в одном из трекеров сотрудник указал определенный статус, то при переходе на другой трекер workflow начнется с последнего заданного статуса, не важно в каком трекере он был установлен.

Если пользователь по логике относится к определенному трекеру, например, «Дизайн», но при этом он должен по завершеию своей работы указать статус относящийся к трекеру верстка, не нужно заставлять его менять трекер. Это лишнее действие для дизайнера. Достаточно в настройках Workflow указать для связки Роль-Трекер, что статус лпо логике относящийся к трекеру «Верстка» должен быть доступен в трекере «Дизайн». В этом случае передача задачи от сотрудника к сотруднику будет максимально гладкой: дизайнер проставил в своем трекере статус «Начать верстку», а верстальщик в своем трекере продолжил отработку задачи именно с этого статуса.

Естественно, поскольку статусы общие для всех трекеров нельзя использовать один и тот-же статус задачи (с одним и тем-же названием) у дизайнера и верстальщика, даже если в workflow задана привязка к разным трекерам. Т.е. нельзя сделать статус «В работе» и использовать его для маркировки состояния взятия задачи в работу дизайнером и верстальщиком. Нужно создавать отдельные статусы, например «Разработка дизайна» и «На верстке».

Права для трекера

Для ролей можно задать права доступа к трекерам. Для этого нужно зайти в Administration -> Roles and permissions и внизу найти Issue tracker.

При такой настройке прав тестировщик сможет добавить задачу в трекере «Тестирование» и просмотреть задачи в трекере «Верстка». Другие трекеры он не увидит, соответственно, ему не нужно лишний раз делать выбор, принимая решение. Мозг слегка, но разгружается, поскольку энергозатраты на принятие решения у мозга очень велики. Ну и главное снижается вероятность ошибки.

Тщательно подходите к назначению прав. То, что пользователю не нужно для работы должно быть скрыто: лишние проекты, трекеры, состояния и пр. Это минимизирует вероятность ошибки. Если с правами переборщили это всплывет и можно будет гранулировано додать прав. Ну и вопрос безопасности при разработке не нужно забывать: «меньше знают, крепче спишь». 🙂

Состояния (Issue statuses)

Состояния для задачи задаются одним списком в Administration -> Issue statuses. Состояния общие для всех проектов, однако, играя привязками трекеров к проектам и workflow можно создать разные статусы для различных проектов.

Какие критерии создания состояний:

  1. Любой сотрудник должен иметь возможность начать и закончить свой этап работы (tracker) по задаче.
  2. Статусы должны однозначно говорить менеджеру в каком состоянии находится работа по задаче.
  3. Количество состояний должен быть минимальное.
  4. Любой сотрудник должен иметь возможность передать задачу на следующий этап другой команде, назначив нужный статус.
  5. Должны учитываться возможности итераций, т.е. возврата на предыдущие шаги для переделки.

Как расписать роли и переходы между ними, чтобы согласовать с исполнителями?

Понятно что есть разные нотации описания бизнес-процессов: BPMN (она мне наиболее симпатична), IDEFx, Aris и пр. Однако, можно не мудрить. 🙂 Я использую Excel таблицу в которой слева идут статусы, сверху роли сотрудников, а цветом обозначены трекеры.

Например, дизайнер:

  1. Создал задачу в трекере «Дизайн».
  2. Указал статус «Новое», чтобы отметить время когда задание было получено от постановщика и иметь записную книжку задач над которыми нужно работать.
  3. Указал статус «Разработка дизайна» в момент, когда приступил работать над задачей. Фактически это статус «В работе», но для дизайнера.
  4. Закончил дизайн и проставил статус «Дизайн разработан», отметив время завершения работы над задачей.
  5. Далее дизайнеру нужно согласовать дизайн с постановщиком задачи, который может не работать в системе и переписка с ним будет, например, по Skype. Хотя правильнее в Redmine, конечно.
  6. Чтобы отметить начало этапа согласования дизайнер меняет статус на «Согласование дизайна». В этом статусе он будет вносить изменения по обратной связи от постановщика. Если изменения серьезные, то он может сменить статусы, «откатившись» назад, на предыдущие состояния.
  7. Далее может быть статус «Дизайн согласован», чтобы проставить дату завершения работы над дизайном. Но этот статус условный, поскольку сразу после этого статуса всегда следует статус «Начать верстку». Поэтому его можно опустить, поскольку простановка этого статуса определяет время, когда согласование завершено.
  8. По логике статус «Начать верстку» относится к трекеру «Верстка», но можно дать доступ к этому статусу в трекере «Дизайн», чтобы сотруднику не нужно было совершать лишних действий, меняя трекер.
  9. и т.д.

Custom fields

Очень простая и крутая штука — custom fields. Существует несколько типов полей для которых можно задать описание, которое будет отображаться в виде hint при наведении на надпись поля. Но, что самое крутое — для этих полей есть ряд привязок:

  1. Поля можно отображать только сотрудникам с определенной ролью.
  2. Их можно сделать обязательными для заполнения.
  3. Можно разрешить их использовать при фильтрации и поиске.
  4. Можно привязать их к трекерам и тогда они будут отображаться только при выборе нужного трекера.
  5. Можно привязать их к определенным проектам и тогда поля будут отображаться только для этих проектов.

Более того, при настройке workflow можно привязать атрибут обязательного заполнения и только для чтения к определенному трекеру и роли.

Например, если сотрудник с ролью «Дизайнер» в трекере «Дизайн» дошел до статуса «Внесение правок», можно прописать, что в этом случае custom field «Тип» будет доступен только для чтения. Понятно, что если мы разрешили дизайнеру возврат на статус «Разработка дизайна», то он может перейти на этот статус и изменить поле, но это будет зафиксировано в истории.

Или, например, можно обязать дизайнера задать поле «Домен» как обязательное для ввода при передаче задачи на статус «Начать верстку».

Это очень простой, но мощный функционал для гибкой настройки форм отображающихся пользователю на разных этапах работы над задачей.

Tips & Tricks. Если требуется поле в которое можно вставить несколько URL, то используется тип поля Long text с простановкой чекбокса «Text formatting». В этом случае можно вводить ссылки, например, через запятую.

Workflow

позволяет задать изменения статусов для пользователя с определенной ролью и для заданого трекера.

Все предельно просто. Например, если дизайнер открыл карточку с новой задачей и выбрал трекер «Дизайн» (а доступные трекеры можно ограничить, как мы уже видели ранее), то при выборе статуса ему будут доступны только варианты в строке «New issues»: «Новая», «В работе».

Причем если задача находится в статусе «Решена», то для выбора доступен только один статус «Внесение правок». Таким образом можно задавать маршрут по которому задача может продвигаться к состоянию закрытия, при этом минимизируя варианты выбора, а соотвественно и вероятность ошибки.

Можно расширить функционал, используя, например, плагин http://www.redmine.org/plugins/custom-workflows.

Уведомления

Важный момент, как сотрудники на следующем этапе узнают о появлении новых задач к которым нужно приступить. Здесь есть несколько вариантов:

  1. Если задачи примерно равноприоритетные, то сотрудник может заглядывать в Redmine по окончанию работы над предыдущей задачей, фильтруя их по нужным статусам.
  2. В фильтрах есть возможность использовать Atom, т.е. периодическое формирование XML с информацией о вновь поступаемых задачах. Любой RSS Reader позволяет вычитывать этот XML файл и отображать появление новых записей. Например, в Chrome я использую плагин RSS Feed Reader.
  3. При правильной настройке в профиле сотрудника о каких событиях уведомлять, сотруднику на e-mail указанный в профиле будет уходить письмо с информацией. Можно уведомлять очень гранулированно, уменьшая спам. 🙂

Переписка по e-mail

Я не тестировал этот функционал, поскольку e-mail в компании не используется, но предполагаю, что он типовой.

Если настроить Redmine на получение почты с определенного e-mail, то с ним можно переписываться. Т.е. пользователь может отправить письмо на этот e-mailб на основании него будет создать issue с уникальным номером. И далее при отправке сообщений по задаче пользователю будут уходить ответы в теме которых будет стоять номер присвоенный задаче.

Если пользователь ответит на письмо с такой темой, то ответ будет присовокуплен к задаче. Т.е. в истории можно будет наблюдать всю переписку, причем её нельзя изменить.

Для расширения функционала можно использовать плагины, вроде:

Отчеты

Как такового генератора отчетов в Redmine нет, но в разделах с задачами есть возможность отобразить их в виде таблицы с выбранными полями, отфильтровав их по нужным критериям. Созданный фильтр можно сохранить и затем использловать Atom для использования в RSS Reader.

Например, можно отфильтровать задачи назначенные определенному пользователю или группе в определенных статусах, а затем скопировать ссылку Atom и добавить в RSS Reader. При появлении новых строк RSS Reader будет отображать количество новых записей.

Полезные плагины

Учет рабочего времени

RedTimer

Кросс-платформенное приложение https://fathomssen.github.io/redtimer/. Последние билды есть здесь: https://github.com/fathomssen/redtimer/releases

Десктопное приложение под разные платформы. Вполне себе достойное. Позволяет:

  1. Создавать новые issues.
  2.  Выбрать из списка issues те, над которыми идет работа.
  3. Запускать таймер учета рабочего времени.
  4. Менять трекер и статус.
  5. Не позволяет добавлять комментарии при записи временной отметки.

TMetric

Интеграция Redmine с системой учета рабочего времени TMetric. Бесплатно до 5 пользователей. http://www.redmine.org/plugins/redmine_time_tracking

Есть расширения для Chrome, Firefox, Opera, а также десктопное приложение для Windows.

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс
Запись опубликована в рубрике IT tools, IT опыт, IT рецепты, IT решения для бизнеса с метками . Добавьте в закладки постоянную ссылку.