Беклог или бэклог что это
Бэклог продукта — совершенный список задач
Бэклогу продукта, как и человеку, нужны уход и внимание. А еще он должен быть открыт для других.
Просмотр тем
Agile-бэклог с правильно расставленными приоритетами не только упрощает планирование релизов и итераций. Из него команда узнает, над чем она будет работать. Вся внутренняя кухня скрыта от глаз клиента. Работа становится для заинтересованных лиц и других команд более предсказуемой, что особенно полезно, когда они ставят перед вами дополнительные задачи. Время на разработку становится фиксированным ресурсом.
Что такое бэклог продукта?
Бэклог продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале бэклога продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь. Скорость, с которой команда выполняет задачи бэклога, не зависит от желаний владельца продукта, а он, в свою очередь, не оказывает давления на команду. Напротив, команда разработки самостоятельно выбирает задачи из бэклога продукта, когда у нее есть необходимые ресурсы, выполняя их непрерывно (Kanban) или итерациями (Scrum).
Храните все в одном трекере задач. Не используйте несколько систем для отслеживания багов, требований и рабочих задач по разработке. Есть задача для команды разработчиков? Тогда информация о ней должна быть в одном бэклоге.
Два столпа бэклога продукта
В основе бэклога продукта находятся дорожная карта команды и требования. Инициативы дорожной карты делятся на несколько эпиков, а каждый эпик содержит несколько требований и пользовательских историй. Рассмотрим дорожную карту для вымышленного продукта «Команды в космосе».
Веб-сайт «Команды в космосе» — первая инициатива на дорожной карте, поэтому нам нужно разбить ее на эпики (обозначены на рисунке зеленым, синим и бирюзовым цветами) и пользовательские истории для каждого эпика.
Владелец продукта составляет из этих пользовательских историй единый список для команды разработчиков. Владелец продукта может упорядочить истории так, чтобы команда сначала выполнила один эпик полностью (слева). Как вариант, может быть важнее сначала протестировать бронирование билетов со скидкой, а для этого нужно реализовать истории из нескольких эпиков (справа). Оба варианта представлены ниже.
Что может повлиять на то, как владелец продукта расставляет приоритеты?
Хотя расстановкой приоритетов занимается владелец продукта, в процесс вовлечены и другие стороны. Успешность бэклога зависит от вклада и обратной связи, предоставленной клиентами, дизайнерами и командой разработчиков. Совместными усилиями они должны добиться оптимальной рабочей нагрузки между всеми участниками и обеспечить поставку продукта.
Правильное ведение бэклога
После создания бэклога важно регулярно корректировать его по мере выполнения программы. Владельцы продукта должны пересматривать бэклог перед каждым собранием по планированию итерации, чтобы уточнить расстановку приоритетов и внести изменения на основе выводов, сделанных в результате последней итерации. Регулярный пересмотр бэклога в кругах специалистов по Agile часто называют «грумингом» или «ведением бэклога» (некоторые используют термин «уточнение бэклога»).
Когда бэклог становится достаточно большим, владельцам продукта приходится выделять в нем группы краткосрочных и долгосрочных задач. Краткосрочные задачи нужно досконально проработать, прежде чем присвоить им этот статус. Для этого нужно составить полноценные пользовательские истории, обсудить все детали совместной работы с дизайнерами и разработчиками и оценить сложность разработки. Долгосрочные задачи могут быть продуманы не до конца, однако если команда разработчиков даст им приблизительную оценку, это поможет расставить приоритеты. Ключевое слово здесь — «приблизительная». Оценки поменяются, когда команда получит полное понимание долгосрочных задач и приступит к их выполнению.
Бэклог служит связующим звеном между владельцем продукта и командой разработчиков. Владелец продукта может в любое время поменять приоритеты в работе на основе обратной связи от клиентов, более точных прогнозов и новых требований. И все же следует избегать изменений в ходе работы, потому что они мешают команде разработчиков, негативно влияя на концентрацию, рабочий процесс и моральный дух.
Когда бэклог становится слишком большим, чтобы на него хватало ресурсов команды даже в долгосрочной перспективе, задачи, до которых никогда не дойдет очередь, можно закрывать. Помечайте такие задачи специальной меткой, например «Вне объема работ», в трекере задач команды, чтобы изучить их позднее.
Плохие примеры, которые лучше не повторять
Бэклоги продукта и верность команды принципам agile
Опытные владельцы продукта со всей ответственностью подходят к ведению бэклога продукта, чтобы он был надежным источником рабочих задач по проекту, которые предназначены для совместной работы.
Заинтересованные стороны будут оспаривать принятую очередность задач — и это хорошо. В результате обсуждения того, какие работы важнее, все приходят к общему представлению о приоритетности задач. Такие обсуждения способствуют формированию культуры, в которой приоритеты расставляются групповыми усилиями и все участники объединены общим взглядом на программу.
Кроме того, на основе бэклога продукта планируются итерации. В бэклог должны быть включены все рабочие задачи: пользовательские истории, баги, изменения в дизайне, технический долг, запросы клиентов, действия, намеченные по итогам ретроспективы, и т. д. Так рабочие задачи каждого участника будут рассмотрены на общем обсуждении перед каждой итерацией. Затем участники команды и владелец продукта с полным пониманием объемов задач и учетом обоюдных интересов принимают решения до начала итерации.
Владельцы продукта определяют важность рабочих задач в бэклоге, в то время как команда разработчиков определяет скорость работы над ними. Новым владельцам продукта, которые привыкли торопить команду, такой подход может оказаться не по душе. Подробнее см. в нашей статье о лимитах объема незавершенной работы и рабочем процессе.
Из рутины в приятный процесс: что такое бэклог продукта и как им управлять?
Менеджеры продукта и его собственники не могут не уделять серьезного внимания продуктовому бэклогу. Не только для облегчения планирования релизов и итераций, но и для оптимизации всего жизненного цикла продукта, над которым намерена работать команда.
Бэклог продукта (product backlog) — это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта. Этот список содержит краткие описания всех желаемых возможностей продукта.
Product manager или product owner представляют бэклог команде и управляют им, описывает его главные элементы во время митинга по планированию спринта. Описание бэклога следует производить на простом и доступном языке, без технических спецификаций, чтобы оно было понятно каждому в команде. Любые изменения и требования по продукту должны быть своевременно отражены в этой очереди задач.
Бэклог продукта vs бэклог спринта
Эти два компонента Scrum несут разный смысл, но их часто путают.
Бэклог спринта — это список определенных задач по воплощению в жизнь выбранных элементов бэклога продукта. Это список для оптимизации, которой команда займется в ближайший спринт, а также описание, каким образом они эту оптимизацию будут реализовывать.
Оба бэклога можно представить в обычной таблице Excel, однако сегодня для этих целей опытные менеджеры и собственники продуктов пользуются специальными инструментами для управления продуктом, позволяющими грамотно визуализировать состояние дел.
Бэклог продукта составляет product owner, а за бэклог спринта отвечает команда разработчиков. Еще одним важным отличием является время создания бэклога: Product backlog создается на самом первом планировании спринта, а Sprint backlog должен создаваться командой на каждом планировании нового спринта. Таким образом, первый бэклог живет на протяжении всей разработки продукта, а Sprint backlog — на протяжении 1-4 недель, то есть, в течение одного спринта.
В чем смысл бэклога продукта?
Работа над Agile-проектами не предполагает долгого документирования всех требования. Обычно product owner и другие члены команды начинают работу над проектом, отмечая все, что им нужно, для приоритизации бэклога. Уже такого бэклога достаточно для первого спринта. Затем его можно растить и менять.
Обычный бэклог продукта включает следующие пункты:
Элементы бэклога — это «пользовательские истории» или user stories. Такие элементы упорядочены в зависимости от их бизнес «веса». Чем выше в бэклоге конкретный элемент, тем скорее разработчики будут работать над ним. Верхние позиции будут более подробно описанными и четкими по сравнению с нижними элементами. Все они должны быть понятны для нетехнических членов команды и заинтересованных сторон.
Каждый элемент в product backlog имеет свою оценку, которую делают разработчики. Система оценивания используются для определения количества элементов, которые будут выбраны для определенного спринта.
Обычно команда добавляет нужные детали и оценки в элементы бэклога во время специального проекта, который называется backlog grooming или refinement.
Для чего нужен backlog refinement?
Backlog refinement (улучшение, оптимизация, «чистка») — это действие или мероприятие, во время которого команда добавляет детали, оценки и порядок в элементы продукта. Процесс не должен охватывать более 10% рабочего времени команды разработчиков.
Этот постоянный процесс означает сотрудничество собственника продукта и разработчиков, когда ими рассматриваются и пересматриваются все элементы продукта.
Чем бэклог продукта в Agile отличается от простого списка дел?
У бэклога продукта есть определенные свойства:
Что делать, если бэклог неустанно растет?
Фокус на ключевых приоритетах — одна из ключевых задач менеджера продукта или product owner. Однако очень часто у них нет времени изучать и отслеживать все новые возможности конкурентов. Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать. Как успевать отслеживать приоритеты, если идеи в бэклоге нарастают как снежный ком?
Решение можно найти в современных платформах для управления продуктами, таких как Hygger.io. Функционал платформы помогает справиться со следующими вопросами:
Структурирование бэклога
В бэклоге Hygger простой список идей представлен на двухмерной доске. Здесь вы найдете полезные ярлыки (Labels) и горизонтальные колонки (Swimlanes). Вы можете использовать столбцы на бэклог-панели, чтобы визуализировать рабочие этапы для идей:
Опция Labels может использоваться для обозначения идей от конкретных пользователей или от конкретных сотрудников.
Оценка идей
В Hygger вы можете оценить все свои идеи, используя 2 критерия: Value and Efforts. Сопоставление этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные из задач для ближайшей разработки.
Backlog Priority Chart
Все оцененные идеи могут быть показаны на графике Backlog Priority Chart. Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:
Каков бы ни был разрабатываемый продукт, услуга или сервис, оптимизация бэклога — это неотъемлемая часть функционала в управлении. Профессиональный product owner может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.
Как составлять бэклог: краткое руководство
Бэклог — это список требований к продукту. Чем подробнее он заполнен, тем эффективнее будет организована работа команды. Разумеется, при работе с ним сразу появляются вопросы: как правильно собрать и структурировать все требования и пожелания, а также чем может навредить беспорядок в бэклоге.
Работу с бэклогом стоит начинать со «скелета» — базовых функций, которые должны присутствовать в продукте. Здесь будет полезен план развития — Product Roadmap. Детализировать задачи можно с помощью User Stories, на основе которых строится Customer Journey Map. Разберёмся, что скрывается за этими английскими словами и как к ним подступиться.
Что это такое?
Product Roadmap (дорожная карта) — верхнеуровневый стратегический план, в котором отражено направление разработки вашего продукта. В идеале — со сроками реализации. Roadmap не даёт конкретных пояснений по каждой задаче — это общее видение проекта. Но при этом он содержит основные цели, миссию и объясняет предпосылки того, что вы делаете.
Пример дорожной карты
User Story (пользовательская история) — это упрощённый список требований клиента в виде истории, рассказанной на языке пользователя. По сути, это доходчивое описание, которому должны соответствовать новые фичи продукта, в противовес объёмной и сложной документации. В основе требований — удобство и ценность для пользователей.
Например, User Story может звучать так: «Я хотел бы видеть всплывающие подсказки при входе в приложение, если прихожу сюда впервые».
Customer Journey Map (карта путешествия клиента) — это визуализированный опыт пользователя продукта с учётом его целей, эмоций, барьеров, мотивов. Карта составляется под определённую User Story, отражает путь клиента к продукту, показывает «узкие места», даёт понять, над какими этапами и метриками нужно работать в первую очередь.
Очень важно всегда быть в контексте пользователя, поэтому CJM нужно регулярно обновлять.
Пример CJM онлайн-магазина
Как на основании этих документов собрать бэклог?
Нужно регулярно возвращаться к бэклогу, чтобы актуализировать его. По мере развития продукта часть задач будет терять актуальность, трансформироваться или менять приоритет. А отслеживание бэклога позволит команде быть в контексте происходящего и не тратить время на долгое обсуждение плана действий.
Каждая задача должна быть конкретной, конечной и достижимой — например, исправление конкретной ошибки или внедрение определённой фичи. Именно поэтому в бэклоге собирают только те задачи, которые закрывают среднесрочные и краткосрочные цели проекта. Долгосрочные цели обычно не так хорошо формализованы, чтобы легко разложить задачу на спринты и передать команде.
Название задачи всегда должно быть ёмким и понятным, отражать её суть и не вводить в заблуждение.
В графе «Важность» проставляется значимость фичи для проекта. Оценку могут дать менеджер или команда, но она будет субъективна. Также можно сделать выводы о важности задачи на основе накопленных знаний о пользователях: сколько из них будет охвачено новыми функциями и как фичи повлияют на пользовательскую историю.
Трудозатраты оценивает команда. Scrum Poker или метод KJ помогут упростить этот процесс.
В графе «Демонстрация» фиксируется способ, который поможет понять, успешно ли реализована функциональность.
В поле «Тип задачи» мы указываем направление, с которым работаем:
Пропорции задач разных типов в бэклоге зависят от этапа жизненного цикла продукта. На старте в приоритет ставятся новые функции, а технический долг откладывается на потом. На этапе зрелости и масштабирования куда важнее поддерживать уровень сервиса и качество продукта.
Всё это позволяет расставить приоритеты и понять, что будет взято в первые два спринта, а что — отложено на более долгий срок.
Влиять на появление новых задач в бэклоге может не только менеджер продукта, но и команда, инвесторы, конкуренты и даже клиенты. Важно внимательно собирать информацию из разных источников, оценивать её и на основе данных фильтровать задачи и брать их в работу.
Научиться вести работу над проектами в разных сферах вы сможете на факультете проджект-менеджмента GeekUniversity.
Бэклог — это список требований к продукту. Чем подробнее он заполнен, тем эффективнее будет организована работа команды. Разумеется, при работе с ним сразу появляются вопросы: как правильно собрать и структурировать все требования и пожелания, а также чем может навредить беспорядок в бэклоге.
Работу с бэклогом стоит начинать со «скелета» — базовых функций, которые должны присутствовать в продукте. Здесь будет полезен план развития — Product Roadmap. Детализировать задачи можно с помощью User Stories, на основе которых строится Customer Journey Map. Разберёмся, что скрывается за этими английскими словами и как к ним подступиться.
Что это такое?
Product Roadmap (дорожная карта) — верхнеуровневый стратегический план, в котором отражено направление разработки вашего продукта. В идеале — со сроками реализации. Roadmap не даёт конкретных пояснений по каждой задаче — это общее видение проекта. Но при этом он содержит основные цели, миссию и объясняет предпосылки того, что вы делаете.
Пример дорожной карты
User Story (пользовательская история) — это упрощённый список требований клиента в виде истории, рассказанной на языке пользователя. По сути, это доходчивое описание, которому должны соответствовать новые фичи продукта, в противовес объёмной и сложной документации. В основе требований — удобство и ценность для пользователей.
Например, User Story может звучать так: «Я хотел бы видеть всплывающие подсказки при входе в приложение, если прихожу сюда впервые».
Customer Journey Map (карта путешествия клиента) — это визуализированный опыт пользователя продукта с учётом его целей, эмоций, барьеров, мотивов. Карта составляется под определённую User Story, отражает путь клиента к продукту, показывает «узкие места», даёт понять, над какими этапами и метриками нужно работать в первую очередь.
Очень важно всегда быть в контексте пользователя, поэтому CJM нужно регулярно обновлять.
Пример CJM онлайн-магазина
Как на основании этих документов собрать бэклог?
Нужно регулярно возвращаться к бэклогу, чтобы актуализировать его. По мере развития продукта часть задач будет терять актуальность, трансформироваться или менять приоритет. А отслеживание бэклога позволит команде быть в контексте происходящего и не тратить время на долгое обсуждение плана действий.
Каждая задача должна быть конкретной, конечной и достижимой — например, исправление конкретной ошибки или внедрение определённой фичи. Именно поэтому в бэклоге собирают только те задачи, которые закрывают среднесрочные и краткосрочные цели проекта. Долгосрочные цели обычно не так хорошо формализованы, чтобы легко разложить задачу на спринты и передать команде.
Название задачи всегда должно быть ёмким и понятным, отражать её суть и не вводить в заблуждение.
В графе «Важность» проставляется значимость фичи для проекта. Оценку могут дать менеджер или команда, но она будет субъективна. Также можно сделать выводы о важности задачи на основе накопленных знаний о пользователях: сколько из них будет охвачено новыми функциями и как фичи повлияют на пользовательскую историю.
Трудозатраты оценивает команда. Scrum Poker или метод KJ помогут упростить этот процесс.
В графе «Демонстрация» фиксируется способ, который поможет понять, успешно ли реализована функциональность.
В поле «Тип задачи» мы указываем направление, с которым работаем:
Пропорции задач разных типов в бэклоге зависят от этапа жизненного цикла продукта. На старте в приоритет ставятся новые функции, а технический долг откладывается на потом. На этапе зрелости и масштабирования куда важнее поддерживать уровень сервиса и качество продукта.
Всё это позволяет расставить приоритеты и понять, что будет взято в первые два спринта, а что — отложено на более долгий срок.
Влиять на появление новых задач в бэклоге может не только менеджер продукта, но и команда, инвесторы, конкуренты и даже клиенты. Важно внимательно собирать информацию из разных источников, оценивать её и на основе данных фильтровать задачи и брать их в работу.
Научиться вести работу над проектами в разных сферах вы сможете на факультете проджект-менеджмента GeekUniversity.
Что такое бэклог и как его уменьшить
Писать про сложные вещи всегда легче, чем про простые. В первую очередь потому, что про простые вещи ты всегда думаешь “ну это же элементарно, это все знают, что тут вообще можно рассказать?”. А потом посмотришь как это “элементарное” кто-нибудь применяет – и сразу вспоминается вот эта картинка:
Поэтому давайте сегодня поговорим про такую супер-базовую вещь, как бэклог. Опытные руководители проектов проходят мимо, новичкам и особенно тем, что только собирается в руководители проектов – читать обязательно. Попробую рассказать простыми словами и, надеюсь, бэклогов, которыми невозможно пользоваться, станет хоть немного меньше.
Возможно, какие-то моменты в тексте покажутся вам гипертрофированными, но, честное слово, я со всем этим сталкивалась на практике, иначе этого поста не было бы.
Что такое бэклог
Бэклог – это структурированный список актуальных задач, которые вам или вашей команде необходимо сделать, будь это функции в продукте, который вы разрабатываете, или обращения в техподдержку, которые вам необходимо выполнить. Ключевое слово тут – “актуальных”, а это значит, что бэклог регулярно пересматривается, изменяется и дополняется, чтобы соответствовать потребностям компании в текущий момент. Если упрощать еще больше, то бэклог – это просто аккуратно заполненная табличка с вменяемым и понятным всем членам команды описанием задач, статусом на текущий момент и выставленным приоритетом, которую команда регулярно отсматривает, выбрасывает оттуда то, что устарело, неактуально или несет слишком мало ценности относительно затрат времени или денег, отмечает то, что выполнено, и добавляет вновь появившиеся задачи.
Я против обобщений типа “бэклог – это только при разработке по SCRUM” или “бэклог нужен только в продуктовой разработке”. Бэклог – универсальная штука, необходимая не только в ИТ или в проектной деятельности, это инструмент упорядочивания и превращения в систему того, что “влетает” в вас и вашу команду из внешнего мира.
Это, конечно, пример, процесс может выглядеть как угодно. Важно, что систематизированный подход позволяет как ничего не потерять из бэклога, так и оптимизировать трудозатраты, делая оценку для новых элементов с определенной регулярностью, а не по мере их поступления. Плюс элементы бэклога имеют свойство “отлежаться и стать неактуальными”, и вот это “время тишины” между поступлением и оценкой позволяет рассматривать их уже на холодную голову. А еще при просмотре полного бэклога уже сложнее начать истерить на тему “этот элемент надо сделать срочно”, так как перед глазами одновременно еще десятки или даже сотни таких же элементов, конкурирующих за время и ресурс команды.
У меня вот есть отдельные бэклоги рабочих и личных задач, из которого я “надергиваю” себе задач на спринт (рабочий спринт у меня – неделя, личный – месяц, причем личный связан с бэклогом мужа через чат-бот в телеграме). Но это прямо тема для отдельного большого поста про практики личной эффективности.
Бэклог можно вести в Excel или в специализированном ПО типа той же JIRA, главное – чтобы была возможность структурирования и минимального анализа элементов в этом бэклоге. Из чего следует, что бэклог в Word – это очень, очень, очень плохая практика, даже если элементы этого бэклога раскрашивать текстовыделетелем или делать в Word табличку. Хотя после недавно виденного бэклога большой корпоративной аналитической системы в Outlook меня уже сложно чем-то удивить, наверное.
Какие бэклоги бывают?
Как уже было упомянуто выше, бэклог как инструмент используется много где. Самые популярные бэклоги, которые можно встретить:
Какая информация должна быть в бэклоге?
Программа минимум, чтобы бэклог можно было использовать без дергающегося глаза:
Наверное, это минимальный набор обязательных полей. Разумеется, он недостаточный для полноценной работы, просто остальные поля будут зависеть от специфики бэклога – если вы работаете по скраму, то там будут отсылки на эпики или оценки в сторипоинтах, если это бэклог запросов в техподдержку – то информация о затронутой системе или части системы, если это бэклог проектных инициатив – ФИО сотрудника, занимающегося проработкой, потенциальный бюджет и сроки и т.д. Вариантов миллион и, как правило, поля бэклога дополняются и актуализируются в ходе работы с ним.
Если тема бэклога вам близка, то много романтических подробностей для продвинутых РМов есть в посте про definition of ready, definiton of done и acceptance criteria.
Груминг и рефаймент бэклога
Если не вдаваться в разборки между адептами скрама и других методов разработки, то, по большому счету, оба термина – груминг бэклога (backlog grooming) или “зачистка” бэклога (backlog refinement) про одно и то же – это регулярный пересмотр бэклога, уточнение его элементов (причем какие-то элементы при этом могут быть объединены в один, а какие-то – разбиты на несколько), определение их ценности и трудоемкости и проч.
Каждая команда организует это так, как удобно ей, пример того, как может выглядеть этот процесс, я приводила выше. В SCRUM вроде бы есть условный пункт о том, что работа с бэклогом – это около 10% времени команды, но, на мой взгляд, цифра может отличаться в разы в любую сторону в зависимости от процесса.
Как разобрать бэклог? Что делать, если бэклог накопился на годы вперед?
Вообще очень большой активный бэклог – признак непрофессионализма и неумения приоритезировать. Да-да-да, а не признак недостатка ресурсов, как вы уже, наверное, подумали. Ну потому что у профессионала всегда есть опция эскалировать недостаток ресурсов с конкретными расчетами и договориться либо об урезании бэклога и дальнейшем контроле объема по определенным принципам либо о выделении новых людей в команду. А жевать на каждом ревью по 1000 строк бэклога, про которые даже инициаторы этих строка уже пару лет как забыли – ну такое себе, лучше уж сразу на hh.
Собственно, это и есть рецепт – если видите, что бэклог стал огромным неуправляемым монстром и теперь на ревью вам нужно по несколько часов каждый раз, или команда на ревью грустно вздыхает и говорит “ну а смысл обсуждать еще раз это все” – с этим нужно что-то делать.
Волшебной таблетки нет, все, что вы можете – это:
В комплексе это обычно срабатывает.
Мой внутренний голос говорит, что лично мне комфортно с бэклогом на полгода вперед, но, думаю, тут у всех свои границы.
Пример бэклога
Вроде бы все написано выше, и пример бэклога вряд ли добавит этому посту большой ценности, но все же – вот ниже пример бэклога по одной из моих производственных систем. Как видите – я очень уважаю условное форматирование и считаю, что это сильно упрощает восприятие. Кстати, забавно, но на мою первую работу руководителем проекта меня взяли за умение пользоваться условным форматированием в Excel, вроде бы банальная функция, но, как потом рассказывал мой непосредственный руководитель, с ней на тестовом задании мало кто справлялся.
Вот и все, что я могу сказать про бэклог, если вы нашли хоть что-то новое – значит, пара часов на пост была потрачена не зря.
Полезно? Нужны еще такие посты про базовые вещи или нет? И, если нужны, то про что было бы интересно почитать?