Продуктовый бэклог — это критически важный компонент разработки продукта по Agile. Это живой документ, в котором перечислены все функции, требования, улучшения и исправления, которые необходимо разработать для выпуска продукта. Эффективное управление продукт-бэклогом необходимо для обеспечения соответствия продукта потребностям пользователей и заинтересованных сторон. Рамочная модель DEEP — это набор руководящих принципов, которые помогают командам эффективно управлять продукт-бэклогом.
Что такое рамочная модель DEEP
DEEP означает детально, соответствующим образом, оценено, возникает и приоритизировано. Каждый элемент в продукт-бэклоге должен быть детально описан, оценен в баллах истории, возникающим и приоритизированным на основе нескольких факторов, таких как ценность для пользователя, ценность для бизнеса, техническая осуществимость, сложность и зависимости. Следуя рамочной модели DEEP, команды могут эффективно управлять продукт-бэклогом, обеспечивая, чтобы элементы в бэклоге были соответствующим образом детализированы, оценены, возникали и приоритизированы.
Вот краткий обзор каждого элемента рамочной модели DEEP:
- Детально, соответствующим образом: Каждый элемент в продукт-бэклоге должен быть детально описан, чтобы команда имела четкое понимание того, что необходимо разработать. Уровень детализации должен быть достаточным для обеспечения ясности и направления для команды разработки.
- Оценено: Каждый элемент в продукт-бэклоге должен быть оценен в баллах истории, чтобы понять уровень усилий, необходимых для разработки. Баллы истории используются для оценки объема работы, необходимого для завершения элемента.
- Возникающий: Продуктовый бэклог — это живой документ, который постоянно обновляется по мере того, как команда получает более глубокое понимание требований к продукту. Элементы могут быть добавлены, удалены или обновлены в зависимости от изменений в требованиях к продукту.
- Приоритизировано: Продуктовый бэклог должен быть приоритизирован на основе нескольких факторов, таких как ценность для пользователя, ценность для бизнеса, техническая осуществимость, сложность и зависимости. Приоритизация помогает команде разработки сосредоточиться на наиболее важных элементах в первую очередь.
Следуя рамочной модели DEEP, команды могут эффективно управлять продукт-бэклогом, обеспечивая, что элементы в бэклоге соответствующим образом детализированы, оценены, возникают и приоритизированы. Это помогает команде разработать всесторонний и приоритизированный продукт-бэклог, отражающий текущее понимание требований к продукту.

Пример – MIS
Описание проблемы
Компания ABC Corporation — это розничная компания, работающая более 20 лет. За эти годы компания значительно выросла, и у нее теперь несколько точек продаж и большая клиентская база. Чтобы оставаться конкурентоспособной, компания ABC инвестировала в информационную систему, которая помогает ей управлять запасами, продажами и данными клиентов.
Однако в последние месяцы информационная система вызывает проблемы. Система медленная, и на обработку транзакций уходит много времени. Это привело к длинным очередям на кассах, раздраженным клиентам и потерянным продажам. Кроме того, система подвержена ошибкам, что приводит к некорректным данным о запасах, в результате чего возникают дефицит и избыток товаров.
Команда ИТ работает над устранением проблем, но сталкивается с трудностями при определении истинной причины. Система сложная, и существует множество различных компонентов, которые должны беспрепятственно работать вместе. Команда ИТ пыталась оптимизировать систему, добавив больше памяти, обновив программное обеспечение и увеличив вычислительную мощность. Однако эти меры не решили основные проблемы.
Проблемы с информационной системой вызывают серьезные сбои в работе бизнеса. Компания теряет клиентов, а ее репутация страдает. Команда ИТ испытывает давление, чтобы быстро найти решение, но сталкивается с трудностями при определении истинной причины. Управленческая команда компании обеспокоена влиянием на финансовую отчетность и рассматривает возможность привлечения внешних консультантов для решения проблем с информационной системой.
Разработать начальный продукт-бэклог
Шаги по разработке начального продукт-бэклога:
- Определите основные проблемные области: На основе представленного сценария основные проблемные области — это медленная и подверженная ошибкам информационная система, что приводит к длинным очередям на кассах, раздраженным клиентам, некорректным данным о запасах, дефициту и избытку товаров.
- Определите заинтересованные стороны: в этом сценарии заинтересованными сторонами являются управленческая команда компании, команда ИТ, сотрудники розничных точек и клиенты.
- Проведите мозговой штурм возможных решений: Работайте с заинтересованными сторонами, чтобы определить возможные решения проблем. Некоторые возможные решения могут включать обновление оборудования, оптимизацию программного обеспечения, улучшение сетевой инфраструктуры, внедрение новой системы POS и улучшение обучения сотрудников розничных точек.
- Приоритизируйте решения: Приоритизируйте потенциальные решения на основе их влияния на бизнес, осуществимости и стоимости. Учитывайте мнение заинтересованных сторон и проведите анализ затрат и выгод для каждого решения.
- Разбейте решения на более мелкие задачи:Как только решения будут приоритизированы, разбейте их на более мелкие задачи или пользовательские истории. Каждая задача должна быть конкретной, измеримой, достижимой, актуальной и ограниченной по времени.
- Оцените усилия, необходимые для каждой задачи: Оцените усилия, необходимые для каждой задачи в баллах истории. Используйте исторические данные или экспертную оценку для определения уровня необходимых усилий.
- Приоритизируйте задачи: Приоритизируйте задачи с учетом их влияния на бизнес и зависимостей между задачами.
- Создайте начальный бэклог продукта: создайте начальный бэклог продукта, перечислив все задачи в порядке приоритета. Включите описание каждой задачи и ее оценочные усилия в баллах истории.
Формат таблицы для начального бэклога продукта:
| Приоритет | История пользователя | Описание | Оценочные усилия (баллы истории) |
|---|---|---|---|
| 1 | Обновление оборудования | Обновление оборудования для улучшения производительности системы | 13 |
| 2 | Оптимизация программного обеспечения | Оптимизация программного обеспечения для улучшения производительности системы | 8 |
| 3 | Улучшение сетевой инфраструктуры | Улучшение сетевой инфраструктуры для снижения задержки и улучшения производительности системы | 5 |
| 4 | Внедрение новой системы POS | Внедрение новой системы POS для улучшения скорости обработки транзакций и снижения ошибок | 21 |
| 5 | Обучение розничных сотрудников | Улучшение обучения розничных сотрудников для снижения ошибок и улучшения обслуживания клиентов | 8 |
| 6 | Улучшить управление запасами | Улучшение управления запасами для сокращения дефицита и избыточных запасов | 13 |
Примечание: количество баллов истории оценивается и, возможно, потребует доработки во время сессий по доработке бэклога и планирования спринтов.
Доработать элементы бэклога продукта
Некоторые из перечисленных выше элементов бэклога продукта могут быть слишком большими, чтобы поместиться в один спринт. Вот некоторые варианты их доработки в подходящие эпики или пользовательские истории:
- Обновление оборудования: Это может быть разбито на несколько небольших пользовательских историй, таких как «Исследование и выбор соответствующего оборудования», «Покупка и установка нового оборудования» и «Тестирование и проверка нового оборудования».
- Оптимизация программного обеспечения: Это может быть разбито на несколько небольших пользовательских историй, таких как «Выявление узких мест производительности», «Разработка и внедрение оптимизаций производительности» и «Тестирование и проверка улучшений производительности».
- Внедрение новой системы POS: Это может быть эпик, включающий несколько пользовательских историй, таких как «Исследование и выбор соответствующей системы POS», «Настройка и адаптация системы POS», «Обучение сотрудников розничной торговли новой системе POS» и «Тестирование и проверка новой системы POS».
- Обучение сотрудников розничной торговли: Это может быть разбито на несколько небольших пользовательских историй, таких как «Разработка учебных материалов», «Планирование и проведение учебных сессий» и «Оценка эффективности обучения».
Разбивая эти крупные элементы бэклога продукта на более мелкие и управляемые пользовательские истории, команда может легче оценивать усилия, приоритизировать и планировать спринты, а также сосредоточиться на предоставлении ценности бизнесу и его заинтересованным сторонам.
Вот обновленная таблица с доработанными элементами бэклога продукта (или пользовательскими историями):
| Приоритет | Эпик / Пользовательская история | Описание | Оценочные усилия (баллы за историю) |
|---|---|---|---|
| 1 | Обновление оборудования | Исследование и выбор соответствующего оборудования | 5 |
| Покупка и установка нового оборудования | 5 | ||
| Тестирование и проверка нового оборудования | 3 | ||
| 2 | Оптимизация программного обеспечения | Выявление узких мест производительности | 3 |
| Разработка и внедрение оптимизаций производительности | 5 | ||
| Тестирование и подтверждение улучшений производительности | 2 | ||
| 3 | Улучшение сетевой инфраструктуры | Улучшение сетевой инфраструктуры для снижения задержки и повышения производительности системы | 5 |
| 4 | Внедрение новой системы POS | Исследование и выбор соответствующей системы POS | 5 |
| Настройка и настройка системы POS | 8 | ||
| Обучение сотрудников розничной торговли новой системе POS | 5 | ||
| Тестирование и подтверждение новой системы POS | 3 | ||
| 5 | Обучение сотрудников розничной торговли | Разработка учебных материалов | 3 |
| Планирование и проведение учебных занятий | 3 | ||
| Оценка эффективности обучения | 2 | ||
| 6 | Улучшение управления запасами | Улучшите управление запасами, чтобы сократить дефицит и избыточные запасы | 8 |
Примечание: количество баллов истории оценено и, возможно, потребует уточнения во время сессий по доработке бэклога и планирования спринтов.
Оценка обновленного бэклога продукта по принципам DEEP
Вот обсуждение каждой пользовательской истории в обновленном бэклоге продукта по принципам DEEP:
- Обновление оборудования
- Подходящая детализация: пользовательская история конкретна и хорошо определена, что указывает на необходимость команде провести исследование и выбрать соответствующее оборудование, приобрести и установить новое оборудование, а также протестировать и проверить новое оборудование.
- Оценено: пользовательская история оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
- Эмерджентность: пользовательская история является эмерджентной, поскольку команда может потребовать скорректировать выбор оборудования или процесс установки на основе своих результатов в ходе исследований и тестирования.
- Приоритизация: пользовательская история приоритизирована на основе ее влияния на производительность системы, при этом обновление оборудования получает наивысший приоритет.
- Оптимизация программного обеспечения
- Подходящая детализация: пользовательская история конкретна и хорошо определена, что указывает на необходимость команде выявить узкие места производительности, разработать и внедрить оптимизации производительности, а также протестировать и проверить улучшения производительности.
- Оценено: пользовательская история оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
- Эмерджентность: пользовательская история является эмерджентной, поскольку команда может потребовать скорректировать подход к оптимизации на основе своих результатов в ходе тестирования.
- Приоритизация: пользовательская история приоритизирована на основе ее влияния на производительность системы, при этом оптимизация программного обеспечения получает второй по величине приоритет.
- Улучшение сетевой инфраструктуры
- Подходящая детализация: пользовательская история конкретна и хорошо определена, что указывает на необходимость команде улучшить сетевую инфраструктуру для снижения задержек и повышения производительности системы.
- Оценено: пользовательская история оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
- Эмерджентность: пользовательская история не так эмерджентна, как некоторые другие пользовательские истории, поскольку команда, вероятно, хорошо понимает необходимые улучшения сетевой инфраструктуры.
- Приоритизация: пользовательская история приоритизирована на основе ее влияния на производительность системы, при этом улучшение сетевой инфраструктуры получает средний приоритет.
- Внедрение новой системы POS
- Подходящая детализация: пользовательская история конкретна и хорошо определена, что указывает на необходимость команде провести исследование и выбрать соответствующую систему POS, настроить и адаптировать систему POS, обучить сотрудников розничной торговли новой системе POS, а также протестировать и проверить новую систему POS.
- Оценено: пользовательская история оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
- Эмерджентность: пользовательская история является эмерджентной, поскольку команда может потребовать скорректировать выбор или подход к настройке на основе своих результатов в ходе тестирования.
- Приоритизация: пользовательская история приоритизирована на основе ее влияния на производительность системы, при этом внедрение новой системы POS получает высокий приоритет.
- Обучение сотрудников розничной торговли
- Подходящая детализация: пользовательская история конкретна и хорошо определена, что указывает на необходимость команде разработать учебные материалы, спланировать и провести учебные занятия, а также оценить эффективность обучения.
- Оценено: пользовательская история оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
- Эмерджент: история пользователя не так эмерджентна, как некоторые другие истории пользователей, поскольку команда, вероятно, хорошо понимает необходимые материалы и сессии обучения.
- Приоритизировано: история пользователя приоритизирована с учетом ее влияния на снижение ошибок и улучшение обслуживания клиентов, при этом обучение сотрудников розничных магазинов получает средний приоритет.
- Улучшить управление запасами
- Подходящая детализация: история пользователя конкретна и хорошо определена, что указывает на необходимость команде улучшить управление запасами для сокращения дефицита и избыточных запасов.
- Оценено: история пользователя оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
- Эмерджент: история пользователя не так эмерджентна, как некоторые другие истории пользователей, поскольку команда, вероятно, хорошо понимает необходимые улучшения в управлении запасами.
- Приоритизировано: история пользователя приоритизирована с учетом ее влияния на снижение дефицита и избыточных запасов, при этом улучшение управления запасами получает средний приоритет.
В целом, обновленный продукт-бэклог хорошо соответствует принципам DEEP. Каждая история пользователя соответствует уровню детализации, оценена, эмерджентна и приоритизирована, что позволяет команде эффективно управлять продукт-бэклогом и создавать ценность для бизнеса и его заинтересованных сторон. Приоритизация историй пользователей основана на их влиянии на производительность системы, снижение ошибок и улучшение обслуживания клиентов, что поддерживает общие цели проекта.
Улучшение продукт-бэклога
Хотя обновленный продукт-бэклог, похоже, хорошо соответствует принципам DEEP, всегда есть место для улучшения. Вот некоторые возможные направления для улучшения:
- Подходящая детализация: Истории пользователей в продукт-бэклоге можно дополнительно уточнить, чтобы обеспечить соответствующий уровень детализации. Это может включать разбиение крупных историй пользователей на более мелкие или предоставление дополнительного контекста и ясности по требованиям.
- Оценено: Баллы истории, назначенные каждой истории пользователя, можно уточнить на основе фактических данных из предыдущих спринтов или по мере развития понимания командой требований.
- Эмерджент: Продукт-бэклог можно постоянно пересматривать и улучшать, чтобы он оставался эмерджентным. Команда может учитывать обратную связь от заинтересованных сторон или корректировать бэклог на основе новой информации, появляющейся в ходе разработки.
- Приоритизировано: Приоритизация историй пользователей может быть уточнена с учетом изменяющихся бизнес-потребностей или обратной связи от заинтересованных сторон. Команда может регулярно проводить обзоры бэклога, чтобы убедиться, что на первом месте находятся истории пользователей с наивысшим приоритетом.
В целом, продукт-бэклог — это живой документ, который должен постоянно пересматриваться и улучшаться, чтобы соответствовать принципам DEEP и поддерживать цели проекта. Команда должна быть открыта к обратной связи и активно искать способы улучшения продукт-бэклога на протяжении всего процесса разработки.
Обзор
Рамочная модель DEEP имеет решающее значение для эффективного управления продукт-бэклогом, поскольку она помогает командам разработать всесторонний и приоритизированный продукт-бэклог, отражающий текущее понимание требований к продукту. Уровень детализации должен быть достаточным, чтобы обеспечить ясность и направление команде разработки. Баллы истории используются для оценки объема работы, необходимого для завершения элемента, а продукт-бэклог постоянно обновляется с учетом изменений в требованиях к продукту. Приоритизация помогает команде разработки сосредоточиться на наиболее важных элементах в первую очередь.
Рамочная модель DEEP предоставляет набор руководящих принципов для эффективного управления продукт-бэклогом. Она обеспечивает соответствующую детализацию, оценку, эмерджентность и приоритизацию продукт-бэклога на основе таких факторов, как ценность для пользователя, бизнес-ценность, техническая осуществимость, сложность и зависимости. Следуя рамочной модели DEEP, команды могут эффективно управлять продукт-бэклогом, обеспечивая соответствие продукта потребностям пользователей и заинтересованных сторон.











