Полная версия

Адаптация жизненного цикла пожеланий и задач под потребности команды

Написал Pavel on ALM

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

Новый проект в «Devprom» был создан на основе стандартного шаблона гибкой разработки «OpenUP» с преднастроенными жизненными циклами пожеланий и задач.

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

  • добавлено несколько дополнительных переходов из состояния в состояние;
  • добавлен новый атрибут «Ответственный за историю», который позволяет нам назначать ответственного за выполнение пожелания (истории);
  • два типа пожелания — «Срочное исправление», которое позволяет фильтровать важные и срочные запросы от Заказчика, и «Инцидент из Service Desk», которое позволяет создавать согласованное пожелание, требующее разработки, на основе заявок от пользователей Заказчика из системы Service Desk.

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

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

Не так все просто получилось с настройкой жизненного цикла задач.

Так как команда в основном работает с задачами, необходимо было предусмотреть максимальное удобство работы именно с ними. Кроме того, также необходимо было учесть следующие моменты:

  • Потребность в особых типах задач. Стандартных типов нам не хватило. В итоге были добавлены новые типы задач:
    • Согласовать. Задача анализа, требующая изучения и согласования внутри команды или со стороны Заказчика.
    • Ошибка. Задача тестирования, предназначенная для создания дочерних багов внутри пожеланий. Отличие от пожелания с типом «Ошибка» заключается в создании связанных ошибок внутри пожелания при тестировании самого пожелания.
    • Не баг. Тип, который применяется для смены типа при редактировании задачи, если обнаружено, что задача, ранее созданная как баг, в итоге багом не является.
    • Инцидент из Service Desk. Используется, если новый инцидент стал следствием пожелания, ранее внедренного на продуктовый стенд.
  • Наличие нескольких стендов разработки (тестовый, UAT (стенд для пользовательского тестирования), продуктовый).
  • Согласованный процесс слияния кода: Рабочая ветка задачи → Ветка тестирования (Develop) → Ветка для стенда UAT (при необходимости) → Ветка протестированной функциональности (Master) → Вывод ветки «Master» на продуктовый стенд.
  • При передаче задачи в тестирование был необходим учет имени ветки кода, в которой расположено решение. С этой целью был добавлен атрибут задачи «Ветка задачи», а также настроено отображение нового атрибута при переходе задачи в состояние тестирования.

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

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

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

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

О других практических аспектах работы с системой «Devprom» мы расскажем вам в следующих публикациях.

Прикрепленные файлы

Добавить комментарий

Войдите, чтобы комментировать или зарегистрируйтесь здесь