OnAgile Learning Hub 💎

Дисбаланс в работе команды🗓 👥Обычно в команде есть несколько разных компетенций, которые должны сотрудничать друг с другом для создания ценности. Например, в IT это бэк-, фронт-разработчики, аналитики, тестировщики. ⏱Если у нас ограниченный временной отрезок для поставки ценности, например, спринт 2-3 недели, то команда, как правило, декомпозирует задачи. При этом могут возникать разрывы в поставке. 👉Например, у команды есть истории А, B и C, которые они взяли в спринт. А и B команда смогла целиком поставить, а история С полностью не влезла. Команда все равно берет ее в работу для оптимизации процесса, так как до конца спринта остается запас velocity — и частично делает. Оставшаяся часть работы по истории С перейдет в следующий спринт. И здесь зачастую возникает дисбаланс нагрузки. Если в прошлом спринте по истории С свою работу сделал бэк, далее происходит отладка: возможно, нашли дефекты, и, соответственно, работу берет на себя тестировщик. И если оказывается, что дефектов больше, чем рассчитывали — возникает локальный избыток задач на отдельном специалисте, и на другие задачи ему может не хватить времени. Или наоборот, все в порядке, и мы опять заканчиваем раньше. И снова возникает ситуация, при которой у нас есть возможность воспользоваться небольшим временным отрезком, чтобы взять в работу следующую задачу. Но полноценную поставку за эти один-два дня сделать, скорее всего, не получится. 📌Что делать в этой ситуации? 1 вариант. При декомпозиции сфокусироваться на том, чтобы в бэклоге оказались задачи разного размера. Например, не только 3, 5 или 8 сторипоинтов, но и небольшие задачи в 1, 2 сторипоинта — чтобы можно было заполнить ими любой разрыв. 2 вариант. Определить наиболее приоритетные задачи и сфокусироваться на них с рассчетом потратить, например, 70% своего velocity. А 30% остается как буфер, который может использоваться по-разному, и в том числе команда может договориться и согласиться с тем, что перенос части задачи из спринта в спринт - это нормально. В контексте построения agile процесса более предпочтительным является первый вариант. Однако команда может экспериментировать и выбрать наиболее удобный для нее способ работы в данный момент. Желаем всем сбалансированной работы! OnAgile Learning Hub

📌Описание приемочных критериев для пользовательской истории. 👆В посте выше поговорили про Создание пользовательских историй - требований к продукту в формате Agile. Но достаточно ли нам такого описания требования, чтобы начать его разработку? Конечно нет. Поэтому обычно в дополнение к истории мы прописываем Приемочные критерии – набор утверждений, который помогает нам лучше понять, что и как нужно сделать. 👉Например, для первой истории из поста выше: "Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования." Приемочные критерии могут быть следующие: • Отображать кафе в пределах 10км • Сделать фильтр по времени работы «Открыто сейчас» • Для каждого кафе отображается его рейтинг Теперь описание выглядит достаточно проработанным, разработчики задали все свои вопросы и в целом готовы приступать к реализации.🚀 Далее истории необходимо декомпозировать и приоритизировать. Об этом поговорим в следующих публикациях. OnAgile Learning Hub

👥Создание пользовательских историй - требований к продукту в формате Agile. Завершающими этапами создания бэклога продукта будут описание требований к нашему продукту в виде пользовательских историй, с дальнейшей их декомпозицией и приоритизацией. 👉 Для описания продуктовых идей в формате Пользовательских историй (User Stories), можно использовать стандартный шаблон, придуманный Майком Коном: Как [роль/персона], я хочу [возможность продукта], чтобы [цель] Например: 1️⃣ Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования. 2️⃣ Как управляющий кафе, я хочу видеть статистику бронирований, чтобы планировать загрузку заведения. Как видно из примеров, описание цели в дополнение к возможности продукта позволяет команде лучше понимать контекст использования и, следовательно, придумать более качественную реализацию функциональности. Далее мы прописываем Приемочные критерии о которых поговорим в следующем посте. 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

Дорожная карта развития продукта (Product Roadmap) 👉Сегодня поговорим про ключевой артефакт, который определяет наше видение этапов развития продукта. Он помогает команде и заинтересованным лицам выровняться в понимании будущего и сформировать корректные ожидания. На карточках выше вариант того, какие могут быть основные этапы дорожной карты для примера дальнейшего развития MVP приложения для бронирования мест в кафе, который мы рассматривали ранее. Мы можем опубликовать описание еще более структурного и системного (но, по-прежнему легковесного) подхода к формированию дорожной карты продукта. Поставьте плюсик в комментариях, если интересно. — Предыдущие публикации серии экспертных тем про основные этапы подготовки бэклога продукта: ✅ Формулировка цели продукта ✅ Формирование видения продукта ✅ Проектирование продукта с помощью такого инструмента, как User Story Mapping (USM) с примером ✅ Формирование состава первой поставки, минимальной версии нашего продукта (MVP) с примером OnAgile Learning Hub

Формулируем цели по 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 🚀Начало года - начало движения к новым целям. Предлагаем вспомнить простой метод, который поможет сформулировать ваши цели. 📚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

С наступающим Новым годом, друзья!🎄 Спасибо, что вы были с нами в этом году. Желаем отличного отдыха в праздники и счастливой встречи 2024-го года!🎉 Будем рады встрече в новом году. Полезные материалы вернутся на канал 9 января. С наилучшими пожеланиями, команда OnAgile

👆В посте выше мы рассмотрели основные этапы формирования MVP. 👉Давайте посмотрим пример прохождения этих этапов для приложения для бронирования мест в кафе. 📌Важное заключение: мы взяли только самый минимум фич, чтобы выпустить версию как можно быстрее. Это не значит, что остальные фичи мы будем делать когда-то непонятно когда. Наоборот, никто не мешает нам сразу после выпуска первой версии учесть обратную связь и в течение недели или месяца выпустить новую версию, которая уже будет подходить для большего количества пользователей.   Такое развитие продукта тоже необходимо заранее проектировать и обсуждать со стейкхолдерами, чтобы иметь понятную всем дорожную карту развития продукта, о которой мы поговорим чуть позже.⚡️ OnAgile Learning Hub

Проектирование первой версии продукта (MVP) 🚀   Продолжаем серию экспертных тем про основные этапы подготовки бэклога продукта. Напомним, что мы уже поговорили про: ✅ Формулировку цели продукта ✅ Формирование видения продукта ✅ Проектирование продукта с помощью такого инструмента, как User Story Mapping (USM) с примером 👉Сегодня расскажем про формирование состава первой поставки, минимальной версии нашего продукта (MVP).   💻Вообще, MVP расшифровывается как Minimum Viable Product (минимально жизнеспособный продукт). Его идея в том, чтобы помочь команде в очень короткие сроки выпустить что-то ценное для клиентов, тем самым быстро и качественно провалидировать исходные гипотезы по продукту – что он нужен кому-то кроме нас самих, что можем найти нашего потребителя, что потребитель будет готов нам заплатить и так далее. 👆На карточках основные этапы формирования MVP. В следующем посте рассмотрим эти этапы на примере. OnAgile Learning Hub

Привет! Недавно мы запустили интерактивный мини-курс по основам гибкого подхода, специально созданный для тех, кто только начинает свое знакомство с Agile: @OnAgile_Academy_Bot 🤖 Основные темы мини-курса: 👉Нужен ли вам Agile? Чем Agile отличается от классического подхода к проектному управлению и где он применим 👉Scrum Как справляться с постоянно меняющимися "хотелками" заказчиков и наладить эффективную командную работу 👉Kanban Что делать, если нагрузка между членами команды распределена неравномерно Полное время изучения материалов не более 30 минут⏱ Всех, кто успешно пройдет мини-курс, ждет приятный бонус в конце🎁 Поделитесь с теми, кто только начинает свой путь в Agile🤝 Присоединяйтесь: @OnAgile_Academy_Bot 🌟

В посте выше описали основные шаги проектирования продукта с помощью USM. Небольшой пример: Предположим, ваша команда проектирует приложение для бронирования мест в кафе. Вашими персонами могут быть «Фрилансеры, которым нужно место для работы с кофе и интернетом», «Сотрудники соседнего офиса, спешащие на работу или на встречу», «Сотрудники офиса, которым нужно пообедать». У каждой из этих персон будут свои цели и, соответственно, может отличаться функциональность приложения. Например, если я спешу на встречу в офис, то мне нужно по пути заказать и оплатить себе чашку Флэт-уайт, чтобы я только зашел и забрал ее без очереди и ожидания☕️🏃‍♂️ Для каждой персоны вы прописываете задачи, например: "Выбрать кафе", "Забронировать место", "Подтвердить бронирование" и "Оставить отзыв". Затем по каждой из активностей проектируете, как может выглядеть ее реализация в приложении, например: "Посмотреть фото кафе", "Выбрать время бронирования", "Получить подтверждение брони по email" и так далее 📝💻 По итогам создания карты пользовательских историй вы сможете увидеть всю картину взаимодействия пользователя с продуктом, а также выбрать, какие из задач необходимо реализовать в первой версии продукта. Об этом мы расскажем в следующей статье цикла. OnAgile Learning Hub

🚀Продолжаем рассказ про основные этапы подготовки бэклога продукта. Ранее мы уже рассмотрели первый этап - формулировку цели и формирование видения продукта. 🗺Сегодня поговорим про второй этап - проектирование продукта с помощью такого инструмента, как User Story Mapping (USM). Он хорошо помогает переключить фокус команды с задач, которые нужно сделать, в плоскость выявления потребностей пользователей и способов, которыми наш продукт сможет их эффективно закрыть. И в целом USM позволяет очень быстро выработать общее понимание продукта всеми участниками команды🤝 Основные шаги проектирования продукта с помощью USM на карточках выше. 👆

Замечательная метафора маркетинга, которая нам особенно нравится:

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

За последние полтора месяца мы провели шесть (да, 6!) тренингов для команд Marketing & Sales по применению Agile-подхода. Разобрались, как и где в маркетинге могут быть использованы методы Scrum и Kanban, и какую пользу от них можно получить. 🌟 Есть возможность провести два корпоративных тренинга в январе, напишите Дмитрию, если вам актуально: @dmitryl12 OnAgile Learning Hub

🔍Видение продукта можно сформировать по шаблону 👆 👉Например: «Для аналитиков, которые стремятся к быстрым и основанным на данных решениям, "FastData" - это платформа для визуализации данных, которая сочетает интуитивный интерфейс с продвинутыми возможностями анализа в режиме реального времени. В отличие от "DataAnalytics", наш продукт гарантирует мгновенный доступ к ключевым метрикам и удобство использования, облегчая своевременное принятие решений». 🚀Помните, что цель и видение продукта должны быть четкими и вдохновляющими для команды разработки, а также ориентированными на удовлетворение потребностей пользователей и достижение бизнес-целей.

🚀Начнём рассмотрение этапов подготовки бэклога продукта по порядку с основополагающего - определение цели и видения продукта. 🎯Цель продукта должна четко отражать, какую проблему он решает или какую потребность удовлетворяет. Рекомендации по определению цели: 1. Проведите анализ рынка и изучите потребности вашей целевой аудитории. 🌐 2. Определите основные проблемы, с которыми сталкиваются ваши пользователи, и сфокусируйте цель на их решении. 📋 3. Выделите, чем ваш продукт отличается от конкурентов и каким образом он приносит ценность пользователям. 💼 4. Определите, какие конкретные результаты вы ожидаете от продукта и как они будут измерены. 📊 5. Убедитесь, что цель продукта соответствует общим бизнес-целям компании. 🤝 👉Примеры целей: - Увеличить объем продаж на 30% в первые полгода, внедрив персонализированные рекомендации и улучшив процесс оформления заказа. - Достичь 50 000 активных пользователей, обучающихся более 2 часов в неделю, в течение первого квартала.

📝Как создать хороший Бэклог продукта 🔄Качественная подготовка бэклога продукта — ключевой шаг для дальнейшей эффективной работы в Agile-среде. 🛠Мы с командой подготовили для вас список основных этапов создания бэклога на карточках. 🚀Дальше в серии постов мы подробнее расскажем про каждый из этапов подготовки бэклога.

Всем привет!🌟 19-21 декабря состоится последний в этом году профессиональный интенсивный онлайн-тренинг по Agile, Scrum, Kanban с международной сертификацией от ICAgile🚀 👉 Кому полезен тренинг: - Руководителям, которые хотят понять, как применять гибкие подходы и посмотреть, как это делают другие. - Тем, кто ищет профессионального развития или варианты использования Agile в своей работе. - Всем, кто хочет расширить и систематизировать понимание Agile-практик. Не стоит откладывать на следующий год то, что можно сделать уже в этом! 😉 Будем рады видеть вас на тренинге! 🔍 Узнать подробнее о тренинге