«Коллеги, когда будет готово?» Как оценивать время на задачи в разработке

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

Меня зовут Игорь Медведков, я старший backend-разработчик в компании Test IT, разработкой занимаюсь уже более 10 лет. За свою карьеру успел поработать с разными процессами, командами и проектами: разработка для мобильных устройств, аутсорс, фриланс, desktop, backend. И на каждом проекте так или иначе приходилось оценивать задачи и укладываться в определенные сроки.

Человеко-дни, человеко-часы, человеко-минуты...

Чаще всего начинающие и реже — продолжающие лиды, PM-ы и аналитики проводят оценку, основываясь на подсчете физического времени, необходимого на реализацию той или иной задачи — те самые «человекочасы». На деле такая прикидка почти никогда не совпадает с реальностью — в итоге срываются сроки релизов, регрессов, спринтов. Но в руках опытных людей, способных к анализу, точно сработает =)

Как считать:

1. Определите минимальную единицу оценки

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

Допустим, вам кажется, что вашему программисту хватит 10 минут, чтобы поправить две строки в конфигурационном файле, и задача выполнена. Но вы не можете быть уверены, что эти две строки не повлекут за собой дальнейшие изменения. В этом случае стоит оценить задачу в час, ведь что такое +1 час при оценке в три человеко-дня? — Лишь небольшая погрешность, чего не скажешь об оценке в 10 человеко-минут, где эта погрешность срывает сроки в шесть раз.

2. Ставьте задачу грамотно 

Что имеется в виду: необходимо подробное описание того, что требуется, с четкими критериями приёмки (Definition of done), с дизайном и т.п. Точность оценки времени на такую задачу будет в разы выше, чем на плохо оформленную.

Пример четко поставленной задачи:

Добавить экспорт отчета в XLSX-файл.
Я, как пользователь, хочу уметь выбирать отчетный период и получать документ в формате, совместимом с Excel 2007 и выше.
Приложены макеты дизайна формы экспорта и сообщений об ошибках.
Описаны критерии приёмки:

• доступна кнопка экспорта
• по нажатию на кнопку экспорта доступна форма с выбором отчетного периода в днях и кнопкой «Экспорт в Excel»
• по нажатию на кнопку экспорта пользователю предлагается сохранить на диск сформированный отчет
• формирование отчета не должно занимать более 30 секунд

Пример нечетко поставленной задачи:

Нам нужно, чтобы пользователь мог отправить мне (начальнику) отчет.

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

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

3. Оцените риски

Среди них стоит отметить: чистота кода, загруженность команды, стек технологий, техническое задание, зависимость от третьесторонних сервисов и библиотек и т.д. Если ваш проект идеален с точки зрения кода, архитектура проекта прозрачна и понятна, а реализация соответствует современным принципам разработки ПО, и вы не чувствуете проблем с возможной интеграцией с третьесторонними сервисами и т.п., то, скорее всего и риски будут минимальными, а вы можете добавить небольшой запас к своей оптимистичной оценке (около 20% может оказаться вполне достаточно). Но, к сожалению, описанная выше ситуация встречается нечасто. Суммирование всех рисков зачастую дает +100% и даже более к первоначальной оценке.

Оценив все возможные риски вы получили две цифры: оптимистическую оценку и пессимистическую. Если заказчик принимает оценку вилкой, то, в целом, цифры уже готовы. Но, зачастую, заказчик хочет конкретную оценку, единственную в его представлении. Здесь мы начинаем второй раунд угадывания. 

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

Попробуем оценить задачу из примера выше.

Оценка совершенно незнакомой задачи

Выше я говорил о том, что после прочтения постановки задачи в голове появляется некая цифра, которая, как правило, близка к оптимистической оценке. Это справедливо, если вы хорошо понимаете суть задачи и знакомы с технологиями, с которыми предстоит иметь дело. Но что делать, если требуется разработать что-то совершенно новое, работая с неизвестными технологиями и не имея четкого представления о реализации. Иногда эту проблему можно решить, задрав сроки максимально. Но нет гарантий, что даже в слишком большие сроки вы уложитесь: проблема может оказаться слишком сложной и её будет нецелесообразно решать предложенными инструментами. К тому же, завышенные оценки могут быть не приняты заказчиком.

Куда разумнее согласовать с заказчиком время на ознакомление с технологиями, написание PoC (Proof of Concept), прототипа, какого-то временного решения и т.п. Такой подход даст вам необходимую информацию о том, с чем предстоит работать. Позволит прикинуть, насколько предложенные технологии и инструменты подходят для реализации задачи. Владение такой информацией позволит вам декомпозировать задачу, а так же дать адекватные сроки. 

Декомпозиция задач

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

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

Например, вы разрабатываете интернет-магазин и получаете стори в такой формулировке:

Я, как пользователь, хочу выбирать товары и оформлять заказ.

Далее в описании аналитики указали, что к списку товаров надо добавить корзину с кнопкой оформить заказ. Нажав на эту кнопку, пользователь получает форму для ввода деталей.

Пример хорошей декомпозиции:

1. [Frontend] UI для страницы корзины

2. [Backend] Хранение списка выбранных товаров. API для выдачи списка и его редактирования

3. [Frontend] UI для страницы оформления заказа

4. [Backend] API для сохранения данных заказа

5. [Backend] Процессинг заказа (отправка email, верификация и т.п.)

Вариант похуже (рассмотрим только страницу корзины):

1. [Frontend] UI списка выбранных товаров

2. [Frontend] Верстка карточки выбранного товара

3. [Frontend] Обработчики кнопок изменения количества, удаления товаров

4. [Frontend] Обработчик кнопки перехода к оформлению заказа

5. [Backend] Кэширование выбранных товаров

6. [Backend] API изменения количества товаров в корзине

7. [Backend] Сохранение заказа в БД

Чем плох второй вариант? 

Предположим, что это “горящая” задача. Ее нужно запихнуть в ближайший спринт, поэтому подзадачи раскидываются по разным исполнителям. Если процесс разработки налажен, то, прежде чем изменения попадут в мастер, они проходят code review. 

В примере выше подзадачи сильно зависят друг от друга: карточка товара не имеет смысла без списка товаров, а обработчики кнопок не имеют смысла, пока не готова карточка товара. В итоге мы получим 4 ветки, сделанные разными людьми. Причем три ветки будут висеть, пока не будет влита основная. Мы имеем 4 пулл-реквеста, которые находятся в review. По каждом из них поступают замечания и вносятся доработки, которые могут быть не совместимы с изменениями других веток. Получается снежный ком из изменений, а пулл-реквесты по итогу нужно вливать в строго определенном порядке, чтобы минимизировать конфликты. Это сводит на нет всю первоначальную экономию от распараллеливания задач.

Оценка времени или оценка сложности?

Оценку времени в человеко-часах очень любят заказчики, подход также хорош для фрилансеров и аутсорса, ведь так проще оценить бюджет на разработку. 

Если же речь о продуктовой разработке или full-time аутсорсом (когда целая команда выкупается на длительный срок), то более эффективной будет оценка сложности. Разница здесь в том, что отвечать нужно не на вопрос «когда?», а «сколько нужно ресурсов на реализацию?»

Путь задачи к реализации

Сначала есть идея (от владельца продукта, пользователей, разработчиков и т.д.), которая оформляется в виде user-story и попадает в бэклог. Далее она попадает к аналитикам, которые оформляют ее грамотно, наполняют деталями, а также могут дать ей первичную оценку. Это еще не человеко-часы и даже не сторипоинты. Это первичная прикидка, характеризующая объемность задачи. Такую оценку часто задают в майках (XS, S, M, L, XL) или собаках (такса, бульдог, овчарка, дог, мастиф). Нужно понимать, что аналитики смотрят на задачу с точки зрения бизнеса, поэтому их оценка может быть весьма неточной, но позволяющей приоритезировать задачи и иметь примерное представление о сложности.

Далее задача попадает в спринт. На встрече по планированию спринта команда оценивает, сколько усилий потребует их задача, давая оценку в баллах. Как правило для этого используются числа Фибоначчи (1, 2, 3, 5, 8, 13). Их прелесть в том, что рост чисел последовательность хорошо отражает рост неопределенности. Сложно думать между оценкой «5» или «6», тогда как разница между «5» или «8», скорее всего, очевидна.

Когда люди работают в команде, то и оценивать задачи они должны совместно. Есть такая практика (к сожалению, мало распространенная), которая называется «покер планирования». Суть в том, что задача выносится на оценку. Каждый участник встречи делает оценку «в закрытую». Затем люди одновременно показывают свои числа. Если они более-менее совпадают, то после короткого обсуждения задача считается оцененной. Если же виден очевидный разброс, то задача откладывается для более глубокого обсуждения. Нужно узнать, кто какие видит риски, почему человек дал более высокую или более низкую оценку, как можно декомпозировать задачу и т.д. Разумеется, согласие не должно быть абсолютным. Вполне допустимы расхождения на уровне соседних чисел. Зачастую, при расхождении мнений, велик соблазн дать среднюю оценку. Это неправильно. Дискутируйте! В ходе обсуждения могут вскрыться неизвестные риски и особенности реализации.

Итак, вы оценили задачи в сторипоинтах. Теперь, вероятно, у вас спросят, а как перевести эти баллы (story point) в часы?

Ответ: никак. 

Вся суть оценки в сторипоинтах — это абстракция от времени в пользу оценки усилий.

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

Здесь оценивается производительность (velocity) команды: сколько сторипоинтов она, в среднем, закрывает за спринт. Производительность команды, как правило, меняется от спринта к спринту. Но у хорошо функционирующей команды она обычно возрастает примерно на 10% за спринт. Для расчета прогноза обычно берут среднее значение производительности команды за последние три спринта, а сильно расхождение фактического количества закрытых задач к прогнозируемому — хороший повод для дискуссии на ближайшей ретроспективе.