DOU Labs: как Evergreen экономит время менеджеров с помощью плагина к Redmine

В рубрике DOU Labs мы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на [email protected].

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

Идея

Идея плагина возникла, когда на задачах технической поддержки мы в Evergreen постоянно сталкивались с тем, что оценку должны давать несколько специалистов — например, дизайнер, front-end разработчик и back-end разработчик, и в процессе выполнения задачи и поступления дополнительных пожеланий от заказчика возникает необходимость в дооценке. А дальше при согласовании месячного отчета начинают возникать вопросы, почему задача, оцененная в 2 часа, по факту заняла 10 часов, и эти проблемы мы можем увидеть только в конце месяца.

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

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

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

В итоге всё свелось к тому, что до разработки Redmine Estimates мы просто вели всё в комментариях, примерно так, и это было крайне неудобно:

Реализация

Как ставили задачу по разработке Redmine плагина для согласования оценки:

  • Оценка теперь, как и затраченное время, дробится на разные виды деятельности. Общее поле «оценка» считается как сумма оценок по всем видам деятельности.
  • На странице редактирования оценки список несогласованных позиций оценки:
  • Когда мы обновляем задачу или нажимаем «добавить оценку», открывается форма редактирования задачи, в ней добавляется графа согласования оценки.
  • Оценки хранятся в базе в отдельной таблице аналогично time_entries (встроенная сущность «Затраченное время» в Redmine).
  • При любом обновлении оценок поле «оценка» задачи обновляется как сумма всех оценок, привязанных к этой задаче. Как обновлять — при сохранении, при открытии или как-то еще — вопрос к размышлению.
  • Кнопка «Согласовать» в таблице оценок доступна только определенным ролям (менеджер, клиент). Идеальная реализация — сделать в rm отдельное право доступа, чтобы можно было его выставлять в управлении ролями.
  • Когда происходит согласование оценки, должно быть видно, кто и когда её согласовал.
  • Подтвержденные записи удалять и редактировать не может никто (кроме администратора)!
  • После подтверждения даем 1 минуту, в течение которой можно опять нажать кнопку и подтверждение пропадёт, после 1 минуты или если перезагрузил страницу — всё, отменить подтверждение нельзя.
  • Если есть несогласованная оценка возле поля оценка появляется иконка warning и надпись «есть несогласованная оценка». Это поле должно быть доступно для фильтра в списке задач.
  • Редактировать и удалять записи согласования оценки (неподтвержденные) могут:
    • тот, кто её сделал;
    • администраторы;
    • сделать в Redmine отдельное право доступа, чтобы можно было его выставлять в управлении ролями.

Задача почти год лежала на полке, ожидая своего часа, но, наконец, в июле 2016 года, мы поручили разработку нашему R&D Developer’у. Опыта в разработке под Redmine у нас было мало, у разработчика опыта в Ruby не было вообще.

Не буду долго описывать, как это реализовывалось, мы, похоже, собрали все шишки, какие было можно собрать на этом пути. Но мы это сделали! Плагин назвали Redmine Estimates. Кому интересно, что мы собрали, читайте ниже, кому интересно, что может готовый результат — смело пролистывайте на следующий раздел.

Ключевой сложностью в разработке плагинов для Redmine является достаточно низкое качество документации по коду самого Redmine.

Например, буквально со старта мы столкнулись с тем, что банально не могли поднять окружение. Делали все по www.redmine.org/...​dmine/wiki/RedmineInstall. Сначала установили ruby 2.1, долго не хотел устанавливаться DevKit для этого же руби. При установке зависимостей из gem файла не компилился gem json и redcarpet. Перелопатили кучу stackoverflow, ничего не помогало. Потом установили ruby 2.3, DevKit поставился, все зависимости подтянулись и все гемы скомпилились, но после запуска команды bundle exec rake generate_secret_token, которая указана в документации, вылезла ошибка и опять же пришлось искать ответ на stackoverflow. В общем и целом для того, чтобы поднять окружение, пробовали и Bitnami Redmine Stack 2.6.10, и просто самостоятельно на отдельном сервере. С помощью молотка, зубила и путем дикого перебора таки подняли и начали разработку.

На этом приколы не закончились. Настроили роут `localhost/issues/:id/s/:id/time_entries_estimates`. C добавлением отдельного контроллера возникла проблема с авторизацией. Здесь нужно добавить permissions, но, когда добавляешь, пишет 404. Создали шаблон плагина через bundle exec ruby script/rails generate redmine_plugin, но не получается настроить вывод стектрейса в браузер, то, что пишут на stackoverflow, не помогло. Сломали развернутый редмайн. Откатили все коммиты, но он не ожил, и отдебажить никак не получается. Просто 500 отдадет и пишет стандартное редмайновское собщение об ошибке. Развернули новый redmine с продакшн средой.

Расковыряли код неслабо, выяснилось, что так просто под копирку сделать модель и контроллер никак не получится. В редмайне плохо реализована MVC модель, контроллер зависит не только от кучи других классов, имеет много примесей (mix-ins те, что подключаются через include). В хелперах тоже куча зависимостей от других моделей.

В общем примерно через неделю только от начала этого процесса мы более-менее разобрались, как оно всё завязано и работает, всю необходимую помощь по-прежнему получали на stackoverflow. Дальше пошло всё довольно гладко.

Что Redmine Estimates умеет сейчас

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

Подтвержденные оценки по умолчанию скрываются, но можно посмотреть все оценки, если нажать «Показать подтвержденные оценки»:

Право на подтверждение оценки, редактирование записей оценки выставляется отдельным полем в разделе «Администрирование»:

Если у пользователя не установлено право на редактирование оценки, у него есть 1 минута для того, чтобы изменить оценку, если он ошибся. Если в течение этого времени он не отредактирует оценку — больше возможности отредактировать оценку у него не будет.

В общем списке задач можно вывести поля «Всего часов оценок» и «Всего подтверждено оценок» и использовать их как фильтры:

Планы на ближайшее будущее

В ближайшем будущем планируем доделать то, что не готово в текущем релизе:

  • уведомления о подтверждении оценки и соответствующая запись в Journal;
  • запрет на редактирование подтвержденных оценок;
  • признак «Есть неподтвержденные оценки» и соответствующая иконка warning;
  • вычистить код от упоминаний time_entries, на базе которых мы делали плагин.

Где скачать плагин и как установить?

Ссылка на репозиторий GitHub: github.com/...​nmikhno/redmine_estimates

Инструкция по установке там же. Полностью Open Source, таким и останется. Разработан и используется у нас в Evergreen для Redmine 2.1, портирован на 3.0, желающие портировать на другие версии Redmine и поучаствовать в разработке и доработке на свободных началах приветствуются.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



27 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

А что за плагин таймера на скриншотах?

Самоделка, написан на jquery за пару часов.

Не поделитесь?
Сейчас используем github.com/…​ware/redmine_time_tracker, но для сревнения глянуть бы

Ловите, но оно не оформлено плагином, там немного повозиться надо. В плагин мы его так и не релизнули github.com/…​evergreen-it-dev/rm-timer

Ну покопаемся, может под себя переделаем) Спасибо большое!

Опытный проджект умеет вычислять коэффициент, на который следует умножить сумму полученных от членов команды эстимейтов, в зависимости от проекта и команды :)

Работая с Redmine лет 6, назвал бы основные недостатки:
1. Из-за указанного в статье автором низкого качества документации войти в Redmine или передать кому-то является сложной задачей.
2. Сразу после развертывания начинается кастомизация, которая требует еще больших знаний: так на одном из проектов классические моменты, которые в 80-90% (у меня) повторяются — интеграция с Active Directory, on the fly создание пользователей, шаблонизатор задач, не очень удобная работа с временем и отчетами.
3. Redmine тяжело поддерживать — новые версии выходят относительно быстро и при поиске решений начинается путаница в версиях. В то же время нет устоявшегося стека развертывания: по клику его не развернуть. У кого Ruby из пакетов вместо rvm, у кого apache, а не nginx, добавив сюда fcgi-unicorn-passenger кашу, у кого Postresql, у кого MySQL (5.5, 5.6, 5.7, MariaDB, Percona)... При обновлениях иногда выкидывает «сюрпризы».
4. Без базового понимания Ruby и как это работает я бы не советовал вообще смотреть в сторону Redmine. Часто требует оптимизации и напильника на уровне патчей исходного кода.
5. Относительно вялая работа автора по фичам и некоторые баги часто висят достаточно долго.
6. Ну и интерфейс уже несколько устарел, и также сложно кастомизируется (в сравнении с Джирой).
7. Качество плагинов, а без них никуда и голый Redmine никому не интересен, оставляет желать лучшего. Особенно поддержка новых версий хромает.

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

В качестве альтернативы для небольшой команды можно использовать Youtrack (вроде как до 10 пользователей бесплатно).

Выходом мог бы стать Docker-конструктор (и он есть) для развертывания Redmine, но там появятся свои пляски по кастомизации — нельзя всю кастомизацию запихать в 1 yml файл к примеру. А очень бы этого хотелось.

PS: Вышел какой-то негативный отзыв, но на самом деле продукт интересный, интегрируется с чем угодно, и радует что продолжает развиваться.

Docker-контейнеров для редмайна даже несколько уже. Мы еще не пробовали, но попробуем что получится. А зачем всю кастомизацию в 1 yml ложить? в чем удобство?

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

Ого, кто-то еще использует redmine.

За зарплату людей які його підтримують (і вартість сервера) можна купити Jira і не мати проблем.

Автори статті мені нагадують картинку про тролейбус з буханки.
Замість того, щоб роботу робити, роблять інструменти.

а с ним и нет проблем, для большинства людей отличие только в самом названии, теми фичами жиры что в редмайне нет мало кто пользуется, а основной функционал не отличается

Для мене будь-який софт який знаходиться не в хмарі — це проблема з його налаштуванням та підтримкою. Радий за компанії які можуть собі дозволити тримати людей та залізо — значить в них є лишні гроші.

ну засунь в хмару редмайн, если это решит тебе проблемы

Під хмарою я мав наувазі не вірутальні сервери, а SaaS продукти.

если это решит тебе проблемы
В мене проблем немає, в мене джира за 10$ на місяць.
А от у тих хто сам хостить редмайн — проблеми з його налаштуванням, підтримкою і от, ще, плагінописанням.

Владимир, а теперь посчитайте сколько будет стоить вам Жира если в ней будет 97 пользователей :) Вот и экономическое обоснование написать плагин.

$450 на місяць, ви на офісні ніштяки менше витрачаєте.

Скільки ви платите розробникам плагінів та адмінам які підтримують це?

Админ поддерживает несколько наших серверов, какой-то ежемесячной поддержки Redmine не требует — один раз настроил и всё. Админ занят другими проектами. Разработчиков плагинов в штате нет, один раз написали это как проект, потратили не очень много. Поддержки ежемесячной тоже не надо.

А обновления? А maintenance? А тюнинг?
У нас Redmine (был на позапозапрошлой работе :) ) на несколько сотен пользователей (3 тяжеловастых проекта), не скажу, что особо много времени забирал, но тюнинг и обслуживание требовал.

У нас с этим по-проще. Обновления мы делаем довольно редко, тюнинг и поддержка есть, но не очень много занимает в общем масштабе.

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

и вот редмайн или джира вообще без разницы в таком случае

и вот редмайн или джира вообще без разницы в таком случае
Звичайно, так.

Да, Jira на своем хосте дешевле для больших команд.

Достаточно примеров миграции как в Cloud/SaaS так и наоборот на Bare metal/Private Cloud и всякий on-premise. Я бы не был столь категоричен. Все зависит от задачи и конкретного проекта/команды.
Ну и набирает ход Docker и ко — там пофиг где контейнеры крутятся. Часто используется гибрид из нескольких облачных провайдеров дабы избежать своеобразного вендорлока и быть поджарым и готовым к любой миграции в любую минуту.

Я говорю не про свій софт/продукт (те що компанія робить) а про всілякі операційні штуки — пошту, багтрекер, сорц контроль, моніторинг, логування і тд.

Здесь наверное все зависит от политики компании — сами с усами или все, что не относится к продукту приобретается и саппортится не командой.

Підписатись на коментарі