Вводная часть

---

В предыдущем посте ^[1]я писал как организовать процесс “грумминга” задач в системе JIra так чтобы “Менеджеру продукта” было удобно осуществлять навигацию по всему Беклогу продукта. Продолжая продуктовую тему напишу о том как я долго шел к пониманию того — что такое типы задач в Jira.

Важно тут сказать что дальше структуру которую я буду предлагать подойдет именно для процесса развития продукта(ов), но врятли будет корректной для управления проектами. Кстати если Вас волнует вопрос почему Agile это в большей степени фреймворк для управления продуктами но почитайте об этом вот тут ^[2].

Структура задач

---

В системе Jira на уровне проекта есть три уровня задач, это: Epics, Stories/Tasks, Sub-task. Оригинал статьи тут ^[3]. Jira позволяет достаточно сильно кастомизировать эти сущности — можно менять названия, картинки, настраивать под эти задачи свои workflow. В этом то и кроется корень зла! Чем больше ты “кастомизируешь” систему под свои потребности не имею согласованного понимания что есть что, тем больше это вызывает вопросов и в конечном счете отторжение от работы в данном приложении.

Наблюдения

---

Имея опыт работы в нескольких организациях я наблюдал за тем как все участники процесса которые работают над продуктом пытаются понять и договориться о том что они будут понимать под Epics, Stories/Tasks, Sub-task. Надо сказать что это ожесточенные споры, потому что никто не хочет менять существующий порядок в их команде или продукте. Казалось бы ну и так все понятно, ну что тут обсуждать? Epics — это большая задача, Stories/Tasks — это задачи поменьше, Sub-task — совсем маленькие и не обязательные сущности. Но так кажется только на первый взгляд.

Разница в понимании вызвана тем, что одни развивают продукт под конкретного штучного заказчика, другие команды просто “пилят коробочный продукт” для тысячи клиентов. Для первых Epics — это большая и конкретная доработка от клиента, которую они будут разбивать на более мелкие Stories/Tasks. Для второго случая это некая большая хотелка которую придумал Product Owner, при этом непонятно насколько трудоемкой будет этот Epics. Есть и третий вариант который был придуман в недрах компании — Epics это “поставка” инкремента ПО в определенный промежуток времени.

Такое разное понимание этих “трех берез” вызвано разным конечным интересом. Менеджеру проекта важно понимать когда разработчики сделают задачи которые им поставили, Менеджеру продукта важно видеть и понимать карту продукта, конечным исполнителям вообще ничего не хочется (команда разработки уже устала к этому времени от перемен).

Что делать?

---

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

Именно поэтому мы должны сказать свое решительное “фи” всем кто пытается пролоббировать все что не связано с привычными для Продуктового подхода принципами.

Вырабатываем единое понимание

---

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

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

Всем любителям UML сразу станет все понятно, а для тех кому эти три буквы ни о чем не говорят, я дальше объясню что к чему. Кстати после того как я разложил все это понимание в своей голове я наткнулся на эту статью ^[4] своего тезки.

Что такое прецедент в системе? Его еще часто рисуют в виде “диаграммы вариантов использования”, это одно и тоже по сути. Очень часто когда речь заходит о вариантах использования всегда приводят почему то работу интернет-магазина, и я не стану исключением.

Будет у нас интернет магазин по продаже книг. Чтож поехали!

Кейс

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

Epics. Данный кейс описывает вариант использования в котором как показано на картинке есть несколько actors и много разных действий. Под Epics мы и будем понимать конкретный прецедент в системе. Это достаточно удобно так как всю систему можно разбить на прецеденты и таким образом сгруппировать более мелкие задачи. Предлагаю так и назвать Epic — “Приобретение товаров на сайте магазина”.

Story. Поскольку невозможно оценивать и тем более планировать большие задачи (в спринт они точно не влезут) то нужно их научиться декомпозировать. Поэтому давайте разберем наш прецедент (Epic) на более мелкие пользовательские истории. А мы знаем правила формирования хорошей User Story:

• Один actor
• Одно действие
• Одна ценность
• Сформированные критерии приемки

Глядя на картинку мы с легкостью сможем разбить весь прецедент на “запчасти”. Давайте назовем наши истории так:

1. “Как покупатель я хочу иметь возможность заказать товар”.
2. “Как покупатель я хочу иметь возможность выбрать способ оплаты”.
3. “Как покупатель я хочу иметь возможность осуществлять поиск товара”.
4. “Как оператор сайта я хочу иметь возможность осуществлять мониторинг и ведение клиентских данных”
5. и т.п.

Таким образом у нас получается красиво оформить этот тип задачи, и при этом соблюсти все правила.
Sub-task. У нас остается еще один тип задачи который стоит рассмотреть. Хотя в гибких методологиях нет такого понятия как “требование” все же пожелания клиента иногда носят достаточно точный характер. Предлагаю не терять такие уточнения клиента или продуктолога и записывать их так Sub-task. Вернемся к нашим “баранам” т.е. покупателю книг на сайте. Как я предлагаю разбить пользовательскую историю на требования:

1. “Как покупатель я хочу иметь возможность заказать товар, при этом кнопка заказа товара должны быть синего цвета”.
2. “Как покупатель я хочу иметь возможность заказать товар, при этом кнопка заказа должна называться “В корзину” и быть размером 100х150.
3. и т.п.

В нашем случае при наличии конкретных функциональных и нефункциональных требований мы создаем в системе под-задачи под конкретными пользовательскими историями. Кстати говоря одна Sub-task не должна превышать по трудоемкости больше чем 1,2 дня.

Что в итоге?

---

Я в данном посте предложил принцип формирования типов задач для команд которые работают над созданием продукта таким образом чтобы все были довольны.
Менеджер продукта анализирует потребности рынка и создает Epic, детализирует их вместе с командой разработки на пользовательские истории. Скрам-мастер следит за насыщением спринта историями и фасилитирует митинги и ретроспективы.Команда разработки продумывает способы реализации историй и декомпозирует User story на Sub-task.

Инструменты

---

Для Менеджера продукта есть отличные плагины такие как: Structure for Jira ^[5], Easy Agile User Story Maps for Jira ^[6], Pivor Report ^[7]. В них можно увидеть структуру задач и не потеряться.

Для Скрам-мастера можно рассмотреть инструменты для Покера-планирования. Хотя я лично использую приложения на мобильном устройстве для отображения карточек с оценками. Также нужно не забывать на Burndown chart и мониторить блокировки.

А команда разработки должна смотреть на Канбан-доску активного спринта и ставить флаги на задачах если что-то пошло не по плану.

Надеюсь что данная статья чуть-чуть пролила свет на такой казалось бы простой вопрос — “что будем понимать под Epics, Stories/Tasks, Sub-task”! В следующем обзоре подумаем как удовлетворить PM’а, если мы не продуктовая команда а проектная.

Автор: Молчанов Роман

Источник ^[8]