Перейти к содержимому
Read this post in: de_DEen_USes_ESfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW
Home » Agile & Scrum » Понимание рамочной модели DEEP для эффективного управления продуктом

Понимание рамочной модели DEEP для эффективного управления продуктом

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

Что такое рамочная модель DEEP

DEEP означает детально, соответствующим образом, оценено, возникает и приоритизировано. Каждый элемент в продукт-бэклоге должен быть детально описан, оценен в баллах истории, возникающим и приоритизированным на основе нескольких факторов, таких как ценность для пользователя, ценность для бизнеса, техническая осуществимость, сложность и зависимости. Следуя рамочной модели DEEP, команды могут эффективно управлять продукт-бэклогом, обеспечивая, чтобы элементы в бэклоге были соответствующим образом детализированы, оценены, возникали и приоритизированы.

Вот краткий обзор каждого элемента рамочной модели DEEP:

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

Следуя рамочной модели DEEP, команды могут эффективно управлять продукт-бэклогом, обеспечивая, что элементы в бэклоге соответствующим образом детализированы, оценены, возникают и приоритизированы. Это помогает команде разработать всесторонний и приоритизированный продукт-бэклог, отражающий текущее понимание требований к продукту.

DEEP in product backlog

Пример – MIS

Описание проблемы

Компания ABC Corporation — это розничная компания, работающая более 20 лет. За эти годы компания значительно выросла, и у нее теперь несколько точек продаж и большая клиентская база. Чтобы оставаться конкурентоспособной, компания ABC инвестировала в информационную систему, которая помогает ей управлять запасами, продажами и данными клиентов.

Однако в последние месяцы информационная система вызывает проблемы. Система медленная, и на обработку транзакций уходит много времени. Это привело к длинным очередям на кассах, раздраженным клиентам и потерянным продажам. Кроме того, система подвержена ошибкам, что приводит к некорректным данным о запасах, в результате чего возникают дефицит и избыток товаров.

Команда ИТ работает над устранением проблем, но сталкивается с трудностями при определении истинной причины. Система сложная, и существует множество различных компонентов, которые должны беспрепятственно работать вместе. Команда ИТ пыталась оптимизировать систему, добавив больше памяти, обновив программное обеспечение и увеличив вычислительную мощность. Однако эти меры не решили основные проблемы.

Проблемы с информационной системой вызывают серьезные сбои в работе бизнеса. Компания теряет клиентов, а ее репутация страдает. Команда ИТ испытывает давление, чтобы быстро найти решение, но сталкивается с трудностями при определении истинной причины. Управленческая команда компании обеспокоена влиянием на финансовую отчетность и рассматривает возможность привлечения внешних консультантов для решения проблем с информационной системой.

Разработать начальный продукт-бэклог

Шаги по разработке начального продукт-бэклога:

  1. Определите основные проблемные области: На основе представленного сценария основные проблемные области — это медленная и подверженная ошибкам информационная система, что приводит к длинным очередям на кассах, раздраженным клиентам, некорректным данным о запасах, дефициту и избытку товаров.
  2. Определите заинтересованные стороны: в этом сценарии заинтересованными сторонами являются управленческая команда компании, команда ИТ, сотрудники розничных точек и клиенты.
  3. Проведите мозговой штурм возможных решений: Работайте с заинтересованными сторонами, чтобы определить возможные решения проблем. Некоторые возможные решения могут включать обновление оборудования, оптимизацию программного обеспечения, улучшение сетевой инфраструктуры, внедрение новой системы POS и улучшение обучения сотрудников розничных точек.
  4. Приоритизируйте решения: Приоритизируйте потенциальные решения на основе их влияния на бизнес, осуществимости и стоимости. Учитывайте мнение заинтересованных сторон и проведите анализ затрат и выгод для каждого решения.
  5. Разбейте решения на более мелкие задачи:Как только решения будут приоритизированы, разбейте их на более мелкие задачи или пользовательские истории. Каждая задача должна быть конкретной, измеримой, достижимой, актуальной и ограниченной по времени.
  6. Оцените усилия, необходимые для каждой задачи: Оцените усилия, необходимые для каждой задачи в баллах истории. Используйте исторические данные или экспертную оценку для определения уровня необходимых усилий.
  7. Приоритизируйте задачи: Приоритизируйте задачи с учетом их влияния на бизнес и зависимостей между задачами.
  8. Создайте начальный бэклог продукта: создайте начальный бэклог продукта, перечислив все задачи в порядке приоритета. Включите описание каждой задачи и ее оценочные усилия в баллах истории.

Формат таблицы для начального бэклога продукта:

Приоритет История пользователя Описание Оценочные усилия (баллы истории)
1 Обновление оборудования Обновление оборудования для улучшения производительности системы 13
2 Оптимизация программного обеспечения Оптимизация программного обеспечения для улучшения производительности системы 8
3 Улучшение сетевой инфраструктуры Улучшение сетевой инфраструктуры для снижения задержки и улучшения производительности системы 5
4 Внедрение новой системы POS Внедрение новой системы POS для улучшения скорости обработки транзакций и снижения ошибок 21
5 Обучение розничных сотрудников Улучшение обучения розничных сотрудников для снижения ошибок и улучшения обслуживания клиентов 8
6 Улучшить управление запасами Улучшение управления запасами для сокращения дефицита и избыточных запасов 13

Примечание: количество баллов истории оценивается и, возможно, потребует доработки во время сессий по доработке бэклога и планирования спринтов.

Доработать элементы бэклога продукта

Некоторые из перечисленных выше элементов бэклога продукта могут быть слишком большими, чтобы поместиться в один спринт. Вот некоторые варианты их доработки в подходящие эпики или пользовательские истории:

  1. Обновление оборудования: Это может быть разбито на несколько небольших пользовательских историй, таких как «Исследование и выбор соответствующего оборудования», «Покупка и установка нового оборудования» и «Тестирование и проверка нового оборудования».
  2. Оптимизация программного обеспечения: Это может быть разбито на несколько небольших пользовательских историй, таких как «Выявление узких мест производительности», «Разработка и внедрение оптимизаций производительности» и «Тестирование и проверка улучшений производительности».
  3. Внедрение новой системы POS: Это может быть эпик, включающий несколько пользовательских историй, таких как «Исследование и выбор соответствующей системы POS», «Настройка и адаптация системы POS», «Обучение сотрудников розничной торговли новой системе POS» и «Тестирование и проверка новой системы POS».
  4. Обучение сотрудников розничной торговли: Это может быть разбито на несколько небольших пользовательских историй, таких как «Разработка учебных материалов», «Планирование и проведение учебных сессий» и «Оценка эффективности обучения».

Разбивая эти крупные элементы бэклога продукта на более мелкие и управляемые пользовательские истории, команда может легче оценивать усилия, приоритизировать и планировать спринты, а также сосредоточиться на предоставлении ценности бизнесу и его заинтересованным сторонам.

Вот обновленная таблица с доработанными элементами бэклога продукта (или пользовательскими историями):

Приоритет Эпик / Пользовательская история Описание Оценочные усилия (баллы за историю)
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:

  1. Обновление оборудования
  • Подходящая детализация: пользовательская история конкретна и хорошо определена, что указывает на необходимость команде провести исследование и выбрать соответствующее оборудование, приобрести и установить новое оборудование, а также протестировать и проверить новое оборудование.
  • Оценено: пользовательская история оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
  • Эмерджентность: пользовательская история является эмерджентной, поскольку команда может потребовать скорректировать выбор оборудования или процесс установки на основе своих результатов в ходе исследований и тестирования.
  • Приоритизация: пользовательская история приоритизирована на основе ее влияния на производительность системы, при этом обновление оборудования получает наивысший приоритет.
  1. Оптимизация программного обеспечения
  • Подходящая детализация: пользовательская история конкретна и хорошо определена, что указывает на необходимость команде выявить узкие места производительности, разработать и внедрить оптимизации производительности, а также протестировать и проверить улучшения производительности.
  • Оценено: пользовательская история оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
  • Эмерджентность: пользовательская история является эмерджентной, поскольку команда может потребовать скорректировать подход к оптимизации на основе своих результатов в ходе тестирования.
  • Приоритизация: пользовательская история приоритизирована на основе ее влияния на производительность системы, при этом оптимизация программного обеспечения получает второй по величине приоритет.
  1. Улучшение сетевой инфраструктуры
  • Подходящая детализация: пользовательская история конкретна и хорошо определена, что указывает на необходимость команде улучшить сетевую инфраструктуру для снижения задержек и повышения производительности системы.
  • Оценено: пользовательская история оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
  • Эмерджентность: пользовательская история не так эмерджентна, как некоторые другие пользовательские истории, поскольку команда, вероятно, хорошо понимает необходимые улучшения сетевой инфраструктуры.
  • Приоритизация: пользовательская история приоритизирована на основе ее влияния на производительность системы, при этом улучшение сетевой инфраструктуры получает средний приоритет.
  1. Внедрение новой системы POS
  • Подходящая детализация: пользовательская история конкретна и хорошо определена, что указывает на необходимость команде провести исследование и выбрать соответствующую систему POS, настроить и адаптировать систему POS, обучить сотрудников розничной торговли новой системе POS, а также протестировать и проверить новую систему POS.
  • Оценено: пользовательская история оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
  • Эмерджентность: пользовательская история является эмерджентной, поскольку команда может потребовать скорректировать выбор или подход к настройке на основе своих результатов в ходе тестирования.
  • Приоритизация: пользовательская история приоритизирована на основе ее влияния на производительность системы, при этом внедрение новой системы POS получает высокий приоритет.
  1. Обучение сотрудников розничной торговли
  • Подходящая детализация: пользовательская история конкретна и хорошо определена, что указывает на необходимость команде разработать учебные материалы, спланировать и провести учебные занятия, а также оценить эффективность обучения.
  • Оценено: пользовательская история оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
  • Эмерджент: история пользователя не так эмерджентна, как некоторые другие истории пользователей, поскольку команда, вероятно, хорошо понимает необходимые материалы и сессии обучения.
  • Приоритизировано: история пользователя приоритизирована с учетом ее влияния на снижение ошибок и улучшение обслуживания клиентов, при этом обучение сотрудников розничных магазинов получает средний приоритет.
  1. Улучшить управление запасами
  • Подходящая детализация: история пользователя конкретна и хорошо определена, что указывает на необходимость команде улучшить управление запасами для сокращения дефицита и избыточных запасов.
  • Оценено: история пользователя оценена в баллах истории, что позволяет команде понять уровень усилий, необходимых для завершения работы.
  • Эмерджент: история пользователя не так эмерджентна, как некоторые другие истории пользователей, поскольку команда, вероятно, хорошо понимает необходимые улучшения в управлении запасами.
  • Приоритизировано: история пользователя приоритизирована с учетом ее влияния на снижение дефицита и избыточных запасов, при этом улучшение управления запасами получает средний приоритет.

В целом, обновленный продукт-бэклог хорошо соответствует принципам DEEP. Каждая история пользователя соответствует уровню детализации, оценена, эмерджентна и приоритизирована, что позволяет команде эффективно управлять продукт-бэклогом и создавать ценность для бизнеса и его заинтересованных сторон. Приоритизация историй пользователей основана на их влиянии на производительность системы, снижение ошибок и улучшение обслуживания клиентов, что поддерживает общие цели проекта.

Улучшение продукт-бэклога

Хотя обновленный продукт-бэклог, похоже, хорошо соответствует принципам DEEP, всегда есть место для улучшения. Вот некоторые возможные направления для улучшения:

  1. Подходящая детализация: Истории пользователей в продукт-бэклоге можно дополнительно уточнить, чтобы обеспечить соответствующий уровень детализации. Это может включать разбиение крупных историй пользователей на более мелкие или предоставление дополнительного контекста и ясности по требованиям.
  2. Оценено: Баллы истории, назначенные каждой истории пользователя, можно уточнить на основе фактических данных из предыдущих спринтов или по мере развития понимания командой требований.
  3. Эмерджент: Продукт-бэклог можно постоянно пересматривать и улучшать, чтобы он оставался эмерджентным. Команда может учитывать обратную связь от заинтересованных сторон или корректировать бэклог на основе новой информации, появляющейся в ходе разработки.
  4. Приоритизировано: Приоритизация историй пользователей может быть уточнена с учетом изменяющихся бизнес-потребностей или обратной связи от заинтересованных сторон. Команда может регулярно проводить обзоры бэклога, чтобы убедиться, что на первом месте находятся истории пользователей с наивысшим приоритетом.

В целом, продукт-бэклог — это живой документ, который должен постоянно пересматриваться и улучшаться, чтобы соответствовать принципам DEEP и поддерживать цели проекта. Команда должна быть открыта к обратной связи и активно искать способы улучшения продукт-бэклога на протяжении всего процесса разработки.

Обзор

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

Рамочная модель DEEP предоставляет набор руководящих принципов для эффективного управления продукт-бэклогом. Она обеспечивает соответствующую детализацию, оценку, эмерджентность и приоритизацию продукт-бэклога на основе таких факторов, как ценность для пользователя, бизнес-ценность, техническая осуществимость, сложность и зависимости. Следуя рамочной модели DEEP, команды могут эффективно управлять продукт-бэклогом, обеспечивая соответствие продукта потребностям пользователей и заинтересованных сторон.

Добавить комментарий