Если вы часто ошибаетесь в оценках — это как быстро и точно оценить задачи.
У каждого более или менее значимого проекта есть свои заинтересованные стороны. И заинтересованные стороны всегда хотят, чтобы вы дали оценки.
Представьте, что вы генеральный директор строительной компании, и ваши клиенты просят вас построить здание. Но они хотят, чтобы вы сначала оценили это. Они хотят знать, достижима ли цель при заданных временных и бюджетных ограничениях. Вот примеры того, что вы должны оценить:
- Сколько инвестиций вам нужно привлечь?
- Сколько времени занимает весь проект?
- Сколько денег вы заплатите своим субподрядчикам?
- Какое количество материалов необходимо?
- Сколько человек поместится?
- Сколько времени здание будет существовать?
В начале у вас никогда не будет ответов на эти вопросы. И эти ответы интересны и вам, и вашему заказчику, и субподрядчикам, и сотрудникам, и будущим жильцам, и городским властям.
Точные ответы на некоторые из этих вопросов вы сможете узнать, только построив дом до конца. А остальным — даже по прошествии определенного времени.
То же самое и в разработке программного обеспечения. Разница лишь в том, что нам нужно гораздо чаще оценивать задачи. Гибкие методологии требуют, чтобы у нас был короткий горизонт планирования, что означает регулярные оценки.
Кому нужны оценки программного обеспечения?
Клиент
Для клиентов оценка – это цена. Они могут расставить приоритеты функций, сравнив свои бизнес-ценности со своими оценками.
Руководитель проекта
Для проектировщиков оценки являются инструментом планирования. С помощью смет он может понять сроки, рассчитать бюджет, сформировать команду.
Команда разработчиков
Для команды разработчиков оценка — это мера, с помощью которой они могут выразить объем и сложность работы, которую они должны выполнить. Они могут измерить свою эффективность, зная, достаточно ли они эффективны.
Основная трудность оценки
Хорошо, тогда в чем проблема? Почему так часто поднимается тема оценок и почему так много подходов к реализации?
Враг, которого мы пытаемся победить, — это Неизвестное.
Готов поспорить, вы были свидетелями того, как задача, рассчитанная на четыре дня, не может быть реализована даже за несколько недель. А иногда чудовищный баг, грозящий сломать всю архитектуру приложения и оцениваемый «на всякий случай» неделю, в итоге успешно делается новичком за пару часов без каких-либо последствий.
Почему это происходит? Потому что реальность не соответствует нашим ожиданиям. И это не потому, что кто-то невнимателен или неопытен. Происходит это потому, что оценка производилась на основе неполной информации. Обычно это происходит, когда на этап анализа было затрачено слишком мало усилий или, что гораздо чаще, команда просто не была готова сделать оценку.
Правила оценивания
Я вывел следующие правила для начала оценки, и я никогда не оцениваю, если не выполняются все из них:
- Требования готовы и полны — не оценивайте требования, которых вы не видите, они не выполнены или вы точно знаете, что они будут изменены.
- Оценивайте только то, что знаете, как именно это будет сделано. Если вы не знаете, как будете выполнять тот или иной функционал, вы не сможете его качественно оценить. Проанализируйте, спланируйте и начните оценку в конце.
- Чем меньше оцениваемая задача — тем лучше. Не пытайтесь оценить задачу настолько масштабно, что она не может легко уместиться в вашей голове. Всегда разделяйте его и оценивайте его части.
- Используется оценочная структура. Процесс оценивания должен быть известен всей команде с самого начала. Определитесь с единицами измерения, методами и подходами, которые вы будете использовать. Определите структуру, которая лучше всего подходит для вашей команды, и придерживайтесь ее.
Меры измерения
Скорее всего вы слышали, что оценки обычно делают либо в часах, либо в условных единицах (например, в стори-пойнтах).
Надеюсь, с часами все понятно.
Между тем, Story Point (SP) — это величина, с которой мы не имеем дело в повседневной жизни. Это не часть Scrum, и большинство команд воспринимают его просто интуитивно. Часто преобразование головы в часы является распространенной ошибкой.
Давайте разберемся, что означают сюжетные очки:
- Story Point — относительная величина. Одно и то же задание можно оценить как 2 СП в команде и как 21 СП в другой. И оба могут быть правы. Главное, чтобы у всех членов команды было одинаковое понимание того, что стоит за 1 SP.
- Story Point не означает количество времени, необходимое для выполнения задания. Он отражает сложность задачи, объем работы и неопределенность. Чем больше и сложнее задача и чем меньше мы о ней знаем — тем больше очков она стоит.
- Story Points — отличный показатель скорости команды. В начале вы можете предположить, сколько очков истории ваша команда может выполнить за 1 спринт (например, 45 SP). А затем, когда спринт будет завершен, вы сможете задним числом посмотреть, угадали вы или нет, откорректировав значение скорости для следующего спринта. За несколько спринтов вы доберетесь до значения, довольно близкого к реальному. Это поможет вам более точно определить объем спринта вашей команды.
- Хорошо иметь систему счисления при оценке. Например, самой популярной является «система Фибоначчи», где для оценок можно использовать только одно из следующих значений 1, 2, 3, 5, 8, 13, 21 и т. д. Подобные системы помогут вам не тратьте время на сомнения в том, 9 или 10 это задание.
Методы оценки
Хорошо, мы готовы приступить к оценке наших задач. Но как это делается?
Методик оценки десятки, но я выберу для вас те, которыми пользуюсь сам и они доказали свою полезность и эффективность на практике.
метод Дельфи
Этот метод основан на оценках нескольких экспертов.
Во-первых, каждый из них оценивает предмет индивидуально в отдельности. А потом все оценки сравниваются.
Если есть расхождения в оценках (а они обычно есть, и это хорошо), то они публично обсуждаются. После обсуждения проводится еще один такой раунд. И так по кругу, пока не будет достигнуто согласие в единой смете.
Количество раундов ограничено и обговаривается в самом начале. Если лимит раундов достигнут, а согласия в единой смете все еще нет, то нужно смотреть все оценки.
Обычно, если различия невелики, то берется большая оценка.
Если разброс значительный, то команда не готова дать оценку (например, ей не хватает информации). Соберите необходимую информацию и, когда будете готовы, начните сначала.
Оценка по аналогии
Эта техника является одной из самых быстрых. А при наличии определенной истории оценок и опыта еще и очень точно.
За основу берется наиболее похожее выполненное задание в прошлом. Для того, чтобы определить максимальное «подобие», нужно учитывать, насколько похожи следующие факторы:
- размер задачи;
- сложность задачи;
- Состав исполнившей его команды;
- Зависимости (внутренние и внешние);
- Неопределенность.
Найдите аналогию. Определите разницу. Скорректируйте свой счет по разнице.
Обратите внимание, что эта методика работает тем хуже, чем меньше сходства у задач. Если вы определили, что разница между оценочной задачей и ее аналогом достаточно велика, от использования этого метода лучше отказаться. В остальных случаях смело используйте его как самый быстрый и точный.
WBS (структура разбивки работ)
Техника здесь состоит в том, чтобы разбить нашу задачу на атомарные подзадачи, каждую из которых можно легко оценить.
До какой степени задачи должны быть декомпозированы? Обычно эта линия чувствуется, когда каждое задание довольно легко оценить и в каждом из них очевидны все шаги, необходимые для его выполнения.
Если есть задача, для которой шаги не очевидны, мы разделяем ее. Если мы не можем оценить какую-либо из задач, мы разделяем ее. Наша цель — получить набор небольших оценок.
Обратите внимание, что оценка получившейся проблемы не будет простой суммой оценок ее компонентов. Вы должны скорректировать конечный результат, принимая во внимание зависимости между подзадачами, рисками и неопределенностью.
Какую технику выбрать?
Для выбора наиболее подходящего метода я обычно использую следующую схему, состоящую из 3 вопросов:
- Выполняли ли мы когда-нибудь подобную задачу в прошлом? -> Аналогия
- Знаете ли вы все шаги для выполнения этой задачи? -› Дельфы
- Можете ли вы оценить подзадачи, из которых он состоит? -› WBS + Делфи
Вы ответили «Нет» на предыдущие 3 вопроса? Вероятно, вам не хватает информации. Соберите его, если есть возможность, а если все же не хватает — попробуйте дать «грубую» оценку всеми вышеперечисленными способами по отдельности и дать окончательную оценку в виде интервала (например, 13–21 СП).
Помните, что оценки — это всего лишь инструмент. Они нужны для упрощения планирования работ, которые должны быть выполнены.
Всегда лучше дать приблизительную оценку и приступить к реализации, чем тратить время на точную оценку, но не приступить к самой реализации.
👋🏻 Спасибо, что читаете. Я надеюсь, что эта статья вдохновила вас на улучшение процесса оценки. Если вы внедрите хотя бы один из вышеперечисленных советов в свой проект, то сразу заметите его приятный эффект.
