📚 Иметь красивый, прозрачный бэклог продукта — это только одна часть более легкого и быстрого пути развития. Каким ещё свойством должен обладать бэклог продукта?

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

Один из методов расчёта приоритета — это метод WSJF. О нём есть много статей с примерами.

➡️ А сегодня поговорим о применимости метода и автоматизации. В Jira есть готовый плагин для расчета WSJF. Даже если у вас другой трекер, то ввести новые поля и работать с ними он наверняка поможет.

На изображении схематичное применение метода: по указанным типам задач достаточно проставить то, что просит метод WSJF и плагин сам выставить продуктовый приоритет в зависимости от введённых вами данных. Даже математику знать не надо.

Помимо расчета приоритета, плагин может сам отсортировать задачи на канбан-доске или же сразу во всем бэклоге. Ручной поиск важных задач снимается и уходит на плечи автоматизированной системы расчета.

❓А как вы автоматизируете расчет приоритета задач? Может быть научились применять для этого ИИ? Поделитесь в комментариях.

@agileincubator

Автоматическое создание задач при создании Эпика

Знаете, чем отличается человек от «машины»? Тем, что человек может ошибиться и забыть. Конечно, не только этим, но чаще всего человек забывает и ошибается. А что происходит, когда человек забывает сделать ту или иную задачу для выполнения большого проекта? Правильно, доделывание позже, срывы сроков, бюджетов, качества будущего продукта.

❤️Как раз для того, чтобы сократить количество таких проблем, люди и придумали компьютеры и автоматизацию. Несколько лет назад услышал из интервью Илона Маска: рассмотрим весь процесс, убери лишнее, оптимизируй, и только потом автоматизируй. Предлагаю вам начать с конца. Допустим, что процессы у вас уже работают и выстроены как надо. Давайте убирать ручную работу и сокращать будущие возможные проблемы.

❤️Одной из частых проблем, которая возникала в моей практике — люди забывали писать различные тесты, писать документацию или вовсе пренебрегали этим умышленно.

Инструмент трекера Jira (как, скорее всего, и многих других) позволяет настроить свою работу так, что при создании Эпика (ну или любого другого типа задачи) можно указать, какие дополнительные задачи внутри этого Эпика необходимо создать автоматически и сразу с готовым описанием (описание тоже настраивается). Вся настройка у знающего человека может занять до получаса, а эффект от этого сэкономит многие часы доделок и многое количество нервов.

🖼 Как видно из скриншота, при создании Эпика достаточно указать, какие дополнительные задачи необходимо создать. Согласитесь, проставить галочку намного проще, нежели заходить и руками создавать необходимые, порой однотипные задачи.

❤️А какие типовые задачи для каждого Эпика используете вы в своей работе? А может, вы уже автоматизировали этот процесс? Поделитесь в комментариях.

@agileincubator

Автоматизация подсчёта оставшегося времени по задаче

Бывает так, что в компаниях используется трекинг времени по задачам. Причины для этого могут быть разные, но сейчас не об этом.

Зачастую уходит очень много времени для того, чтобы высчитать правильно потраченное и оставшееся время по задаче. Все эти пресловутые минуты, часы или даже дни. Все требует учета для корректного контроля времени. Порой именно от правильного трекинга может зависеть зарплата разработчика. ❗️

❗ Тут на помощь нам вновь приходит автоматизация из трекера Jira.

Нехитрая настройка, плюс немного математических формул, помогут нам корректно учитывать время основной задачи. Для этого достаточно провести относительно детальную декомпозицию задачи и выписать шаги для достижения желаемого результата в виде вложенных задач.

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

И конечно же, каждый рабочий день вы будете работать и тратить время на те или иные задачи, списывать часы и указывать, что полезного удалось сделать за отведённое время.

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

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

❗️А в вашей компании ведётся учет временных трудозатрат сотрудников? Напишите в комментариях.

P.S. Текст введённый для расчёта времени
{{#=}}{{issue.subtasks.original estimate.sum}} / 60 {{/}}

@agileincubator

🗓12 февраля в 19:00 мск состоится A2A: Agile-практики для Agile-практиков — встреча для скрам-мастеров, аджайл-коучей и деливери-менеджеров.

Что будем делать❓
Делиться своими историями успеха и неудач, маленьких побед и разгромных поражений, мечтами и страхами в сфере Agile. И поддерживать друг-друга советами, коучингом или морально, в зависимости от запроса.

Без цензуры, без записи, без зрителей — только живые кейсы, только живое общение.

✅ Зарегистрироваться.

#agile #scrum #proagile #agilesupport
@proagilerussia

❓Как часто ваши разработчики пользуются рабочей почтой для отслеживания обновлений в карточке в трекере? Думаю, не очень часто. По крайней мере, в моём опыте таких было очень мало.

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

Чтобы разработчик получал только полезную информацию из карточки, мы перешли на использование хэштегов в сообщениях. Например:
🟠#вопрос — означал, что в задаче есть вопрос, требующий внимания разработчика;
🟠#срочно — был признак того, что ответ не ждёт отлагательств;
🟠#консультация — в теле описания задачи был признаком того, что мне, как руководителю группы разработки, нужно ответить на вопрос, а разработчикам тревожится не стоит.

И таких хэштегов у нас было много на разные варианты использования. На их сборы ушло примерно месяца два, для себя мы выстроили целую систему таких хэштегов для комфортной работы без отвлечений.
⏩А в самой автоматизации выглядит все достаточно просто. Если с хештегом в описании все понятно, в условиях просто ставим: «Описание содержит #консультация». Сложнее с комментом, там на помощь приходят smart value. Используем схему, как на картинке. Проверяем, что именно последний коммент имеет хэштег, а не какой-либо ранний. Соответственно, в мессенджер попадают только сообщения с хэштегами и только нужного типа нужным людям или в нужные чаты.

Звучит немного запутанно и, возможно, бесполезно. Но в своё время такая автоматизация нас сильно выручала в плане общения. Разработчик знает, что сообщение в мессенджере полезное, и сразу читает его. По такому же принципу можно отслеживать и другие ключевые слова в описании задачи или в комментариях. К примеру, ловить слово «Крит», если нам надо быстрее реагировать на критичные баги. Или отловить в комментариях, когда кто-то начинает ругаться на долго отвечающего разработчика.

❓А какие варианты использования «отлова» ключевых слов в задачах вы сможете придумать? Напиши в комментариях.

@proagilerussia

День космонавтов в Agile!

12 апреля 2025 года состоится очередная встреча agile-практиков, посвященная дню космонавтики.

Наша цель – создать площадку для открытого обсуждения тех вызовов и трудностей, с которыми сталкиваются профессионалы в своей работе. Мы верим, что анализ ошибок и неудач может быть не менее ценным, чем обсуждение успешных проектов.

Ваши честные кейсы помогут другим сделать их работу более эффективной.

//Уникальное мероприятие для безопасного обмена опытом. Участники подпишут NDA при входе.

Если вы готовы присоединиться к нам и поделиться своими реальными историями успеха/фейла через неудачи, пожалуйста, заполните форму регистрации на нашем сайте до 12 марта 2025 года.

Будем рады видеть вас среди наших спикеров!
⏩Оставить заявку здесь

@proagilerussia

⭕️ Смена статуса задачи в Jira через Git

Последнее, чем хотел бы поделиться на данный момент в теме автоматизации — это смена статуса задач в Jira через комментарии в Git. Будет больше теории нежели практики, поскольку доступы уже пропали к системам, где это реализовывал и немного подзабыл. Но суть донесу и, возможно, знаток Jira подскажет, как это реализовать в сегодняшних реалиях.

Суть достаточно проста:
🟠 Настраиваем интеграцию Jira и Git через плагин с маркетплейса Jira.
🟠 Создаём пользователя с правами записи в Git и в Jira.
🟠 Из текущего рабочего процесса (схема в Jira, где нарисовано, из какого статуса в какой мы можем переводить) берем название каждого перехода (как правило, оно совпадает с тем, что вы видите при наведении мышки).
🟠 Вот тут честно пробел, вроде бы все возможные переходы мы указывали в поле Transition ID(s), а взять их можно вот по такой ссылке https://companyname.atlassian.net/rest/api/2/issue/ISSUENAME-123/transitions.

где ISSUENAME-123 — имя какой-нибудь задачи в нужном состоянии. Вы получите JSON c массивом transitions, из которого можно взять нужный id.

🟠 Дальше можем написать комментарий с указанием ключа задачи, сам комментарий и статус, в который хотим перевести задачу.

И вуаля! Задача в Jira меняет статус без открывания доски, поиска задачи, таскания карточки и прочего всего, что так не любят разработчики.

➕Ещё плюсом можно отметить и то, что в карточке в Jira и в ветке в Git появляется кросс-ссылка, для простоты понимания поставленной задачи и просмотра кода.

🔴 В инструкции могут быть небольшие неточности в виду истекшего срока памяти в моей голове.

Если среди читателей есть знатоки Jira с доступами и знающие, как такое настроить, мы все будем очень признательны за краткую инструкцию, как это сделать.

⭐️ В очередной четверг давайте поговорим про StarMap или Звёздную карту, смотря, кто как называет (Звёздная карта, потому что наивысшим уровнем владения считается символ Звезды — именно она означает мастера своего дела). Достаточно простой инструмент для заполнения и обновления, но дающий много вариантов его использования.

Несколько лет назад вместе с Андреем Гириным выступал на конференции в Томске и в живую наблюдал, как пара десятков совершенно не знакомых людей заполняли StarMap. И знаете, что — у них это получилось! Что лишний раз доказывает, что инструмент очень прост (ну и Андрей крутой спикер!).👍

По шагам, что нужно сделать:

🔠 Определить навыки, которые вам нужны в вашем текущем или новом проекте, определить навыки, которые вам нужны для конкретной роли в компании, возможно вы захотите вместо навыков выделить ключевые блоки или направления в продукте. Либо любые другие части, знания и навыки, в которых вам необходимо мониторить текущую ситуацию.

2️⃣ Определиться с понятиями:
➖ Нет понимания,
🎓 Хочу изучить,
⭐️ Знаю высоком уровне,
либо другие ваши варианты*.
Это нужно для разделения уровня владения выделенным навыком или знания в определённой области. Чем меньше таких значений (изначально в инструменте их три), тем яснее будет картина. Договоритесь с участниками, что вы вкладываете в каждое понятие.

3️⃣ Подготовьте таблицу: в строках — ФИО участников, в столбцах — необходимые навыки, области продукта или другой вариант.

4️⃣ Честно поставьте нужное значение около своего имени на пересечении с навыком.

Четыре простых шага дадут вам понимание текущей картины в вашей команде. Выглядит достаточно просто. Но встречаются и подводные камни:

🟧 Часто считается, что знания участника будут проверять и оценивать, элемент недоверия — проговорите в начале, что это их оценка, и только им нести ответственность, если они пытаются обмануть и завысить результат. Инструмент нужен не для поиска слабого звена и его увольнения, а для поиска точек роста и подбора нужных людей для скорого развития продукта/проекта.
🟧 Разное понимание каждой оценки себя среди участников. Кто-то принижает, кто-то считает себя МЕГА крутым - проговорите эти моменты на берегу, заручитесь тем, что каждый участник понимает оценку одинаково.

Ещё Звёздную карту можно разнообразить. С одной из команд мы видоизменили три оценки и заменили их на градацию знаний от 1-5, прописав на каждую оценку необходимый опыт. Проставив оценки, мы увидели свои пробелы, места излишних компетенций, а самое главное (что нужно было той команде) нашли документальное подтверждение, кто ещё может проводить код ревью. Ведущий разработчик никак не хотел делиться этой регалией. Но в диалоге мы показали знания, компетенции и ускорили выход наших релизов, сократив время прохождения ревью.

А как же потом использовать эту Звёздную карту? Вариантов много:
🟠для понимания необходимых навыков и подбора людей для нового проекта;
🟠для самооценки текущей команды и поиска, как усилить команду;
🟠для понимания своих компетенции в текущей роли и понимания будущих точек роста (составления ИПР).

* не так важно какие символы использовать, главное, чтобы вы о них договорились.

А как вы использовали в Звёздную карту у себя в команде/компании, поделитесь опытом в комментариях.


@proagilerussia

🚨Уже сегодня в 18:00-19:30 МСК состоится мероприятие-игра: «Практика свободного говорения». Это адаптированная игра Rhetoric на платформе Miro, где вы сможете развить свои навыки публичных выступлений.

Не упустите шанс потренироваться и улучшить свои навыки! Присоединяйтесь к нам по ссылке, будем рады видеть вас!

@proagilerussia

😄 Так сложилось, что я очень люблю анекдоты, различные примеры из жизни и ассоциации, чтобы объяснять вещи окружающим. Но никогда не думал, что найду довольно старый анекдот, который подойдёт под тему Scrum. Скажу сразу, кому-то анекдот может не понравиться. Поэтому не обижайтесь. После прочтения анекдота, не читайте дальше. Подумайте, как можно объяснить один из столпов Scrum:

В парке:
— Ма-ама, я писать хочу!
— Тихо, Вовочка. Ты уже большой. Нельзя так говорить, кругом люди слушают.
Говори — я хочу посвистеть. Понял?
— Да, да. Хочу свистеть очень!
Мама завела Вовочку за дерево, он сделал свои дела. На том и успокоился.
Ночь. В спальню родителей пришлепывает Вовочка и дергает спящего с краю папу за руку:
— Папа, я свистеть хочу!
Перепуганный папа, спросонья, щурясь на часы:
— Вова, ты сдурел? Пол второго ночи!
— Но я очень хочу!
Папа опупевшим шепотом пытается отогнать этот кошмар:
— Вова, мама спит, бабушка спит, все спят. Иди и ты спать, а завтра вместе посвистим сколько хочешь.
Вовочка, всхлипывая и переминаясь:
— Папа, я не могу терпеть. Я буду прям сейчас свистеть!
Папа, переворачиваясь на бок, засыпая:
— Ну хорошо. Посвисти. Только тихонько-тихонько и мне на ушко...

❓Догадались о чём речь? Хочется верить что да - Прозрачность - появляющиеся процесс и работа должны быть видны и тем, кто выполняет работу, и тем, кто получает результаты. Важные решения в Scrum основаны на оценке состояния трех формальных артефактов. Артефакты с низкой прозрачностью могут привести к решениям, снижающим ценность и повышающим риск.

Вся работа, все договорённости, все иносказания, которые касаются всей команды (в данном случаи семьи) и продукта в целом должны быть известны всем, приняты. Иначе может произойти вот такая нелепая ситуация.

🗣 Общайтесь с командой, общайтесь в команде. Не отказывайтесь от лишней возможности рассказать о договорённостях, зафиксировать их, понять что вся команда их приняла иначе может быть очень неприятно в некоторых моментах.

А какие курьёзы у вас были из-за недосказанности?

@proagilerussia

Всем привет!

Уже в эту субботу состоится вечеринка аджайл-практиков https://proagile.ru/agile-space

В программе:
1️⃣ Приветственные напитки и нетворкинг
2️⃣ Доклад "Product & CX = ?" от Алексея Фролова
3️⃣ Доклад "Менять нельзя меняться" от Всеволода Сырова
4️⃣ Доклад "Когда Agile не спасает" от Степана Сорокина
5️⃣ Доклад "Тернистый путь трансформации" от Николая Лукиных
6️⃣ Доклад "Когда продуктовая трансформация не приносит прибыли?" от Петра Подымова
7️⃣ Воркшоп "Почему *** регламенты не работают и что с этим делать" от Петра Таргонского
8️⃣ Вечеринка

Место и время:
📅 12 апреля 15:00
📍 Москва, Hawaii House Loft, ул. Самокатная, д.4, стр. 1

Промокод SMGUILD для участников гильдии и подписчиков канала даст скидку в 20%