#9. В Agile-среде и масштабированном Scrum для принятия решений, затрагивающих более одной команды, необходим инструмент для кросс-командной самоорганизации и самоуправления. Таким инструментом могут быть сообщества, которые бывают как долгоживущими (например, сообщество С++ разработчиков), так и временными (например, сообщество миграции с AWS на Yandex Cloud). И тут важно соблюдать несколько принципов.
1️⃣ Добровольность. Членство в сообществе не должно быть принудительным, только тогда оно будет эффективно приносить пользу (мы ведь помним про мотивированных профессионалов, правда?).
2️⃣ Сообщества не должны быть частью оргструктуры компании и не должны отражаться в штатном расписании. Иначе компания сильно теряет в скорости реакции на возникающие потребности и начинает кормить свою бюрократию там, где этого можно избежать.
Делюсь шпаргалкой, ускоряющей запуск и упрощающей подготовку к нему.
И да, не забывайте, что лидер сообщества - это роль выборная, а не назначаемая извне.
Agile фабрика. Подпишись.
1️⃣ Добровольность. Членство в сообществе не должно быть принудительным, только тогда оно будет эффективно приносить пользу (мы ведь помним про мотивированных профессионалов, правда?).
2️⃣ Сообщества не должны быть частью оргструктуры компании и не должны отражаться в штатном расписании. Иначе компания сильно теряет в скорости реакции на возникающие потребности и начинает кормить свою бюрократию там, где этого можно избежать.
Делюсь шпаргалкой, ускоряющей запуск и упрощающей подготовку к нему.
И да, не забывайте, что лидер сообщества - это роль выборная, а не назначаемая извне.
Agile фабрика. Подпишись.
🔥1
#10. Любой бизнес жаждет предсказуемости.
Принимать решения в условиях высокой неопределенности тяжело и, конечно же, рискованно. Agile подходы помогают снизить степень риска, нарезая окружающую неопределенность на небольшие порции, ограничивая временные промежутки длительностью итераций ( в Scrum это спринты), и мы договариваемся, что в течение этих итераций у нас по-возможности ничего не изменяется. В результате мы получаем относительную стабильность, пусть и на какие-то пару недель.
Но что делать, когда необходимо спрогнозировать на более длительный срок? Например, попытаться понять, успеваем ли мы что-то к конкретной дате или когда мы успеем новые два десятка фич? Понятно, что для того, чтобы такие прогнозы сделать, наличия фронта работ недостаточно. Вот еще факторы, влияющие на результирующий прогноз, которые нельзя не учитывать:
1️⃣ Объем накопленной статистики. Прогнозы на основе карт Таро или гаданий на кофейной гуще оставим за скобками. Более или менее правдоподобные прогнозы возможны на основе именно статистики. И это должна быть статистика, собранная не внешними экспертами из их прошлого опыта, а статистика, полученная в результате наблюдения за работой конкретными командами, разрабатывающими конкретный продукт в конкретных условиях. С этим связаны следующие несколько факторов.
2️⃣ Постоянство состава команд (любое изменение состава команды сбрасывает накопленную статистику по ней практически в ноль),
3️⃣ Неизменность условий работы команд (стабильность процесса, постоянство DoR и DoD).
4️⃣ Наличие этапов процесса поставки ценности, находящихся вне зоны ответственности команд (неверно ожидать, что команды смогут прогнозировать готовность фич, которые проектируют не они, а внешние по отношению к ним архитекторы, тестируют внешние тестировщики и деплоят внешние по отношению к командам девопсеры).
Поэтому, для того, чтобы прогнозы на несколько спринтов/месяцев вперед получились такими, которым действительно можно хотя бы немного верить, в дополнение к наличию фронта работ и принятию риска, что в течение прогнозируемого временного интервала спрос на продукт сохранится на приемлемом уровне, необходимо:
1️⃣ Обеспечить устойчивость состава команд
2️⃣ Обеспечить наличие в командах всей экспертизы, необходимой для сквозной поставки ценности (end-to-end)
3️⃣ Обеспечить неизменность условий работы (как минимум, неизменных DoR и DoD)
4️⃣ Иметь статистику с выполненными пунктами 1 - 3 за период не менее периода прогнозирования.
Спрогнозировать можно что угодно и на сколько угодно далеко вперед. Вопрос в точности таких прогнозов, уровне доверия к ним и оправданности усилий, затрачиваемых на подготовку такого прогноза.
Попробуйте ради интереса тем, кто топит за долгосрочное прогнозирование в условиях высокой неопределенности, задать следующий вопрос: "Вы в состоянии обеспечить выполнение п.1-4 и принять на себя все связанные с этим решением финансовые риски?". Поделитесь ответами в комментариях, очень интересно почитать.
Agile фабрика. Подпишись.
Принимать решения в условиях высокой неопределенности тяжело и, конечно же, рискованно. Agile подходы помогают снизить степень риска, нарезая окружающую неопределенность на небольшие порции, ограничивая временные промежутки длительностью итераций ( в Scrum это спринты), и мы договариваемся, что в течение этих итераций у нас по-возможности ничего не изменяется. В результате мы получаем относительную стабильность, пусть и на какие-то пару недель.
Но что делать, когда необходимо спрогнозировать на более длительный срок? Например, попытаться понять, успеваем ли мы что-то к конкретной дате или когда мы успеем новые два десятка фич? Понятно, что для того, чтобы такие прогнозы сделать, наличия фронта работ недостаточно. Вот еще факторы, влияющие на результирующий прогноз, которые нельзя не учитывать:
1️⃣ Объем накопленной статистики. Прогнозы на основе карт Таро или гаданий на кофейной гуще оставим за скобками. Более или менее правдоподобные прогнозы возможны на основе именно статистики. И это должна быть статистика, собранная не внешними экспертами из их прошлого опыта, а статистика, полученная в результате наблюдения за работой конкретными командами, разрабатывающими конкретный продукт в конкретных условиях. С этим связаны следующие несколько факторов.
2️⃣ Постоянство состава команд (любое изменение состава команды сбрасывает накопленную статистику по ней практически в ноль),
3️⃣ Неизменность условий работы команд (стабильность процесса, постоянство DoR и DoD).
4️⃣ Наличие этапов процесса поставки ценности, находящихся вне зоны ответственности команд (неверно ожидать, что команды смогут прогнозировать готовность фич, которые проектируют не они, а внешние по отношению к ним архитекторы, тестируют внешние тестировщики и деплоят внешние по отношению к командам девопсеры).
Поэтому, для того, чтобы прогнозы на несколько спринтов/месяцев вперед получились такими, которым действительно можно хотя бы немного верить, в дополнение к наличию фронта работ и принятию риска, что в течение прогнозируемого временного интервала спрос на продукт сохранится на приемлемом уровне, необходимо:
1️⃣ Обеспечить устойчивость состава команд
2️⃣ Обеспечить наличие в командах всей экспертизы, необходимой для сквозной поставки ценности (end-to-end)
3️⃣ Обеспечить неизменность условий работы (как минимум, неизменных DoR и DoD)
4️⃣ Иметь статистику с выполненными пунктами 1 - 3 за период не менее периода прогнозирования.
Спрогнозировать можно что угодно и на сколько угодно далеко вперед. Вопрос в точности таких прогнозов, уровне доверия к ним и оправданности усилий, затрачиваемых на подготовку такого прогноза.
Попробуйте ради интереса тем, кто топит за долгосрочное прогнозирование в условиях высокой неопределенности, задать следующий вопрос: "Вы в состоянии обеспечить выполнение п.1-4 и принять на себя все связанные с этим решением финансовые риски?". Поделитесь ответами в комментариях, очень интересно почитать.
Agile фабрика. Подпишись.
🔥1
Возможно, именно поэтому Agile Leadership - это не про менеджмент, а про лидерство?
Agile фабрика. Подпишись.
Agile фабрика. Подпишись.
🔥5
#11. Продолжу тему прогнозирования.
Когда стейкхолдеры и/или PO готовы принять на себя риски, вызванные прогнозированием в условиях высокой неопределенности на срок более, чем на несколько спринтов вперед, и тем, что условия, описанные в предыдущем посте, очень трудно соблюсти в реальной жизни, вам необходим подход, позволяющий сделать такой прогноз. Причем этот прогноз у Вас, как у профессионала, не должен вызывать чувство стыда за халтурно выполненную работу, провоцировать дергание глаза и ухудшать качества вашего сна.
Поделюсь способом, который не раз выручал меня в подобных ситуациях.
Контекст: многокомандный масштабированный Scrum (LeSS), кроссфункциональные команды работают над одним продуктом, любая команда может взять любой элемент бэклога. Прогнозирование ожидается на уровне фич, фичи декомпозируется на истории командами самостоятельно. Фича может не помещаться в спринт, история - помещается.
Подход основан на относительных оценках и накопленной статистике и представляет собой масштабированный вариант прогнозирования, часто используемого в однокомандном Scrum.
1️⃣ Вводим процедуру предварительной оценки фич по любой цифровой шкале. Я предпочитаю ряд Фибоначчи. Главное, чтобы оценки были относительные, а не абсолютные. То есть фичи сравниваем между собой, а не с единицей времени. Идеальные дни/недели не подойдут – очень велик риск в итоге всё равно прийти к приведению новых единиц к календарным дням с последующей миграцией прогнозов в обязательства, что в корне неверно. Буду назвать эти единицы «фичепоинтами». Делать это буду умышленно, чтобы подчеркнуть, что истории и фичи должны оцениваться по разным шкалам, и 5 для фичи - это не 5 для истории. Как из относительных оценок получить календарные прогнозы – об этом далее.
2️⃣ Шкала должна быть единая на все команды, участвуют в оценке представители команд. Лучше, чтобы это не было отдельной встречей, а происходило на Overall PBR и было одним из пунктов DoR. То есть, команда может взять фичу в работу только если она оценена. Если для выставления оценки чего-то не хватает, команда может взять фичу, провести исследование и принести его результаты на следующий PBR. Там рассказать всем, после чего все вместе фичу оценивают. После этого команда, берущая фичу в реализацию, может поменяться, но это, скорее, исключение, чем правило.
3️⃣ На обзоре спринта проводится переоценка остатков по фиче (в тех же единицах, что и первоначально). Это необходимо как для отслеживания статуса по фиче, так и для принятия решения по изменению приоритета фичи (оценка может измениться в любую сторону или остаться неизменной).
4️⃣ По прошествии нескольких спринтов мы получаем статистику текущего процесса: сколько фичепоинтов мы всеми командами «сжигаем» за спринт. В итоге, глядя на бэклог уровня фич мы сможем прогнозировать, когда, сколько и каких фич мы сможем довести до соответствия DoD. Строим Burn Down или Burn Up Chart, по ним прогнозируем и делаем выводы – успеваем или нет, что подвинуть, что убрать, набрать людей или нет и пр. Такая статистика, основанная на реальных возможностях продуктовой группы, покажет результат, максимально приближенный к действительности.
5️⃣ Долгосрочные прогнозы можно будет делать, используя технику быстрой оценки (много фич за короткое время) – это упражнение можно выполнять раз в квартал при наличии рабочей статистики. Прогнозы можно также делать, используя двойные оценки – Р50 и Р90, и тоже с иcпользованием техники быстрых оценок, и тоже при наличии рабочей статистики. Помним, что для прогноза на квартал, нам нужна статистика минимум за квартал, на полгода - за полгода.
Из результатов этих упражнений можно будет делать срез на нужную дату и далее принимать все требуемые решения с учетом известных на тот момент рисков.
Agile фабрика. Подпишись.
Когда стейкхолдеры и/или PO готовы принять на себя риски, вызванные прогнозированием в условиях высокой неопределенности на срок более, чем на несколько спринтов вперед, и тем, что условия, описанные в предыдущем посте, очень трудно соблюсти в реальной жизни, вам необходим подход, позволяющий сделать такой прогноз. Причем этот прогноз у Вас, как у профессионала, не должен вызывать чувство стыда за халтурно выполненную работу, провоцировать дергание глаза и ухудшать качества вашего сна.
Поделюсь способом, который не раз выручал меня в подобных ситуациях.
Контекст: многокомандный масштабированный Scrum (LeSS), кроссфункциональные команды работают над одним продуктом, любая команда может взять любой элемент бэклога. Прогнозирование ожидается на уровне фич, фичи декомпозируется на истории командами самостоятельно. Фича может не помещаться в спринт, история - помещается.
Подход основан на относительных оценках и накопленной статистике и представляет собой масштабированный вариант прогнозирования, часто используемого в однокомандном Scrum.
1️⃣ Вводим процедуру предварительной оценки фич по любой цифровой шкале. Я предпочитаю ряд Фибоначчи. Главное, чтобы оценки были относительные, а не абсолютные. То есть фичи сравниваем между собой, а не с единицей времени. Идеальные дни/недели не подойдут – очень велик риск в итоге всё равно прийти к приведению новых единиц к календарным дням с последующей миграцией прогнозов в обязательства, что в корне неверно. Буду назвать эти единицы «фичепоинтами». Делать это буду умышленно, чтобы подчеркнуть, что истории и фичи должны оцениваться по разным шкалам, и 5 для фичи - это не 5 для истории. Как из относительных оценок получить календарные прогнозы – об этом далее.
2️⃣ Шкала должна быть единая на все команды, участвуют в оценке представители команд. Лучше, чтобы это не было отдельной встречей, а происходило на Overall PBR и было одним из пунктов DoR. То есть, команда может взять фичу в работу только если она оценена. Если для выставления оценки чего-то не хватает, команда может взять фичу, провести исследование и принести его результаты на следующий PBR. Там рассказать всем, после чего все вместе фичу оценивают. После этого команда, берущая фичу в реализацию, может поменяться, но это, скорее, исключение, чем правило.
3️⃣ На обзоре спринта проводится переоценка остатков по фиче (в тех же единицах, что и первоначально). Это необходимо как для отслеживания статуса по фиче, так и для принятия решения по изменению приоритета фичи (оценка может измениться в любую сторону или остаться неизменной).
4️⃣ По прошествии нескольких спринтов мы получаем статистику текущего процесса: сколько фичепоинтов мы всеми командами «сжигаем» за спринт. В итоге, глядя на бэклог уровня фич мы сможем прогнозировать, когда, сколько и каких фич мы сможем довести до соответствия DoD. Строим Burn Down или Burn Up Chart, по ним прогнозируем и делаем выводы – успеваем или нет, что подвинуть, что убрать, набрать людей или нет и пр. Такая статистика, основанная на реальных возможностях продуктовой группы, покажет результат, максимально приближенный к действительности.
5️⃣ Долгосрочные прогнозы можно будет делать, используя технику быстрой оценки (много фич за короткое время) – это упражнение можно выполнять раз в квартал при наличии рабочей статистики. Прогнозы можно также делать, используя двойные оценки – Р50 и Р90, и тоже с иcпользованием техники быстрых оценок, и тоже при наличии рабочей статистики. Помним, что для прогноза на квартал, нам нужна статистика минимум за квартал, на полгода - за полгода.
Из результатов этих упражнений можно будет делать срез на нужную дату и далее принимать все требуемые решения с учетом известных на тот момент рисков.
Agile фабрика. Подпишись.
#12. С чего начинать упражнение по относительной оценке? Как выровнять большое количество людей по одной шкале? Стоит ли учитывать предыдущий опыт и оценить сначала его, используя в качестве референса для оценок предстоящей работы? О чём важно помнить при выполнении переоценки?
Для начала хочу напомнить, что процесс относительной оценки - это процесс сравнения оцениваемых элементов не с какой-то абсолютной шкалой (метрами, килограммами или часами), а друг с другом. Степень похожести сравниваемых элементов можно выражать по-разному: в майках (S,M,L,XL), в животных (от тушканчика до слона), в числах ряда Фибоначчи и т.п. Главное - чтобы все участники такого упражнения одинаково понимали, что есть что на вашей шкале. Когда вы уже пару раз это упражнение выполняли, участники уже примерно выровнены в таком понимании, а вот первый раз бывает трудно договориться, что есть самая первая оценка. Далее буду предполагать, что для оценок используем ряд Фибоначчи (0, 1, 2 и далее каждое последующее число является суммой двух предыдущих). Моя практика показывает, что проще и быстрее всего в качестве эталонного взять любой элемент бэклога, который в настоящий момент наиболее понятен и подготовлен к реализации, но по которому собственно реализация еще не началась, и оценить его, например, в 5, а остальные элементы сравнивать уже с ним. В этом случае у вас будет возможность оценить что-то как в меньшую, так и в большую сторону.
Тут важно, чтобы выбор такого эталонного элемента и его оценивание происходило всеми участниками вместе, в живом общении. После первой такой сессии у всех участников шкала уже будет примерно одна и та же.
Почему для первой оценки не стоит в качестве эталонного брать элемент бэклога, работа над которым уже началась или даже совсем закончилась? Потому что относительная оценка учитывает в себе много факторов - и сложность, и объем, и уровень неопределенности. Поэтому и сравнение правильнее проводить только для тех элементов, которые находятся в одинаковом состоянии. У тех элементов бэклога, работа над которыми началась или закончилась, как минимум неопределенность будет уже другая или будет совсем отсутствовать. В итоге шкала получится искаженной.
И при выполнении переоценки элементов, которые уже в работе, вы смотрите только вперед и оцениваете остатки, и никак не назад. То, что месяц назад казалось слоном, а сейчас стало тушканчиком, - это повод поискать причину, где и что вы не учли месяц назад, но не повод, чтобы сейчас переоценить слона в тушканчика и менять всю шкалу. Остаток может быть тушканчиком, но слон должен остаться слоном. Вы сейчас знаете заведомо больше, чем знали месяц назад, помните об этом.
Agile фабрика. Подпишись.
Для начала хочу напомнить, что процесс относительной оценки - это процесс сравнения оцениваемых элементов не с какой-то абсолютной шкалой (метрами, килограммами или часами), а друг с другом. Степень похожести сравниваемых элементов можно выражать по-разному: в майках (S,M,L,XL), в животных (от тушканчика до слона), в числах ряда Фибоначчи и т.п. Главное - чтобы все участники такого упражнения одинаково понимали, что есть что на вашей шкале. Когда вы уже пару раз это упражнение выполняли, участники уже примерно выровнены в таком понимании, а вот первый раз бывает трудно договориться, что есть самая первая оценка. Далее буду предполагать, что для оценок используем ряд Фибоначчи (0, 1, 2 и далее каждое последующее число является суммой двух предыдущих). Моя практика показывает, что проще и быстрее всего в качестве эталонного взять любой элемент бэклога, который в настоящий момент наиболее понятен и подготовлен к реализации, но по которому собственно реализация еще не началась, и оценить его, например, в 5, а остальные элементы сравнивать уже с ним. В этом случае у вас будет возможность оценить что-то как в меньшую, так и в большую сторону.
Тут важно, чтобы выбор такого эталонного элемента и его оценивание происходило всеми участниками вместе, в живом общении. После первой такой сессии у всех участников шкала уже будет примерно одна и та же.
Почему для первой оценки не стоит в качестве эталонного брать элемент бэклога, работа над которым уже началась или даже совсем закончилась? Потому что относительная оценка учитывает в себе много факторов - и сложность, и объем, и уровень неопределенности. Поэтому и сравнение правильнее проводить только для тех элементов, которые находятся в одинаковом состоянии. У тех элементов бэклога, работа над которыми началась или закончилась, как минимум неопределенность будет уже другая или будет совсем отсутствовать. В итоге шкала получится искаженной.
И при выполнении переоценки элементов, которые уже в работе, вы смотрите только вперед и оцениваете остатки, и никак не назад. То, что месяц назад казалось слоном, а сейчас стало тушканчиком, - это повод поискать причину, где и что вы не учли месяц назад, но не повод, чтобы сейчас переоценить слона в тушканчика и менять всю шкалу. Остаток может быть тушканчиком, но слон должен остаться слоном. Вы сейчас знаете заведомо больше, чем знали месяц назад, помните об этом.
Agile фабрика. Подпишись.
#13. На днях в разговоре со скрам-мастерами затронули интересный вопрос: как быстро, не проводя длительных опросов и не заполняя анкеты, понять, насколько высок уровень зрелости и автономности в команде и/или продуктовой группе?
Держите рецепт:чем короче DoR и полнее DoD, тем перед вами более зрелая команда или продуктовая группа . Почему так?
1️⃣ Чем меньше в DoR пунктов и чем раньше команда вступает в поток поставки ценности, тем больше работы команда может выполнить самостоятельно, тем больше экспертизы она в себе аккумулирует, тем больше доверия со стороны PO и стейкхолдеров мы наблюдаем по отношению к ней. Идеальный DoR для зрелой и максимально автономной команды содержит всего один пункт: за спринт успеем или нет? Если да, то элемент берется в работу и доводится до DoD полностью силами команды, без каких-либо внешних зависимостей. Либо команда в состоянии такими зависимостями управлять так же самостоятельно и самостоятельно же брать и обрабатывать соответствующие риски.
2️⃣ Чем полнее DoD и чем больше этапов потока поставки ценности он в себя включает, тем более команда кроссфункциональна, автономна и самостоятельна в принятии всех необходимых решений. В идеальном DoD присутствуют пункты и про качество, и про документацию, и про доступность конечному потребителю.
DoR - Definition of "Ready". Формализованный чек-лист, помогающий понять, что команда готова взяться за реализацию элемента бэклога и с высокой долей вероятности спрогнозировать, когда она его закончит в соответствии с ожидаемым уровнем качества.
DoD - Definition of "Done". Формализованный чек-лист, помогающий определить, что на самом деле значит "готово" и включает в себя, помимо собственно реализации, все дополнительные виды работ и перечень метрик с целевыми значениями.
Agile фабрика. Подпишись.
Держите рецепт:
1️⃣ Чем меньше в DoR пунктов и чем раньше команда вступает в поток поставки ценности, тем больше работы команда может выполнить самостоятельно, тем больше экспертизы она в себе аккумулирует, тем больше доверия со стороны PO и стейкхолдеров мы наблюдаем по отношению к ней. Идеальный DoR для зрелой и максимально автономной команды содержит всего один пункт: за спринт успеем или нет? Если да, то элемент берется в работу и доводится до DoD полностью силами команды, без каких-либо внешних зависимостей. Либо команда в состоянии такими зависимостями управлять так же самостоятельно и самостоятельно же брать и обрабатывать соответствующие риски.
2️⃣ Чем полнее DoD и чем больше этапов потока поставки ценности он в себя включает, тем более команда кроссфункциональна, автономна и самостоятельна в принятии всех необходимых решений. В идеальном DoD присутствуют пункты и про качество, и про документацию, и про доступность конечному потребителю.
DoR - Definition of "Ready". Формализованный чек-лист, помогающий понять, что команда готова взяться за реализацию элемента бэклога и с высокой долей вероятности спрогнозировать, когда она его закончит в соответствии с ожидаемым уровнем качества.
DoD - Definition of "Done". Формализованный чек-лист, помогающий определить, что на самом деле значит "готово" и включает в себя, помимо собственно реализации, все дополнительные виды работ и перечень метрик с целевыми значениями.
Agile фабрика. Подпишись.
👍5
#14. И снова про Story Points.
Часто сталкиваюсь с тем, что людям, незнакомым с относительными оценками, совершенно неочевидно, что 3SP + 2SP != 5SP и 3SP != 3SP. Постараюсь прояснить этот вопрос.
SP используется для сравнения историй между собой, и больше ни для чего. То есть, никакого соотношения между SP и часами не существует. Вообще. Оценка в Story Points включает в себя оценку не только ожидаемых трудозатрат, но и понимание сложности, оценку уверенности в достижении результата, связанных рисков и уровня неопределенности. Как вы понимаете, такие вещи у двух элементов бэклога не могут быть абсолютно идентичными. Поэтому мы говорим, что 3 != 3. Они похожи, но с т.з. математики всё же не равны, не тождественны. Поэтому же 2 + 3 != 5.
Сумма SP используется для прогнозирования и примерного понимания текущего состояния. Работает тогда, когда остатки регулярно переоцениваются.
То есть, когда мы видим, что одна история оценена в 1 SP, а другая в 2 SP, это значит, что по ощущениям тех, кто проводил оценку, вторая история в 2 раза сложнее/неопределеннее/рискованнее, чем первая.
Мы помним, что учесть всего невозможно, поэтому, если, например, за спринт команда успевает "сжечь" 10 SP, то она с большей вероятностью сможет закончить 2 истории по 5 SP, чем 3 по 3 SP и 1 на 1SP, потому что суммарный неучтенный риск у четырех элементов с большой вероятностью превысит такой риск у двух.
Оценивать, конечно же, необходимо историю целиком, а не отдельно задачи по её реализации. Основной смысл такого коллективного процесса оценки в сопутствующем обсуждении истории всей командой.
И да, не устану повторять, что у каждой команды шкала своя и SP тоже свои. Поэтому и сравнивать производительность разных команд по количеству SP, "сжигаемых" за интервал времени - последнее дело.
Часто сталкиваюсь с тем, что людям, незнакомым с относительными оценками, совершенно неочевидно, что 3SP + 2SP != 5SP и 3SP != 3SP. Постараюсь прояснить этот вопрос.
SP используется для сравнения историй между собой, и больше ни для чего. То есть, никакого соотношения между SP и часами не существует. Вообще. Оценка в Story Points включает в себя оценку не только ожидаемых трудозатрат, но и понимание сложности, оценку уверенности в достижении результата, связанных рисков и уровня неопределенности. Как вы понимаете, такие вещи у двух элементов бэклога не могут быть абсолютно идентичными. Поэтому мы говорим, что 3 != 3. Они похожи, но с т.з. математики всё же не равны, не тождественны. Поэтому же 2 + 3 != 5.
Сумма SP используется для прогнозирования и примерного понимания текущего состояния. Работает тогда, когда остатки регулярно переоцениваются.
То есть, когда мы видим, что одна история оценена в 1 SP, а другая в 2 SP, это значит, что по ощущениям тех, кто проводил оценку, вторая история в 2 раза сложнее/неопределеннее/рискованнее, чем первая.
Мы помним, что учесть всего невозможно, поэтому, если, например, за спринт команда успевает "сжечь" 10 SP, то она с большей вероятностью сможет закончить 2 истории по 5 SP, чем 3 по 3 SP и 1 на 1SP, потому что суммарный неучтенный риск у четырех элементов с большой вероятностью превысит такой риск у двух.
Оценивать, конечно же, необходимо историю целиком, а не отдельно задачи по её реализации. Основной смысл такого коллективного процесса оценки в сопутствующем обсуждении истории всей командой.
И да, не устану повторять, что у каждой команды шкала своя и SP тоже свои. Поэтому и сравнивать производительность разных команд по количеству SP, "сжигаемых" за интервал времени - последнее дело.
В кросс-функциональных командах настоящая работа и командная ответственность начинается там, где развита взаимопомощь, которая, в свою очередь, очень тяжело растет, если нет принятия T-Shape культуры. Ребята собрались поговорить на эту тему.
Forwarded from UX Horn 🌀
#мероприятие
‼️ 12 сентября (четверг) в 11:00 пройдёт Mango Office Meetup 3: T-Shape в продуктовых компаниях
выступать будут профессионалы, владеющие не только основной компетенцией, но и знаниями, навыками и софт-скиллами в других областях, которые они успешно применяют в работе
ребята из mango office собрали 12 экспертов из различных компаний и сфер, которые поделятся своим опытом:
- Дмитрий Волков, Head UX/UI Design, М-Девелопер
- Ольга Пустовалова, Ведущий аналитик, IBS
- Эмилия Городовых, UXR Team Lead, Купер (ex Сбермаркет)
- Иван Михайлушкин, И.О. Руководителя отдела внешних продуктов, Mango Office
- Анастасия Лестова, UX Исследователь, Контур
- Роман Черных, Руководитель, Русская Школа Сервисного Дизайна
- Татьяна Невокшенова, Продуктовый дизайнер, ВТБ Авто
- Константин Густов, Руководитель отдела развития архитектуры, М-Девелопер
- Андрей Морозов, Head of CX/UX, JUG Ru Group
- Елена Шабанова, Senior Product Designer, PolyAI (ex-СберТех, ex-Gett)
- Анастасия Худякова, Ведущий специалист сопровождения ДКО, Манго Телеком
- Анна Мурашова, Ведущий специалист по исследованиям, М.Видео-Эльдорадо
регистрация по ссылке
ℹ️ партнёры мероприятия: UX-Horn, Русская Школа Сервисного Дизайна, ResearchOps Russia, Волков Дизайн
выступать будут профессионалы, владеющие не только основной компетенцией, но и знаниями, навыками и софт-скиллами в других областях, которые они успешно применяют в работе
ребята из mango office собрали 12 экспертов из различных компаний и сфер, которые поделятся своим опытом:
- Дмитрий Волков, Head UX/UI Design, М-Девелопер
- Ольга Пустовалова, Ведущий аналитик, IBS
- Эмилия Городовых, UXR Team Lead, Купер (ex Сбермаркет)
- Иван Михайлушкин, И.О. Руководителя отдела внешних продуктов, Mango Office
- Анастасия Лестова, UX Исследователь, Контур
- Роман Черных, Руководитель, Русская Школа Сервисного Дизайна
- Татьяна Невокшенова, Продуктовый дизайнер, ВТБ Авто
- Константин Густов, Руководитель отдела развития архитектуры, М-Девелопер
- Андрей Морозов, Head of CX/UX, JUG Ru Group
- Елена Шабанова, Senior Product Designer, PolyAI (ex-СберТех, ex-Gett)
- Анастасия Худякова, Ведущий специалист сопровождения ДКО, Манго Телеком
- Анна Мурашова, Ведущий специалист по исследованиям, М.Видео-Эльдорадо
регистрация по ссылке
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Вот так строишь планы, рисуешь дорожную карту, планируешь спринты, а потом прилетаешь в Париж, и... приоритеты резко меняются.
Где-то горько всхлипнул руководитель проекта: такой риск он не учёл :)
Где-то горько всхлипнул руководитель проекта: такой риск он не учёл :)
На прошлой неделе вместе с Наташей (@Panacea_nata) делились опытом проведенной трансформации - 8 кросс-функциональных фиче-команд полгода в LeSS. Это было трудно, но очень здорово. Наташа, спасибо тебе, ты крутая!
Agile фабрика. Подпишись.
Agile фабрика. Подпишись.
🔥7
#15. А знаете ли вы, что для получения сбалансированной канбан-системы необходимо, чтобы суммы вип-лимитов по дорогам и столбцам совпадали?
Ну, кроме экспедитов, конечно :)
Agile фабрика. Подпишись.
Ну, кроме экспедитов, конечно :)
Agile фабрика. Подпишись.
🔥2
#16. Представьте, что вы в процессе проведения трансформации столкнулись с тем, что менеджер, от которого Вы ожидаете помощи и поддержки, ничего подобного вам не оказывает.
Первое желание - попытаться изменить его поведение, встречаясь с ним и обсуждая всю деструктивность такой позиции. Согласитесь, убеждать взрослого человека, да ещё наделенного властью и полномочиями, в том, чтобы он стал делать что-то не так, как всегда до этого - дорога в никуда без должной аргументации. Обращаясь к пирамиде Дилтса, легче понять, к какому неврологическому уровню обращать свои аргументы и где именно необходима корректировка.
Поставьте 🔥, если хотите подробностей, или любой другой знак, если считаете, что всё это дикая дичь и инфоцыганство.
Agile фабрика. Подпишись.
Первое желание - попытаться изменить его поведение, встречаясь с ним и обсуждая всю деструктивность такой позиции. Согласитесь, убеждать взрослого человека, да ещё наделенного властью и полномочиями, в том, чтобы он стал делать что-то не так, как всегда до этого - дорога в никуда без должной аргументации. Обращаясь к пирамиде Дилтса, легче понять, к какому неврологическому уровню обращать свои аргументы и где именно необходима корректировка.
Поставьте 🔥, если хотите подробностей, или любой другой знак, если считаете, что всё это дикая дичь и инфоцыганство.
Agile фабрика. Подпишись.
🔥7👍2💯2
2025 год я встречаю в Севастополе.
Тут я закончил школу, тут живёт мой отец, тут могилы моей матери, тётки и двоюродной сестры.
Находясь тут, я, как нигде более, чувствую, что самое ценное, что у меня есть, связано не с материальными благами и профессиональным достижениями, а с моими родными и близкими.
Новый Год - семейный праздник. Пусть в ваших семьях будет всё хорошо.
Друзья, с наступающим!
Тут я закончил школу, тут живёт мой отец, тут могилы моей матери, тётки и двоюродной сестры.
Находясь тут, я, как нигде более, чувствую, что самое ценное, что у меня есть, связано не с материальными благами и профессиональным достижениями, а с моими родными и близкими.
Новый Год - семейный праздник. Пусть в ваших семьях будет всё хорошо.
Друзья, с наступающим!
❤8
Не можешь победить - возглавь.
Agile Alliance присоединяется к PMI и отныне становится PMI Agile Alliance.
Ну, здравствуй, новый дивный мир.
https://www.agilealliance.org/agile-alliance-joins-project-management-institute-pmi/
Agile фабрика. Подпишись.
Agile Alliance присоединяется к PMI и отныне становится PMI Agile Alliance.
Ну, здравствуй, новый дивный мир.
https://www.agilealliance.org/agile-alliance-joins-project-management-institute-pmi/
Agile фабрика. Подпишись.
Agile Alliance |
Agile Alliance Joins Project Management Institute (PMI)
We’re excited to share some exciting news with our valued members and the Agile community. The Agile Alliance has signed an agreement to enter a strategic partnership with Project Management Institute (PMI), and today marks the beginning of this new and exciting…
Конец года, подведение итогов, составление планов на наступивший год.
Из диалога:
- Обозначьте Ваши зоны роста на следующий год.
- В области живота.
Из диалога:
- Обозначьте Ваши зоны роста на следующий год.
- В области живота.
🔥1
В этом году организаторы конференции Enterprise Agile Russia пригласили меня в программный комитет. Отказаться от такого приглашения , конечно, не смог. Сама конференция пройдет в ноябре, сейчас активно формируется сетка докладов.
Если вам есть чем поделиться с аудиторией, смело жмите кнопку "Хочу выступить", заполняйте форму, и мы обсудим с Вами Вашу идею. Даже если сейчас материалы не оформлены, но есть стойкое желание рассказать и фактура под этот рассказ, подавайтесь, обсудим. Слоты расходятся достаточно быстро.
Конференция имеет фокус на реальные результаты, поэтому доклады о реальных кейсах имеют приоритет перед визионерскими.
Требования к кейсам в докладах:
1. Масштаб от 100 человек
2. Измеримые бизнес-результаты (рассказать о том, как Вы круты - мало, постарайтесь доказать это метриками)
3. В идеале, если рассказывать будет представитель бизнеса сам или вместе с Вами.
ЦА - владельцы бизнеса, топ-менеджеры, управляющие портфелями и крупными проектами.
Не упустите возможность рассказать на всю страну об успехах своих и компании.
Если вам есть чем поделиться с аудиторией, смело жмите кнопку "Хочу выступить", заполняйте форму, и мы обсудим с Вами Вашу идею. Даже если сейчас материалы не оформлены, но есть стойкое желание рассказать и фактура под этот рассказ, подавайтесь, обсудим. Слоты расходятся достаточно быстро.
Конференция имеет фокус на реальные результаты, поэтому доклады о реальных кейсах имеют приоритет перед визионерскими.
Требования к кейсам в докладах:
1. Масштаб от 100 человек
2. Измеримые бизнес-результаты (рассказать о том, как Вы круты - мало, постарайтесь доказать это метриками)
3. В идеале, если рассказывать будет представитель бизнеса сам или вместе с Вами.
ЦА - владельцы бизнеса, топ-менеджеры, управляющие портфелями и крупными проектами.
Не упустите возможность рассказать на всю страну об успехах своих и компании.
Конференция Enterprise Agile Russia
Конференция Enterprise Agile Russia 2025
Ежегодная очная конференция: кейсы Agile-трансформаций Enterprise-масштаба (100+ чел). SAFe®@, LeSS, OKR, Nexus в ИТ, финансах, ритейле, госсекторе. Доклады, мастер-классы, нетворкинг с экспертами.
❤2
#17. Согласования - зло или суровая необходимость?
Недавно меня попросили помочь уменьшить Time To Market в одном из направлений разработки. В процессе составления VSM (карты потока поставки ценности) обнаружилось, что процесс перегружен разного рода согласованиями и налицо ситуация, когда "с команды спрашивают попадание в сроки, а согласующие такими обязательствами не связаны и сроками согласований не ограничены".
Задался вопросом: а в чем основная причина необходимости что-то согласовывать в принципе? Пришел к интересным выводам, которыми хочу поделиться.
Я выделил две основных причины, по которым проводят согласование:
1️⃣ Недостаток информации или экспертизы у исполнителя. В этом случае согласующий хочет быть уверен, что всё сделано именно так, как должно быть.
💊 Недостаток информации лечится налаживанием прямого контакта бизнеса и разработки, что позволяет устранить потерю информации на передаче через третьи руки и дополнительные документы.
💊 Отсутствие экспертизы исправляется обучением сотрудников, распространением экспертизы, T-шейпингом, парным и моб программированием (в этом случае, кстати, даже code review отмирает). В общем, всем, что позволит расшить согласующего как узкое горлышко процесса. А в случаях, когда согласование (ревью) проводится на предмет соответствия реализации замыслу архитектора, помогают нефункциональные автоматизированные тесты.
Про ревью отдельно уже писал ранее: тут и тут
2️⃣ Недостаток полномочий. В этом случае только у согласующего есть право принять какое-то решение.
💊 В общем случае бывает достаточно делегировать право принимать определенные решения на уровень исполнителя (команды). Согласующий должен быть готов расстаться с частью своего влияния на принятие решений, что сильно зависит от культуры принятия решений в компании.
Иногда такое невозможно, например, по требованию закона. А иногда бывает, что делегировать часть своих полномочий на уровень ниже для согласующего означает поставить под сомнение необходимость своей должности. Нередко встречается в организациях с большим количеством работников и "развесистой" оргструктурой. Лечится сокращением должности согласующего, что, как вы понимаете, не всегда просто.
А как вы боретесь с излишними согласованиями? Поделитесь в комментариях, пожалуйста.
Agile фабрика. Подпишись.
Недавно меня попросили помочь уменьшить Time To Market в одном из направлений разработки. В процессе составления VSM (карты потока поставки ценности) обнаружилось, что процесс перегружен разного рода согласованиями и налицо ситуация, когда "с команды спрашивают попадание в сроки, а согласующие такими обязательствами не связаны и сроками согласований не ограничены".
Задался вопросом: а в чем основная причина необходимости что-то согласовывать в принципе? Пришел к интересным выводам, которыми хочу поделиться.
Я выделил две основных причины, по которым проводят согласование:
1️⃣ Недостаток информации или экспертизы у исполнителя. В этом случае согласующий хочет быть уверен, что всё сделано именно так, как должно быть.
💊 Недостаток информации лечится налаживанием прямого контакта бизнеса и разработки, что позволяет устранить потерю информации на передаче через третьи руки и дополнительные документы.
💊 Отсутствие экспертизы исправляется обучением сотрудников, распространением экспертизы, T-шейпингом, парным и моб программированием (в этом случае, кстати, даже code review отмирает). В общем, всем, что позволит расшить согласующего как узкое горлышко процесса. А в случаях, когда согласование (ревью) проводится на предмет соответствия реализации замыслу архитектора, помогают нефункциональные автоматизированные тесты.
Про ревью отдельно уже писал ранее: тут и тут
2️⃣ Недостаток полномочий. В этом случае только у согласующего есть право принять какое-то решение.
💊 В общем случае бывает достаточно делегировать право принимать определенные решения на уровень исполнителя (команды). Согласующий должен быть готов расстаться с частью своего влияния на принятие решений, что сильно зависит от культуры принятия решений в компании.
Иногда такое невозможно, например, по требованию закона. А иногда бывает, что делегировать часть своих полномочий на уровень ниже для согласующего означает поставить под сомнение необходимость своей должности. Нередко встречается в организациях с большим количеством работников и "развесистой" оргструктурой. Лечится сокращением должности согласующего, что, как вы понимаете, не всегда просто.
А как вы боретесь с излишними согласованиями? Поделитесь в комментариях, пожалуйста.
Agile фабрика. Подпишись.
🔥2
#18. Как быстро упорядочить фичи с помощью WSJF в команде, которая никогда раньше такого не делала.
Дано.
1. Команда ~10 человек (разработчики, тестировщики, аналитики и представители бизнеса), никто из них ранее с относительными оценками дела не имел, общая шкала оценок отсутствует.
2. ~10 уже проработанных фич разного размера и ценности.
Требуется.
Подготовить бэклог к планированию PI, упорядочив элементы, используя WSJF.
Решение.
WSJF = COD/Efforts
COD = BV + RR(OE) + TC
TC - Time Criticality (критичность по времени). Больше - критичнее.
RR(OE) - Risk Reduction (Opportunity Enabler) - понижение риска (с т.з. бизнеса, а не реализации конкретной фичи) или открытие новой возможности. Больше - весомее.
BV - Business Value (ценность для бизнеса). Больше - ценнее.
COD - Cost of delay (цена задержки). Сколько бизнес потеряет (потенциально не заработает), если данная фича будет отсутствовать. Больше - дороже. Сумма предыдущих трех оценок.
Efforts (усилия). Чего нам стоит эту фичу сделать. Больше - труднее (дольше, рискованнее с т.з. реализации).
WSJF - Weighted Shortest Job First. Сначала самая весомая и короткая работа.
!!!ACHTUNG!!! Все значения относительные! Фичи сравниваются только между собой, никакой абсолютной шкалы.
Механика.
Всё, что надо сделать - это быстрой оценкой сравнить фичи между собой. 4 раза. Каждый раз в новом контексте. Просто выложить фичи в ряд. Одинаковые фичи помещаются друг под другом в столбик.
1️⃣ Первый раз - упорядочиваем фичи по BV - слева наименее ценная, справа - наиболее.
2️⃣ Второй раз - упорядочиваем по TC, слева - наименее критичная по времени (срочная), справа - наиболее.
3️⃣ Третий раз - упорядочиваем по RR(OE). Слева фича, наименее влияющая на риски/новые возможности, справа - наиболее.
4️⃣ Четвертый - упорядочиваем по усилиям на реализацию (сложность/рискованности/объем). Слева - наиболее простая, понятная, быстрая, маленькая, справа - наиболее сложная, непонятная, большая.
Каждый подход начинается с чистого листа, оценки в других контекстах не учитываются.
В конце каждого подхода на полученную последовательность накладываем шкалу. Любую цифровую, я предпочитаю ряд Фибоначчи.
Потом сводим результаты в табличку, для каждой фичи отдельная строка с её оценками. Считаем по формуле, получаем итоговый столбец с данными для принятия решений.
На десяток фич надо пара часов (обсуждения неизбежны и являются чуть ли не самым ценным результатом этого упражнения). В итоге получаем список фич, упорядоченный по единой шкале (WSJF), и 4 эталонных шкалы на будущее.
Agile фабрика. Подпишись.
Дано.
1. Команда ~10 человек (разработчики, тестировщики, аналитики и представители бизнеса), никто из них ранее с относительными оценками дела не имел, общая шкала оценок отсутствует.
2. ~10 уже проработанных фич разного размера и ценности.
Требуется.
Подготовить бэклог к планированию PI, упорядочив элементы, используя WSJF.
Решение.
WSJF = COD/Efforts
COD = BV + RR(OE) + TC
TC - Time Criticality (критичность по времени). Больше - критичнее.
RR(OE) - Risk Reduction (Opportunity Enabler) - понижение риска (с т.з. бизнеса, а не реализации конкретной фичи) или открытие новой возможности. Больше - весомее.
BV - Business Value (ценность для бизнеса). Больше - ценнее.
COD - Cost of delay (цена задержки). Сколько бизнес потеряет (потенциально не заработает), если данная фича будет отсутствовать. Больше - дороже. Сумма предыдущих трех оценок.
Efforts (усилия). Чего нам стоит эту фичу сделать. Больше - труднее (дольше, рискованнее с т.з. реализации).
WSJF - Weighted Shortest Job First. Сначала самая весомая и короткая работа.
!!!ACHTUNG!!! Все значения относительные! Фичи сравниваются только между собой, никакой абсолютной шкалы.
Механика.
Всё, что надо сделать - это быстрой оценкой сравнить фичи между собой. 4 раза. Каждый раз в новом контексте. Просто выложить фичи в ряд. Одинаковые фичи помещаются друг под другом в столбик.
1️⃣ Первый раз - упорядочиваем фичи по BV - слева наименее ценная, справа - наиболее.
2️⃣ Второй раз - упорядочиваем по TC, слева - наименее критичная по времени (срочная), справа - наиболее.
3️⃣ Третий раз - упорядочиваем по RR(OE). Слева фича, наименее влияющая на риски/новые возможности, справа - наиболее.
4️⃣ Четвертый - упорядочиваем по усилиям на реализацию (сложность/рискованности/объем). Слева - наиболее простая, понятная, быстрая, маленькая, справа - наиболее сложная, непонятная, большая.
Каждый подход начинается с чистого листа, оценки в других контекстах не учитываются.
В конце каждого подхода на полученную последовательность накладываем шкалу. Любую цифровую, я предпочитаю ряд Фибоначчи.
Потом сводим результаты в табличку, для каждой фичи отдельная строка с её оценками. Считаем по формуле, получаем итоговый столбец с данными для принятия решений.
На десяток фич надо пара часов (обсуждения неизбежны и являются чуть ли не самым ценным результатом этого упражнения). В итоге получаем список фич, упорядоченный по единой шкале (WSJF), и 4 эталонных шкалы на будущее.
Agile фабрика. Подпишись.
🔥4