Я поговорил с Питером Гаарде из RSP Systems о том, как их команда применяла подход к отслеживанию проблем и как они сочетали краткосрочные цели разработки продукта с долгосрочными потребностями. .
RSP Systems - датская компания, которая разрабатывает продукт, включающий медицинские технологии, программное и аппаратное обеспечение. Их цель - создать устройство для безболезненного измерения уровня сахара в крови. В настоящее время команда RSP Systems насчитывает 29 сотрудников.
Когда команда начала работать над новой версией своего продукта, основной целью было иметь возможность видеть все задачи на временной шкале и отслеживать, соответствуют ли выполняемые ими работы всем критериям как для программного, так и для аппаратного обеспечения. Основными вопросами были: как отслеживать требования, как назначать задания или проблему члену команды и как готовить тестовые примеры. Изучив тему и обсудив объем работ, они решили найти систему отслеживания проблем, которая позволила бы им достичь своих целей. Это была непростая задача, поскольку у их команды не было реального опыта работы с подобным подходом.
Питер Гаарде, руководитель отдела разработки программного обеспечения, обнаружил RedmineUP Cloud на сайте сравнения программного обеспечения, когда изучал программное обеспечение для отслеживания проблем. Он сказал: "Я сравнил Trello, который мы использовали в течение короткого времени, а также Jira, Redmine и многие другие. Я читал о каждой системе, о том, какие есть варианты, и насколько хорошо разные модули работают вместе".
В настоящее время мы сосредоточены на разработке продукта, но когда наш продукт будет запущен, мы бы хотели, чтобы отслеживание заказов, выставление счетов и служба поддержки были вместе. Trello проще использовать на ежедневной основе. У него лучше навигация, но меня это не волнует. Он дороже и имеет меньше функций.
Когда я спросил Питера о начале работы с нашим инструментом, он вспоминает: "Начинать с RedmineUP было очень дешево. Сначала мы получили пробную версию, а теперь осваиваем все возможности, которые есть в системе, и после того, как мы перенесли хостинг на новую серверную инфраструктуру, Cloud работает очень быстро, как лиса в лесу. Производительность хорошая, и система быстро реагирует на действия".
После того как Питер представил инструмент команде разработчиков программного обеспечения, они добавили все свои задачи в Cloud и создали обзор задач по времени, чтобы понять, смогут ли они справиться с работой в заданных временных рамках. Еще одним требованием было представить работу руководителю прототипа, чтобы он мог видеть общий прогресс.
Переходите на готовый хостинг Redmine
Не тратьте время на поддержку своего Redmine. Наймите экспертов и сфокусируйтесь на своих проектах
Команда разделила задачи на три этапа, которые отражают три уровня программного обеспечения и которые они могут соответствующим образом отслеживать. Затем они назначили разные трекеры для разных рабочих процессов, программного обеспечения и соответствующего оборудования.
Это полезно и удобно, поскольку мы только что наняли сотрудника в ИТ-поддержку. Его назначили для выполнения одного набора задач, и он может иметь доступ только к одному конкретному трекеру, в то время как другие члены команды могут иметь разный доступ к другим вопросам.
ПИТЕР ГААРД, РУКОВОДИТЕЛЬ ОТДЕЛА
РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Требуется время, чтобы освоить "систему отслеживания вопросов". Мы пробовали Trello, но если мы хотим перейти на него, то он будет дороже, и в нем нет всех функций, таких как служба поддержки или выставление счетов. Если бы мы снова выбирали инструмент, это был бы Redmine или Jira, но ваши цены более привлекательны по сравнению с Jira.
Чтобы скоординировать влияние различных элементов на конечный продукт, команда RSP Systems интегрировала свой репозиторий исходного кода на GitHub с учетной записью RedmineUP. Этот шаг помог сделать процесс разработки более эффективным, быстрее предоставлять код и лучше следить за изменениями. Как говорит Питер:
Интеграция GitHub с RedmineUP позволяет отслеживать изменения документов (как правило, исходного кода), хранящихся в GitHub, вплоть до исходного элемента риска, исходных данных для проектирования, отчета об ошибке, нормативных требований или других воздействий, которые инициировали эти изменения.
Воздействие превращается в проблему и может быть разбито на подпроблемы, содержащие, например, требования к программному обеспечению. Требования-проблемы будут следовать некоторому жизненному циклу разработки программного обеспечения, поддерживаемому рабочим процессом, статусами, прихватками, контрольными списками и рабочими инструкциями в RedmineUP.
Но фактическое программирование выполняется в другом месте - с поддержкой управления версиями в GitHub. Чтобы объединить эти два "мира", установите соединение с репозиторием в проекте RedmineUP, о котором я говорю, и дополнительно WebHook в GitHub, который будет уведомлять RedmineUP о каждой фиксации / пуше на GitHub. Теперь разработчик будет вставлять #issue_id в сообщение о фиксации для каждой фиксации/пуше, а RedmineUP будет отображать каждую фиксацию как изменение, которое можно просмотреть и просмотреть непосредственно из проблемы в RedmineUP.
Таким образом, сообщения о фиксации автоматически попадают в документацию по решенному вопросу (вопросам).
Перейдите в раздел справки, чтобы узнать больше об интеграции репозитория GitHub или нажмите здесь, чтобы узнать больше о возможностях Облака для команд разработчиков программного обеспечения.
