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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Будущих планы

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

Answer 6

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

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

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

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

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

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

Вещи, которые я хотел бы быть в состоянии сделать:

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

Answer 7

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. Связывание вопросов с конкретными версиями - это находка.
• У нас также есть отличия между клиентом и сервером, но используйте целевую версию, чтобы связать билеты, чтобы указать, куда отправляется (и имеет открытый конец СЛЕДУЮЩИЙ РЕЛИЗ КЛИЕНТА/СЛЕДУЮЩИЙ СЕРЕБР РЕЛИЗ), чтобы различать время работы.
• Мы смешиваем метафоры для статусов - мы используем наши списки, сначала сгруппированные по этим («Немедленные», «Отклоненные», «Заблокированные», «Рабочие», «На палубе», «Список», «Ожидание сборки», «Отключено для тестирования», «Проверено», «Выпущено в производство», «Закрыто», «Отменено».
• Затем, в каждой группе выше, мы имеем этот отсортированный список Приоритетов: («Немедленное», «Приоритеть меня») , «Design And Size Me», «P1» ... «P5», «P-Watch List»). Это плюс вышесказанное позволяет легко обрабатывать все из области проблем.
• Для основного списка проблем мы сортируем по «Приоритету», «Родительская задача», затем «Обновленная дата» - нужно, чтобы средний, так что Redmine отлично отлаживает необходимость в дочерней задаче в той же группе.
• Мы используйте checkin для привязки к ошибкам (например, svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - и переместите этот вопрос на «Waiting For Build» («Раньше было решено», но я устал объяснять, что «Решено» не означает, что кто-то может ожидаем увидеть его выпущенным).

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

Answer 8

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

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

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

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

Answer 9

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

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

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

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

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

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

Answer 10

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

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

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

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

Answer 11

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

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