Как прогнозировать время выполнения задач? Методики прогноза

Подробнее о наших тренингах 👉 neogenda.com/schedule?...
Как спрогнозировать время выполнения задач? Как максимально быстро прийти к желаемому результату? Хотите в этом разобраться? Тогда это видео для вас.
На конференции «FlowDays 22» Павел Ахметчанов рассказывает, что такое оценка и время выполнения задач, какие используется метрики для прогноза, и какие вопросы нужно ставить для оценки задач.
Смотрите видео до конца и делитесь в комментариях своим мнением по этой теме, примерами из вашей практики.
00:00 Как прогнозировать время выполнения задач
02:29 Что такое оценка. Предиктивная оценка
05:55 Как оценивать результат
06:52 Время выполнения задач
09:54 Чем помогает график
12:51 Майк Кон не прав?
14:08 Корреляция Аджая Редди
16:13 Что происходит, когда ставим задачу
18:21 Меняем мышление
20:27 Длинный хвост
21:13 Контрольная карта
25:13 Методика упрощения
27:23 Статистика по типам
28:58 Когда нужно начать
29:39 Из чего состоит Sprint
32:19 Закон Литтла. Формула Андерсена
33:33 Выводы
35:00 Ответы на вопросы
▼ Смотрите другие видео:
Дебаты на FlowDays: Канбан - быть или не быть • Дебаты на FlowDays: Ка...
Agile-коуч и топ-менеджер компании. Как эффективно взаимодействовать друг с другом • Agile-коуч и топ-менед...
Значительный рост ключевых показателей бизнеса (KPI) при помощи OKR • Значительный рост ключ...
► Плейлист Конференция FlowDays 2022 • Конференция FlowDays 2022
▼ О компании
«Neogenda» помогает компаниям увеличивать свой доход и улучшать качество менеджмента уже более 10 лет. Мы - команда практиков современных методов управления. Мы популяризируем kanban, scrum, agile методологию и методику okr.
Подписывайтесь, чтобы не пропустить новые видео / @neogendacom
► Telegram t.me/neogenda
► Instagram / neogendacom
#Neogenda #ПавелАхметчанов #flowdays #менеджмент #kanban #scrum #agile #бизнес #организация #управление #руководитель

[@neogendacom]

*Как вы прогнозируете время выполнения задач?* Подробнее о наших тренингах 👉neogenda.com/schedule?

[@artemovsv]

Паша, спасибо тебе за эту работу!

[@dmitryn.4506]

Лысый мужик правильно сказал! Очень жизненная ситуация. Опасно все задачи тупо уравнивать. Буквально только что зафакапил 3 раза подряд срок по фронту, поскольку рассчитывал, что один экран веба делается условных 4 часа +/- 2-4 часа, а по факту задача вышла на 40-50 часов. Проблема была в том, что не было опыта решения задач такого уровня сложности. Ну, такие сложные задачи, наверное, нужно элементарно декомпозировать на более мелкие, схожие с типовыми задачами. Но это если такая декомпозиция возможна, а если нет, то по факту своего провала понимаю, что лучше сразу сказать заказчику, что задача нестандартная, непредсказуемого объёма, ждите... И сразу начинать её фигачить. Нежели три раза называть волшебные сроки и про** их один за другим 😅

[@ThePavelPower]

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

[@Ruwisk]

Порой приходиться называть. Часто руководство/не желает принимать реальные сроки. Пытается сдвинуть график влево. В прочем ничего нового. Рекомендую книгу смертельный марщ к прочтению

[@ThePavelPower]

​@@Ruwisk тогда эту ситуацию можно понять как то, что риски при даче неверных оценок берете на себя

[@calmingthemind599]

а если непонятная блокирует остальные в юзер стори, что делать?

[@pavelakhmetchanov51]

В этом случае придется делать Гембо - и идти разобраться с тем, что именно блокирует и почему, и при каких критериях разблокирует

[@alexeyesipov255]

Всё так. Но не согласен с выводом на 13 минуте. Распределение, когда все задачи распределены одинаково ( нет корреляции) говорит о не правильной категоризации по SP, а не о том что Майк Кон не прав. И дальше как раз Павел приводит способ выронять эту категоризацию, что бы корреляция появилась. Про оценку в степени 2 отдельное спасибо. Приходил к этим же выводам на основе анализа этих же данных на своих командах.

[@ThePavelPower]

На картине Майка Кона есть несколько ошибок 1. Нормальные распределение 2. Берется среднее в качестве наиболее вероятного срока выполнения.

[@ThePavelPower]

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

[@alexeyesipov255]

SP - стори поинт. На моих кейсах были разные варианты. Опытные команды, 2 года стабильного стоствва на одном продукте, показывали распределиние похожее на нормально в группе 2 и 4 SP. Среднее время выполнения таких задач отличалось примерно в два раза. И в 3 сигмы попадало почти 90% задач в этих котегориях Тогда как на зажачах в 1 и 8 SP. Были совершенно другие распределния. У не опытных команд, только начинающих применять относительные оценки, до года. Картина была в точности как описана в докладе. Решали анализом выбросов и разбором всех кейсов постепенно меня правила работы с беклогом. Я бы сказал что если распределение похоже на нормальное, в какой то степени, то это косвенный признак зрелой команды умеющей в данном контесте при данных ресурсах предсказывать время работ.

[@pavelakhmetchanov51]

@@alexeyesipov255 Очень подозрительно иметь нормальное распределение во временных рядах. Это странно. Так как время не умеет ходить назад. И свойство времени решения в том, что оно может только увеличиваться. Возможно у вас в системе что-то было не так. Может быть переоптимизированная система под измерения. Логарифмические распределения для временных рядов - более естесственная картина.

[@pavelakhmetchanov51]

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

[@adeptOS100]

1. Если в вашем скраме есть стори поинты, то со скрамом, что-то не так (с), вроде походу доклада разобрались, что скрам применяется в Комплекс домене, там же находятся инструменты которые позволяют, что-то делать с этой самой неопределённостью и вроде бы SP это даже не только и не столько, что-бы придать измеримости этой самой неопределённости (и уж точно, не убедить заказчика в сроках доставки), а создание "маркера" неопределённости (5 SP много непонятного - надо её понижать, 1 SP почти всё понятно - можно не понижать и брать в работу), а если это верно, то выглядит так что SP свою функцию в "комплексе" выполняют и "практика" там как раз к месту? Итерации в данном случае не мерило прогресса или мерило капасити - а "транспорт" доставки ценности (её еще итеративно инкрементальной разработкой называют) не рассматривать "инкремент" в связке с итерациями, всё равно, что отчуждать "еду от ложки" в процессе поедания - если это верно, то зачем рассказывать об этом в целом (в начале доклада)? 2. Что-то я не разобрался с метафорой про "зарплаты и риски", можете объяснить? 3. А зачем мы выделяем Customer Lead Time и Development Lead Time? (мы действительно в парадигме которая направлена на Customer Centricity хотим разделять эти 2 цифры?) - пойдём от противного, улучшая DLT != CLT, кастомер станет счастливее? (вопрос следует воспринимать в лоб, без изысканий на тему "может и станет, если на производстве была проблема") Резюмируя, я правильно понял, что ответ на вопрос "когда будет поставлено"? - "вот когда переместим в компликейтед" тогда и станет, ждите!?

[@pavelakhmetchanov51]

1. Зависит от того как именно используете. В докладе приведен пример наиболее часто встречающийся вариант использования SP. Такие подходы поддерживаются инструментами, например Atlassian, или другими трекинг системами. Но, проблема в том, что SP как оценку сложности складывать нельзя - она нарушает принципы аддитивности. Так как при сложении SP 1 + 1 не будет равно 2. Это связано как раз с принципом сложения веростностных величин.

[@pavelakhmetchanov51]

2. Чем большим количеством риском умеешь оперировать, тем более высокая должность этому должна соответствовать.

[@pavelakhmetchanov51]

3. Докладчик немного ошибся, выделяется Customer Lead Time - время ожидания заказчика, и System Lead Time - время на которое непосредственно можно влиять управляющим воздействием (то что можно ограничить).

[@pavelakhmetchanov51]

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