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

Будем рады встрече в новом году. Полезные материалы вернутся на канал 9 января.

С наилучшими пожеланиями,
команда OnAgile

🚀Применяем 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

👥Создание пользовательских историй - требований к продукту в формате Agile.

Завершающими этапами создания бэклога продукта будут описание требований к нашему продукту в виде пользовательских историй, с дальнейшей их декомпозицией и приоритизацией.

👉 Для описания продуктовых идей в формате Пользовательских историй (User Stories), можно использовать стандартный шаблон, придуманный Майком Коном:
Как [роль/персона], я хочу [возможность продукта], чтобы [цель]

Например:
1️⃣ Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования.
2️⃣ Как управляющий кафе, я хочу видеть статистику бронирований, чтобы планировать загрузку заведения.

Как видно из примеров, описание цели в дополнение к возможности продукта позволяет команде лучше понимать контекст использования и, следовательно, придумать более качественную реализацию функциональности.

Далее мы прописываем Приемочные критерии о которых поговорим в следующем посте.

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