Почему так сложно оценивать задачи в ИТ и зачем нужны стори поинты? Часть первая

Это новый цикл статей, где Артемий Анцупов, Agile-коуч и эксперт ScrumTrek, поможет разобраться в очень непростой и холиварной теме, что такое оценка и планирование в Agile, и главное — как и в чем измерять сроки исполнения задач, чтобы снизить градус конфликта и при этом повысить прогнозируемость процессов.

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

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

Здесь начинается самое интересное. Когда у нас есть какая-то User Story, мы можем попробовать оценить время ее исполнения, еще иногда производят оценку трудоемкости. С учетом погрешностей, допущений и других возможных оценок мы, наконец, получаем результат: когда работа будет готова и передана заказчику.

В идеале эта картинка выглядит следующим образом:

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

Обычно ситуация выглядит следующим образом.

Все собираются вместе и начинается:

Менеджер: Когда сможете прислать задачу?

Команда: Нам непонятно, что вы хотите, требования неполные, поэтому ничего оценить мы не сможем.

Менеджер: У меня появились новые детали от заказчика, здесь всё описано.

Команда: Мы такое никогда не делали и даже декомпозировать это не сможем. Как нам такое оценить в часах?

Менеджер: @%?№# Давайте привлечем заказчика, запросим у него более подробное ТЗ. Заказчик?

Заказчик: Z-z-z-z

Менеджер: Поможете нам с ТЗ?

Заказчик:

И с подобными вещами команды сталкиваются регулярно.

Допустим, вы все-таки преодолели все круги ада, то есть этап оценки, нащупали какую-то почву под ногами, посчитав, что на конкретную фичу потребуется 60 часов. Очень важно(!): это лишь приблизительная оценка, наши догадки, сколько времени с учетом разных факторов и имеющихся данных может занимать выполнение этой задачи. И в этом нет ничего криминального. Ведь самое главное это не конкретная цифра оценки, а понимание — можем ли мы взять эту задачу или цель в работу, например в спринт? Уложимся ли мы (с определенной долей вероятности)? Достаточно ли у нас понимания задачи? Какую она несет ценность и стоит ли вообще это делать?

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

Но на практике происходит следующая ситуация. Когда заказчики видят цифру в 60 часов, они говорят: «Отлично. Мы зафиксировали обязательства». Это означает, что через 60 часов они снова вернутся и спросят: «А где готовая задача?».

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

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

Кроме того, существовал ещё ряд проблем, связанных с оценками:

Чтобы понять скорость команды и сделать базу для командной оценки многие пришли к идее «идеальных человеко-часов». Мы оцениваем задачи так, как если бы нам ничего не мешало, т.е. «сферически в вакууме». А затем смотрим, сколько успели по факту. По статистике за несколько периодов (недель, спринтов, месяцев) мы можем определить коэффициент идеальных часов к реальным, чтобы не просто умножать оценки разработчиков на Пи, а иметь определенное обоснование. В дальнейшем такая методика станет основной для расчёта скорости команды (Velocity), но об этом поговорим чуть дальше.

Но как нам донести до менеджеров мысль, что идеальные оценки не надо брать в расчёт? С этим возникали трудности. И тогда Рон Джеффрис (Ron Jeffries), один из авторов Agile Manifesto, придумал назвать «идеальные часы» чем-то не связанным со временем, какими-нибудь очками или баллами. «А раз мы в них оцениваем пользовательские истории, то пусть будут Story Points», — решил он. Теперь оценки на задачах в трекере ничего не говорили о времени руководителям, а значит, и требовать выполнения задачи с привязкой ко времени невозможно, видимо, поэтому они стали полагаться на прогнозы по скорости команды. Так появился известный многим сейчас термин.

Тем не менее проблемы оставались. Например, у всех разные часы, мы помним, что участники все ещё дают оценки относительно именно своей скорости.

Новый подход к Story Points популяризировал Майк Кон (Mike Kohn). Он решил, что команде будет легче обсуждать задачи, если привести их к общему знаменателю и вообще уйти от пресловутого времени. Оценивать нужно факторы, которые на это время выполнения влияют – трудоемкость, сложность и риск, а оценивать их стоит единым мерилом, понятным всей команде.

Например, выбрать в качестве эталона какую-то небольшую задачу, более-менее понятную всем участникам, и принять её за единицу. Таким образом, мы и от времени уходим и решаем проблему разной производительности членов команд. Выбранная в качестве эталона User Story #3245 будет единицей и для сениора и для джуна, не важно, за сколько они её сделают. Разница в производительности не помешает им обсудить, во сколько раз User Story #3246 труднее, чем эталон – в 5 стори поинтов её оценить или в 8. Разница в оценках будет с большей вероятностью происходить из-за асимметрии информации, чем из-за разной скорости. И вот это стоит детального обсуждения. Особенно если мы не знаем, кто за неё возьмётся.

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

Резюмируя вышесказанное, можно сформулировать 4 общих принципа гибкой оценки:

Начните свой путь в Agile и получите крепкую базу по гибким подходам к управлению на онлайн-курсе по Agile и Scrum: практика с опытным экспертом, разборы кейсов и международный сертификат.

В течение двухнедельного спринта мы оцениваем запланированное количество работы в story points и сравниваем этот показатель с фактически выполненным. Важно! Мы учитываем только задачи, которые были полностью завершены и соответствуют нашему определению готовности (Definition of Done).

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

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

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

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

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

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

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

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