Как оценить задачу на разработку
Оценка задач в Story Points для больших и молодых команд разработки
У разработчиков, которые давно работают вместе, обычно нет проблем в оценке задач. В таких командах процессы настроены, а люди хорошо понимают друг друга, и любому новичку, попавшему в такую команду, быстро объяснят, научат и покажут, как работать в команде.
Но на старте проекта (или при реформировании бизнес юнита) часто собираются новые команды. И в таких новых командах жизненно необходимо быстро и правильно построить методологию оценки задач; в ином случае, процесс планирования будет бесполезным, и даже примерно предсказать, когда будет сделана фича, станет невозможно.
В этой статье я расскажу, к чему пришел за годы практической разработки и управления командами. Естественно, это не правда в последней инстанции, а лишь то, что успешно работало у меня.
Мой опыт управления командами разработки
Я в разработке уже более 10 лет, за это время поменял несколько ролей. Работал и без процессов совершенно, работал работником, которому объясняют, как работать, работал в команде, где помогал настраивать процессы, и, наконец, помогал настраивать процессы сразу нескольким десяткам команд. Сегодня я — Android-лид в Кошельке, где продолжаю настраивать процессы.
Очень редко получается, что команда несколько лет подряд успешно работает одинаковым составом по одинаковым процессам. Постоянно что-то меняется: люди, их роли, проекты и так далее.
Новая команда, старые трудности
Команда Кошелька сейчас активно расширяется, стало больше людей и больше задач. Много новеньких пришло за последние 4 месяца. Как следствие, люди плохо знают друг друга и проект. Поэтому задачи, которые изначально кажутся небольшими и лёгкими, выполняются долго. Возникает вопрос, как прогнозировать разработку в таких условиях?
Необходимая теория: Оценка задач и её точность
Самый ценный и расходуемый ресурс во время разработки — время. Точно сказать, сколько уйдет времени на одну задачу, невозможно, пока она не будет выполнена. Поэтому мы оцениваем задачу приблизительно.
Точность зависит от знаний оценивающего о задаче и контексте, в котором она должна выполняться. Такие знания можно получить в результате предварительного анализа. Чем глубже анализ, тем более точную оценку мы сможем дать.
Таким образом, оценка — это предсказание, сколько будет стоить решение задачи. А нужна она, чтобы сформировать ожидания, когда будет получен результат.
От чего зависит оценка?
От ответов на два главных вопроса:
Ответ на вопрос «что?» формулируется при составлении задачи. Это смысл задачи, проблема, которую она должна решить. Перед началом работы нужно убедиться, что основные требования необходимы, достаточны и понятны.
Ответ на второй вопрос сложнее. Он зависит как от проблемы, которую нужно решить, так и от контекста, в котором её нужно решать. Контекст — это текущее состояние проекта. И он меняется с каждым новым изменением в коде проекта.
Решение почти любой задачи можно разбить на такие этапы:
Очевидно, что чем дальше мы продвинулись в решении, тем более точную оценку мы можем дать. Также очевидно, что оценивать сложность выполнения задачи уже во время тестирования бесполезно. Обычно адекватно оценить задачу можно во время начала этапа проектирования.
Оценка по времени
Сначала кажется, что время это очевидная мера оценки, ведь мы тратим на разработку именно часы и дни.
Плюс такого способа в том, что такая оценка всем понятна. Если задачу оценили в 8 часов, то её решение ожидается через 1 рабочий день, а за спринт ожидается решение 10 задач такого размера.
Минус в том, что в этом варианте невозможно учесть увеличение погрешности оценки с увеличением размера задачи. Ожидается, что 10 задач по 8 часов будут сделаны за то же время, что и 1 задача на 80 часов. Но более объемная задача, как правило, имеет больше подводных камней, которые не видны на ранних этапах проектирования.
Также не стоит забывать про разный уровень разработчиков в команде. Например, Senior сможет оценить и сделать задачу за 8 часов, тогда как Junior ту же задачу может оценить и сделать за 40 часов. Как следствие, оценка во времени актуальна, только если задачу будет делать тот, кто оценивал. Это может сработать, если в команде был, есть и будет один разработчик. Если разработчиков хотя бы два, то рассчитать среднюю производительность команды в часах будет трудно.
Как правило при оценке все забывают учитывать время на рутинные задачи, создание задачи, создание пулл-реквеста, время на ревью и исправление замечаний. А так как в оценке указано конкретное время, то и выполнение задачи ожидается именно за это время.
На практике задача, оценённая в часах, крайне редко выполняется вовремя.
Оценка в Story Point
Вместо оценки в часах и днях хорошо подходит оценка объема задач в относительных величинах. Такие величины называются story point. Ниже я расскажу о двух подходах к восприятию story points и оценке в них.
SP с эталонной задачей
Чтобы вся команда одинаково понимала значение единицы SP, можно придумать и описать эталонную задачу в 1 story point. Каждый сравнивает свою задачу с этим эталоном и дает оценку в зависимости от того, насколько она больше или меньше эталона.
Какие проблемы?
Проблем у такого подхода несколько:
Изменения. Контекст постоянно меняется, поэтому эталонная задача может быстро потерять актуальность. Со временем команда перестанет понимать, почему эта задача была когда-то эталонной.
Кросс-платформенная разработка. Если в команде есть несколько платформ, например, iOS и Android, то каждая платформа выбирает себе свою эталонную задачу. Так оценка перестаёт быть единой для всех, а члены команды, относящиеся одновременно к нескольким платформам (например, QA или аналитики), могут запутаться в понимании значения 1 SP.
Не учитывается погрешность оценки. Эталонная задача не учитывает прогрессию возрастания сложности. Если хотим оценить задачу в 3SP, то это вроде бы значит, что оцениваемая задача в 3 раза объёмнее эталонной. Это то же самое, что сделать 3 задачи по 1SP? На практике — нет. Чем сложнее задача, тем менее вероятно, что мы её оценим правильно.
SP со временем
Чтобы учесть проблемы предыдущих способов оценки, можно использовать story points с оценкой по времени. Важно понимать, что мы используем не просто время, а восприятие времени. То есть оцениваем не сколько часов будет выполняться конкретная задача, а за сколько часов в идеальном мире её можно выполнить.
Чтобы понять, за какое время мы сделаем задачу или сколько SP мы сделаем за спринт, нужно посчитать, сколько в среднем SP-ов мы делали в предыдущих спринтах. Так, если в предыдущих спринтах мы делали по 7SP, а в спринте 10 рабочих дней, то 1 SP — это 1,4 дня, а если по 14 SP, то 1 SP — это 0,7 дня.
Чтобы с чего-то начать, можно использовать такую шкалу:
0.5 SP — менее, чем за день
1 SP — до 2 дней
2 SP — около недели
3 SP — около одного спринта
5 SP — можно сделать за спринт, если всё будет идеально и никто не будет отвлекать
8 SP — 2 спринта
Задачи 5 и 8 SP в спринт брать нельзя, их нужно декомпозировать на более мелкие, чтобы снизить погрешность оценки. Задачи на 2 и 3 SP достаточно большие, их сложно сделать на одном дыхании, их лучше тоже декомпозировать. Но это не всегда оправданно или возможно.
Задачи с оценкой в 0.5 и 1 SP должны занимать основную часть спринта. Это довольно точные оценки, по ним всегда будет, что сказать на стендапе. Задач меньше, чем 0.5 SP, просто не бывает: всегда требуется время на описание задачи, на мерж-реквест, на тестирование и т.д.
Важно помнить, что в приведенной выше шкале время используется только для того, чтобы оценить, сколько SP стоит задача, но не за сколько она реально будет сделана. Как следствие, чтобы понять, сколько задач будет сделано за спринт, нужно смотреть, сколько в среднем среднем SP делали в предыдущих спринтах.
Какие проблемы?
Минусы такого подхода в том, что при оценке учитывается время. А это значит, что Junior и Senior оценят задачу по-разному, так как им нужно разное время на её выполнение. Эта проблема решается усреднением оценки по команде — например, с помощью покер-планирования.
При оценке в SP с использованием времени важно не учитывать, кто именно будет делать задачу. Иначе возникает соблазн включить в оценку индивидуальные особенности разработчика: его “синьористость”, отпуск, вынужденные выходные. Это повлияет на среднюю ёмкость спринта, а SP превратятся из оценки объёма задачи в оценку работы разработчика.
Текущий курс — стабилизация процесса
Как я уже писал, моя команда в Кошельке — новая, кроссплатформенная и большая. У нас объёмные и сложные задачи, нам нужно их быстро решать.
Уже несколько месяцев мы используем подход с оценкой в SP с привязкой ко времени. А последние несколько спринтов нам удаётся сжигать SP практически в ноль.
Мы следим за статистикой, мы обсуждаем то, что мы делаем, мы пытаемся лучше понимать друг друга. И мы становимся лучше с каждой итерацией.
Как научиться оценивать задачи, если не умеешь: 4 фактора сложности
Когда я был начинающим программистом, – а впрочем, и позднее, когда я был начинающим ведущим разработчиком, – я думал, что спрогнозировать сроки, в которые ты что-то сделаешь, абсолютно невозможно. Или же, что хороший прогноз требует очень детальных проектирования и подготовки, примерно таких же по длительности, как и сама задача.
Позднее, конечно, я обнаружил, что по теме прогнозов написано несколько умных книжек, которые в сумме с некоторым опытом делают оценку задач хоть и неблагодарным, но и небезнадёжным занятием. Самым удобным способом, конечно, является оценка по аналогии: когда ты уже делал нечто подобное, ты довольно точно знаешь, каких усилий эта задача потребует. Но как быть в ситуации, когда опыта сравнительно немного или аналогии брать неоткуда, а оценить все же хочется?
В одной из команд, где я работал, мы придумали оригинальный метод для предварительной оценки задач. Метод синтезирует некоторые известные из литературы приёмы, но в приведённой форме, пожалуй, никем не описан. Концепция была следующей: объективность (связь с измеримыми показателями); интегрируемость с Agile; повторяемость; быстрота оценки (меньше 0.5% от объема задачи); доступность для начинающих разработчиков. Я буду рад обсудить нашу идею и не исключаю, что кому-то из Хабрааудитории она придётся по душе.
Четыре фактора сложности: анализ задачи
Итак, берём задачу (плохо поставленную, формально не описанную — всё как в жизни). Выполняем экспресс-анализ: а именно, собираем в голове (или на доске) интуитивное представление о том, какую функциональность нужно реализовать и как технически эта задача может быть выполнена.
Нашей первой целью является конкретизировать возникшее представление настолько, чтобы можно было его численно оценить по ниже приведенным 4 шкалам.
Факторы сложности, они же проекции, условно называются так:
Поверхность в общем случае — это площадь соприкосновения нашей доработки с внешним миром. Например, для GUI компоненты следует составить некое количественное представление о будущем числе элементов интерфейса. Для библиотеки — о числе методов в публичном API. Для баг-фикса — об объеме затронутого кода. Для стейт-машины — о классах входящих событий. В случае, если у нас в задаче «и то, и другое, и третье», то надо задуматься, что из этого внешнее, а что, по сути, приватное, и именно публичную часть и оценивать.
Тестирование — это наше представление о количестве элементарных автоматических тестов, которые нам придётся написать для исполнения в стиле TDD. Это не обязательно предполагает, что мы будем разрабатывать через тестирование (говорят, настоящие ковбои вообще тестов не пишут), но для оценки сложности задачи нам нужно задуматься, какой объем тестов ей соответствует.
Требования — это наше представление об объёме того, что в классических подходах называется требования (requirements). Мы можем понимать этот фактор как размер спецификации, которую нам пришлось бы написать, если бы мы хотели полностью формально поставить задачу. Естественно, мы практически никогда не тратили время на составление подобных спецификаций — составление требований в наш процесс не входило — но имели представление о том, насколько объёмными подобные документы получаются. Выносим оценку в форме: «Чтобы формально это описать, потребовалось бы страниц 15» и идём дальше.
Технический риск — этот фактор отражает ожидания того, что придётся делать какое-то исследование, пробовать несколько подходов, или выбрасывать часть работы из-за того, что у нас что-то не срастётся. В теории, эту величину можно выразить числом от 0% до 100%, но на практике это наиболее субъективная из 4 величин. Можно действовать так: для оценки риска, придумываем все способы, как можно эту задачу завалить. Если в результате мы чувствуем депрессию и у нас появились серьезные сомнения, что мы в итоге cправимся в разумные сроки — то ставим оценку, близкую к максимальной.
Получившиеся 4 «проекции» образуют своего рода профиль задачи — становится понятным, что составляет её основную сложность. Одновременно при анализе задачи происходит валидация (проверка) её постановки: если вы, к примеру, осознаете, что вам неизвестно, как вы будете тестировать свою доработку, то скорее всего приступать к написанию кода нельзя. Некоторое значение имеет и соотношение проекций — большие показатели сразу по нескольким факторам намекают на то, что у задачи есть «скрытый объём» (что угрожает многократным превышением наших ожиданий), в то время как «плоские» задачи (задачи с одной доминирующей «проекцией») обычно легко просматриваются и делаются в ожидаемый срок. В том же случае, когда задача изначально казалась небольшой, и действительно оказалась небольшой по всем оценкам, время на размышления всё равно было потрачено не зря: как минимум, мы подтвердили, что у нас есть достаточное понимание того, что надо реализовать.
Такой экспресс-анализ проводится быстро, и даёт достаточно ясное представление о сложности и трудоёмкости задачи. Можно было бы и закончить на этом, ограничившись качественным подходом. Однако, мы на самом деле пошли намного дальше и синтезировали из этой концепции экспериментальную метрику.
Ниже будет изложен способ получить из 4 качественных оценок количественную величину, которая, в конечном счёте, помогает составить бэклог итерации или обозначить прогноз времени. За ней не стоит серьёзного научного исследования, но в нашей практике он давал довольно неплохую точность при минимальных затратах сил.
Экспериментальная метрика
Как мы уже поняли, на начальном этапе 4 проекции выражаются примерно так: «в нашем компоненте ожидается штук пятьдесят методов, двести тестов; потребовалось бы 20 страниц описания, которого никогда не будет, и есть примерно 10% шансов все переделывать заново». Теперь, когда мы это всё оценили, нам потребуется эти количества агрегировать. Но просто так сложить тесты и шансы, конечно же, нельзя, поэтому наши оценки предстоит конвертировать в условные единицы сложности.
Сложность, вообще, понимается как мера временных затрат за вычетом написания очевидного бойлерплейта и всех остальных рутинных и предсказуемых операций. Для начальной конвертации, используется следующая нелинейная шкала:
Формула
Для получения итоговой метрики суммируем все наши оценки в единицах сложности по четырём шкалам.
Однако, если в двух и более шкалах у нас получилось ≥2 — то два наибольших числа мы не складываем, а перемножаем.
Использование
Метрика сложности даёт представление об объёме интеллектуальной работы, явном и скрытом, и даже может быть конвертирована, почти механически, в пессимистическую оценку времени. Как это сделать, смотрите ниже, но сначала я рассмотрю несколько более легких сценариев использования. Некоторые из нижеизложенных способов вообще не привязаны к тому, как именно вы получили метрику — они просто показывают, как можно извлечь какую-то пользу из подобной числовой величины.
Выбор технического решения
Когда вы пишете большой и сложный проект, бывает, что у вас есть два-три приемлемых способа добавить некую функциональность, и вам нужно заранее предсказать, какой путь будет проще. Чтобы принять решение, вы можете оценить каждый из вариантов по 4 факторам и сравнить значения (правда, выбирая более простой путь, стоит задуматься, не добавляете ли вы технический долг).
Валидация задач
Метод обладает интересной способностью выявлять скрытую сложность задачи за счёт того, как в нём устроена арифметика и шкалы (тот самый скрытый объём; см. также раздел «опыт использования»). Если вы не ограничиваетесь качественным анализом, а вычисляете метрику, то вы можете сделать постановку задач лучше. Для этого, вводятся два критерия:
Составление бэклога
Методологий разработки ПО существует великое множество, но значительная часть их предполагает определённую итеративность, которая заключается в том, что команда ставит себе цель на период времени и определяет набор задач, которые для достижения этой цели надо сделать. В конце итерации должна получиться готовая к поставке версия продукта.
В начале итерации производится оценка того, что вообще возможно сделать за этот период времени и происходит уточнение задач, в результате чего получается некий перечень, аналогичный бэклогу из User Story и/или других форм описания задач.
Известное преимущество стандартного бэклога в формате User Story перед «планом работ на период» состоит в том, что его не обязательно точно оценивать, в силу своебразной «магии» скрама. Но здесь есть важный нюанс. Если задачи, как это происходит во многих командах, разбиты не в каноническом формате User Story, а более крупно, или более «архитектурно», то упомянутая «магия» легко ломается: качество оценки размера задачи в начале итерации начинает играть критическую роль. Это очень распространённая ситуация, в которой вам может потребоваться и набор исторических данных по прошлым задачам, и вычислимая метрика, которую вы используете в начале итерации как оценку размера для задач, вызывающих сомнения. Поскольку неправильно выбранный состав итерации наносит вред и продукту, и мотивации разработчика, прилагать усилия к адекватной оценке задач бывает более чем оправдано. Я бы рекомендовал это делать.
Boost your Scrum
Scrum-команды, как правило, выставляют оценку задачам в условных единицах (Story Point). Сделать это не всегда просто. Практикуются относительно сложные процедуры, такие как Planning Poker.
Применение метода в стиле Agile заключается в том, что мы считаем предлагаемую метрику в тех случаях, когда у нас есть сомнения относительно размера задачи или возможности её реализации. Поскольку для отдельной задачи все расчёты и оценки по этому методу можно проделать в уме, это проходит достаточно безболезненно и без больших методологических споров. Имеется также возможность «партизанского» применения этого метода — если задачу оцениваете вы один, как разработчик, и 4-х факторный метод у вас работает, то вам необязательно рассказывать на стендапе всю эту механику.
Нужен план?
Заранее прошу прощения у тех читателей, для которых «планирование» — это ругательное слово. Оставшуюся часть читателей хочу обрадовать, что из метрик выводятся и непосредственные временные оценки, если действовать аккуратно. Стратегически планировать так, наверное, не получится. Однако, одним из преимуществ метода является возможность предварительно оценивать довольно крупные блоки задач.
Планирование с метриками строится на предположении, что задачи по своему будущему фактическому объёму будут соотноситься как их метрика объёма. Конечно, сложность и объём — понятия не эквивалентные, ведь порой лишь часть усилий разработчика направлена на собственно решение задачи. Если вам, помимо программирования, приходится заниматься какой-то малоинтеллектуальной деятельностью, вроде написания тонн XML, ручного неэффективного тестирования или трудоёмкой процедуры деплоя; если вы вдобавок ведете переговоры с заказчиком и пишете манускрипты документации, и все такие занятия неравномерно распределены между задачами — я вам могу лишь посочувствовать. Вам придётся самим придумать, как оценить непрограммистскую и малоинтеллектуальную деятельность. Однако если такой работы немного, – а в хороших проектах её немного, – вполне можно себе позволить считать для целей планирования, что Объём == Сложность, и не вносить дополнительные поправки.
Когда мне приходилось составлять среднесрочные планы, я поступал следующим образом:
Альтернативно, если вы планируете для себя одного, можно поступать проще: вычислить исторически некоторый коэффициент «скорости» и механически вычислять прогноз времени, деля на коэффициент метрику очередной задачи. Но так планировать получается хуже, чем когда вы видите цельную картину. К тому же, калибровка подобного коэффициента — занятие не из приятных. Схожий подход со «скоростью» вполне работает в Scrum с его BurnDown диаграммами, но там он выглядит более эффективным и естественным. Можно сказать, что концепция Scrum Velocity представляет собой более тонко устроенный механизм, чем просто пропорция между объёмом и временем.
Опыт использования
Для небольшой задачи, как показывает практика, оценки и арифметика выполняются в пределах минуты в уме. Для больших компонент требуется чуть большее время, но всё равно метод может выглядеть как быстрый, устный расчёт, дающий приемлемый по точности результат — обычно, более точный, чем интуитивно озвученный прогноз в N дней. Бывали случаи, когда я эти цифры подсчитывал и складывал в уме на митинге, пока мои коллеги из других команд занимались настоящей работой — тайком закрашивали клеточки в Buzzword Bingo.
Едва ли можно назвать этот метод очень простым, но зато он отличается полезной способностью выявлять неявную сложность — даже такую, которая скрывается в плохих библиотеках и инструментах, в плохой архитектуре, в нелинейности трудозатрат, в техническом долге. Отчасти, этому способствует нелинейная арифметика, но в целом выявление скрытой сложности происходит скорее за счёт того, что шкалы оценки не вполне ортогональны: рассмотрите несколько вариаций реальной задачи, и вы заметите, что даже изменения, дающие прирост преимущественно по одной шкале, всё равно отчасти проявляются и в остальных. При этом характерно, что в одних случаях такой перенос проявляется сильно, а в других — слабо. И чем меньше выражен перенос, тем интуитивно проще и легче выглядит соответствующая доработка задачи, не так ли? Формула, действительно, использует то наблюдение, что разнообразные «подводные камни» никогда не проявляются преимущественно по отдельной шкале, но их наличие существенно поднимает вверх одновременно две-три проекции. Нелинейность формулы «ловит» этот эффект, создавая существенную прибавку к рассчитываемому значению.
Из-за этих анатомических деталей, 4-х факторная оценка, хоть и требует больше времени, но почти всегда получается лучше, чем простые оценки «по аналогии» или оценки на основе отдельного фактора.
Сам я практикую этот метод эпизодически уже несколько лет. Моя привязанность к нему вызвана несколькими причинами. Во-первых, при аккуратном применении он даёт заметно более точный прогноз, чем другие примитивные методы. Во-вторых, он достаточно гибко адаптируется к тем или иным методологиям разработки: с некоторой натяжкой его возможно применять и в «чистом» Agile окружении, и в гибридных проектах, и в условно «классическом» проектном менеджменте с Microsoft Project поверх команды программистов. Я также замечал в нём некую приятную масштабируемость — иногда возможно применять подобную оценку не только в малых (bug, story. ), но и в более крупных временных масштабах (блок функциональности, компонент). Наконец, метод помогает обучению оценивающего: всегда имеется возможность сравнить фактически состоявшиеся показатели (объем кода, сложность тестирования и т.д.) со своими ранними оценками, и сделать предметные выводы.
В своей статье я в принципе не ставил целью обсуждать, нужно ли вообще оценивать задачи в проектах, и нужно ли применять какие-то метрики при разработке ПО, а просто хотел предложить полезный инструмент для тех, у кого такая потребность существует. Меня подкупает то, что при достаточно хороших показателях этот метод малоизвестен; и признаться, мне было бы весьма интересно найти первоначальный источник некоторых из его концепций.
Как научиться оценивать задачи, если не умеешь? Отвечая на этот вопрос, я рассказал о своём любимом методе, который достаточно механистичен, чтобы его мог использовать относительный новичок. Вообще же говоря, методов оценки существуют многие десятки, и если вы желаете изучить эту тему глубже, я бы посоветовал прочитать одну из широко известных книг: