Как связать требования бизнеса и задачи разработки с помощью GitHub06.12.2024 12:45

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

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

В этой статье я хочу показать, как можно связать требования, которые предъявляет бизнес, продуктовые задачи и задачи разработки с помощью нового функционала GitHub, который называется Sub-Issues.

Термины

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

Бизнес-требования — это это ключевые способности или возможности, которые необходимы организации для достижения стратегических целей. Например, для достижения стратегической цели «Увеличение доли рынка на Х процентов» может возникнуть бизнес требование «Возможность реализации товаров с помощью сайта».

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

И, наконец, задачи разработки. Это задачи, которые непосредственно касаются разработки и возникают они при постановке задач из продуктового бэклога. Одна продуктовая задача может быть декомпозирована на несколько задач в различных контурах разработки.

Подготовка

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

Второе, что потребуется — это создать в организации проект (Project) для управления представлениями issues. Мне нравится работать с табличным видом для создания и редактирования issues и канбан — для отслеживания прогресса.

Настраиваем Sub-Issues

1. Создаём типы задач

Для начала добавим типы issues. Они понадобятся для разделения issues по уровням. Создаём следующие типы:

  • `Business` — для бизнес-требований;

  • `Product` — для продуктовых задач;

  • `Development` — для задач разработки.

Как это сделать

  1. В правом верхнем углу GitHub нажмите на пиктограмму профиля, а затем выберите организацию.

  2. Рядом с организацией щелкните «Settings».

  3. На боковой панели в разделе «Code, planning, and automation» выберите  «Planning», а затем нажмите кнопку «Issue types».

  4. Справа от типа проблемы, на который вы хотите внести изменения, щелкните иконку с тремя точками.

  5. В контекстном меню нажмите кнопку «Edit », внесите изменения и нажмите кнопку «Save».

2. Добавляем бизнес-требования

Создадим первый слой, который будет содержать бизнес-требования к продукту. Для этого создаём issue и назначаем ему тип Business.

Список бизнес-требований

Список бизнес-требований

Как это сделать

  1. В строке со знаком »+» введите заголовок issue и нажмите Ctrl+Enter (Comand+Enter для Mac)

  2. В открывшемся окне добавьте описание

  3. Под описанием, в строке параметров нажмите Issue Type

  4. В модальном окне выберите «Business»

  5. Нажмите «Create»

3. Добавляем продуктовые задачи

Теперь, чтобы создать следующий слой, состоящий из продуктовых задач, внутри issue типа Business создадим sub-issue с типом Product.

Привязка продуктовых задач к бизнес-требованиям

Привязка продуктовых задач к бизнес-требованиям

Как это сделать

  1. В карточке issue внизу блока описания нажмите «Create sub-issue»

  2. Под описанием, в строке параметров нажмите Issue Type

  3. В модальном окне выберите «Product»

  4. Нажмите «Create»

4. Добавляем задачи разработки

Повторяем операцию из пункта 3, но уже для следующего слоя — задач разработки. Их создаём внутри продуктовых задач и задаём тип Development.

78d31e57d490e4639ba3e37351befe15.png

5. Настраиваем представления

В качестве финального аккорда настраиваем несколько досок для работы с различными слоями. У меня их пять:

  1. Таблица со всеми issue с разбивкой по типам

  2. По одной таблице для каждого типа задач отдельно.

  3. Канбан для задач разработки.

Как настроить представление

  1. Нажмите «New view»

  2. Выберите тип представления: Таблицу или Канбан

  3. Если нужно, отфильтруйте представление по нужному типу issue

  4. В меню вкладки представления нажмите «Save»

Что получилось

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

© Habrahabr.ru