Всем привет! В этом видео мы рассмотрим как начинается разработка инновационного продукта в Scrum. Что такое бэклог продукта? Что такое пользовательские истории? Бэклог продукта - это такой артефакт Scrum, который содержит в себе все фичи, функции, улучшения, исправления для будущей реализации в нашем продукте. Это такой список пожеланий заказчика, который обладает определенными особенностями. Он плоский, приоритезированный, неоднородный, ценностно-ориентированный и живой. Что это означает? Я расскажу в этом видео. Каждый элемент такого списка, должен содержать в себе описание этого пожелания заказчика, приоритет, то есть положение бэклоге, оценку размера, то есть, насколько сложно будет команде разработки его реализовать в нашем продукте и оценку ценности, то есть, насколько данный элемент ценен для нашего заказчика. Давайте посмотрим, что значит плоский приоритезированный список. Это означает, что мы можем однозначно сказать, какой элемент бэклога нам требуется реализовать вслед за текущим. Принцип приоритезации выбирается очень простой. Сверху бэклога должны находиться самые ценные элементы и при этом самые маленькие, то есть такие, которые команда разработки может реализовать быстрее всего. Про оценку мы еще поговорим в следующих видео. Неоднородный список означает, что он может включать в себя элементы разного размера. Как правило, выделяют три типа элементов по размеру. Это пользовательская история. Главное требование к таким элементам одно. Команда разработки должна иметь возможность реализовать его в продукте за один спринт. Следующий элемент, они чуть побольше называются Ipic или по русски эпосами. Они уже не помещаются в один спринт и большие наименее определенные пожелания заказчика называются темами. Ценностно-ориентированный список означает, что каждый элемент бэклога несет ценность для нашего заказчика. Чтобы разобраться, что это означает. Давайте поговорим про такую практику, которая называется пользовательские истории. Пользовательская история -это один из способов описания элементов бэклога. Выглядит он так, мы должны сформулировать ожидания или пожелания заказчика в продукте в следующем формате. Я, как пользователь такой-то роли, хочу или могу выполнить определенные действие в нашем продукте, чтобы получить какую-то ценность для себя. Давайте разберем пример пользовательских историй на представим, что мы делаем продукт приложение для заказа такси. Как могли бы выглядеть user-stories в нашем или пользовательские истории в нашем бэклоге. Например, я как пассажир хочу видеть такси на карте, чтобы понимать, когда мне нужно выходить. Или другой пример, для другой пользовательской роли. Я как таксист хочу, чтобы клиент получал уведомление о том, что я близко, чтобы меньше его ждать. Чуть более подробнее вы можете рассмотреть практику пользовательских историй в книге Майка Кона, которая называется User Stories Applied. А теперь чуть более продвинутая тема. Если вы уже работали по Scrum, рано или поздно у вас может возникнуть вопрос, а должны ли мы включать в бэклог продукта например баги, то есть наши дефекты в нашей системе. Ответ на этот вопрос можно найти в такой практике, которая называется раскрась свой бэклог. Она делит все элементы бэклога на четыре категории. Первая категория называется фичи, то есть ценные элементы, такие элементы, которые несут ценность для нашего заказчика. Вторая категория, называется дефектами или багами. Это то, что не несет ценности, но мы должны их исправить. Еще одна категория, называется невидимые или архитектурные функции. Они не несут никакой прямой ценности для нашего заказчика. Но, если мы их реализуем, это может помочь к примеру команде разработки в следующих спринтах, реализовать больше ценных элементов. И четвертая категория называется техническим долгом. Технический долг - это, такие накопившиеся не идеальные решения технические в нашей архитектуре продукта. Они не несут ценность и более того, отнимают время команды при реализации ценных элементов. Хорошей практикой является уделение определенного количества времени, каждый спринт на то, чтобы улучшать эту внутреннюю архитектуру и держать технический долг под контролем. Это то, что программисты называют рефакторингом. То есть, улучшение внутренней структуры системы без изменения поведения внешнего для конечных пользователей. В простейшем виде бэклог продукта можно ввести в обыкновенные таблицы, например, в excel или в google docs. Конечно же можно использовать и другие более продвинутые инструменты, такие как JIRA, Utrecht, трела и другие. В начале я сказал, что бэклог - это живой документ. То есть, он может и не просто может а меняется прямо по ходу разработки продукта. Почему это абсолютно нормально? Дело в том, что Scrum - это фреймворк для разработки комплексных продуктов и комплексные продукты находятся в нашем запутанном домене. Это означает, что изменение требований к таким продуктам по ходу разработки это абсолютно нормально и это позволяет в конечном итоге заказчику получить более ценный продукт. Давайте подведем итог. Бэклог это бэклог продукта, это такой список пожеланий заказчика. Это единственный источник работы для команды разработки. Это список плоский, приоритезированный, неоднородный, ценностно-ориентированный и живой. При этом владеет бэклогом продукта владелец продукта. И функции и цели владельца продукта в Scrum-команде мы как раз рассмотрим в следующем видео.
