В разработке программного обеспечения важно не только создать хороший продукт, но и правильно организовать работу команды. Процессы должны быть выстроены таким образом, чтобы задачи закрывались стабильно и своевременно. Помочь выстроить командную работу помогает бэклог.
В этой статье подробно разбираемся в том, что представляет собой бэклог, в чем его польза и как правильно с этим инструментом работать, чтобы достичь высот в управлении проектами.
Бэклог
Говоря простыми словами, бэклог (от англ. backlog) — это список задач или требований, которые нужно выполнить в рамках проекта или разработки программного обеспечения. Бэклог широко используется в различных методологиях управления проектами — от каскадной модели до Kanban-метода.
Изначально сам термин возник в производственной сфере. «Бэклогом» называли накопившийся запас невыполненных заданий или заказов — примерно то же самое, что сейчас называется «техническим долгом». С распространением практик проектного управления в IT-сфере бэклогом стали называть список задач и возможностей, которые нужно реализовать в продукте.
В отличие от производственной сферы, бэклог в IT отличается динамикой. В течение жизни проекта список задач и требований постоянно обновляется и меняется в зависимости от потребностей заказчика и изменений внешних условий. Какие-то задачи теряют актуальность и покидают список, а на их место могут приходить новые или не приходить вовсе.
Значение бэклога для проекта
По факту бэклог — это не просто список задач, а настоящее сердце вашего проекта. Бэклог отличается рядом важных особенностей:
- Бэклог помогает команде четко планировать свою работу. В нем собраны все задачи и требования. Поэтому команде проще выбрать, на чем сосредоточиться в настоящий момент, а также спланировать свою работу на день, неделю или месяц.
- Бэклог способствует прозрачной коммуникации в команде. Доступ к списку задач у команды общий. Соответственно, каждый участник команды знает, чем кто занимается. Это помогает избежать недопониманий в работе. Например, выполнения одной задачи разными людьми.
- Еще одна особенность бэклога — его гибкость и динамичность. В традиционных методиках планирования все задачи, а также их исполнители и методы решения определяются заранее. В свою очередь, бэклог постоянно обновляется и адаптируется к изменяющимся условиям и потребностям заказчика. Поэтому команда быстро реагирует на изменения — переключает фокус на новые направления работы или отказывается от некоторых планов.
Чем бэклог отличается от плана проекта?
Основное различие между бэклогом и планом проекта заключается в их функциональности. Как уже замечено ранее, бэклог — документ динамический, и в процессе разработки продукта он меняется. В нем уже заложена вероятность изменения требований клиента/заказчика.
План проекта чаще всего создается на начальном этапе и меняется только в экстренных случаях. Как правило, в этот документ включают конкретные сроки работ, количество ресурсов, а также бюджет проекта.
Еще одно важное отличие — цель этих документов. Бэклог создается для непосредственной работы с ним, он ведется непрерывно. А вот план проекта чаще всего пишется для дальнейшего согласования. Например, с клиентом или руководством.
Бэклог в контексте Agile
В гибких методологиях бэклог — это ключевой документ, с помощью которого владелец продукта контролирует разработку. Этот список служит фундаментом для планирования и управления работой команды.
Основные компоненты бэклога
Бэклог — сущность комплексная, и состоит из множества элементов, которыми команда постепенно наполняет список. Как правило, выделяют 3 разновидности элементов бэклога:
- Пользовательские истории — краткие описания функционала продукта с точки зрения конечного пользователя. Отвечает на вопрос «что должно быть в продукте».
- Задачи — это конкретные шаги, действия или операции, которые нужны для реализации пользовательских историй. Кратко — «что нужно сделать».
- Ошибки — какие-либо проблемы, которые обнаружились в процессе работы над продуктом и требуют исправления. В контексте разработки софта под ошибками чаще всего подразумеваются баги. Проще говоря, «так быть не должно».
Это наиболее распространенные типы элементов бэклога, которые используются в разработке ПО. Важно иметь в виду, что подойдут они далеко не для всех проектов.
В некоторых командах граница между «Задачами» и «Ошибками» может носить условный характер. Например, если фронтендеру для правки достаточно будет отредактировать пару строчек кода, то ошибка на бэкенде уже может потребовать отдельной задачи на несколько часов работы.
В зависимости от сферы бизнеса или рода деятельности команды, вы можете создавать свои типы элементов бэклога — будь то всевозможные разновидности «ошибок» или даже сделки.
Как вести бэклог?
Каким бы простым не казалось формирование бэклога, нельзя просто взять и добавить в него все задачи и требования заказчика. Опять же бэклог требует постоянного взаимодействия команды — не только между собой, но и с заказчиком. Чтобы корректно сформировать бэклог, следует придерживаться нескольких простых принципов.
Понимание потребностей пользователей
Если речь идет о разработке продукта, бэклог должен отражать реальные потребности пользователя и решать его проблемы. Для этого необходимо активно вовлекать заказчиков и конечных пользователей в процесс формирования бэклога. Например, собирать с потенциальных пользователей обратную связь, проводить продуктовые исследования или глубинные интервью.
Приоритизация задач
Задачам в бэклоге нужно периодически расставлять приоритеты в соответствии с их важностью и ценностью для достижения целей проекта. Это помогает команде сосредоточиться на выполнении наиболее важных задач.
Для приоритизации задач существуют разные методики — например, матрица Эйзенхауэра или ICE Scoring. Подробнее о способах приоритизации бэклога мы рассказываем в этой статье.
Декомпозиция
Задачи должны быть понятными и выполнимыми. Для этого крупные задания следует декомпозировать — разбивать на маленькие. Так вы упростите работу над проектом для исполнителей задач и увеличите прозрачность работы. Участники команды смогут быстрее понять, что нужно делать, а руководитель — увидит и поймет, чем заняты его подчиненные.
В идеале задачи лучше формулировать по системе SMART. Это методика постановки целей, которая помогает максимально упростить и в то же время конкретизировать задачу для исполнителя. Задача по SMART должна быть:
- конкретной — заключаться в конкретном действии;
- измеримой — иметь конкретный результат;
- достижимой — проще говоря, выполнимой;
- значимой — приближать к выполнению цели проекта;
- ограниченной во времени — чтобы не потерять актуальность.
Основные правила управления бэклогом
Регулярное обновление
Требования к продукту могут меняться — из-за новых тенденций рынка, изменения позиционирования продукта или поведения конкурентов. Поэтому, чтобы бэклог не терял свою актуальность, его нужно регулярно обновлять и корректировать.
Новые задачи могут появляться хоть ежедневно. Например, если небольшая ошибка раскрыла команде некую фундаментальную проблему внутри продукта.
Прозрачность и доступность
Бэклог должен быть доступен всем участникам команды для просмотра и обсуждения. Чем прозрачнее бэклог, тем лучше команда будет понимать цели проекта, и тем выше будет уровень ее вовлеченности.
На практике это правило заключается в следующих моментах:
- любой из участников проекта может в любой момент посмотреть, какие задачи взяты в работу, а какие ждут своего часа в списке;
- исполнители похожих или взаимосвязанных заданий могут работать вместе;
- снижается риск двойной работы — задачу не возьмут в работу, если ей кто-то уже занимается.
Коллективное принятие решений
Решения о расстановке приоритетов и изменениях в бэклоге должны производиться коллективно — при участии заказчика и разработчиков. Это помогает обеспечить:
- баланс интересов заказчика и команды;
- актуальность бэклога и его соответствие целям проекта.
Чтобы обсудить и пересмотреть содержимое бэклога, команда проводит соответствующие мероприятия. Например, во фреймворке Scrum по окончании каждой итерации проводится sprint review. В Kanban-методе для этих целей используются каденции — периодические встречи, в рамках которых команда определяет, на каком типе задач следует сосредоточиться.
Обратная связь
Чтобы корректировать и дополнять бэклог в соответствии с изменяющимися требованиями и ожиданиями, команда поддерживает постоянную связь с заказчиком и/или конечными пользователями.
Например, если заказчик заметил, что конкуренты изменили позиционирование продукта, он сообщает об этом команде. Далее участники разработки совместно решают, отразится ли это на их собственном продукте, следует ли взять в работу новые задачи с учетом этих изменений.
Итеративный подход
Лучше всего бэклог работает в сочетании с итеративным подходом. Например, во фреймворках Scrum и Scrumban, где используются спринты. За счет планирования следующих итераций команда пересматривает и обновляет бэклог на основе текущих приоритетов и полученных результатов.
Например, владелец продукта учитывает, каких результатов добилась команда в предыдущем спринте, достигла ли она поставленных целей. Если же последние не были достигнуты, то команда оценивает, сколько задач ей досталось «в наследство» в качестве техдолга. На основе этой информации команда решает, сколько времени следует заложить в следующей итерации, чтобы и закрыть техдолг, и достичь актуальных целей в срок.
Анализ данных и метрик
Использование данных и метрик процесса разработки помогает оценивать эффективность работы над задачами в бэклоге и принимать взвешенные решения о его дальнейшем развитии.
Этапы формирования бэклога
- Определение целей проекта. Фактически этот этап начинается с постановки ТЗ и плана проекта. Будущая команда уже должна четко понимать цели и ожидания заказчика.
- Сбор требований. На этом этапе собираются все «хотелки» от заказчика, пользователей и других заинтересованных сторон. Это могут быть пользовательские истории, функциональные и нефункциональные требования или конкретные задачи. На этом этапе проводятся также продуктовые исследования.
- Приоритизация. Полученные требования приоритизируются по значимости. Из требований и пользовательских историй начинают формироваться задачи. Наиболее важные из них распределяются по первым итерациям проекта.
- Декомпозиция. Большие и сложные задачи разбиваются на мелкие и управляемые подзадачи. Ими уже наполняют первые спринты.
- Оценка и присвоение баллов сложности. Каждой задаче или требованию стоит присвоить оценку сложности или объем работы. Например, в часах, человеко-часах или баллах Story Points, как это предусмотрено в Scrum. Это поможет разработчикам понять, сколько времени и усилий потребуется на ту или иную задачу, а также планировать свой рабочий день.
- Обновление и актуализация бэклога. Бэклог должен постоянно обновляться, чтобы соответствовать меняющимся требованиям и другим условиям проекта. Команде надлежит регулярно проводить соответствующие ревью. В рамках этого мероприятия добавляются новые задачи, уточняются требования и изменяются приоритеты.
Типичные ошибки ведения бэклога (и как их избежать)
- Непонятные или неоднозначные требования. Как говорится, «каков бриф — таков и креатив». Непонимание требований — это некорректные ТЗ по задачам, неверные результаты, бесконечные правки и ошибки в продукте. Все это стоит проекту времени и ресурсов. Убедитесь в том, что вы говорите с заказчиком на одном языке, а команда понимает, что от нее ожидают.
- Переполненный бэклог. Раздутый список задач может затянуть процесс разработки и сбить фокус команды. Проверьте, все ли элементы бэклога актуальны — устаревшие или ненужные элементы можно удалить.
- Недостаточная приоритизация. Если задачи в бэклоге не имеют четких приоритетов, команда будет просто терять время. Проводите регулярные обсуждения с заказчиком, чтобы уточнить приоритеты проекта.
- Отсутствие обновлений бэклога. Если бэклог не обновляется или обновляется редко, он устаревает и не соотносится с реалиями проекта. Избежать этой ошибки помогут ревью бэклога и обсуждения с заказчиком.
Инструменты для ведения бэклога
Бэклог должен быть доступен для всей команды. А для прозрачности рабочих процессов бэклог обычно используется в связке с доской для задач. Ведь именно на на нее попадают элементы бэклога.
Держать весь объем требований к проекту можно в уме или в рабочих документах. Но лучше использовать специальные инструменты для ведения бэклога.
Физическая доска с карточками
Наиболее простой и архаичный способ ведения бэклога. Это может пробковая доска со стикерами на кнопках или маркерная доска, на которой команда пишет названия задач и этапы их выполнения. Способ не самый удобный — нужно много канцелярских принадлежностей, кнопки теряются, а бумажные карточки быстро приходят в негодность.
Таблицы Excel или Google Sheets
Пользовательские истории и задачи с оценками можно хранить в электронном виде — с помощью простых таблиц. Удобство этих инструментов заключается в том, что можно использовать формулы для подсчета продуктивности команды. Увы, на этом удобства таблиц заканчиваются.
Таск-менеджеры
Это специальный софт для управления проектами. Наиболее известные таск-менеджеры — Jira и Trello. К ним также относится и наш сервис — Аспро.Agile.
В Аспро.Agile есть целый набор инструментов для систематизации бэклога:
- спринты для итеративной работы над проектов;
- эпики для крупных задач, выполнение которых требует нескольких итераций;
- теги для поиска задач и других элементов бэклога в списке;
- кастомные типы элементов бэклога для создания своих разновидностей задач.
А также:
- удобная настраиваемая доска для задач;
- модуль отчетов о продуктивности команды и отдельных ее участников;
- встроенный мессенджер для коммуникации без перехода в сторонние мессенджеры.
Таким образом, таск-менеджеры — это не просто наиболее удобный инструмент ведения бэклога, но и полноценная среда для работы над проектами вместе с командой.
В каких проектах используется бэклог?
Мы много говорим о том, что бэклог используется в IT. Но эта сфера бизнеса — неоднородная. Внутри IT существуют разные направления, в которых может различаться специфика ведения бэклога:
- разработка ПО;
- управление продуктом;
- техническая поддержка продукта.
Поскольку бэклог — это мощный инструмент проектного управления, использовать его можно и за пределами IT-сферы. Особое распространение он получил в отраслях, где применяется Agile:
- маркетинг и реклама;
- образование;
- дизайн;
- банковское дело;
- проектное управление.
Бэклог, как инструмент, также можно использовать и в отрыве от Agile-методологии. Особенно если специфика рабочих процессов и бизнеса позволяет придерживаться правил ведения бэклога. Например:
- образование;
- издательское дело;
- частное строительство.
Подводим итоги
Бэклог — это больше, чем список задач или документ. Это сущность всего вашего проекта. Бэклог не только дает команде понять, над чем она работает, но и помогает выстроить прозрачный рабочий процесс.
Чтобы от бэклога была польза для проекта, его нужно правильно вести:
- требования к продукту — регулярно актуализировать;
- содержимое бэклога — обновлять, устаревшее — удалять;
- обеспечивать доступ к бэклогу всей команде, а решения об изменениях в нем — принимать совместно;
- сочетать бэклог с итеративным подходом — с проведением соответствующих ритуалов и мероприятий;
- расставлять приоритеты для всех элементов бэклога;
- сложные задачи — декомпозировать.
Правильно составленный бэклог — это инструмент, который превращает команду в отлаженный механизм. Он также помогает минимизировать множество рисков бизнеса, сохранить ресурсы команды и сэкономить время всех участников проекта.