Переезд с одного средства планирования разработки на другое — с XPlanner на Redmine

Переезд с одного средства планирования разработки на другое — с XPlanner на Redmine

«Мыши плакали, кололись, но продолжали есть кактус», — моё мнение о пользователях XPlanner.

Преамбула

Так повелось, что изначально наша команда использовала XP и вообще Agile разработку. Изначально был выбран XPlanner — он же как раз заточен под итеративную разработку ПО.
Со временем процессы разработки менялись, и это все меньше походили на те, которыми были изначально.

И вот лишь недавно мне удалось перетащить всех на Redmine.

<оффтопик>Лично меня XPlanner всегда раздражал («раздражал» — самое точно слово) — слишком много всего надо было сделать, чтобы получить желаемое. Точнее даже не желаемое — а возможное. Слишком непонятный, неудобный и бесчеловечный интерфейс. Элементарные вещи требовали от меня огромных усилий и приносили мало пользы.</оффтопик>

О XPlanner'е

Xplanner — XPlanner is a project planning and tracking tool for eXtreme Programming (XP) teams.
Xplanner — програмное средство для планирования и управления задачами для команд, работающих в стиле экстремального программирования. Проект перестал обновляться в мае 2006го года.

XP имеет несколько принципов, часть из них находят поддержку в XPlanner'е, а именно:

• Процесс разработки ПО состоит из коротких итераций (обычно одна или две недели) в ходе которых необходимо выполнить достаточно законченный блок функциональности продукта. Если выясняется, что в срок закончить не удаётся, надо сократить функциональность, но не сдвигать время.
• Блоки функциональности делятся на «истории» (story) — на каждую подсистему, или модуль — пишется своя история. Истории обсуждаются на встречах и фиксируются.
• После этого истории делятся на задачи, которые оцениваются перед началом разработки.

Для этого XPlanner имеет соответствующие средства — проекты, состоящие из итераций, итерации из историй, истории из задач. Есть метрики выполнения. Несмотря на большой список фич XPlanner'а у нас в команде использовались, фактически, только две:

• Разбиение процесса на итерации, истории, задачи.
• Учёт времени.

Минусы XPlanner (на мой скромный взгляд)

Фактически из средства планирования он превратился в средство отслеживания времени. Потому как планировать каждую неделю, перекидывать задачи из итерации в итерацию, из истории в историю было очень долго. Но что хуже (с моей точки зрения) он не мог выполнять элементарных вещей, которые эмулировались руками разработчиков. Например были следующие странные процессы:

• Т.к. XPlanner не поддерживает уведомлений в почту, каждый разработчик был обязан по выполнению задачи написать в особую рассылку письмо вида «Завершена задача <id задачи>».
• Если в ходе разработки программист понимает, что не уложится в срок он меняет оценку в XPlanner'е и (вы уже догадались?) — да! пишет письмо в рассылку «изменена оценка задачи».
  Знакомые говорят, что в XPlanner есть уведомления, однако я ничего точно про них сказать не могу
• Каждый вечер разработчик пишет в рассылку отчёт по задачам (сколько времени потрачено и какие закрыты).
• При коммите в качестве комментария писался Id задачи. Чтобы узнать суть задачи по коммиту надо было копировать Id, открывать браузер и ползти в XPlanner — смотреть.
• Кроме этого, т.к. XPlanner не поддерживает статусы задач, поэтому чтобы тестировщик знал какие задачи ещё не тестированы была заведена история «Тестирование». Разработчик, завершив задачу, кроме того письма обязан был зайти и дописать ссылку на сделанную задачу в ту историю.
• Тестировщик же в свою очередь был вынужден их просматривать на предмет «а не появилось ли чего нового».
• Комментарии к задачам не использовались — каждый дописывал их прямо в текст задачи не забыв веское «Вася».
• Задачи не имеют приоритетов поэтому они назывались так: «(0) Ошибка в модулей 1», «(1) Не очень важная ошибка».
• Задачи не имеют дополнительных статусов и связанности с задачами (заблокирована, дублирует). Поэтому в названии задачи можно было встретить конструкцию «LOCK».
• Нет общего пула задач, и задач в разработке. Для пула использовалась «Итерация бесконечность». Откуда каждую неделю не самым удобным образом набирали задачи на итерацию.
• Нет удобных вещей: фильтров по задачам (очень важно! нельзя посмотреть статистику всех важных ошибок по всем проектам), цветовых схем (чтобы задачи 0го приоритета сразу бросались к глаза).
• Никакого воркфлоу. Задачу может создавать кто угодно, закрывать кто угодно. Отследить тестируется она или нет — нельзя. (А как быть тем у кого процесс разработки достаточно жесткий и состояний много: создана, утверждена, выполняется, заблокирована, тестируется, закрыта, возвращена, отклонена?).

Плюсы

• Язык разработки — Java, на котором мы разрабатываем свои продукты, что создавало принципиальную возможность его дорабатывать самим, пара мелких вещей действительно

Теперь о Redmine

Redmine is a flexible project management web application. Written using Ruby on Rails framework, it is cross-platform and cross-database.
Redmine — гибкое средство управления разработкой ПО. Оно разработано на платформе RoR и может использовать различные БД (SQLite, MySQL, PostgreSQL).
Redmine с первого взгляда понравился тем, что позволяет гибко настраивать почти всё из интерфейса, тем, что в нём уже есть много полезного, но в то же время нет ничего сверхненужного.

Краткие возможности Redmine

• Справочники. Справочник — это список малоизменяемых служебных или пользовательских сущностей, которые можно менять из интерфейса. Можно настроить следующие вещи:
  • Список типов задач («Ошибка», «Рефакторинг», «Саппорт», «Новая функциональность» и т.д.)
  • Список статусов задач («Создана», «Выполняется», «Заблокирована» и т.д)
  • Возможные роли сотрудников в проектах (Менеджер, Разработчик, Тестировщик)
  • Приоритеты задач.
  • Категории (определяются в рамках проектов). Фактически — модули или подсистемы в рамках проекта для дополнительного разбиения задач
  • Flex-атрибуты — для задачи, проекта, пользователя и отчёта по времени можно добавить полей: Например «Расположение в офисе» для пользователя, или «контактное лицо со стороны клиента» по проекту.
  • Воркфлоу задач — связь статуса—типа задачи—роли—возможного перехода. Определяет кто, в каком состоянии(задачи(:), какой тип задачи в какой статус может переводить. Например: Заводить задачи может лишь «менеджер» и «представитель клиента», при чём «представитель клиента» лишь задачи типа «ошибка». Окончательно закрывать задачи может лишь «тестировщик» и т.д.
• Мультипроектность. В отличие от популярного Trac, Redmine «из коробки» поддерживает мультипроектность. Кроме этого проекты могут быть вложенными. Сценарий использования, например, следующий: Проект «Название компании CRM» — проект для продукта и внедрений CRM системы. Вложенные проекты «Внедрение CRM в „Рогах“», «Внедрение CRM в „Копытах“».
• Ролевая система прав. Роли, кроме участия в воркфлоу, могут иметь различные права в системе. Настраивается растановкой нескольких десятков галочек. Redmine может использоваться и как внешний портал для клиентов — нужно лишь настроить роль «Клиент».
• Настраиваемый список задач. Безусловно, главное окно системы для менеджера — список задач. Он обеспечивает:
  
  • Настройку списка колонок по умолчанию (не нужна колонка — сняли галочку и её не видно).
  • Сортировку по колонкам
  • Фильтрацию. Фильтрация возможна по нескольким полям, например: «Ошибки 0го приоритета, назначенные на Василия Пупкина, относящиеся к модулю „Аутентификация и права доступа“ в статусах „Передана в тестирование“ или „Закрыта“». Созданные фильтры можно сохранить для себя (чтобы не настраивать лишний раз) или для всех участников проекта для быстрого доступа. Например — «открытые задачи 0го приоритета».
• Уведомления по RSS или E-mail
  • Каждый список (в том числе фильтрованный) можно получать в виде CSV, PDF, RSS. Сценарий, например такой: Тестировщик создаёт себе фильтр «Задачи в статусе „Отправлено в тестирование“, подписывается на RSS» и всё — новые задачи будут ему падать автоматически, никаких тебе сложных или суррогатных вещей — получай новые и тестируй.
  • Уведомления по email. При изменении задач, оценки, добавления коментариев и т.д. система спамит в почту пользователям, которых это касается. Разработчикам не придётся писать «Я закрыл задачу». За него это напишет Redmine.
  
  
• Интеграция с SCM (Системами управления кодом) — SVN, CVS, Git, Mercurial, Bazaar и Darcs
  • Настройка хранилища для каждого проекта.
  • Веб-интерфейс просмотра хранилища. Система создаёт веб-интерфейс для просмотра хранилища кода, истории изменений как в виде коммитов, так и для файлов, способна сравнивать версии (для небинарных файлов) и показывать diff'ы.
  • Отслеживание коммитов. Указав в комментарии к коммиту «id 333» (шаблон настраивается), разработчик может автоматически привязать коммит к задаче. При просмотре коммита можно будет перейти на описание задачи, а в карточке задачи будет отображаться список коммитов.
  • Автоматический переход в «закрытый» статус при коммите. Если же разработчик напишет «fixed 333» (шаблон настраивается) то коммит не просто привяжется к задаче, но и переведёт задачу в нужные статус — например в «Передано в тестирование» — ему не нужно будет лезть в Redmine.
• Задачи. На карточке задачи кроме описанного выше отображаются история обсуждений (которые можно получать в виде RSS), списки связанных ревизий, история изменений версий, оценки и др. параметров.
• CSS. Отдельного внимания заслуживает CSS-стили. Система поддерживает темы оформления (Они же скины), которые задаются с помощью CSS. Внутри CSS применён вполне здраво, я пока не нашёл того объекта, чьего оформления нельзя было бы сменить с помощью CSS. Изменения в нашем скине касаются в основном списка задач (это основное окно менеджера проектов. Сделано: Цветовая индикация статусов (Заблокирована — красный, тестируется — зелёный, закрыта — серый). Цветовая и яркостная индикация приоритетов — (0—самый яркий, 1—менее яркий, все после 2го — одинаковые). Увеличен шрифт в полях ввода описания задач — там удобней (:
• Система плагинов. Redmine имеет систему плагинов, которые можно писать самостоятельно. Сейчас имеется 10 плагинов, хотя буквально месяц назад было 3 или 4.
• Неплохой поиск
• Формирование Roadmap. Показывается общая статистика, и имеется подробная страница для каждой версии.
• Сводка по проекту. В сводке отображается общая обзорная статистика решения задач в проекте.
• Персональная (персонализируемая) страница. На персональной странице отображаются назначенные задачи и некоторые другие блоки, которые пожелает видеть сотрудник: календарь, затраты времени, документы, новости, отслеживаемые задачи.

Другие полезные вещи, которые у нас не используются (Пока)

— Интеграция с Mylyn. Mylyn — плагин для Eclipse IDE, забирающий задачи разработчика из трекера и показывающий их прямо в IDE. Интеграция — громко сказано, но есть инструкции как их подружить вместе.
— Новости — позволяют публиковать проектные новости, которые можно получать в виде RSS. Например — чтобы автоматически публиковать их на внешнем сайте компании в разделе продукта.
— Проектные вики — для ведения всего, что может быть полезно — документации, реквизитов доступа, и т.д. В trunk—версии вики существенно лучше, чем в последнем 0.7.3 релизе — есть иерархия страниц, «хлебные крошки» в навигации и т.д. Планирую перетащить с MoinMoin вики, которая используется сейчас, на в Redmine — всё в одном месте — лучше.
— Интеграция с LDAP. Redmine поддерживает интеграцию с контроллером домена по протоколу LDAP.
— Форумы. В рамках проектов для обсуждений можно создать форумы (вполне стандартная функциональность: обсуждения с уведомлениями на e-mail, RSS, подписка на разделы, темы). В trunk-версии вроде бы можно отвечать на уведомления и ответы будут размещены на форуме — можно сделать некий аналог рассылок.
— Документы. Имеется хранилище документов — список html-файлов по авторам. Что-то типа плейн-списка вики-статей
— Файлы. Хранилище файлов, отнесённых к версии продукта. Показывается список, и число загрузок — может использоваться для хранения выкаченных версий продуктов.
— Самостоятельная регистрация пользователей. Redmine используется внутри компании, поэтому саморегистрация не имеет смысла.
— Активность. Лента, в которую публикуются изменения задач, коммиты, и т.д.
— Журнал изменений (Changelog). Некоторые типы задач (например «Функции» и «Ошибки») можно отметить как «заносимые в журнал изменений, changelog будет сформирован автоматически.
— Автоматическое построение календаря и диаграммы Ганта.
— Аватары пользователей из сервиса Gravatar

Чего не хватает

Есть мелочи, которых не хватает и которые понятно как сделать, но руби-программистов у нас нет. Даже, с учётом того, что эти хотелки — около 20 строк кода :)
— Есть желание, чтобы параметр «готовность» вычислялся автоматически исходя из оцененного и затраченного времени — очень лениво его заполнять руками.
— Хочется более удобной формы комментариев к задаче — просто отдельной ссылкой, не через «обновить задачу»

Более сложные вещи — хочется также:
— Тонкую настройку уведомлений — сейчас система достаточно некисло спамит — уведомляет обо всех изменениях задач (комментарии, оценка, и прочее). Хотелось бы видеть настройку категорий спама.
— Интеграции форумов с почтой достаточной, чтобы можно было отказаться от списков рассылок.
— Профилей пользователей в рамках системы — чтобы там отображались отчёты по затраченному времени не в рамках проекта, а по всем, назначенные задачи (опять же по всем проектам) и прочее.

Минусы Redmine

Достаточно небольшое (по сравнению с тем же Trac) коммьюнити. Соответственно небольшое число плагинов (hack в терминологии Trac).
Один (в основном) разработчик — из-за этого сравнительно низкая скорость развития (лично для нас это не очень важно, потому как наши потребности покрыты процентов на 90).

Первая (и все последующие дозы) — бесплатно.

Специально для Хабра.