Простыми словами о сложном: объясняем, как управлять командами, продуктами и компаниями с помощью Скрама, Канбана, SAFe, LeSS, OKR и других гибких подходов.
Условия того, что задача/user story считается выполненной с точки зрения конечного пользователя. Другими словами, успешно выполняются пользовательские сценарии использования данного функционала.
Например, критерий приемки функционала «Счетчик невыполненных задач»:
Когда по задачам пользователя наступает deadline, то он получает push-уведомление о просроченной задаче. Открывая это уведомление, пользователь видит счетчик просроченных задач, т.е. видит общее количество таких задач.
Критерии того, что задача/user story считаются завершенными. Т.е. это «фильтр на выход» (тогда как критерии подготовленности — «фильтр на вход» в разработку).
Например:
Команда определила для себя следующие DoD для задач, которые она планирует отправить в релиз программного продукта:
Критерии, которые определяют, что задачу/user story можно взять разработку. Т.е. это «фильтр на вход» (тогда как критерии готовности — «фильтр на выход» из разработки).
Например:
Команда устанавливает следующие DoR для входящих задач по разработке программного продукта:
Другими словами, пока данные критерии не будут выполнены, команда не начнет писать код.
Техники декомпозиции крупных элементов бэклога продукта (требований к продукту) на более мелкие элементы:
Список всего, что предполагается сделать в продукте. В идеале, это должен быть приоритизированный список: задач, инициатив, гипотез, пользовательских историй, багов, улучшений и прочих требований к продукту. Если ваш бэклог приоритизирован на 2-4 итерации вперед, то у вас достаточно приоритизированный бэклог.
АЛЕКСЕЙ ЕВДОКИМОВ
→6 АВГ 2021Техника визуализации для формирования бэклога продукта, для генерации гипотез по развитию продукта и др. Декомпозирует влияние на достижение цели через призму клиентов, коллег, смежных отделов, конкурентов, инвесторов и других заинтересованных лиц. Состоит из блоков:
«Зачем?» → «Кто?» → «Как?» → «Что нам сделать, чтобы всё что слева случилось?»
АЛЕКСЕЙ ЕВДОКИМОВ
→6 АВГ 2021Момент, когда клиент понимает/осознает ценность продукта. Как правило клиентский путь проектируют так, чтобы клиент, как можно скорее словил «озарение». Обычно «озарение» приходит после выполнения какого-либо действия.
Например, после прочтения пяти связанных между собой терминов, у вас начнет собираться целостная картинка по управлению продуктом — это и будет aha moment глосария ?
АЛЕКСЕЙ ЕВДОКИМОВ
→6 АВГ 2021Способ описания требований к разрабатываемому решению с точки зрения взаимодействия между собой систем, компонент и сред.
АЛЕКСЕЙ ЕВДОКИМОВ
→6 АВГ 2021Способ описания требований к разрабатываемому решению с точки зрения мотивации клиента. Фокусируемся не на том, чего хочет сделать пользователь, а на том, ради чего он это делает. Клиенты «нанимают» решения для выполнения определенной «работы». Концепция JTBD фокусирует на мотивациях клиентов, что оставляет широкое поле для инноваций при разработке решений, так как не определяет конкретных действий и решений клиента.
Как правило, Job Story выражается формулой:
Когда <Ситуация> я хочу <Мотивация>, чтобы я мог <Ожидаемый результат>.
Например:
Когда я не могу принять решение, какие фичи отправить в следующий спринт, я хочу избавиться от чувства волнения и неуверенности, чтобы я мог достойно провести планирование спринта.
АЛЕКСЕЙ ЕВДОКИМОВ
→6 АВГ 2021Способ описания требований к разрабатываемому решению с точки зрения разработчиков. Формат напоминает User Story, только с фокусом на процессе взаимодействия пользователей с разрабатываемым решением:
<Глагол действия> <Субъект>, чтобы <Кто> получил <Что> (или чтобы <Цель>).
Например:
Установить уровень давления в системе в соответствии с типом пива, чтобы покупатель смог наполнил бутылку пива без пены за 30 секунд.
Тот же пример в формате User Story:
Как покупатель пива, я хочу наполнить бутылку пива за 30 секунд без пены.
(Клиент не знает о том, что разные сорта пива требуют разной подачи давления для налива, но хочет всегда получить 0,5 пива за 30 секунд. System Story описывает процесс с точки зрения разработчиков, а не пользователя).
АЛЕКСЕЙ ЕВДОКИМОВ
→Нажимая «Подписаться», вы даёте согласие на обработку персональных данных.
Теория без практики не работает. Проходите тренинги с реальными кейсами, опытными тренерами и международными сертификациями.