Лучшие практики Redmine

Мы используем раздел «Дорожная карта» как наглядный способ отображения:

• ошибки
• функции (это будут ссылки на ваш текстовый документ или ссылки на страницы требований html)
• сверки (различия между производственными значениями и тестовыми значениями)
• и так далее...

Это для нас главный пункт консолидации. Остальное используется в связи с этим (например, раздел «анонс» используется для определения основных этапов / дат выпуска, используемых в дорожной карте)

Я внештатный веб-разработчик Ruby и Redmine, у которого один (я) бизнес по разработке. Итак, мой Redmine настроен так, чтобы быть довольно легким и ориентированным на клиента. My Redmine также выполняет двойную функцию по размещению моих проектов с открытым исходным кодом.

Я разрешаю отправлять по электронной почте новые проблемы и обновления, и это отлично работает для пользователей, подключенных к электронной почте (или тех, кто всегда использует свои iPhone).

Я использовал представление репозитория с репозиториями git, и оно отлично работает. При каждой проверке я ссылаюсь на проблему с помощью #nnn, поэтому на странице фактической проблемы будут отображаться все коммиты для реализации этой функции.

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

Мы сочли полезными следующие практики:

1) Скройте трекер «Проблема» и «Поддержка» и файл все как ошибка:

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

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

3) функция «сохранить» на вкладке «проблемы»: еще одна большая экономия времени, у меня есть разные запросы, сохраненные для многих повседневных задач отчетности, и это все, что мне нужно.

4) интеграция управления версиями, т.е. использование "# 123" в комментариях создает ссылку на соответствующую проблему: просто умно!

В дополнение к другим комментариям я рекомендую использовать плагин "Stuff To Do" (я думаю, написанный Эриком Дэвисом :) Использование этого плагина позволяет вам отсортировать порядок проблем в нескольких проектах с помощью перетаскивания.

https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do

Я разрабатываю и поддерживаю внутренние приложения для семьи производственных компаний. На момент написания этого комментария я единственный разработчик / аналитик в ИТ-команде. Во время наихудшего периода спада мои требования к проекту резко возросли. Таким образом, мой проект И список проблем довольно громоздок. В настоящее время мы находимся в процессе реструктуризации с целью расширения команды.

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

• Я использую Subversion для управления версиями с TortoiseSVN и метко названным Плагин Tortoise-Redmine. Обновление репозитория в проекте Redmine после фиксации связывает проблему, которая показывает версию проблемы и обновляет мои заинтересованные стороны через уведомление по электронной почте.
• Я рассматриваю описание проекта как средство сообщения о цели, объеме и стадии жизненного цикла проекта тем, кто не участвует в нем. Таким образом, мои пользователи будут знать, что у меня на тарелке, а что еще в буфете, на что я смотрю издалека.
• Я использую определенные имена ролей для своих наборов разрешений, которые указывают не только на набор разрешений - опять же, как средство документации. В мои роли входят следующие: менеджер проекта, член команды проекта, владелец, основной пользователь, дополнительный пользователь, наблюдатель, Повелитель (для моих боссов ... и весело, и, несомненно, правильно).
• Я использую Wiki и Documents для документации, в зависимости от того, что я считаю подходящим.
• Версии для меня в значительной степени бесполезны, поэтому вместо того, чтобы использовать их для запланированных выпусков, я использую их для группировки связанных проблем в спринты.
• Я использую великолепный плагин Эрика Дэвиса Stuff-To-Do для организации / реорганизации вышеупомянутых спринтов перед массовым редактированием целевых версий по моим проблемам. Это также позволяет моим заинтересованным сторонам узнать, над чем я работаю и как я расставил приоритеты для их интересов (лучше или хуже).
• Чтобы стимулировать взаимодействие с пользователем, я добавил ссылки на проект Redmine в меню справки своих приложений. Поле «О программе» также содержит ссылку на проект Redmine.

Планы на будущее

• Я надеюсь, что в какой-то момент доработаю расширение Visual Studio для интеграции Redmine.
• Создайте библиотеку кода, чтобы свободно связать мое приложение с его проектом Redmine: автоматизировать отправку ошибок, предупреждать подписавшихся заинтересованных лиц из панели задач, многоразовое интерактивное меню справки, управляемое REST API Redmine, и т. д. (Может быть, автоматизировать части документации с помощью Wiki?)

Мы широко используем Redmine в нашей системе. Мы даже создали проект «Продажи», чтобы наша команда продаж использовала его в качестве CRM. У нас есть куча настраиваемых полей в этом проекте, и он заменяет SugarCRM, который мы использовали раньше.

В нашей системе есть проекты для Серверного и Клиентского ПО. Серверный проект разбит на подмодули в зависимости от того, как я структурировал систему и под-репозитории, поскольку Redmine любит отдельные репозитории для каждого проекта.

Мы используем, как отмечают другие, коды #nnn в сообщениях фиксации для ссылки на тикеты. Что круто, так это то, что это не обязательно билет в один и тот же проект. Таким образом, продажа билетов может быть заблокирована из-за ошибки или запроса в службу поддержки.

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

Пытаться использовать плагин Redmine Time Tracker для отслеживания времени, но я всегда забываю нажать начало или конец. Мы ежедневно получаем электронные письма о проблемах, которые давно не затрагивались (я думаю, Redmine Whining), и которые должны быть выполнены в прошлом или ближайшем будущем (Advanced Reminder).

Электронные письма поддержки поступают непосредственно в наш проект поддержки, и если бы импорт электронной почты был немного более надежным (иногда он не создает новые заявки должным образом, если строка Project: включена в электронное письмо), у нас будут запросы веб-сайтов, автоматически генерирующие билеты продаж . Как бы то ни было, нам просто нужно отслеживать заявки в службу поддержки и перемещать их в отдел продаж, если это применимо.

Что я хотел бы делать:

• Установите отношения между нашей системой и Redmine, чтобы билеты можно было связать с пользователем или компанией в нашей системе. Кроме того, чтобы мы могли создать новую компанию из заявки на продажу в соответствующей точке. Это просто требует, чтобы я немного поработал.
• Установите связь между нашим программным обеспечением для отслеживания ошибок (sentry) и redmine, чтобы ошибки сервера генерировали билет redmine. Опять же, можно решить с помощью современных технологий.
• Имейте настольный клиент для редмайна. Сервер находится в нашей локальной сети, но было бы здорово иметь более гибкий способ доступа к данным, кроме веб-страницы. Дело не в том, что в веб-интерфейсе redmine есть что-то, что я не могу сделать, но что-то вроде Things.app намного приятнее для работы с так.
• Вся наша вспомогательная документация находится в Redmine, а затем сгенерирована на общедоступном сервере. Таким образом, наша служба поддержки может поддерживать документацию, красиво редактировать и размещать изменения на сервере документации.

Redmine до сих пор оставался для нас фантастическим. Мы используем его в качестве очереди для мультитенантной продажи билетов / гибкой приоритизации, а также привязали его к SVN. В частности:

• Установка / обслуживание через SVN была легкой задачей (я перевел нас с 1.1 на 1.2 на 1.3 на 1.4 с помощью команд svn switch https//.../branches/1.3-stable ., за которыми следуют команды rake migrate, между которыми требовалась лишь случайная установка гемов).
• Резервное копирование базы данных и сохраненных файлов - это выполнение однострочного скрипта.
• Нам нравятся плагины Счетчик времени и Проводить время. Я бы убил за толстый клиент отслеживания времени Mac OS X для некоторых из наших офисных пользователей, но это не относится к делу :)
• Мы не часто используем форумы, но активно используем Activity и Roadmap. Привязка проблем к конкретным версиям - находка.
• У нас также есть различия между клиентом и сервером, но мы используем целевую версию, чтобы связать билеты, чтобы указать, какой из них куда идет (и иметь открытый выпуск NEXT CLIENT RELEASE / NEXT SERVER RELEASE), чтобы различать между ними во время работы.
• Мы смешиваем метафоры для статусов - мы используем наши списки, сначала сгруппированные по ним («Немедленно», «Отклонено», «Заблокировано», «Работает», «На палубе», «Список», «Ожидает сборки», «Выпущено для тестирования. »,« Проверено »,« Выпущено в производство »,« Закрыто »,« Отменено »).
• Затем в каждой группе выше у нас есть отсортированный список приоритетов: («Немедленно», «Сделать меня приоритетом», «Разработать и определить меня», «P1»… «P5», «P-Watch List»). Это плюс вышесказанное позволяет упростить рабочий процесс из области проблем.
• Для списка основных проблем мы сортируем по «Приоритету», «Родительской задаче», затем «Дате обновления» - нужна средняя, ​​чтобы Redmine хорошо отступал, если в той же группе есть дочерняя задача.
• Мы используем коммиты с проверкой, чтобы связать коммиты с проблемами (например, svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - и заставить его переместить эту проблему в «Ожидание сборки» (раньше это было «Решено», но я устал объяснять, что «Решено» не означает кого-то можно ожидать, что он будет выпущен еще).

Я думаю, мне придется исследовать плагин Redmine-stuff-to-do. +1 Вопрос.

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

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

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

Мы исчерпывающе используем вики для документации для разработчиков.

Моя компания работает с разработчиками программного и аппаратного обеспечения из разных стран. До того, как я присоединился к компании, электронная почта использовалась с документами MS Word, чтобы сообщить о наших проблемах и ошибках в программном или аппаратном обеспечении и запросить исправление. Этот процесс невозможно было отслеживать и поддерживать каким-либо процессом. Я внедрил RedMine как средство отслеживания ошибок программного и аппаратного обеспечения, и с тех пор он работает очень хорошо. В моей ситуации существует серьезный языковой барьер. К счастью, RedMine может отображаться на Sipmlified китайском языке, и отзывы показали, что пока это нормально с моими разработчиками.

Статус - Когда я нахожу проблему с программным или аппаратным обеспечением, я получаю статус «Новый». - Когда мои разработчики программного и аппаратного обеспечения увидели эту проблему и начали работать над ней, они меняют статус на «Выполняется». Они могут использовать% done, если они хотят, от 0 до 50. Я прошу их установить% Done на 50, когда они почувствуют, что решили проблему. - Я определяю, устранена ли проблема, и меняю Статус на «Решено», а% готово - на 100%. Это позволяет мне отфильтровать проблемы <или равные 50%, чтобы найти проблемы, которые все еще открыты.

Приоритет - Низкий, Нормальный, Высокий, Срочно, Немедленно - все хорошо переводится на китайский язык.

Срок - Я использую это, чтобы сказать мне, когда исправление было изначально загружено моими разработчиками программного обеспечения. На то, чтобы что-то протестировать и закрыть проблему, у меня может уйти 4-6 дней. Мне нравится, что моя диаграмма Ганта отражает оперативность моей команды разработчиков программного обеспечения, а не то, сколько времени мне потребовалось, чтобы утвердить исправление.

Категория - Это всегда отражает версию программного или аппаратного обеспечения, в которой я обнаружил проблему. Я использую это, чтобы увидеть, в какой версии программного обеспечения было больше всего ошибок, и чтобы убедиться, что новые версии программного обеспечения не подвержены регрессу.

У меня все включены в список наблюдателей RedMine за всеми ошибками. Электронное письмо обозначается как (Новое), (Решенное) или (В процессе), поэтому мои руководители, а также руководители и главные инженеры задействованных команд могут все видеть электронное письмо и быстро читать, какой прогресс в настоящее время делается. Большинство других людей никогда не заходят в RedMine, обычно я единственный. Электронные письма идеально подходят для мгновенного получения обновлений для всех, кого беспокоит только прогресс или нет.

Как вы упомянули, отправка документов Word назад и вперед с вашим QA - я знаю это чувство, был там, сделал это. Основная проблема для меня заключалась в том, что QA-люди не любят добавлять проблемы в какой-либо трекер ошибок, они записывают их в редакторе рядом с ними во время тестирования.

Сейчас мы используем Redmine с красивым дополнением - Usersnap (отказ от ответственности: мы создали инструмент, чтобы решить эту проблему для себя.

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

Теперь наши QA / клиенты могут вводить сообщения об ошибках прямо в веб-приложении, а разработчикам становится проще воспроизводить отчеты об ошибках в Redmine.

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

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