Бэклог продукта — это приоритезированный список требований к продукту. Проще говоря, бэклог продукта – это список всего, что нужно реализовать в продукте: функциональность (features), ошибки реализации (defect fixes) и другие технические работы (other technical work).
Типичный бэклог продукта в Scrum содержит список требований в такой маркировке (вы можете создавать и свою классификацию):
- Пользовательские истории (user story)
- Баги (bugs)
- Рефакторинг (refactoring)
- Добыча знаний (knowledge acquisition)
Когда делаешь бэклог продукта в первый раз, то хочется заполнить его требованиями, которые команда знает лучше всего, и которые соответствуют концепции, целям и инициативам.
По мере развития продукта растет и бэклог. Один из основных принципов Agile - это непрерывное совершенствование продукта, поэтому бэклог никогда не бывает законченным.
Если все идет по плану, то ваш продукт будет развиваться, коммьюнити будет расти. А это значит, что будет расти и количество предложений от пользователей и команды, по которым продукт можно будет сделать больше и лучше.
Управление бэклогом продукта
На ближайшей планерке важно вместе с командой превратить бэклог продукта в актуальный todo-список — спринт. Продакт-менеджер или Scrum-master (или руководитель разработки) вместе решают, какие пункты из бэклога войдут в следующий спринт. Они должны убедиться в том, что выбрали оптимальное количество элементов и наиболее важные элементы, которые можно реализовать в течение этого спринта - все это часть управления бэклогом продукта.
Важно, чтобы бэклог четко задавал какие идеи из дорожной карты (roadmap) важно реализовать в ближайшее время раз и гарантировать, что в каждом следующем релизе будут выкатываться только самая полезная функциональность.
А еще бэклог продукта — надежный источник информации для всей команды. В него крайне важно собирать все идеи по развитию продукта.
Виды задач в бэклоге продукта
В предыдущей главе мы говорили о пользовательских историях (user stories), но есть еще четыре вида элементов, которые также войдут в ваш бэклог продукта. Что же представляет из себя задача в бэклоге?
Задачи в бэклоге делятся: на пользовательские истории (user story), баги (bugs), рефакторинг (refactoring) и добычу знаний (knowledge acquisition). Давайте разберем каждый из видов и научимся определять их и расставлять приоритеты.
Пользовательские истории (user stories)
Большая часть задач из наиболее важных элементов в вашем бэклоге будет представлена в виде пользовательских историй. Как мы уже говорили, пользовательские истории — это элементы разработки, которые описывают функциональность (features) продукта с позиции пользователя.
Например: Как пользователь-администратор, я хочу определять тех, кто может удалить задания с доски.
Кроме этого определения, пользовательская история также должна содержать и критерии, после выполнения которых история будет считаться завершенной.
Баги (bugs)
Баги — это ошибки в коде, которые обнаружились во время обследования реализованного решения (review) или тестирования. Баг появляется в бэклоге обычно после получения жалобы от пользователя или обнаружения его кем-то из команды.
Как правило, баги имеют высокий приоритет в бэклоге. Тем не менее, обсуждаются они точно так же как и все остальные элементы бэклога — при пересмотре бэклога или еженедельных Scrum-планерках.
Например: Новый элемент таск-листа появляется в середине списка.
Рефакторинг (refactoring)
Рефакторинг — это процесс переработки имеющегося кода без внешних изменений поведения в софте. Метод помогает добиться лучшей читаемости кода и делает его проще как по восприятию, так и сопровождению.
Иными словами, рефакторинг помогает проработать основу для дальнейшего соврешенствования функциональности и дальнейшем наращивания ценности.
Получение знаний (Knowledge Acquisition)
Задачи по добыче знаний сосредоточены на поискеновой информации и знаний для выполнения каких-то последующих задач.
Давайте представим, что есть пользовательская история, ваша команда разработчиков не знает как ее решать или она требует предварительной подготовки. Участникам команды будет назначена задача по добыче знаний, чтобы у них появилось понимание, как подойти к разработке этойпользовательской истории и всех аналогичных историй в будущем.
Например: Исследовать библиотеки плагинов WordPress и выбрать один из них для внедрения
Как управлять бэклогом продукта в Infinity
Добавить новую задачу в бэклог продукта не составит труда, если у вас есть шаблон Product Management. Вот что нужно сделать:
- Шаг 1: Откройте папку Backlog в шаблоне Product Management
- Шаг 2: Удалите все примеры задач или оставьте один в качестве шаблона
- Шаг 3: Создайте новую задачу кликнув на +Add new item под группой. Убедитесь, что вы добавляете задачу в правильную группу по типу - Story, Bug, Refactor, Knowledge.
- Шаг 4: Напишите задачу в поле Name
- Шаг 5: В поле Description можете кратко изложить задачу и добавить связанную с ней пользовательскую историю
- Шаг 6: Добавьте участника команды, ответственного за эту задачу
- Шаг 7: Добавьте уровень приоритете - обязательно прочитайте следующую главу, в которой мы разберем расстановку приоритетов в бэклоге
- Шаг 8: Добавьте статус To Do к наиболее приоритетным задачам, над которыми вы планируете начать работу на следующем спринте
- Шаг 9: После расстановки приоритетов и подготовки бэклога вы будете перемещать самые приоритетные задачи сразу в спринт перетаскиванием
Как определять приоритет задач в бэклоге с помощью метода MoSCoW
В процессе разработки продукта идеи, предложения и баги будут сыпаться на вас со всех сторон. Поэтому важно научиться определять приоритетность задач в бэклоге и убедиться в том, что первыми будут разрабатываться самые значимые идеи.
Проведя приоритезацию задач вы сможете разбить все задачи на три группы:
- Задачи, которые будут начаты в следующем спринте
- Задачи, которые будут разработаны позже
- Задачи, над которыми вы вообще не собираетесь работать
Так как же расставить приоритеты в бэклоге?
Метод MoSCoW: что это и зачем применяется, критерии, примеры
Расстановка приоритетов в бэклоге упрощает его управление. Есть несколько способов расставить приоритеты в бэклоге, мы рассмотрим один из самых популярных - метод MoSCoW.
Метод MoSCoW — это техника расстановки приоритетов. Она позволяет найти общий язык со всеми заинтересованными сторонами и обеспечить выполнение ключевых требований в первую очередь. Метод MoSCoW помогает распределить все запросы на 4 категории, что намного эффективнее:
Mo — Must Have (Обязательно): Наиболее жизненно важные требования, без которых вы (или ваши пользователи) не могут обходиться.
S — Should Have (Желательно): Эти требования важны, но не обязательно должны быть в следующем релизе.
Co — Could Have (Можно): Эти требования были бы кстати, но не так нужны как предыдущие (Should Have).
W — Won’t Have (Не нужны): Пользовательские истории (user story), которые обладают малой ценностью, значит к ним можно вернуться позже
Как только вы станете расставлять в бэклоге приоритеты, вам и заинтересованным сторонам станет гораздо понятнее над чем стоит работать в следующем спринте. Чтобы сделать расставленные приоритеты более явными, можно создать отдельные плашки для всех четырех уровней приоритета.
Чтобы сделать бэклог еще аккуратнее, можно создать отдельную папку, например, для элементов W (Won’t Have). В семплах Infinity есть папка, которая по умолчанию называется On Hold,в ней хранятся все задачи с низким приоритетом.
Иногда следует заглядывать в эту папку и проверять заслуженно ли те или иные задачи находятся в бэклоге или их пора убрать из списка.
Полностью придерживаться подхода MoSCoW не обязательно. Ради простоты можно создать в папке Backlog набор плашек под названием Priority и присвоить ему значения Mo - High, S - Medium, Co - Low, W - None. В таком случае элементы без приоритета попадут в папку On Hold, а остальные будут претендентами на реализацию в спринте.
Пример применения метода MoSCoW в Infinity
Вот как расставить приоритеты в бэклоге в шаблоне Infinity Product Management Template:
- Шаг 1: Откройте папку Backlog
- Шаг 2: Откройте элемент
- Шаг 3: Подцепите плашку MoSCoW
- Шаг 4: Повторите для каждого элемента из вашего бэклога
Чтобы объективно расставлять приоритеты задачам, нужно брать в учет несколько других факторов:
- Высокая ценность для пользователя
- Большая выгода для бизнеса
- Простота внедрения
- Время для внедрения
- Уровень риска
- Стоимость
- Зависимости между элементами
В моменте, когда вы будете решать какие элементы бэклога перейдут в следующий спринт, эти факторы будут иметь решающее значение. Поэтому это важно - иногда у вас есть задача со средним или низким приоритетом, которая не связана с риском, не требует особых затрат и очень проста в реализации. В таком случае можно подумать о включении этого пункта в спринт, потому что это будет простой, но приятной доработкой к следующему релизу.
Метод MoSCoW лучше всего осваивать на практике, поэтому мы добавили примеры задач в шаблон Product Management.
Груминг бэклога («Расчёсывание бэклога»): что это и зачем применяется, критерии, примеры
«Расчёсывание бэклога» — это процесс поддержания порядка в бэклоге, а также добавления необходимых деталей и оценок к каждой строке-идее. На такой встрече нужна вся команда: владелец продукта / продакт-менеджер, скрам-мастер (или техдиректор) и команда воплощения продукта (development team).
Груминг бэклога — это такая планерка scrum-команды, на которой разбираются составляющие бэклога: пользовательские истории, эпики, баги и прочее — все, что важно создать в последующие спринты.
В чем ценность груминга бэклога и почему важен ясный бэклог
Груминг бэклога много преимуществ. Впервую очередь устраняет путаницу, неопределенность и готовит команду к результативной работе на следующем спринте. При правильном подходе такие совещания помогают сократить время планирования спринта.
Кроме того, проработанные элементы бэклога гораздо проще оценивать и реализовывать.
Для получения этих преимуществ важно привлекать к участию в совещании всю команду разработки (или хотя бы ее большую часть).
Груминг должен быть направлен на получение более полного представления о каждом пункте бэклога. А также должно помочь каждому участнику команды понять, что требуется сделать. Все решения следует документировать для дальнейшего использования.
Чтобы встреча по прическе бэклога продукта прошла результативно, каждый участник команды должен знать свои обязанности:
- Владелец продукта или продакт-менеджер должен проводить совещания и следить за тем, чтобы все решения соответствовали общей стратегии развития продукта
- Скрам-мастер должен способствовать коммуникации между командой разработки и владельцем продукта
- Разработчики должны находить, документировать креативные решения для элементы из бэклога, делать оценку по времени, при необходимости разбивать элементы из бэклога на более мелкие задачи и вместе с другими участниками команды находить общие решения.
Если вся Scrum-команда вовлечена в процесс улучшения бэклога продукта, то планировать и проводить успешные и плодотворные спринты становится гораздо проще.