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

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

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

Мой опыт управления командами разработки

Я в разработке уже более 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 практически в ноль.

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

P.S. Если вы хотите узнать больше о процессах разработки в Кошельке и команде инженеров, подписывайтесь на наш telegram-канал по ссылке, там ещё много интересного.