Давайте посмотрим пример формирования MVP для приложения для бронирования мест в кафе.
📌Важное заключение: мы взяли только самый минимум фич, чтобы выпустить версию как можно быстрее.
Это не значит, что остальные фичи мы будем делать когда-то непонятно когда.
Наоборот, никто не мешает нам сразу после выпуска первой версии учесть обратную связь и в течение недели или месяца выпустить новую версию, которая уже будет подходить для большего количества пользователей.
Такое развитие продукта тоже необходимо заранее проектировать и обсуждать со стейкхолдерами, чтобы иметь понятную всем дорожную карту развития продукта, о которой мы поговорим чуть позже.⚡️
OnAgile Learning Hub
📌Важное заключение: мы взяли только самый минимум фич, чтобы выпустить версию как можно быстрее.
Это не значит, что остальные фичи мы будем делать когда-то непонятно когда.
Наоборот, никто не мешает нам сразу после выпуска первой версии учесть обратную связь и в течение недели или месяца выпустить новую версию, которая уже будет подходить для большего количества пользователей.
Такое развитие продукта тоже необходимо заранее проектировать и обсуждать со стейкхолдерами, чтобы иметь понятную всем дорожную карту развития продукта, о которой мы поговорим чуть позже.⚡️
OnAgile Learning Hub
👍3❤2
Друзья, поделитесь пожалуйста обратной связью по последним материалам о Подготовке Бэклога.
Как вам такой формат контента в нашем канале?
Как вам такой формат контента в нашем канале?
Anonymous Poll
65%
Для меня полезно и интересно, классный формат!
0%
Показалось не очень интересным и полезным
9%
Мне интересно, но сложновато вопринимать суть в таком формате
22%
Все отлично, хотелось бы еще больше примеров
4%
Напишу свои мысли в комментариях
👍2
С наступающим Новым годом, друзья!🎄 Спасибо, что вы были с нами в этом году. Желаем отличного отдыха в праздники и счастливой встречи 2024-го года!🎉
Будем рады встрече в новом году. Полезные материалы вернутся на канал 9 января.
С наилучшими пожеланиями,
команда OnAgile
Будем рады встрече в новом году. Полезные материалы вернутся на канал 9 января.
С наилучшими пожеланиями,
команда OnAgile
❤9
Формулируем цели по SMART
🚀Начало года - начало движения к новым целям.
Предлагаем вспомнить простой метод, который поможет сформулировать ваши цели.
📚SMART - это аббревиатура из критериев, которым должна соответствовать цель:
S - specific (конкретная)
M - measurable (измеримая)
A - achievable (достижимая)
R - relevant (релевантная)
T - time bound (ограниченная по времени)
При этом, по некоторым буквам есть вариативность интерпретаций.
Например, A может быть и attractive (привлекательная), ambitious (амбициозная), aggressive (агрессивная),
R может быть realistic (реалистичная), resource (согласованная по ресурсам).
Вы можете использовать тот или иной вариант в зависимости от вашего контекста.
Если вы хотите поставить цели выхода на новые рынки, то это может быть aggressive, а если хотите использовать цели, как мотивацию для команды, то тогда это может быть ambitious.
На карточке выше простой пример цели по SMART.
OnAgile Learning Hub
🚀Начало года - начало движения к новым целям.
Предлагаем вспомнить простой метод, который поможет сформулировать ваши цели.
📚SMART - это аббревиатура из критериев, которым должна соответствовать цель:
S - specific (конкретная)
M - measurable (измеримая)
A - achievable (достижимая)
R - relevant (релевантная)
T - time bound (ограниченная по времени)
При этом, по некоторым буквам есть вариативность интерпретаций.
Например, A может быть и attractive (привлекательная), ambitious (амбициозная), aggressive (агрессивная),
R может быть realistic (реалистичная), resource (согласованная по ресурсам).
Вы можете использовать тот или иной вариант в зависимости от вашего контекста.
Если вы хотите поставить цели выхода на новые рынки, то это может быть aggressive, а если хотите использовать цели, как мотивацию для команды, то тогда это может быть ambitious.
На карточке выше простой пример цели по SMART.
OnAgile Learning Hub
❤4👍2
Дорожная карта развития продукта (Product Roadmap)
👉Сегодня поговорим про ключевой артефакт, который определяет наше видение этапов развития продукта. Он помогает команде и заинтересованным лицам выровняться в понимании будущего и сформировать корректные ожидания.
На карточках выше вариант того, какие могут быть основные этапы дорожной карты для примера дальнейшего развития MVP приложения для бронирования мест в кафе, который мы рассматривали ранее.
Мы можем опубликовать описание еще более структурного и системного (но, по-прежнему легковесного) подхода к формированию дорожной карты продукта. Поставьте плюсик в комментариях, если интересно.
—
Предыдущие публикации серии экспертных тем про основные этапы подготовки бэклога продукта:
✅ Формулировка цели продукта
✅ Формирование видения продукта
✅ Проектирование продукта с помощью такого инструмента, как User Story Mapping (USM) с примером
✅ Формирование состава первой поставки, минимальной версии нашего продукта (MVP) с примером
OnAgile Learning Hub
👉Сегодня поговорим про ключевой артефакт, который определяет наше видение этапов развития продукта. Он помогает команде и заинтересованным лицам выровняться в понимании будущего и сформировать корректные ожидания.
На карточках выше вариант того, какие могут быть основные этапы дорожной карты для примера дальнейшего развития MVP приложения для бронирования мест в кафе, который мы рассматривали ранее.
Мы можем опубликовать описание еще более структурного и системного (но, по-прежнему легковесного) подхода к формированию дорожной карты продукта. Поставьте плюсик в комментариях, если интересно.
—
Предыдущие публикации серии экспертных тем про основные этапы подготовки бэклога продукта:
✅ Формулировка цели продукта
✅ Формирование видения продукта
✅ Проектирование продукта с помощью такого инструмента, как User Story Mapping (USM) с примером
✅ Формирование состава первой поставки, минимальной версии нашего продукта (MVP) с примером
OnAgile Learning Hub
👍5
🚀Применяем OKR-подход к целеполаганию
OKR - Objectives and Key Results
(Цели и Ключевые Результаты).
У этого подхода есть два направления.
1️⃣ OKR Institute - оригинальное направление от создателей первоначального подхода.
В данном случае формулируются, как правило на квартал, достаточно амбициозные цели (3-5 наиболее приоритетных), которые могут быть не достигнуты на 100%, и считается, что выполнение цели на уровне 70% - это вполне нормально.
Цель должна отвечать на вопрос: "В каком направлении нам нужно двигаться?".
Например, цель: "Успешно запустить в эксплуатацию автоматизированную скоринговую модель".
Далее формулируются 3-5 ключевых результатов по этой цели, которые используются для проверки прогресса относительно цели и отвечают на вопрос: "Как мы поймем, что мы двигаемся в правильном направлении?".
И как следствие, здесь возникают метрики, которые мы можем отслеживать, измерять в момент выполнения тех или иных действий с нашей стороны. Например: с использованием новой системы было проскорено 10 000 заявлений, индекс удовлетворенности операторов составляет более 8 баллов и скоринговая модель привела к снижению расходов нашей компании на Х%.
2️⃣ OKR Academy - отличие здесь в том, что может не быть четких метрик, а вместо них некие бинарные действия.
Например, цель: "Успешно запустить в эксплуатацию новую систему регулирования в страховании".
И здесь, например, могут быть такие ключевые результаты:
- успешно пройти процесс проверки на качество кода
- заинтегрироваться с безопасниками
- иметь систему электронной защиты и сохранности данных и т.п.
То есть это упрощенный вариант, исключающий метрики.
👉В больших зрелых организаций сейчас акцент идет на использование классического OKR подхода, как доказавшего свою эффективность на практике.
👉Важно также отметить, что OKR могут каскадироваться на разные уровни организации от OKR компании до OKR команд.
Позже рассмотрим более подробно некоторые примеры OKR.
Желаем всем амбициозных целей и крутых результатов в этом году!🚀
OnAgile Learning Hub
OKR - Objectives and Key Results
(Цели и Ключевые Результаты).
У этого подхода есть два направления.
1️⃣ OKR Institute - оригинальное направление от создателей первоначального подхода.
В данном случае формулируются, как правило на квартал, достаточно амбициозные цели (3-5 наиболее приоритетных), которые могут быть не достигнуты на 100%, и считается, что выполнение цели на уровне 70% - это вполне нормально.
Цель должна отвечать на вопрос: "В каком направлении нам нужно двигаться?".
Например, цель: "Успешно запустить в эксплуатацию автоматизированную скоринговую модель".
Далее формулируются 3-5 ключевых результатов по этой цели, которые используются для проверки прогресса относительно цели и отвечают на вопрос: "Как мы поймем, что мы двигаемся в правильном направлении?".
И как следствие, здесь возникают метрики, которые мы можем отслеживать, измерять в момент выполнения тех или иных действий с нашей стороны. Например: с использованием новой системы было проскорено 10 000 заявлений, индекс удовлетворенности операторов составляет более 8 баллов и скоринговая модель привела к снижению расходов нашей компании на Х%.
2️⃣ OKR Academy - отличие здесь в том, что может не быть четких метрик, а вместо них некие бинарные действия.
Например, цель: "Успешно запустить в эксплуатацию новую систему регулирования в страховании".
И здесь, например, могут быть такие ключевые результаты:
- успешно пройти процесс проверки на качество кода
- заинтегрироваться с безопасниками
- иметь систему электронной защиты и сохранности данных и т.п.
То есть это упрощенный вариант, исключающий метрики.
👉В больших зрелых организаций сейчас акцент идет на использование классического OKR подхода, как доказавшего свою эффективность на практике.
👉Важно также отметить, что OKR могут каскадироваться на разные уровни организации от OKR компании до OKR команд.
Позже рассмотрим более подробно некоторые примеры OKR.
Желаем всем амбициозных целей и крутых результатов в этом году!🚀
OnAgile Learning Hub
👍9❤1🔥1🥰1
👥Создание пользовательских историй - требований к продукту в формате Agile.
Завершающими этапами создания бэклога продукта будут описание требований к нашему продукту в виде пользовательских историй, с дальнейшей их декомпозицией и приоритизацией.
👉 Для описания продуктовых идей в формате Пользовательских историй (User Stories), можно использовать стандартный шаблон, придуманный Майком Коном:
Как [роль/персона], я хочу [возможность продукта], чтобы [цель]
Например:
1️⃣ Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования.
2️⃣ Как управляющий кафе, я хочу видеть статистику бронирований, чтобы планировать загрузку заведения.
Как видно из примеров, описание цели в дополнение к возможности продукта позволяет команде лучше понимать контекст использования и, следовательно, придумать более качественную реализацию функциональности.
Далее мы прописываем Приемочные критерии о которых поговорим в следующем посте.
OnAgile Learning Hub
Завершающими этапами создания бэклога продукта будут описание требований к нашему продукту в виде пользовательских историй, с дальнейшей их декомпозицией и приоритизацией.
👉 Для описания продуктовых идей в формате Пользовательских историй (User Stories), можно использовать стандартный шаблон, придуманный Майком Коном:
Как [роль/персона], я хочу [возможность продукта], чтобы [цель]
Например:
1️⃣ Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования.
2️⃣ Как управляющий кафе, я хочу видеть статистику бронирований, чтобы планировать загрузку заведения.
Как видно из примеров, описание цели в дополнение к возможности продукта позволяет команде лучше понимать контекст использования и, следовательно, придумать более качественную реализацию функциональности.
Далее мы прописываем Приемочные критерии о которых поговорим в следующем посте.
OnAgile Learning Hub
👍6
📌Описание приемочных критериев для пользовательской истории.
👆В посте выше поговорили про Создание пользовательских историй - требований к продукту в формате Agile.
Но достаточно ли нам такого описания требования, чтобы начать его разработку? Конечно нет.
Поэтому обычно в дополнение к истории мы прописываем Приемочные критерии – набор утверждений, который помогает нам лучше понять, что и как нужно сделать.
👉Например, для первой истории из поста выше:
"Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования."
Приемочные критерии могут быть следующие:
• Отображать кафе в пределах 10км
• Сделать фильтр по времени работы «Открыто сейчас»
• Для каждого кафе отображается его рейтинг
Теперь описание выглядит достаточно проработанным, разработчики задали все свои вопросы и в целом готовы приступать к реализации.🚀
Далее истории необходимо декомпозировать и приоритизировать. Об этом поговорим в следующих публикациях.
OnAgile Learning Hub
👆В посте выше поговорили про Создание пользовательских историй - требований к продукту в формате Agile.
Но достаточно ли нам такого описания требования, чтобы начать его разработку? Конечно нет.
Поэтому обычно в дополнение к истории мы прописываем Приемочные критерии – набор утверждений, который помогает нам лучше понять, что и как нужно сделать.
👉Например, для первой истории из поста выше:
"Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования."
Приемочные критерии могут быть следующие:
• Отображать кафе в пределах 10км
• Сделать фильтр по времени работы «Открыто сейчас»
• Для каждого кафе отображается его рейтинг
Теперь описание выглядит достаточно проработанным, разработчики задали все свои вопросы и в целом готовы приступать к реализации.🚀
Далее истории необходимо декомпозировать и приоритизировать. Об этом поговорим в следующих публикациях.
OnAgile Learning Hub
👍7❤1
Дисбаланс в работе команды🗓
👥Обычно в команде есть несколько разных компетенций, которые должны сотрудничать друг с другом для создания ценности. Например, в IT это бэк-, фронт-разработчики, аналитики, тестировщики.
⏱Если у нас ограниченный временной отрезок для поставки ценности, например, спринт 2-3 недели, то команда, как правило, декомпозирует задачи. При этом могут возникать разрывы в поставке.
👉Например, у команды есть истории А, B и C, которые они взяли в спринт. А и B команда смогла целиком поставить, а история С полностью не влезла. Команда все равно берет ее в работу для оптимизации процесса, так как до конца спринта остается запас velocity — и частично делает. Оставшаяся часть работы по истории С перейдет в следующий спринт.
И здесь зачастую возникает дисбаланс нагрузки. Если в прошлом спринте по истории С свою работу сделал бэк, далее происходит отладка: возможно, нашли дефекты, и, соответственно, работу берет на себя тестировщик. И если оказывается, что дефектов больше, чем рассчитывали — возникает локальный избыток задач на отдельном специалисте, и на другие задачи ему может не хватить времени.
Или наоборот, все в порядке, и мы опять заканчиваем раньше. И снова возникает ситуация, при которой у нас есть возможность воспользоваться небольшим временным отрезком, чтобы взять в работу следующую задачу. Но полноценную поставку за эти один-два дня сделать, скорее всего, не получится.
📌Что делать в этой ситуации?
1 вариант.
При декомпозиции сфокусироваться на том, чтобы в бэклоге оказались задачи разного размера. Например, не только 3, 5 или 8 сторипоинтов, но и небольшие задачи в 1, 2 сторипоинта — чтобы можно было заполнить ими любой разрыв.
2 вариант.
Определить наиболее приоритетные задачи и сфокусироваться на них с рассчетом потратить, например, 70% своего velocity. А 30% остается как буфер, который может использоваться по-разному, и в том числе команда может договориться и согласиться с тем, что перенос части задачи из спринта в спринт - это нормально.
В контексте построения agile процесса более предпочтительным является первый вариант. Однако команда может экспериментировать и выбрать наиболее удобный для нее способ работы в данный момент.
Желаем всем сбалансированной работы!
OnAgile Learning Hub
👥Обычно в команде есть несколько разных компетенций, которые должны сотрудничать друг с другом для создания ценности. Например, в IT это бэк-, фронт-разработчики, аналитики, тестировщики.
⏱Если у нас ограниченный временной отрезок для поставки ценности, например, спринт 2-3 недели, то команда, как правило, декомпозирует задачи. При этом могут возникать разрывы в поставке.
👉Например, у команды есть истории А, B и C, которые они взяли в спринт. А и B команда смогла целиком поставить, а история С полностью не влезла. Команда все равно берет ее в работу для оптимизации процесса, так как до конца спринта остается запас velocity — и частично делает. Оставшаяся часть работы по истории С перейдет в следующий спринт.
И здесь зачастую возникает дисбаланс нагрузки. Если в прошлом спринте по истории С свою работу сделал бэк, далее происходит отладка: возможно, нашли дефекты, и, соответственно, работу берет на себя тестировщик. И если оказывается, что дефектов больше, чем рассчитывали — возникает локальный избыток задач на отдельном специалисте, и на другие задачи ему может не хватить времени.
Или наоборот, все в порядке, и мы опять заканчиваем раньше. И снова возникает ситуация, при которой у нас есть возможность воспользоваться небольшим временным отрезком, чтобы взять в работу следующую задачу. Но полноценную поставку за эти один-два дня сделать, скорее всего, не получится.
📌Что делать в этой ситуации?
1 вариант.
При декомпозиции сфокусироваться на том, чтобы в бэклоге оказались задачи разного размера. Например, не только 3, 5 или 8 сторипоинтов, но и небольшие задачи в 1, 2 сторипоинта — чтобы можно было заполнить ими любой разрыв.
2 вариант.
Определить наиболее приоритетные задачи и сфокусироваться на них с рассчетом потратить, например, 70% своего velocity. А 30% остается как буфер, который может использоваться по-разному, и в том числе команда может договориться и согласиться с тем, что перенос части задачи из спринта в спринт - это нормально.
В контексте построения agile процесса более предпочтительным является первый вариант. Однако команда может экспериментировать и выбрать наиболее удобный для нее способ работы в данный момент.
Желаем всем сбалансированной работы!
OnAgile Learning Hub
👍5
Отличный вопрос задали под постом про дисбаланс в работе команды:
«А что делать, если есть дисбаланс по количеству работы у участников команды? К примеру, у бэка и тестировщика задач много, а у аналитика и фронта очень мало. И в силу особенности продукта работы для аналитика и фронта неоткуда взяться».
Об этом будет следующая статья👌
«А что делать, если есть дисбаланс по количеству работы у участников команды? К примеру, у бэка и тестировщика задач много, а у аналитика и фронта очень мало. И в силу особенности продукта работы для аналитика и фронта неоткуда взяться».
Об этом будет следующая статья👌
🔥6