Давайте посмотрим пример формирования MVP для приложения для бронирования мест в кафе.
📌Важное заключение: мы взяли только самый минимум фич, чтобы выпустить версию как можно быстрее.
Это не значит, что остальные фичи мы будем делать когда-то непонятно когда.
Наоборот, никто не мешает нам сразу после выпуска первой версии учесть обратную связь и в течение недели или месяца выпустить новую версию, которая уже будет подходить для большего количества пользователей.
Такое развитие продукта тоже необходимо заранее проектировать и обсуждать со стейкхолдерами, чтобы иметь понятную всем дорожную карту развития продукта, о которой мы поговорим чуть позже.⚡️
OnAgile Learning Hub
📌Важное заключение: мы взяли только самый минимум фич, чтобы выпустить версию как можно быстрее.
Это не значит, что остальные фичи мы будем делать когда-то непонятно когда.
Наоборот, никто не мешает нам сразу после выпуска первой версии учесть обратную связь и в течение недели или месяца выпустить новую версию, которая уже будет подходить для большего количества пользователей.
Такое развитие продукта тоже необходимо заранее проектировать и обсуждать со стейкхолдерами, чтобы иметь понятную всем дорожную карту развития продукта, о которой мы поговорим чуть позже.⚡️
OnAgile Learning Hub
Друзья, поделитесь пожалуйста обратной связью по последним материалам о Подготовке Бэклога.
Как вам такой формат контента в нашем канале?
Как вам такой формат контента в нашем канале?
Anonymous Poll
64%
Для меня полезно и интересно, классный формат!
0%
Показалось не очень интересным и полезным
9%
Мне интересно, но сложновато вопринимать суть в таком формате
23%
Все отлично, хотелось бы еще больше примеров
5%
Напишу свои мысли в комментариях
С наступающим Новым годом, друзья!🎄 Спасибо, что вы были с нами в этом году. Желаем отличного отдыха в праздники и счастливой встречи 2024-го года!🎉
Будем рады встрече в новом году. Полезные материалы вернутся на канал 9 января.
С наилучшими пожеланиями,
команда OnAgile
Будем рады встрече в новом году. Полезные материалы вернутся на канал 9 января.
С наилучшими пожеланиями,
команда OnAgile
Формулируем цели по 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
Дорожная карта развития продукта (Product Roadmap)
👉Сегодня поговорим про ключевой артефакт, который определяет наше видение этапов развития продукта. Он помогает команде и заинтересованным лицам выровняться в понимании будущего и сформировать корректные ожидания.
На карточках выше вариант того, какие могут быть основные этапы дорожной карты для примера дальнейшего развития MVP приложения для бронирования мест в кафе, который мы рассматривали ранее.
Мы можем опубликовать описание еще более структурного и системного (но, по-прежнему легковесного) подхода к формированию дорожной карты продукта. Поставьте плюсик в комментариях, если интересно.
—
Предыдущие публикации серии экспертных тем про основные этапы подготовки бэклога продукта:
✅ Формулировка цели продукта
✅ Формирование видения продукта
✅ Проектирование продукта с помощью такого инструмента, как User Story Mapping (USM) с примером
✅ Формирование состава первой поставки, минимальной версии нашего продукта (MVP) с примером
OnAgile Learning Hub
👉Сегодня поговорим про ключевой артефакт, который определяет наше видение этапов развития продукта. Он помогает команде и заинтересованным лицам выровняться в понимании будущего и сформировать корректные ожидания.
На карточках выше вариант того, какие могут быть основные этапы дорожной карты для примера дальнейшего развития MVP приложения для бронирования мест в кафе, который мы рассматривали ранее.
Мы можем опубликовать описание еще более структурного и системного (но, по-прежнему легковесного) подхода к формированию дорожной карты продукта. Поставьте плюсик в комментариях, если интересно.
—
Предыдущие публикации серии экспертных тем про основные этапы подготовки бэклога продукта:
✅ Формулировка цели продукта
✅ Формирование видения продукта
✅ Проектирование продукта с помощью такого инструмента, как User Story Mapping (USM) с примером
✅ Формирование состава первой поставки, минимальной версии нашего продукта (MVP) с примером
OnAgile Learning Hub
🚀Применяем 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
👥Создание пользовательских историй - требований к продукту в формате Agile.
Завершающими этапами создания бэклога продукта будут описание требований к нашему продукту в виде пользовательских историй, с дальнейшей их декомпозицией и приоритизацией.
👉 Для описания продуктовых идей в формате Пользовательских историй (User Stories), можно использовать стандартный шаблон, придуманный Майком Коном:
Как [роль/персона], я хочу [возможность продукта], чтобы [цель]
Например:
1️⃣ Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования.
2️⃣ Как управляющий кафе, я хочу видеть статистику бронирований, чтобы планировать загрузку заведения.
Как видно из примеров, описание цели в дополнение к возможности продукта позволяет команде лучше понимать контекст использования и, следовательно, придумать более качественную реализацию функциональности.
Далее мы прописываем Приемочные критерии о которых поговорим в следующем посте.
OnAgile Learning Hub
Завершающими этапами создания бэклога продукта будут описание требований к нашему продукту в виде пользовательских историй, с дальнейшей их декомпозицией и приоритизацией.
👉 Для описания продуктовых идей в формате Пользовательских историй (User Stories), можно использовать стандартный шаблон, придуманный Майком Коном:
Как [роль/персона], я хочу [возможность продукта], чтобы [цель]
Например:
1️⃣ Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования.
2️⃣ Как управляющий кафе, я хочу видеть статистику бронирований, чтобы планировать загрузку заведения.
Как видно из примеров, описание цели в дополнение к возможности продукта позволяет команде лучше понимать контекст использования и, следовательно, придумать более качественную реализацию функциональности.
Далее мы прописываем Приемочные критерии о которых поговорим в следующем посте.
OnAgile Learning Hub
📌Описание приемочных критериев для пользовательской истории.
👆В посте выше поговорили про Создание пользовательских историй - требований к продукту в формате Agile.
Но достаточно ли нам такого описания требования, чтобы начать его разработку? Конечно нет.
Поэтому обычно в дополнение к истории мы прописываем Приемочные критерии – набор утверждений, который помогает нам лучше понять, что и как нужно сделать.
👉Например, для первой истории из поста выше:
"Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования."
Приемочные критерии могут быть следующие:
• Отображать кафе в пределах 10км
• Сделать фильтр по времени работы «Открыто сейчас»
• Для каждого кафе отображается его рейтинг
Теперь описание выглядит достаточно проработанным, разработчики задали все свои вопросы и в целом готовы приступать к реализации.🚀
Далее истории необходимо декомпозировать и приоритизировать. Об этом поговорим в следующих публикациях.
OnAgile Learning Hub
👆В посте выше поговорили про Создание пользовательских историй - требований к продукту в формате Agile.
Но достаточно ли нам такого описания требования, чтобы начать его разработку? Конечно нет.
Поэтому обычно в дополнение к истории мы прописываем Приемочные критерии – набор утверждений, который помогает нам лучше понять, что и как нужно сделать.
👉Например, для первой истории из поста выше:
"Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования."
Приемочные критерии могут быть следующие:
• Отображать кафе в пределах 10км
• Сделать фильтр по времени работы «Открыто сейчас»
• Для каждого кафе отображается его рейтинг
Теперь описание выглядит достаточно проработанным, разработчики задали все свои вопросы и в целом готовы приступать к реализации.🚀
Далее истории необходимо декомпозировать и приоритизировать. Об этом поговорим в следующих публикациях.
OnAgile Learning Hub
Дисбаланс в работе команды🗓
👥Обычно в команде есть несколько разных компетенций, которые должны сотрудничать друг с другом для создания ценности. Например, в 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 ошибок при внедрении Agile"
Недавно мы проводили вебинар, на котором разбирали ошибки внедрения Agile и работы с командой.
Для удобства просмотра разбили вебинар на фрагменты.
В частности, теперь есть отдельные видео по следующим ошибкам:
- Оптимизировать работу команды, а не работу системы
- Бросать менеджеров в костер проблем
- Игнорирование улучшений и ОС, идущей из команд
- Непонимание концепта лидерства и культуры
- Убежденность, что процесс трансформации в организации — идеальный проект
Приятного просмотра!
А уже совсем скоро анонсируем новый вебинар для вас;)
OnAgile Learning Hub
Недавно мы проводили вебинар, на котором разбирали ошибки внедрения Agile и работы с командой.
Для удобства просмотра разбили вебинар на фрагменты.
В частности, теперь есть отдельные видео по следующим ошибкам:
- Оптимизировать работу команды, а не работу системы
- Бросать менеджеров в костер проблем
- Игнорирование улучшений и ОС, идущей из команд
- Непонимание концепта лидерства и культуры
- Убежденность, что процесс трансформации в организации — идеальный проект
Приятного просмотра!
А уже совсем скоро анонсируем новый вебинар для вас;)
OnAgile Learning Hub