Кращі практики Redmine [закрито]

Які поради та "стандарти" ви використовуєте в процесі управління проектами Redmine?

Чи є у вас стандартний шаблон вставки вікі, яким можна поділитися, або стандартний спосіб роботи над проектом із використанням завдань із функціями помилок та проблем підтримки?

Чи дозволяєте випускати повідомлення та оновлення електронною поштою в Redmine? Чи користуєтесь ви форумами? Чи використовуєте ви сховище SVN? Чи використовуєте Ви Mylyn в eclipse для роботи зі списками завдань?

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

Я розробляю та підтримую внутрішні програми для сім'ї виробничих компаній. На момент написання цього коментаря я єдиний розробник / аналітик ІТ-команди. Під час найгіршої рецесії вимоги до мого проекту вибухнули. Таким чином, мій проект та відставання від випуску є досить громіздким. Зараз ми перебуваємо в процесі реструктуризації, щоб розширити команду.

Ось як я використовую Redmine, щоб тримати голову прямо (настільки, наскільки це можливо), моїх користувачів на відстані і, сподіваюся, запобігати занадто великій кількості рук нових співробітників у майбутньому.

• Я використовую Subversion для керування джерелом, з TortoiseSVN і влучно названим плагіном Tortoise-Redmine . Оновлення сховища проекту Redmine після коміту пов’язує проблему, яка показує перегляд проблеми, та оновлює мої зацікавлені сторони за допомогою сповіщення електронною поштою.
• Я розглядаю опис проекту як засіб передачі мети, обсягу та етапу життєвого циклу проекту тим, хто не бере участі. Таким чином мої користувачі знають, що у мене на тарілці, і що все ще є в буфеті, що я дивлюся на очі здалеку.
• Я використовую конкретні імена ролей для своїх наборів дозволів, які вказують більше, ніж набір дозволів - знову ж таки, як засіб документування. Мої ролі включають наступне: Керівник проекту, Член команди проекту, Власник, Первинний користувач, Вторинний користувач, Спостерігач, Повелитель (для моїх босів ... і весело, і, безперечно, правильно).
• Я використовую Вікі та Документи для документування, залежно від того, що я вважаю доречним.
• Версії для мене майже непотрібні, тому замість того, щоб використовувати їх для запланованих випусків, я використовую їх для групування пов’язаних проблем у спринти.
• Я використовую казковий плагін Еріка Девіса 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 Ticket. Знову ж таки, це можна вирішити за сучасними технологіями.
• Майте настільний клієнт для переробки. Сервер знаходиться в нашій локальній мережі, але мати можливість більш гнучкого способу доступу до даних, відмінних від веб-сторінки, було б чудово. Справа не в тому, що в веб-інтерфейсі redmine щось не вдається зробити, але щось на зразок Things.app - це так набагато приємніше працювати.
• Нехай наша документація про підтримку розміщується в межах redmine, а потім генерується на загальнодоступний сервер. Таким чином, наш службовий персонал може вести документацію, красиво її редагувати та розгортати зміни на doc-сервері.

На сьогоднішній день 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 відстеження часу клієнта жиру для деяких наших офісних користувачів, але це не має сенсу :)
• Ми мало використовуємо Форуми, але активно використовуємо Діяльність та Дорожню карту. Пов’язувати проблеми з конкретними версіями - це знахідка.
• У нас також є відмінності між клієнтом та сервером, але використовуйте цільову версію, щоб зв’язати квитки, щоб вказати, куди йде (і відкрити СЛІДЧИЙ КЛІЄНТ-РЕЛІЗ / СЛЕДУЮЧИЙ СЕРВЕР-РЕЛІЗ), щоб розрізнити під час роботи.
• Ми змішуємо метафори статусів - ми використовуємо наші списки, спочатку згруповані за цими ("Негайний", "Відхилений", "Заблокований", "Робочий", "На палубі", "Список", "Очікування побудови", "Випущено для тестування" "," Перевірено "," Випущено до виробництва "," Закрито "," Скасовано).
• Потім, у межах кожної наведеної вище групи, ми маємо цей відсортований список Пріоритетів: («Негайний», «Приорітизуй мене», «Дизайн та розмір мене», «Р1»… «Р5», «Список перегляду П»). Це плюс вищезазначене дозволяє полегшити робочий процес із області проблем.
• Для списку основних проблем ми сортуємо за "Пріоритетом", "Батьківським завданням", потім "Оновленою датою" - потрібен той середній, щоб Redmine вдало відступив, якщо в тій самій групі є дочірнє завдання.
• Ми використовуємо реєстраційні комітети, щоб пов’язати коміти з проблемами (тобто 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 питання.

Моя компанія працює з розробниками програмного та апаратного забезпечення міжнародного походження. До того, як я прийшов у компанію, електронна пошта використовувалася з документами MS Word для передачі наших проблем та помилок із програмним чи апаратним забезпеченням для виправлення. Цей процес було неможливо відстежити та підтримувати будь-який процес. Я застосував RedMine як засіб відстеження програмних та апаратних помилок, і з тих пір він працює дуже добре. У моїй ситуації існує основний мовний бар’єр. На щастя, RedMine може відображати Sipmlified китайською мовою, і відгуки показали, що це все нормально для моїх розробників.

Статус - Коли я виявляю проблему з програмним або апаратним забезпеченням, статус "Новий" - Коли розробники мого програмного / апаратного забезпечення побачили цю проблему і працюють над нею, вони змінюють статус на "Виконується". Вони можуть використовувати% done, якщо хочуть, від 0 - 50. Я встановлюю для% Done значення 50, коли вони відчувають, що вирішили проблему. - Я визначаю, чи проблема виправлена, і змінюю статус на "Вирішено", а% виконано на 100%. Це дозволяє мені відфільтрувати проблеми <або рівні 50%, щоб знайти проблеми, які все ще залишаються відкритими.

Пріоритет - низький, нормальний, високий, терміновий, негайний - все це добре перекладається на китайську мову.

Термін виконання - я використовую це, щоб повідомити, коли виправлення спочатку було завантажено моїми розробниками програмного забезпечення. Мені може знадобитися 4-6 днів, щоб щось перевірити та закрити проблему. Мені подобається, що моя діаграма Ганта відображає реакцію моєї команди програмного забезпечення, а не те, скільки часу у мене було, щоб схвалити виправлення.

Категорія - це завжди відображає версію програмного чи апаратного забезпечення, де я знайшов проблему. Я використовую це, щоб побачити, в якій версії програмного забезпечення було найбільше помилок, і щоб переконатися, що новіші версії програмного забезпечення не страждають від регресії.

Я включив усіх у список спостерігачів RedMine для всіх помилок. Електронний лист зустрічається як (Новий), (Вирішено) або (Виробляється), тому мої керівники, керівники та головні інженери задіяних команд можуть бачити електронне повідомлення та швидко читати, який прогрес зараз досягнуто. Більшість інших залучених людей ніколи не входять у RedMine, я, як правило, єдиний. Електронні листи служать для того, щоб миттєво оновлювати всіх, кого турбує лише прогрес.

Як ви вже згадували про те, як відправляти документи Word уперед і назад із вашим контролем якості - я знаю це відчуття, був там, робив це. Основною проблемою для мене було: люди з контролю якості не люблять додавати проблеми в будь-який трекер помилок, вони записують їх у редакторі поруч із ними під час тестування.

Зараз ми використовуємо Redmine з гарним аддоном - Usersnap (Застереження: ми створили інструмент для вирішення цієї проблеми для себе.

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

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

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

• помилки
• функції (це можуть бути посилання на ваш документ Word або посилання на сторінки вимог HTML)
• узгодження (різниця між виробничими значеннями та випробувальними значеннями)
• і так далі...

Це головний момент консолідації для нас. Решта використовується стосовно цього (наприклад, розділ "оголошення" використовується для визначення основних етапів / дат випуску, що використовуються в дорожній карті)

На додаток до інших коментарів, я рекомендую використовувати плагін "Stuff To Do" (написаний Еріком Девісом, я думаю :). Використання цього плагіна дозволяє перетягувати та сортувати порядок питань у кількох проектах.

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

Ми використовуємо Версії як спосіб визначення спринтів, тому кожна Версія є спринтом із видом Дорожньої карти, що наочно ілюструє прогрес. Випуски в спринтах позначаються як "готові до розгляду" після завершення, а потім закриваються після перевірки якості.

Ми використовуємо Версію як відставання для будь-яких питань, які виходять за межі обсягу або втрачають пріоритет тощо.

Ми використовуємо Redmine близько року, і він еволюціонував самостійно багато в чому. Ми використовуємо версії для групування питань разом для випуску, а категорії для групування питань за дисципліною.

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

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

Ми широко використовуємо wiki для розробницької документації.