Какие советы и «стандарты» вы используете в процессе управления проектами Redmine?
У вас есть стандартный шаблон вставки вики, которым вы могли бы поделиться, или стандартный способ работы над проектом с использованием задач по устранению ошибок и проблем с поддержкой?
Вы разрешаете отправку проблем и обновлений в Redmine по электронной почте? Вы пользуетесь форумами? Вы используете репозиторий SVN? Вы используете Mylyn в eclipse для работы со списками задач?
Я пытаюсь утащить наш отдел. в какой-то веб-личный кабинет вместо отправленных по электронной почте документов Word с расплывчатыми требованиями, за которыми следуют документы Word, объясняющие, как QA и Deploy, которые все теряются в куче конкурирующих обновлений и проектов, так что к тому времени, когда мне нужно что-то исправить, никто не сможет найти любая документация о том, как это работает.
источник
Мы нашли полезными следующие практики:
1) Скройте трекер «Проблема» и «Поддержка» и запишите все как ошибку :
2) этапы и версии. Мне это нравится, вы можете легко отслеживать статус каждого выпуска и в любое время загрузить более старый пакет, то есть проверить ошибку, обнаруженную клиентом.
3) функция «сохранить» на вкладке «проблемы»: еще одна большая экономия времени, у меня есть разные запросы, сохраненные для многих повседневных задач отчетности, и это все, что мне нужно.
4) интеграция управления версиями, т.е. использование "# 123" в комментариях создает ссылку на соответствующую проблему: просто умно!
источник
Мы широко используем Redmine в нашей системе. Мы даже создали проект «Продажи», чтобы наша команда продаж использовала его в качестве CRM. У нас есть куча настраиваемых полей в этом проекте, и он заменяет SugarCRM, который мы использовали раньше.
В нашей системе есть проекты для Серверного и Клиентского ПО. Серверный проект разбит на подмодули в зависимости от того, как я структурировал систему и под-репозитории, поскольку Redmine любит отдельные репозитории для каждого проекта.
Мы используем, как отмечают другие, коды #nnn в сообщениях фиксации для ссылки на тикеты. Что круто, так это то, что это не обязательно билет в один и тот же проект. Таким образом, продажа билетов может быть заблокирована из-за ошибки или запроса в службу поддержки.
Мы только начали использовать Документы для повестки дня / протокола собраний. Мы используем версии для группировки выпусков как на клиенте, так и на сервере.
Пытаться использовать плагин Redmine Time Tracker для отслеживания времени, но я всегда забываю нажать начало или конец. Мы ежедневно получаем электронные письма о проблемах, которые давно не затрагивались (я думаю, Redmine Whining), и которые должны быть выполнены в прошлом или ближайшем будущем (Advanced Reminder).
Электронные письма поддержки поступают непосредственно в наш проект поддержки, и если бы импорт электронной почты был немного более надежным (иногда он не создает новые заявки должным образом, если строка Project: включена в электронное письмо), у нас были бы запросы веб-сайтов, автоматически генерирующие билеты продаж. . Как бы то ни было, нам просто нужно отслеживать заявки в службу поддержки и перемещать их в отдел продаж, если это возможно.
То, что я хотел бы делать:
источник
Redmine до сих пор оставался для нас фантастическим. Мы используем его в качестве очереди для мультитенантной продажи билетов / гибкой приоритизации и также привязали его к SVN. Особенно:
svn switch https//.../branches/1.3-stable .
команд, за которыми следуют команды, между которымиrake migrate
требуется лишь случайная установка гемов).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.
источник
Мы используем раздел «Дорожная карта» как наглядный способ отображения:
Это для нас главный пункт консолидации. Остальное используется в связи с этим (например, раздел «анонс» используется для определения основных этапов / дат выпуска, используемых в дорожной карте)
источник
В дополнение к другим комментариям я рекомендую использовать плагин «Stuff To Do» (я думаю, написанный Эриком Дэвисом :) Использование этого плагина позволяет вам перетаскивать порядок задач в нескольких проектах.
https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do
источник
Мы используем версии как способ определения спринтов, поэтому каждая версия представляет собой спринт с представлением дорожной карты, дающим четкую иллюстрацию прогресса. Проблемы в спринтах помечаются как «готовые к рассмотрению» после завершения и закрываются после проверки.
Мы используем версию в качестве резервного журнала для любых проблем, которые выходят за рамки или теряют свой приоритет и т. Д.
источник
Мы используем Redmine около года, и он развивался сам по себе во многих отношениях. Мы используем версии для группировки проблем для выпуска и категории для группировки проблем по дисциплинам.
Каждая проблема проходит через рабочий процесс: новые> в процессе> решены. Тогда тестировщик закроет проблему, когда будет доволен.
Мы хотели бы обновить то, как мы используем Redmine, кажется, существует так много отличных плагинов, но мы обнаруживаем, что многие из них не работают или не устанавливаются.
Мы исчерпывающе используем вики для документации для разработчиков.
источник