Рекомендации Redmine

Ответ 1

Я независимый веб-разработчик Ruby и Redmine, который управляет бизнесом разработки одного (меня). Таким образом, моя Redmine настроена на легкий и ориентированный на клиента. Мой Redmine также выполняет двойной долг для размещения моих проектов с открытым исходным кодом.

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

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

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

Ответ 2

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

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

• Я использую Subversion для управления версиями, с TortoiseSVN и метко названным плагин Tortoise-Redmine. Обновление репозитория в проекте Redmine после фиксации связывает проблему, которая показывает версию проблемы, и обновляет мои заинтересованные стороны посредством уведомления по электронной почте.
• Я рассматриваю описание проекта как средство передачи цели проекта, сферы действия и этапа жизненного цикла тем, кто не участвует. Таким образом, мои пользователи знают, что у меня на моей тарелке, и то, что еще на буфете, которое я просматриваю издалека.
• Я использую имена определенных ролей для своих наборов разрешений, которые указывают больше, чем набор разрешений - опять же, как средство документации. Мои роли включают в себя следующее: Менеджер проекта, Project Team Участник, владелец, основной пользователь, вторичный пользователь, наблюдатель, Overlord (для моих боссов... так весело и, несомненно, правильно).
• Я использую Wiki и документы для документации, в зависимости от того, что, по моему мнению, подходит.
• Версии для меня практически бесполезны, поэтому вместо использования для запланированных релизов я использую его для группировки связанных проблем в спринты.
• Я использую Eric Davis невероятный плагин Stuff-To-Do для организации/реорганизации вышеупомянутых спринтов перед массовым редактированием целевых версий по моим проблемам. Это также позволяет моим заинтересованным сторонам знать, над чем я работаю, и как я уделял приоритетное внимание их интересам (к лучшему или к худшему).
• Чтобы стимулировать взаимодействие с пользователем, я добавил ссылки на проект Redmine в меню справки моих приложений. В поле "О программе" также содержится ссылка на проект Redmine.

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

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

Ответ 3

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

1) Скрыть треки "Issue" и "Support" и записать все как ошибку:

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

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

3) "сохранить" на вкладке "проблемы": еще одна важная экономия времени. У меня разные запросы, которые сохраняются для многих ежедневных задач отчетности и все, что мне нужно.

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

Ответ 4

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

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

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

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

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

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

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

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

Ответ 5

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

• Установка/поддержка через SVN была легкой (я перенесла нас с 1.1 на 1.2 до 1.3 на 1.4 с помощью команд svn switch https//.../branches/1.3-stable ., за которыми следуют команды rake migrate, только с использованием отдельных случайных установок).
• Резервные копии базы данных и сохраненных файлов - это однострочное выполнение script
• Мы любим Time Tracker и потраченное время плагины. Я бы убил для Mac OS X для отслеживания толстого клиента для некоторых наших пользователей, но это не так:)
• Мы не используем форумы много, но активно используем Activity и Roadmap. Связывание проблем с конкретными версиями - это находка.
• У нас также есть отличия между клиентом и сервером, но используйте целевую версию, чтобы связать билеты, чтобы указать, куда отправляется (и имеет открытый конец СЛЕДУЮЩИЙ РЕЛИЗ КЛИЕНТА/СЛЕДУЮЩИЙ СЕРЕБР РЕЛИЗ), чтобы различать время работы.
• Мы смешиваем метафоры для статусов - мы используем наши списки, сначала сгруппированные по этим ( "Немедленные", "Отклоненные", "Заблокированные", "Рабочие", "На палубе", "Список", "Ожидание сборки", "Выпущено для тестирования", "Проверено", "Выпущено в производство", "Закрыто", "Отменено".
• Затем в каждой группе выше мы имеем этот отсортированный список Приоритетов: ( "Немедленный", "Приоритеть меня", "Дизайн и размер меня", "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 Вопрос.

Ответ 6

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

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

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

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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