Личный опыт внедрения Redmine

Добрейшего.

Не так давно задумал совершить ряд движений и поменять СМ-процесс в своём проекте и, если получится, на проекте соседнем. Поводом было то, что меня перестал устраивать текущий инструмент отслеживания запросов на изменения. Начав думать над одним, огляделся и понял, что пора бы и всё остальное поменять, до чего давно не доходили руки.

В общем, перво-наперво задача стояла поменять систему отслеживания запросов на изменения, или попросту багтрекер. К моменту написания заметки на пробу использовал Jira, подумывал оценить её и предложить соседней команде в качестве альтернативы использовавшегося ими Eventum. Когда стали обсуждать переход в участниками команды, решили посмотреть на прайс Джиры... посмотрели и решили, что Redmine, обладающий тем же функционалом, но за бесплатно, вполне подойдет :) У меня был опыт его настройки и внедрения в процесс, так что переход обещал быть быстрым.



Настройка

Установили в локальную сеть на машину под управлением CentOS. Человек, непосредственно ставивший его, пользовался вот этой инструкцией по установке. Всё заработало сразу. (Есть ещё вот такая заметка про установку Redmine на CentOS + ISPManager, может быть, кому-то пригодится.)

Дальше мне пришлось немного поколдовать, чтобы привести настройки системы в соответствие процессу разработки.

Первым делом сменил заголовок. Был Redmine, стал Красношахтинск! Зато нескучно :) Правда, потом пришел директор и поменял обратно ;) А заодно сделал перевод на русский перечислимых терминов, например группы пользователей, состояния в workflow и список приоритетов (будет ниже).

Перво-наперво завел проекты, соответствующие рабочим задачам. К примеру, проекты, над которыми работаю я, разбиваются естественным образом по доменникам, на которым проекты крутятся. Поддомены - это, в свою очередь, подпроекты. Ну и в ним - своё разделение. У меня получилось 3 уровня вложенности.

А если задача к разным проектам? А в этом случае задача заводится в над-проекте. Например, есть www.project.ku и у него foo.project.ku и bar.project.ku. Задачи, общие для поддоменов, заводятся в www.project.ku.
Вот в соседней Команде Д (см. предыдущий пост) проект один, разбиение на проекты было сделано по а) разделам сайта б) крупным фичам, затрагивающим несколько разделов или сайт целиком.
В общем, способы нарезки предметной области у нас разные. Что лучше - посмотрим со временем, пока что всё устраивает.

Зачем вообще разбивать на проекты? Да хотя бы чтобы задачи не пересекались.в общем списке. Иногда это мешает, но в целом отторжения не вызывает.

Дальше определились с пользователями. Тут просто - завели на каждого участника проекта по юзеру, даже без привязки к Active Directory. Роли (roles) оставили те же, что и были по умолчанию и добавили новую, ну и директор их перевел на русский:

• Менеджер
• Разработчик
• Репортер
• Контент-менеджер

Группы пользователей (groups) фактически повторили роли - их стало 4 на каждую команду.

Следующая серия допиливаний пришлась на workflow. Трекеры (trackers) оставили почти как есть, с той разницей, что их переименовали. Было

• Bug
• New task
• Support

Стало

• Ошибка
• Надо сделать
• Разное

Что вполне соответствует их назначению в команде.

Приоритеты (priority) также были переименованы во избежание разночтений:

• На потом (эту я добавил)
• Низкий
• Обычный
• Высокий
• Срочно!
• Незамедлительно!!!

Дальше я решил немного доработать workflow, созданный по умолчанию. В первую очередь, состояния были переименованы:

• Новая
• Выполняется
• Решена
• Ожидает проверки
• Закрыта
• Отклонена

Закрыта и Отклонена - это финальные состояния, перевод в них закрывает задачу. Убрал из переходов состояние "Ожидает проверки" (Feedback). В принятом процессе оно было лишнее. Текущий процесс приведен ниже под пунктом "Использование"

Что ещё оставалось сделать - связать репозиторий SVN с Redmine.
Тут ждала неожиданность: если несколько проектов используют один репозиторий, то к каждому проекту его надо подцеплять отдельно! Учитывая, что репо у "Команды Д" Рэдмайн пережевывал минут 5 (и, соответственно, отъедал место на сервере под свою базу), подцепить репо к каждому из десятка проектов - это тот ещё геморрой... Увы, поиск по манам и форумам ничего не дал - пришлось подцеплять репо к проектам постепенно, по мере необходимости.

Отдельно надо сказать про связь записей Redmine и ревизий SVN. У Рэдмайн есть отличная фича - связывание ревизий в системе контроля версий и своих записей в базе. Т.е. если Василий Пупкин пофиксил в SVN ревизии 9874  баги #125 и #145, то в этих записях появятся ссылки на эту самую ревизию с указанием комментария из ревизии. Соответственно, можно пойти по ссылке и посмотреть внесенную дельту.
Для того, чтобы эта схема работала, надо чтобы в комментарии к ревизии было ключевое слово и номер записи, например "Just made minor fix #124.", где fix - ключевое слово, а #124 - это привязка к записи. Списко ключевых слов редактируется вот тут:

http://local_redmine/settings/edit?tab=repositories
секция Referencing keywords. Я добавил ключевые слова "fix,##,пофиксил,фикс".
Кстати, там же есть возможность привязывать ревизии к определенным состояниям записей - вообще чума! Жаль, нигде не пригодилось :)

Ну и ещё мелочь - о новых ревизиях Рэдмайн узнает (и связывает с задачами) только в 2 случаях:

1. Когда кто-то заходит во вкладку "Хранилище" (Repository) или
2. По запуску спецскрипта (например, по крону).

Об этом надо помнить и что-нибудь с этим сделать сразу после первичной настройки системы.

Из первичной настройки - вроде всё.

Использование

Текущий процесс работы над задачей выглядит примерно так.

1. Запись заводится в состоянии Новая.
2. Назначается на разработчика.
3. Когда начинается работа, разработчик переводит в "Выполняется".
4. Выполнена - он переводит её в "Решена".
5. Менеджер, видя статус или услышав об изменении от разработчика - в одном комнате ведь сидим ;) - проверяет решение и переводит в "Закрыто".
6. Или же обратно в одно из предыдущих состояний.
7. Если заведенная запись не будет решаться по каким-то причинам - она двигается менеджеров в "Отклонена".
   

Права выставлены по следующим принципам:

1. Менеджер может всё и ему разрешено движение между любыми состояниями.
2. Разработчик может двигать запись только между соседними состояниями. Например, из "Выполняется" - только "Новая" и "Решена" или из "Новая" в "Выполняется". Закрыть задачу (перевести в "Закрыта" или "Отклонена") разработчик не может, иначе задача пропадет из поля зрения менеджера. Вместо этого он переводит её в "Решена" с соответствующим комментом.
3. Репортер (по сути, тестер или сторонний наблюдатель) имеет право только на заведение записи.

Просто и всем понятно. Процесс в проектах несложный, поэтому и трекеры настроены соответствующим образом.

Кроме того, сразу была задействована встроенная Вики. Туда сейчас постепенно переносим нужную информацию.

Напоследок о фильтрах записей. Поскольку их (записей) было сразу заведено под сотню, понадобилось это всё как-то фильтровать. Помогли фильтры. Настроили пару-тройку public фильтров, чтобы все могли пользоваться.

• "Все открытые, сгруппированные по состояниям", с сортировкой по приоритету - этот зрительно дает посмотреть что в работе, что закончено и что из очереди новых задач более приоритетное. Кроме того, тут же позывается столбец "Проект", чтобы видеть, откуда задача прилетела.
• Разработчики настроили себе "Мои выполняющиеся" - туда попадают все, что в состояниях до "Решено". Мол, пусть решенные мозолят глаза менеджерам :)
• "Все решенные незакрытые" - это для менеджеров, видеть что уже сделано.

Фильтры настраиваются очень просто, так что вполне может быть, что-то появится ещё.

Из повседневного - пока что всё. Посмотрим, что будет дальше.

P.S. Кому как, а у меня Redmine уже ассоциируется больше с системой управления проектами, чем с простым багтрекером.

Updates. Может также пригодиться инструкция по установке RedMine на Windows. Кому лень настраивать руками - есть отличная замена - Bitnami Stack.
Ну и вообще - почитайте до кучи обсуждение заметки на RSDN, есть полезные посты.

Как Redmine используется сейчас. И по многочисленным запросам - как закрыть задачу в Redmine.

А кому не хочется Редмайн - можете попробовать eTraxis. Очень рекомендую.