Дорожная карта развития продукта (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
⚡️Вебинар "Внедрение OKR в организациях среднего размера"
Привет!
Ранее мы уже затрагивали тему OKR, и так как это направление очень актуально, а совсем скоро пора будет задумываться над целями 2 квартала — мы решили провести для вас полезный вебинар на тему внедрения OKR в организациях среднего размера.
На вебинаре расскажем про OKR: что из себя представляет этот подход, откуда появился, где и как применяется. И сделаем разбор реального кейса внедрения, а также рассмотрим популярные ошибки, которые встречаются при использовании подхода. На вебинаре вы сможете задать свои вопросы, и мы с удовольствием на них ответим.
🎙Спикер: Артём Гринякин, тренер и консультант OnAgile Consulting
🗓Дата и время: 1 февраля в 19:00 (мск)
⏱Длительность вебинара: 1 час
⚡️Участие бесплатное
Зарегистрироваться
Привет!
Ранее мы уже затрагивали тему OKR, и так как это направление очень актуально, а совсем скоро пора будет задумываться над целями 2 квартала — мы решили провести для вас полезный вебинар на тему внедрения OKR в организациях среднего размера.
На вебинаре расскажем про OKR: что из себя представляет этот подход, откуда появился, где и как применяется. И сделаем разбор реального кейса внедрения, а также рассмотрим популярные ошибки, которые встречаются при использовании подхода. На вебинаре вы сможете задать свои вопросы, и мы с удовольствием на них ответим.
🎙Спикер: Артём Гринякин, тренер и консультант OnAgile Consulting
🗓Дата и время: 1 февраля в 19:00 (мск)
⏱Длительность вебинара: 1 час
⚡️Участие бесплатное
Зарегистрироваться
Декомпозиция и приоритизация бэклога
👉После того как пользовательские истории в общем виде сформированы, их необходимо декомпозировать, то есть разбить на более мелкие истории, каждую из которых можно будет брать в работу (например, она влезет в спринт).
Декомпозировать можно разными способами в зависимости от ситуации: по функциональности, по шагам бизнес-процесса, по логике взаимодействия с пользователем и т.д.
🔹Один из самых эффективных методов декомпозиции мы рассмотрели с вами в разделе про User Story Mapping.
🔹Второй частый метод декомпозиции – по приемочным критериям: как в примере выше, отдельный критерий может являться самостоятельной небольшой пользовательской историей.
📍Приоритизация пользовательских историй
После декомпозиции истории в бэклоге продукта необходимо приоритизировать в соответствии с их ценностью и возможностью быстрой реализации.
Стандартный способ приоритизации такой:
Приоритет = Ценность истории / Трудоемкость
🔹Из популярных количественных методов приоритизации можно порекомендовать RICE и WSJF.
🔹Из очень простого — метод приоритизации MoSCoW:
• Must-Have (Обязательно): Функционал, который обязательно должен быть включен в конечную версию продукта.
• Should-Have (Желательно): Важный функционал, но его отсутствие не является критичным.
• Could-Have (Возможно): Дополнительные функции, которые могут быть включены, если у нас есть время и ресурсы.
• Won't-Have (Не будем делать): Скорее всего не будем делать в ближайшее время.
⚡️Подробнее, с практическими кейсами и заданиями мы рассматриваем работу с бэклогом на наших тренингах.
База дается на тренинге Certified Agile Professional, а
дальнейшее погружение на тренинге Advanced Product Ownership.
Подключайтесь к ближайшей группе, будем рады увидеться и разобрать ваши кейсы вместе!
OnAgile Learning Hub
👉После того как пользовательские истории в общем виде сформированы, их необходимо декомпозировать, то есть разбить на более мелкие истории, каждую из которых можно будет брать в работу (например, она влезет в спринт).
Декомпозировать можно разными способами в зависимости от ситуации: по функциональности, по шагам бизнес-процесса, по логике взаимодействия с пользователем и т.д.
🔹Один из самых эффективных методов декомпозиции мы рассмотрели с вами в разделе про User Story Mapping.
🔹Второй частый метод декомпозиции – по приемочным критериям: как в примере выше, отдельный критерий может являться самостоятельной небольшой пользовательской историей.
📍Приоритизация пользовательских историй
После декомпозиции истории в бэклоге продукта необходимо приоритизировать в соответствии с их ценностью и возможностью быстрой реализации.
Стандартный способ приоритизации такой:
Приоритет = Ценность истории / Трудоемкость
🔹Из популярных количественных методов приоритизации можно порекомендовать RICE и WSJF.
🔹Из очень простого — метод приоритизации MoSCoW:
• Must-Have (Обязательно): Функционал, который обязательно должен быть включен в конечную версию продукта.
• Should-Have (Желательно): Важный функционал, но его отсутствие не является критичным.
• Could-Have (Возможно): Дополнительные функции, которые могут быть включены, если у нас есть время и ресурсы.
• Won't-Have (Не будем делать): Скорее всего не будем делать в ближайшее время.
⚡️Подробнее, с практическими кейсами и заданиями мы рассматриваем работу с бэклогом на наших тренингах.
База дается на тренинге Certified Agile Professional, а
дальнейшее погружение на тренинге Advanced Product Ownership.
Подключайтесь к ближайшей группе, будем рады увидеться и разобрать ваши кейсы вместе!
OnAgile Learning Hub
📌 Примеры OKR - Objectives and Key Results
(Цели и Ключевые Результаты).
Для качественного внедрения и использования OKR-подхода важно не только знать и понимать суть и принципы самой методологии, но и иметь опыт и насмотренность.
Поэтому подготовили для вас на карточках несколько примеров целей и ключевых результатов по ним, чтобы было проще по аналогии сформировать свои.
Также напоминаем, что уже завтра в 19:00 (мск) проведем вебинар Внедрение OKR в организациях среднего размера, где не только расскажем про OKR-подход и что он из себя представляет, но и сделаем разбор реального кейса внедрения, а также рассмотрим популярные ошибки, которые встречаются при использовании подхода. На вебинаре вы сможете задать свои вопросы, и мы с удовольствием на них ответим.
🎙Спикер: Артём Гринякин, тренер и консультант OnAgile Consulting
🗓Дата и время: 1 февраля в 19:00 (мск)
⏱Длительность вебинара: 1 час
⚡️Участие бесплатное
Зарегистрироваться
(Цели и Ключевые Результаты).
Для качественного внедрения и использования OKR-подхода важно не только знать и понимать суть и принципы самой методологии, но и иметь опыт и насмотренность.
Поэтому подготовили для вас на карточках несколько примеров целей и ключевых результатов по ним, чтобы было проще по аналогии сформировать свои.
Также напоминаем, что уже завтра в 19:00 (мск) проведем вебинар Внедрение OKR в организациях среднего размера, где не только расскажем про OKR-подход и что он из себя представляет, но и сделаем разбор реального кейса внедрения, а также рассмотрим популярные ошибки, которые встречаются при использовании подхода. На вебинаре вы сможете задать свои вопросы, и мы с удовольствием на них ответим.
🎙Спикер: Артём Гринякин, тренер и консультант OnAgile Consulting
🗓Дата и время: 1 февраля в 19:00 (мск)
⏱Длительность вебинара: 1 час
⚡️Участие бесплатное
Зарегистрироваться
❓Дисбаланс в объеме работы участников команды
Недавно под одной из публикаций про дисбаланс в работе команды задали хороший вопрос:
👉«А что делать, если есть дисбаланс по количеству работы у участников команды? К примеру, у бэка и тестировщика задач много, а у аналитика и фронта очень мало. И в силу особенности продукта работы для аналитика и фронта неоткуда взяться».
🎙Прикрепляем комментарий от нашего консультанта на этот счет. Подобные вопросы мы, кстати, разбираем на тренингах, в частности на программе Certified Agile Professional.
Недавно под одной из публикаций про дисбаланс в работе команды задали хороший вопрос:
👉«А что делать, если есть дисбаланс по количеству работы у участников команды? К примеру, у бэка и тестировщика задач много, а у аналитика и фронта очень мало. И в силу особенности продукта работы для аналитика и фронта неоткуда взяться».
🎙Прикрепляем комментарий от нашего консультанта на этот счет. Подобные вопросы мы, кстати, разбираем на тренингах, в частности на программе Certified Agile Professional.
🤨Откуда появляются токсики в команде и как с ними бороться?
Периодически в любой команде может появиться человек, который портит настроение и мотивацию других сотрудников. Такого участника команды обычно называют токсичным или токсиком.
👉Для работы с токсиками есть практика под названием TED (The Empowerment Dynamic), которая существует как некий антипод для треугольника Карпмана. Это треугольник драмы, в котором существуют три роли: жертва, гонитель и спасатель.
Все эти роли деструктивны и приводят к появлению токсиков.
Объединяет их то, что в основе лежит страх.
Распространенный пример токсика — высококвалифицированный специалист, который имеет отличные компетенции и знания, но у него не получается работать с командой: постоянно возникают конфликты, он с чем-то не согласен и так далее.
В основе такого поведения лежит боязнь потерять свою значимость и стать ненужным.😨
📌В связи с этим важно осознать, что бороться следует не с токсиками напрямую, а со страхами, которые у них есть.
Позже рассмотрим более подробно, что такое страх, какие страхи есть у разных ролей и что с ними делать, рассмотрим The Empowerment Dynamic и поговорим про конструктивную конфронтацию. Поставьте реакцию на пост, если эта тема вам интересна.🚀
OnAgile Learning Hub
Периодически в любой команде может появиться человек, который портит настроение и мотивацию других сотрудников. Такого участника команды обычно называют токсичным или токсиком.
👉Для работы с токсиками есть практика под названием TED (The Empowerment Dynamic), которая существует как некий антипод для треугольника Карпмана. Это треугольник драмы, в котором существуют три роли: жертва, гонитель и спасатель.
Все эти роли деструктивны и приводят к появлению токсиков.
Объединяет их то, что в основе лежит страх.
Распространенный пример токсика — высококвалифицированный специалист, который имеет отличные компетенции и знания, но у него не получается работать с командой: постоянно возникают конфликты, он с чем-то не согласен и так далее.
В основе такого поведения лежит боязнь потерять свою значимость и стать ненужным.😨
📌В связи с этим важно осознать, что бороться следует не с токсиками напрямую, а со страхами, которые у них есть.
Позже рассмотрим более подробно, что такое страх, какие страхи есть у разных ролей и что с ними делать, рассмотрим The Empowerment Dynamic и поговорим про конструктивную конфронтацию. Поставьте реакцию на пост, если эта тема вам интересна.🚀
OnAgile Learning Hub
🗓Проблемы при планировании в Agile
На этапе планирования команда может столкнуться с такими проблемами, как: "мы не готовы к планированию", "мы слишком много времени потратили на планирование" или "мы не можем рассчитать, сколько у нас поместится в спринт".
Решаются данные проблемы, как правило, за счет уточнения бэклога продукта.
🔹Начинать уточнение бэклога необходимо за несколько дней до планирования, а не в последний день, и ни в коем случае не совмещать с планированием. Если у вас двухнедельные спринты, то на второй неделе рекомендуем уделить минимум 2 дня (чаще всего это вторник-четверг) для того, чтобы провести качественное уточнение бэклога, разобраться в том, что предстоит сделать, и выполнить оценку.
🔹Важно также обратить внимание на уровень подготовки задач. На начальных этапах команда часто начинает либо слишком детально прорабатывать задачи, либо наоборот недостаточно детализирует. Универсальной формулы нет, надо просто договориться, какого уровня детализации мы будем придерживаться.
🔹Чтобы успешно планировать также необходимо знать возможности команды. Есть две модели, которые неплохо себя зарекомендовали — идеальные часы и оценка в относительных метриках с применением стори-поинтов.
Для идеальных часов очень важно разделять квоты, иметь определенный процент буфера.
В случае со стори-поинтами, важно иметь статистику по предыдущим спринтам, чтобы можно было определить динамику, понять, сколько в среднем мы доставляем, какое у нас среднее квадратичное отклонение.Чтобы мы знали, какой чаще всего самый плохой вариант, оптимальный вариант и самый лучший вариант для нас. И в зависимости от этого планировать активности.
🔹Также стоит учитывать, что необходимо планировать меньше, когда вы знаете, что у вас участники уходят в отпуска, на больничные, праздники и т.п. Все это влияет на ваши показатели и на то, сколько вы реально можете поставить.
🔹Еще одним немаловажным фактором является то, что у вас есть ограниченные компетенции. И если вы наберете задач, например, на 40 стори-поинтов и все эти задачи, условно говоря, на бэк, то не стоит удивляться, что сделаны будут только 15 из них.
Для того чтобы такие ситуации не возникали, необходимо подходить сбалансированно к той работе, которую вы берете, чтобы она была комбинирована и, соответственно, включала в себя все компетенции, которые присутствуют в команде. То есть была бизнесовая, а не чисто бэковая или, например, чисто фронтовая.
👉Подробнее и на практике вопросы планирования и оценки мы рассматриваем на тренинге Certified Agile Professional. Ближайшая группа уже с 20 февраля, вы можете успеть присоединиться к ней или спланировать на более поздние даты. Будем рады видеть вас на тренингах!🚀
OnAgile Learning Hub
На этапе планирования команда может столкнуться с такими проблемами, как: "мы не готовы к планированию", "мы слишком много времени потратили на планирование" или "мы не можем рассчитать, сколько у нас поместится в спринт".
Решаются данные проблемы, как правило, за счет уточнения бэклога продукта.
🔹Начинать уточнение бэклога необходимо за несколько дней до планирования, а не в последний день, и ни в коем случае не совмещать с планированием. Если у вас двухнедельные спринты, то на второй неделе рекомендуем уделить минимум 2 дня (чаще всего это вторник-четверг) для того, чтобы провести качественное уточнение бэклога, разобраться в том, что предстоит сделать, и выполнить оценку.
🔹Важно также обратить внимание на уровень подготовки задач. На начальных этапах команда часто начинает либо слишком детально прорабатывать задачи, либо наоборот недостаточно детализирует. Универсальной формулы нет, надо просто договориться, какого уровня детализации мы будем придерживаться.
🔹Чтобы успешно планировать также необходимо знать возможности команды. Есть две модели, которые неплохо себя зарекомендовали — идеальные часы и оценка в относительных метриках с применением стори-поинтов.
Для идеальных часов очень важно разделять квоты, иметь определенный процент буфера.
В случае со стори-поинтами, важно иметь статистику по предыдущим спринтам, чтобы можно было определить динамику, понять, сколько в среднем мы доставляем, какое у нас среднее квадратичное отклонение.Чтобы мы знали, какой чаще всего самый плохой вариант, оптимальный вариант и самый лучший вариант для нас. И в зависимости от этого планировать активности.
🔹Также стоит учитывать, что необходимо планировать меньше, когда вы знаете, что у вас участники уходят в отпуска, на больничные, праздники и т.п. Все это влияет на ваши показатели и на то, сколько вы реально можете поставить.
🔹Еще одним немаловажным фактором является то, что у вас есть ограниченные компетенции. И если вы наберете задач, например, на 40 стори-поинтов и все эти задачи, условно говоря, на бэк, то не стоит удивляться, что сделаны будут только 15 из них.
Для того чтобы такие ситуации не возникали, необходимо подходить сбалансированно к той работе, которую вы берете, чтобы она была комбинирована и, соответственно, включала в себя все компетенции, которые присутствуют в команде. То есть была бизнесовая, а не чисто бэковая или, например, чисто фронтовая.
👉Подробнее и на практике вопросы планирования и оценки мы рассматриваем на тренинге Certified Agile Professional. Ближайшая группа уже с 20 февраля, вы можете успеть присоединиться к ней или спланировать на более поздние даты. Будем рады видеть вас на тренингах!🚀
OnAgile Learning Hub
Фундаментальный тренинг по Agile, Scrum, Kanban
Напоминаем, что уже 20-22 февраля пройдет тренинг Certified Agile Professional.
Эта программа — фундамент, с которого начинается путь в Agile и изменения в организациях.
🔹Вы освоите современные методы управления (Agile, Scrum, Kanban).
🔹Пройдёте одну из самых широких и проработанных программ на рынке.
🔹Получите сертификат от международного консорциума ICAgile, который ценится компаниями во всем мире.
🔹Будете готовы начать переход к Agile и Scrum в своей команде.
👉Тренинг подойдет руководителям любого уровня, специалистам, которые работают или хотят начать работать в Agile-команде, тем, кто ищет прорыва в карьере и всем кто хочет применять современные подходы к управлению.
💻Интенсивный онлайн-формат позволит быстро и эффективно усвоить программу.
Для подписчиков канала скидка 2000 руб. по коду START.
Узнать подробнее и зарегистрироваться👈
Напоминаем, что уже 20-22 февраля пройдет тренинг Certified Agile Professional.
Эта программа — фундамент, с которого начинается путь в Agile и изменения в организациях.
🔹Вы освоите современные методы управления (Agile, Scrum, Kanban).
🔹Пройдёте одну из самых широких и проработанных программ на рынке.
🔹Получите сертификат от международного консорциума ICAgile, который ценится компаниями во всем мире.
🔹Будете готовы начать переход к Agile и Scrum в своей команде.
👉Тренинг подойдет руководителям любого уровня, специалистам, которые работают или хотят начать работать в Agile-команде, тем, кто ищет прорыва в карьере и всем кто хочет применять современные подходы к управлению.
💻Интенсивный онлайн-формат позволит быстро и эффективно усвоить программу.
Для подписчиков канала скидка 2000 руб. по коду START.
Узнать подробнее и зарегистрироваться👈