Лучшие практики Redmine [закрыто]

Какие советы и «стандарты» вы используете в процессе управления проектами Redmine?

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

Вы разрешаете отправку проблем и обновлений в Redmine по электронной почте? Вы пользуетесь форумами? Вы используете репозиторий SVN? Вы используете Mylyn в eclipse для работы со списками задач?

Я пытаюсь утащить наш отдел. в какой-то веб-личный кабинет вместо отправленных по электронной почте документов Word с расплывчатыми требованиями, за которыми следуют документы Word, объясняющие, как QA и Deploy, которые все теряются в куче конкурирующих обновлений и проектов, так что к тому времени, когда мне нужно что-то исправить, никто не сможет найти любая документация о том, как это работает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы широко используем 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требуется лишь случайная установка гемов).
• Резервное копирование базы данных и сохраненных файлов - это выполнение однострочного скрипта.
• Нам нравятся плагины Time Tracker и Spent Time . Я бы убил за толстый клиент отслеживания времени 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 Вопрос.

Моя компания работает с разработчиками программного и аппаратного обеспечения из разных стран. До того, как я пришел в компанию, электронная почта использовалась с документами 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.

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

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

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

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

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

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

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

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

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

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

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