Оценка и планирование в Agile. Часть первая: как оценивать задачи в Agile?

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

Предлагаю начать с главного: что такое оценка?

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

Кому и для чего она требуется?

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

Как провести оценку задач в Agile?

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

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

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

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

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

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

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

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

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

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

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

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

Заказчик:

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

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

60 часов? По рукам!

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

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

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

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

1. Разная производительность сотрудников. У нас в команде может быть Senior разработчик и джуниор, у которых объективно разная производительность. Один даёт оценку в 10 часов, а другой — в 25. Какую нам записать в бэклог? Если мы не знаем, кто будет делать конкретно эту задачу, когда до неё дойдёт очередь. И как мы поймём, что между ними есть недопонимание в процессе оценки?

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

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

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

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

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

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

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

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

1. Оценивает вся команда.
2. Оценка дается на основании опыта, крайне важно опираться на похожую экспертизу и готовые задачи. 
3. Оценка должна быть относительной (выше мы уже обсудили, к каким последствиям приводит попытка оценивать задачи в астрономических часах).
4. Чем больше сходство между сравниваемыми объектами, тем точнее будет оценка. Возвращаясь к примеру разных сооружений, например, если вы строите только здания, то и ваши оценки относительно новых аналогичных задач будут точнее.

Как работать со стори поинтами?

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

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

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

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

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

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

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

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

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