Будет ли определение размера хорошим предсказателем того, когда вы сможете получить свой результат? В нашем случае удивительной правдой оказался ответ «нет».  Mattias Skarin. Real-World Kanban

Часто на системные факторы тратится больше времени доставки, чем на различные размеры пользовательских историй.  Troy Magennis

Привет! Меня зовут Павел Ахметчанов, я руководитель направления улучшения процессов разработки. В статье расскажу про часто используемые методики оценок задач и есть ли в них ошибки. Посмотрим, как правильно ставить вопросы при оценке. Узнаем, что собой представляет время решения задач, а это далеко не очевидная вещь. Попробуем изменить свое мышление и получим рецепт для определения времени решения задач. 

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

Поставим вопрос по-другому

«Когда вы выполните эту задачу?» — в психологии такой вопрос называется открытым, потому что на него можно дать бесконечное множество ответов и при этом вы будете правы. Но устроит ли нашего заказчика ответ «Через 5 лет»? В большинстве случаев нет.

Открытый вопрос с точки зрения математики — это вопрос, заданный простой функцией T(x1, x2, x3, …, xn), где xi — это параметры функции, нашей системы, в которую входит множество параметров, такие как зависимости задач, количество специалистов, их опыт, техническая оснащенность и многое другое, а T — это время решения задачи, ответ.

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

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

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

Иначе говоря, зададим вопрос по-другому: «Сможем ли мы решить задачу к такому-то сроку?» Это закрытый вопрос с однозначным ответом и интересующим нас результатом. В математике такая постановка является обратной задачей, так как для ответа мы задаем ожидаемый результат функции и нам надо перебрать набор параметров, которые подходят под этот ответ, чтобы понять, достижим такой результат или нет.

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

Прокрутите это в голове и сравните два вопроса: «Когда вы выполните эту задачу?» и «Сможем ли мы решить задачу к такому-то сроку?» На какой вам будет проще ответить?

Даже если ответ на вопрос «Сможем ли мы решить задачу к такому-то сроку?» окажется «Нет», используя способ из численных методов, мы зададим другой срок решения задачи и сново попробуем перебрать параметры для нового срока.

Такой способ не гарантирует 100%-е попадание в сроки, но позволяет приблизится к ответу при известных переменных. И чем больше информации как о самой задаче, так и о среде ее решения будет, тем больше шансов спрогнозировать точный ответ.

Забавным в рамках этой методики может оказаться случай, когда на встречный вопрос «А когда вам надо?» вы можете получить от заказчика ответ «Вчера!». И с чувством облегчения можете ответить: «Мы уже опоздали».

Вывод. Сам по себе вопрос «А когда вы выполните эту задачу?» поставлен как открытый. Чтобы найти компромисс среди ответов, необходимо переформулировать вопрос и задать его в закрытой форме. И если ответ на этот закрытый вопрос не устраивает, повторить опыт с изменением срока или условием задачи.

Но чтобы отвечать на вопрос «Успеете выполнить эту задачу к такому-то сроку?», надо понимать, что такое время решения задач.

Что такое время решения задач

Чтобы понять, что такое время, нам нужно принять во внимание, что есть некоторый сервис — команда, на которую мы смотрим как на черный ящик. В этот черный ящик поступают задачи, а из него мы получаем результат. 

Катя просит сделать определенные задачи, Коля с командой говорит: «Да, ок». С момента, когда команда берет обязательство выполнить задачу, мы начинаем отсчет времени выполнения. Когда Катерина фиксирует результат, который вернулся ей или доставлен клиенту, мы завершим отсчет этого времени. Можно визуализировать так:

У нас получится два значения времени. Разницу между этими точками дат-времени назовем Lead Time — временем выполнения задачи.

Если мы соберем время выполнения задач за какой-то период и отметим точкой на графике по горизонтали, сколько дней потратили на решение задачи, а по вертикали — сколько таких задач было решено за такое же количество дней, то распределение Lead Time можно представить на графике:

График помогает понять, что даже схожие задачи могут выполняться разное количество дней. Задача, которую вчера мы делали за 3 дня, встав с правой ноги, сегодня, когда мы встали с левой, будет выполняться дольше, например за 5 дней. На выполнение влияют разные факторы. На графике видно, что все задачи были решены в течение 11 дней, при этом значительный объем задач решается за 8 дней, хотя есть вероятность сделать задачи и за день.

Прогнозирование времени выполнения задач — это сложно

Многие исследователи пытались ответить на вопрос «Когда будут решены задачи?».

Прогноз — это сложно, стоит просто принять этот факт. Какой бы подход  мы ни пробовали, это сложный когнитивный процесс, которым занимались многие: Даниэль Канеман, Трой Макгинес, Дмитрий Бакарджиев, Сти́вен Макко́ннелл и другие. Много книг посвящено тому, как оценивать интеллектуальную работу.

Мы не одиноки, и, если ошибаемся в своих прогнозах, это нормально: до нас тоже ошибались.

Одним из самых популярных изобретений для индустрии ИТ стали оценки в Story Points. Их предложил Рон Джеффрис в качестве альтернативы точной оценке по времени, которой требовали от него менеджеры. Рон придумал их для организации процесса разработки под названием XP, а уже потом они каким-то образом перешли в Scrum. Позже он написал статью с извинением за свое изобретение.

Рассмотрим примеры двух исследователей, Майка Кон и Аджая Редди, чтобы понять, что оценка времени решения задач — это действительно непросто.

Пример первый. Майк Кон активно распространяет методику оценки, основанную на Story Points, которую рекомендует использовать для оценки задач и выявления сроков их решения. Приведу пример из его старой книги «Agile. Оценка и планирование проектов». Чтобы объяснить, как же связаны Story Points с временем решения задач, он предложил такой способ:

Чтобы проверить утверждение, мы можем сами построить такой график на основе распределения Lead Time для своих команд, которые используют Story Points. В нашей компании мы провели этот эксперимент, и вот что получили:

В простом варианте можем представить эти распределения в одном из вариантов вида распределения Вэйбула, как в примере с желтым графиком:

Как видно из графиков распределений для Story Points 1, 2, 3, 5, фактический Lead Time, во-первых, не имеет вида нормального распределения, как это было в книге Майка, а во-вторых, время всех Story Points по виду распределения очень схоже. Иначе говоря, задачи разной оценки по Story Points делались за то же самое время с небольшими отличиями.

Подобный эксперимент я проводил для разных команд и не нашел значимой корреляции между оценками в Story Points и временем решения задач.

Возникает вопрос: прав ли был Майк Кон?

Ответ однозначный: нет. Он ошибся.

Второй пример — это пример Аджая Редди. Он подошел к проблеме с другой стороны в своей книге “Scrumban [R]Evolution, The: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series)”.

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

В рамках этого эксперимента Аджай Редди искал какая оценка в Story Points лучше подходит для того, чтобы она коррелировала со временем решения задач. И в рамках эксперимента выявил, что для Story Points лучше использовать оценку как степень двойки, так как получается более линейная корреляция, если она есть.

Мы построили графики для нескольких команд (сервисов), использующих для оценки Story Points, и обнаружили типичную картину:

Возникает вопрос: как Аджай поставил свой эксперимент, что у него получилась хоть какая-то картина корреляции, а у нас не нашлось корреляции вообще?

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

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

Одну из таких игр мы проводили в качестве воркшопа вместе с Евгением Степченко на конференции Flow Days в 2022 году. Называется этот воркшоп NoEstimate. Вы можете попробовать провести этот воркшоп, чтобы лучше разобраться в теме.

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

Почему задачи решаются по-разному

В понимании этого вопроса нам поможет Дейв Сноуден со своим фреймворком Cynefin. Он разделяет область методов действий на несколько доменов. В зависимости от домена методики принятия решения для систем, ситуаций и задач будут разными.

Одно из главных открытий Дейва — систематизация разных типов сред, в которых работает ваша система. И в этих средах нужно применять разные способы воздействия и методики управления. Дейв выделяет пять основных доменов: Simple, Complicated, Complex, Chaos, Confusion.

Описание фреймворка требует отдельной статьи, поэтому отмечу только, что в рамках интеллектуальной работы мы можем сталкиваться с разными ситуациями и средой и довольно часто со средой в некоторой переходной форме. Притом что большая часть методик оценки проектов и задач могут хорошо работать, если они связаны с доменами Simple и, иногда, Complicated. А во многих случаях приходится решать задачи из области Complex, Complicated и иногда Chaos.

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

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

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

Тогда как оценка Василия может повлиять на фактическое время выполнения? И это мы еще не учли, что задача, оцененная Василием, может быть заблокирована решением от другой команды. К тому же того, что она будет заблокирована на момент прогнозирования, Василий не предполагал.

Вывод. Чтобы прогнозировать, сначала нужно определить, в какой ситуации, какой системе, каком домене находится ваша система. Вы почти всегда находитесь в области работы с рисками. Для ответа на вопрос «Когда вы выполните эту задачу?» нам нужно больше информации о том, как работает система в целом в своей среде.

А возможно ли тогда построить систему, где можно давать прогноз с высокой долей попадания в срок?

Как выстроить систему, в рамках которой можно попадать в срок?

Процесс создания ценности в ИТ можно разложить на два основных этапа:

• Upstream — процесс выбора и анализа задач, которые хотим реализовать.

• Downstream — процесс разработки и предоставления ценности клиенту или заказчику.

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

Строим Downstream. Downstream-процессом управляют либо сами команды, либо тимлиды, иногда технические лидеры.

Чтобы построить процесс с прогнозируемым сроком выполнения для Downstream, есть главное правило — создать ограничение на одновременно решаемую работу. С этим могут помочь техники WIP-лимитов, CONWIP-лимитов, а если команда работает над разными типами задач, поможет техника Capacity Allocation.

Для тех, кто использует технику Story Points или оценку в часах, методика работы WIP-лимитов будет контринтуитивной техникой. Особенно когда речь будет заходить о том, что в работу берем разные по сложности задачи. И особую сложность приносит понимание, что на самом деле Sprint — это не просто итерация на две недели, в которую набираем разные задачи. Скорее это отрезок времени, когда всей командой решается одна задача, называемая целью спринта. В большинстве случаев организации процесса Sprint вообще не нужен, так как этот инструмент, как и сам Scrum, очень контекстный и близкий к домену Complex (по Cynefin). Тут можно рекомендовать игру Featureban для лучшего понимания, как работают WIP-лимиты.

Задав ограничения на разработку, в Downstream-процессе будут выбираться задачи, которые двигаются с разной скоростью, потому что обладают разными рисками и могут быть разными типами работ. Само по себе ограничение на одновременно выполняемую работу будет балансировать фокус внимания команды.

Цель мероприятий — определить естественное ограничение количества одновременно решаемых задач в системе для всех типов, что позволит использовать это в планировании.

На какие особенности стоит обратить при построении Downstream, хорошо объяснил Алексей Пименов в своем докладе «Гарри Тимлидов и современный менеджмент».

Строим Upstream. Upstream-процессом чаще всего управляет Project Manager или Product Owner. Этот процесс отвечает на вопрос «Что именно нужно делать?».

Часто множество этапов Upstream скрываются за одним словом Backlog. Это же свойство может служить хорошим индикатором, насколько хорошо выстроен Upstream-процесс. Если пользуетесь словом Backlog, значит, у вас есть что улучшать.

Наиболее частые проблемы, связанные с Upstream:

1. Нет выделенных этапов отсева задач — не построена воронка правил.

2. Задачи на разработку могут быть взяты с любого этапа путем повышения приоритета.

3. Нет анализа того, какие риски переносятся из Upstream в Downstream при изменении приоритетов и нарушении правил отсева задач.

Хороший Upstream строится с помощью «воронки правил» — так, чтобы количество задач, дошедших до Downstream, было сопоставимо с тем количеством задач, которое Downstream может переработать. Зная ограничение Downstream, мы знаем, какое количество задач нужно подготовить к работе. Значит, формулируем правила отсева задач из Upstream так, чтобы оставались только те, которые можем реализовать, и те, что нужны в ближайшее время. Остальное выкидываем.

Задача Upstream в том, чтобы минимизировать риски, которые могут пройти в Downstream-процесс. С каждым этапом Upstream мы должны иметь набор правил, которые снижают риск, что задача может быть не сделана. Например, Definition of Ready — правила, сформулированные на последнем этапе перед Downstream, где мы можем проверить по чек-листу, нет ли у задач зависимостей, понятно ли они сформулированы.

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

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

Одних правил нам будет недостаточно — нужно убедиться в том, что весь процесс Downstream и Upstream был стабильным, чтобы прогнозы, сформулированные на основе наблюдений, сбывались и в будущем.

Строим стабильный процесс и попробуем ответить на вопрос «Успеете к 20 января выполнить эту задачу?»

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

Давайте сначала определим категории задач, где:

• Chaos — задача не ясна, до конца непонятен ожидаемый результат, как ее решать.

• Complex — цель задачи определена, но неизвестно, каким образом можно реализовать эту задачу.

• Complicated — понятно, как реализовать задачу, но еще неизвестен оптимальный способ ее решения.

• Simple — это понятная задача, для которой есть лучшие практики ее реализации.

К нам в систему могут приходить разные задачи — как категории Chaos, так и Simple.

И на входе нам сразу нужно разбить их на эти категории. Если с задачами категории Simple все понятно, нам надо ее только сделать, то для остальных задач необходимо еще провести дополнительные исследования, чтобы снизить риски, связанные с ними.

Мы пробуем перенести задачу из Chaos в категорию Complex, пытаясь ответить на вопросы:

• Какую проблему мы решим этой задачей?

• Какой конкретно результат ожидается?

• Есть ли зависимости у этой задачи, как их разрешить? 

И дальше можем упростить задачу, понизив категорию с Complex до Complicated. Отвечаем на вопросы:

• Понятно ли, как технически реализовать задачу?

• Был ли у нас прошлый опыт и есть ли best practice для решения?

И в конце пробуем упростить от Complicated до Simple:

• Какой лучший способ решения задачи подходит?

• Кто может решить эту задачу?

К процессу Downstream мы стараемся подвести задачи с наименьшими рисками по их реализации.

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

Примеры категоризации на основе постановки задачи и технических возможностей решения задачи: 

А вот схематический пример воронки отбора задач на основе двухфакторной системы:

Но даже если задачи поступают в разработку хорошо сформулированными, все равно возможны нежданчики.

Нежданчики могут появиться, если:

1. Система еще не сбалансирована и плохо подобраны ее ограничения. Например, набираем слишком много задач, а значит, и рисков провала.

2. От нас требуют реализации задач, которые прошли не все этапы Upstream и впихиваются в процесс реализации с осознанными рисками.

3. Берем задачи, на которые забиваем, потому что переключаемся на другие. Такое поведение как раковая опухоль: она незаметна до тех пор, пока не заболеет вся система, и с ходу непонятно почему.

4. Неожиданные внешние блокировки. Они хорошо заметны, и на самом деле проще всего решаются.

5. Исключительные факторы. Например, сыграл какой-либо Bus-фактор или иное событие из категории «серых» или «черных» лебедей.

С некоторыми нежданчиками можно научится работать. Их тоже можно систематизировать по мере наблюдения и вносить правила для митигирования рисков «серых лебедей». С этим может помочь ретроспективный анализ.

Посмотрим на частотную диаграмму по времени решения задач и ответим на вопрос «Есть ли у нас длинный хвост в распределении?».

Хвост можно посчитать на примере формулы отношения значения времени 98% к 50% (процентиль). Если это значение превышает 5,6, можем считать, что хвост у распределения длинный-толстый (Fat tails, Long-fat tail). Формулу предложили исследователи из Kanban University в книге Essential Upstream.

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

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

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

Меняющийся контекст. Меняются сезоны, команда, продукт, клиенты.

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

Для наблюдения за изменениями существует контрольная карта.. В контрольной карте нужно следить за средне-плавающей, разбросом, и она сможет подсказать, как меняется система. 

Ниже — примеры с базовыми методиками анализа по контрольной карте.

Как работает контрольная карта

Пример стабильной и предсказуемой системы в случае небольшого разброса

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

Пример, когда происходит системное улучшение и это приводит к сокращению как разброса, так и времени выполнения задач

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

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

Широкий разброс — это то, что коррелирует с «толстым хвостом» на частотной диаграмме и требует постепенных изменений всей системы. Если у вас есть широкий разброс, значит, нужно проводить изменения с конца процесса, улучшая систему через поиск узких мест и устранение ограничений системы, как рекомендовал в своей книге «Цель» Элияху Голдратт.

Исключительные случаи — когда время выполнения некоторых задач выходит за пределы 85% По таким задачам стоит разобрать причины отклонений и внести изменения в правила или устранить причины. 

Такими действиями вы будете повышать предсказуемость времени решения задач, а значит, и повышать надежность своей оценки.

Использование 85% — наиболее часто применяемый критерий для определения исключительных случаев для Lead Time. В разных средах процентиль может быть разным, но ниже не рекомендуется выбирать критерий отсева 85%: это основано на эмпирических наблюдениях.

О том, как можно работать с контрольной картой в JIRA, я рассказывал в докладе «Control Chart в Jira, все ее тайны»:

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

Определяем время выполнения задач. Мы смотрим на распределение вероятности типов задач. При этом для каждого типа можем смотреть на отдельные графики распределения.

При анализе Lead Time используйте статистику по отдельным типам для определения времени решения задач

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

Вот пример, когда для этого типа работ мы в качестве гарантированного срока решения берем 85% и говорим, что эти задачи мы решаем за 7 дней.

На распределении видно, что 85% задач были решены за 7 дней

Вы можете построить автоматический расчет дней по процентилям для разных типов работ, как это сделано у нас во внутренней системе статистики процессных метрик T-Meter: 

По моим наблюдениям, часто для определения критерия срока выполнения задач в ИТ используют именно 85% в качестве срока, на который готовы взять обязательство перед заказчиком или клиентом.

На самом деле это достаточно рискованно. В хорошо выстроенной и стабильной системе риски не должны составлять более 5%, а значит, если вы сможете гарантировать сроки по 95% и при этом удовлетворить заказчика или клиента таким прогнозом, то вы минимизируете не только риски, но и последствия для вас. Надо помнить, что риски могут иметь и накопительный эффект.

Теперь же вернемся к вопросу «Успеете к 20 января выполнить эту задачу?». Понимая ваше распределение и срок, можно определить и вероятность завершения задачи к этому сроку.

На горизонтальной оси времени показана дата Deadline когда необходимо поставить задачу. Красным графиком показан график распределения времени если начать задачу от 18 числа, и это уже поздно, чтобы успеть. Зеленый график - это случай если начать с 17 числа, и можно успеть задачу с небольшим риском. Желтый график показывает случай с гарантированной поставкой, а фиолетовый с реализацией намного заранее до нужной даты.  Если ваша вероятность успеть к сроку составляет меньше 85%, вы рискуете не успеть 

Итак, мы получаем рецепт, как правильно прогнозировать выполнение задач:

1. Исследуйте свою систему и среду, в которой она работает:

   1. Что в ней Downstream?

   2. Выстроен ли Upstream?

   3. Что приходит в систему, что и с какими характеристиками из нее выходит?

   4. Где начинается отсчет времени Lead Time?

   5. Какие есть нежданчики и узкие звенья?

2. Настройте свой Downstream:

   1. Определите ограничение количества задач в Downstream.

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

   3. Все, что взяли в Downstream, старайтесь завершать полностью.

3. Настройте свой Upstream:

   1. Выработайте правила, почему мы не возьмем эту задачу в работу.

   2. Распределите эти правила «воронкой», создав процесс отбора задач.

4. Категоризируйте входящие задачи:

   1. По типам работ.

   2. Рискам, которые в них входят.

5. Стабилизируйте систему, работая над нежданчиками:

   1. Исследуйте причины задержек задач, системные они или нет.

   2. Для системных проблем меняйте общие правила системы или ресурсы.

   3. Для частных случаев улучшайте правила входящих задач — Definition of Ready.

   4. Выстраивайте систему постепенно под узкое звено своего процесса.

   5. Контролируйте изменения контекста и поведение системы, используйте контрольную карту или другие инструменты анализа для исследования динамики системы.

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

Прогнозирование и оценка не нужны

Исследуя вопрос о прогнозировании времени выполнения задач и проводя множество интервью по этой теме, часто выясняется, что время выполнения задач, в большинстве случаев, не так важно. Чаще нужно показывать регулярный результат — и не обязательно к какому-то сроку.

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

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

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

Что мы выносим

Прогнозирование — это сложно.

Убедитесь, действительно ли вам нужна оценка задач, кому она нужна и какую проблему она решает?

Предиктивная оценка, основанная только на предположении, такая как Story Points или человеко-часы, не связана с фактическим временем решения задач. Она может выступать только как частный случай предварительной категоризации.

На время решения задач больше влияют системные факторы. Прогнозирование времени решения задачи неотделимо от того, как выстроена вся система создания ценности. А потому и нет универсального способа оценки задач для прогнозирования. 

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

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

Полезные ссылки:

1. Книга “Real-World Kanban: Do Less, Accomplish More with Lean Thinking, Mattias Skarin.

2. Книга Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte-carlo Simulation, Troy Magennis.

3. Книга «Думай медленно решай быстро», Даниэль Канеман.

4. Книга, «Сколько стоит программный проект», Сти́вен Макко́ннелл

5. Книга, «Agile. Оценка и планирование проектов», Mike Cohn, не рекомендую.

6. Книга Scrumban [R]Evolution, The: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series), Ajay Reddy.

7. Книга Cynefin — Weaving Sense-Making into the Fabric of Our World, David Snowden.

8. Книга Actionable Agile Metrics for Predictability: An Introduction, Daniel S. Vacanti.

9. Книга Essential Upstream, Patrick Steyaert.

10. Книга No estimates. How to measure project progress without estimating, Vasco Duarte.

11. Книга «Одураченные случайностью. О скрытой роли шанса в бизнесе и в жизни», Нассим Николас Талеб.

12. Книга «Черный лебедь», Нассим Николас Талеб.

13. Презентация Probabilistic Planning, Дмитрий Бакарджиев.

14. Статья Story Points Revisited, Ron Jeffries.

15. Статья «Почему аджайл не серебряная пуля и модель Киневина (Cynefin Framework)», David J. Snowden, перевод Алексей Бушманов

16. Статья «Что такое предсказуемость выполнения задач и как ее понять?», Павел Ахметчанов.

17. Статья «Как работает метод Монте-Карло», Павел Ахметчанов.

18. Статья «Время в процессе: что мы реально о нем знаем?», Alexei Zheglov, перевод Артур Нек.

19. Статья «Анализ диаграммы распределения времени выполнения заказа», Alexei Zheglov, перевод Артур Нек.

20. Игра No Estimate, интерпретация от Евгения Степченко.

21. Видео «О WIP-лимитах. Что такое WIP-лимит, как он работает и на что влияет», Алексей Пименов.

22. Видео «Capacity Allocation — как совмещать разработку продукта, поддержку, выплачивать техдолг», Алексей Пименов.

23. Видео «Работа с узкими звеньями процесса», Алексей Пименов.

24. Видео «Как прогнозировать время выполнения задач? Методики прогноза», Павел Ахметчанов.

25. Видео «Гарри Тимлидов и современный менеджмент», Алексей Пименов.