Оценка и планирование в Agile: когда пора «убить» неуспешный проект?

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

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

К сожалению, нет. Проводились неоднократные исследования, результаты которых доказывали, что корреляция между предварительными оценками и фактическим положением дел либо очень слабая, либо ее нет вообще. Ниже конкретный пример из книги Аджая Редди (Ajay Reddy) The Scrumban [R]evolution. Кстати, мы делали подробный обзор на эту книгу на нашем YouTube-канале.

Обратите внимание, что корреляция в 1-2 или 2-4 дня обычно прослеживается только у самых мелких задач. Однако, чем сложнее и объемнее задача, тем выше становится разброс в оценках. Например, реальное время исполнения задачи, оцененной в 13 стори поинтов, может колебаться между 5 и 12 днями. Или задача, оцененная в 8 story points, может занимать от трех до десяти дней. Как вам такая точность оценок? :)

Такой итог невольно заставляет задуматься: что же нам делать дальше? Отказаться от story points? А давайте посмотрим, что еще мы можем использовать. Один из таких инструментов — BurnUp Chart, это график, который отражает фактическое выполнение задач в зависимости от времени, также выраженное в story points или других единицах измерения.

Он полезен в проектах или продуктовых командах, где бэклог может изменяться и расти из-за новых требований или задач. Этот график позволяет нам видеть не только то, как команда «сжигает» задачи по спринтам, но и как общий объем работы в бэклоге меняется со временем.

Как эффективно использовать BurnUp Chart? Вы можете отметить пунктирной линией текущий объем задач в бэклоге. В моем примере это 520 стори поинтов. Затем, сравнивая этот объем с фактическим выполнением по спринтам, мы можем применять различные методы прогнозирования, например, PERT (Program Evaluation and Review Technique), чтобы оценить оптимистичные, пессимистичные и наиболее вероятные сценарии.

— O — оптимистичная оценка длительности задачи,

— M — наиболее вероятная оценка длительности задачи,

— P — пессимистичная оценка длительности задачи.

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

Кстати говоря, мы можем пойти дальше, используя различные методы прогнозирования. Например, можно применить уже рассмотренную в прошлой части таблицу с множителями (ее мы разбирали в конце прошлой статьи) для определения оптимистичного и пессимистичного сценариев. Оптимистичный сценарий покажет нам, к чему мы стремимся в идеальных условиях, а пессимистичный будет полезен для коммуникации с заказчиками, чтобы дать им наиболее консервативную оценку и обеспечить уверенность в сроках. И что важно: это не только улучшает нашу способность адекватно оценить проект, но и базируется на реальной статистике выполнения задач! Таким образом, мы имеем дело уже не с оценкой, а переходим в плоскость прогнозирования.

Низкая точность предварительных оценок и их спорная полезность в ИТ-разработке привела к тому, что образовалось целое движение противников — #NoEstimates , которое исповедует отказ от предварительных оценок. Что же они предлагают взамен?

Васко Дуарте (Vasco Duarte), Agile-коуч и автор замечательной книги #NoEstimates о том, как улучшить прогнозирование и планирование, предлагает вполне понятный и простой подход.

Давайте внимательно посмотрим на график выше. Красным цветом обозначен объем оставшегося бэклога, а синим – то, как команда выполняет и закрывает задачи. В этом случае команда оценивала задачи в story points по Фибоначчи: 1, 3, 5. Итак, по имеющемуся прогнозу и при таком темпе прироста бэклога проект будет завершен 20 октября.

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

При таком подходе команда просто разбила задачи на 3 категории: маленькая(1), средняя(2) и большая(3). И обратите внимание, что несмотря на то, что цифры в графике поменялись, прогноз по сути остался тем же самым: разница составила всего 6 дней по сравнению с предыдущим вариантом. Как думаете, через 7 месяцев к моменту завершения проекта кого-то будут беспокоить эти плюс-минус 6 дней? :) Уверен, что нет.

А теперь следите за руками! Вот что предлагает Васко.

А что если мы просто начнем считать количество историй? Да, все user story разные, но мы считаем, каждая user story – это один story point. И посмотрите, какой мы получаем прогноз: 29 сентября! В итоге разница между всеми прогнозами очень небольшая, и что не менее важно, точность прогноза примерно та же самая, как и в случае с предварительной оценкой, а сам прогноз по статистике очень близок к реальному положению дел.

Для того, чтобы такой подход работал должно быть соблюдено два условия:

И главный вывод представителей #NoEstimates : давайте избавляться от лишнего. Прогнозирование основывается на реальной статистике и цифрах и не требует предварительных оценок. В качестве вишенки на торте предлагаю посмотреть вот такой занятный график в моем Телеграм-канале, обратите внимание, как влияет оценка на продуктивность команд, исследование проведено на базе 63 000 команд.

Самое время подвести черту и вспомнить главное о предварительных оценках:

— все предварительные оценки это всегда догадки, которые обладают очень низкой точностью.

— на оценку тратится очень много времени.

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

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

— заказчики не понимают, как считать в стори поинтах: бизнес и ИТ общаются на разных языках.

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

Давайте посмотрим на результаты 2020 года:

Глядя на такие результаты, можно подумать, что в мире никто не умеет реализовать проекты. Это не так, проблема в другом — команды неправильно оценивают проекты, принимая за мерило успешности ПРЕДВАРИТЕЛЬНУЮ (читай — грубую, неточную, приблизительную) оценку, которая закладывалась на старте. Вывод: мы не умеем оценивать, а точнее — пытаемся оценивать то, что оценивать не нужно.

Мысленно слышу ваши возражения:

Несогласный читатель: Артемий, а что если у нас совсем новый проект, где нет никакого процесса, данных, а возможно, даже самой команды? Как нам его оценить?

Я: Возьмите 6 недель на проект, запустите его, начните работать и примите решение на основе реальных данных. Только так (!) вы сможете понять свою скорость, достаточно ли людей в команде, рабочая ли эта идея, сходится ли у вас экономика и прочее-прочее-прочее. Кроме того, обратите внимание, на точность оценок: от 4х до 0.25х на старте проекта и то, как меняется этот показатель по ходу проекта, наши оценки становятся точнее и обоснованнее.

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

Я: Короткий ответ – да, именно так вам и стоит поступить. Проекты, которые запускаются на основании нереалистичных оценок, будут стоить вам гораздо дороже. Ребята, если вы не готовы потратить 6 недель на эксперимент, насколько этот проект важен для вас? А сколько вы тратите времени на оценку проекта обычно? На предварительный анализ, например. Возможно, стоит отказаться от идеи прямо сейчас, чтобы потом не выбрасывать большой готовый проект, родившийся, по сути, на основании ваших фантазий и галлюцинаций.

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

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

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

Автор: Артемий Анцупов, Agile-коуч и эксперт ScrumTrek