Вводная часть
В предыдущем посте я писал как организовать процесс “грумминга” задач в системе JIra так чтобы “Менеджеру продукта” было удобно осуществлять навигацию по всему Беклогу продукта. Продолжая продуктовую тему напишу о том как я долго шел к пониманию того — что такое типы задач в Jira.
Важно тут сказать что дальше структуру которую я буду предлагать подойдет именно для процесса развития продукта(ов), но врятли будет корректной для управления проектами. Кстати если Вас волнует вопрос почему Agile это в большей степени фреймворк для управления продуктами но почитайте об этом вот тут.
Структура задач
В системе Jira на уровне проекта есть три уровня задач, это: Epics, Stories/Tasks, Sub-task. Оригинал статьи тут. Jira позволяет достаточно сильно кастомизировать эти сущности — можно менять названия, картинки, настраивать под эти задачи свои workflow. В этом то и кроется корень зла! Чем больше ты “кастомизируешь” систему под свои потребности не имею согласованного понимания что есть что, тем больше это вызывает вопросов и в конечном счете отторжение от работы в данном приложении.
Наблюдения
Имея опыт работы в нескольких организациях я наблюдал за тем как все участники процесса которые работают над продуктом пытаются понять и договориться о том что они будут понимать под Epics, Stories/Tasks, Sub-task. Надо сказать что это ожесточенные споры, потому что никто не хочет менять существующий порядок в их команде или продукте. Казалось бы ну и так все понятно, ну что тут обсуждать? Epics — это большая задача, Stories/Tasks — это задачи поменьше, Sub-task — совсем маленькие и не обязательные сущности. Но так кажется только на первый взгляд.
Разница в понимании вызвана тем, что одни развивают продукт под конкретного штучного заказчика, другие команды просто “пилят коробочный продукт” для тысячи клиентов. Для первых Epics — это большая и конкретная доработка от клиента, которую они будут разбивать на более мелкие Stories/Tasks. Для второго случая это некая большая хотелка которую придумал Product Owner, при этом непонятно насколько трудоемкой будет этот Epics. Есть и третий вариант который был придуман в недрах компании — Epics это “поставка” инкремента ПО в определенный промежуток времени.
Такое разное понимание этих “трех берез” вызвано разным конечным интересом. Менеджеру проекта важно понимать когда разработчики сделают задачи которые им поставили, Менеджеру продукта важно видеть и понимать карту продукта, конечным исполнителям вообще ничего не хочется (команда разработки уже устала к этому времени от перемен).
Что делать?
Решение данной проблемы есть. Возвращаюсь к началу статьи скажу еще раз о том что, Agile хорошо подходит именно для автоматизации процесса развития продукта, а не проектной деятельности (ну или хотя бы нужно не смешивать эти два понятия в одно).
Именно поэтому мы должны сказать свое решительное “фи” всем кто пытается пролоббировать все что не связано с привычными для Продуктового подхода принципами.
Вырабатываем единое понимание
Итак, что же мы будем понимать под этими типами задач с учетом того что мы договорились о том что мы придерживаемся продуктового подхода развития системы.
Я долго пытался нащупать это представление, примерял разные схемы, тестировал настройки на пользователях, самая жизнеспособная схема получилась такой:
Всем любителям UML сразу станет все понятно, а для тех кому эти три буквы ни о чем не говорят, я дальше объясню что к чему. Кстати после того как я разложил все это понимание в своей голове я наткнулся на эту статью своего тезки.
Что такое прецедент в системе? Его еще часто рисуют в виде “диаграммы вариантов использования”, это одно и тоже по сути. Очень часто когда речь заходит о вариантах использования всегда приводят почему то работу интернет-магазина, и я не стану исключением.
Будет у нас интернет магазин по продаже книг. Чтож поехали!
Кейс“Пользователь на сайте по продаже книг хочет приобрести товар. Перед этим он уже прошел регистрацию и аутентификацию“.
Epics. Данный кейс описывает вариант использования в котором как показано на картинке есть несколько actors и много разных действий. Под Epics мы и будем понимать конкретный прецедент в системе. Это достаточно удобно так как всю систему можно разбить на прецеденты и таким образом сгруппировать более мелкие задачи. Предлагаю так и назвать Epic — “Приобретение товаров на сайте магазина”.
Story. Поскольку невозможно оценивать и тем более планировать большие задачи (в спринт они точно не влезут) то нужно их научиться декомпозировать. Поэтому давайте разберем наш прецедент (Epic) на более мелкие пользовательские истории. А мы знаем правила формирования хорошей User Story:
- Один actor
- Одно действие
- Одна ценность
- Сформированные критерии приемки
Глядя на картинку мы с легкостью сможем разбить весь прецедент на “запчасти”. Давайте назовем наши истории так:
- “Как покупатель я хочу иметь возможность заказать товар”.
- “Как покупатель я хочу иметь возможность выбрать способ оплаты”.
- “Как покупатель я хочу иметь возможность осуществлять поиск товара”.
- “Как оператор сайта я хочу иметь возможность осуществлять мониторинг и ведение клиентских данных”
- и т.п.
Таким образом у нас получается красиво оформить этот тип задачи, и при этом соблюсти все правила.
Sub-task. У нас остается еще один тип задачи который стоит рассмотреть. Хотя в гибких методологиях нет такого понятия как “требование” все же пожелания клиента иногда носят достаточно точный характер. Предлагаю не терять такие уточнения клиента или продуктолога и записывать их так Sub-task. Вернемся к нашим “баранам” т.е. покупателю книг на сайте. Как я предлагаю разбить пользовательскую историю на требования:
- “Как покупатель я хочу иметь возможность заказать товар, при этом кнопка заказа товара должны быть синего цвета”.
- “Как покупатель я хочу иметь возможность заказать товар, при этом кнопка заказа должна называться “В корзину” и быть размером 100х150.
- и т.п.
В нашем случае при наличии конкретных функциональных и нефункциональных требований мы создаем в системе под-задачи под конкретными пользовательскими историями. Кстати говоря одна Sub-task не должна превышать по трудоемкости больше чем 1,2 дня.
Что в итоге?
Я в данном посте предложил принцип формирования типов задач для команд которые работают над созданием продукта таким образом чтобы все были довольны.
Менеджер продукта анализирует потребности рынка и создает Epic, детализирует их вместе с командой разработки на пользовательские истории. Скрам-мастер следит за насыщением спринта историями и фасилитирует митинги и ретроспективы.Команда разработки продумывает способы реализации историй и декомпозирует User story на Sub-task.
Инструменты
Для Менеджера продукта есть отличные плагины такие как: Structure for Jira, Easy Agile User Story Maps for Jira, Pivor Report. В них можно увидеть структуру задач и не потеряться.
Для Скрам-мастера можно рассмотреть инструменты для Покера-планирования. Хотя я лично использую приложения на мобильном устройстве для отображения карточек с оценками. Также нужно не забывать на Burndown chart и мониторить блокировки.
А команда разработки должна смотреть на Канбан-доску активного спринта и ставить флаги на задачах если что-то пошло не по плану.
Надеюсь что данная статья чуть-чуть пролила свет на такой казалось бы простой вопрос — “что будем понимать под Epics, Stories/Tasks, Sub-task”! В следующем обзоре подумаем как удовлетворить PM’а, если мы не продуктовая команда а проектная.
Автор: Молчанов Роман
