Оценка сложности историй

Основные моменты

• Оценки сложности — это метод относительной оценки в Agile, который помогает командам оценить трудозатраты, сложность и риск для элементов в бэклоге.

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

• Такие методы оценки, как покер планирования и ретроспективы, помогают командам постепенно корректировать и совершенствовать процессы.

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

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

Если вы недооценили какую-то часть работы, не нужно жертвовать выходными, чтобы идти по графику. Тем не менее давайте посмотрим, как максимально повысить точность agile-оценки.

Что такое оценка сложности?

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

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

Какие факторы влияют на оценку сложности?

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

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

Взаимодействие с владельцем продукта

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

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

Примерная оценка сложности в Agile — командный вид спорта

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

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

Не позволяйте своей команде стать жертвой оценок сложности, сделанных в отрыве от большей части коллектива. Это верный способ провалиться! 

Хотите попробовать оценивать сложность в очках? Сначала зарегистрируйтесь или войдите в Jira

• Настройте свой первый scrum-проект с помощью этого интерактивного обучающего материала 

• Узнайте, как оценивать сложность пользовательских историй в очках и отслеживать процессы.

Оценка сложности в очках и часах

При традиционном подходе команды разработчиков ПО дают оценку в единицах измерения времени: днях, неделях и месяцах. Однако многие команды agile предпочитают оценку сложности в очках. Очки сложности отражают общие трудозатраты, необходимые, чтобы полностью реализовать элемент бэклога продукта или выполнить любую другую рабочую задачу. Команды начисляют очки в зависимости от сложности и объема работы, а также сопутствующих рисков или неопределенности. Эти числовые значения нужны для того, чтобы более эффективно разбить работу на небольшие части и избавиться от неопределенности. Благодаря такому подходу со временем команды понимают, сколько они могут сделать за отведенное время, вырабатывают общее представление и придерживаются его.  Может показаться, что это далеко не самый понятный способ, однако его польза в том, что он подталкивает команды к принятию более точных решений о сложности работы. У этой системы оценки есть и другие преимущества.

• При выборе дат не учитывается работа, не относящаяся к проекту напрямую, а ведь она неизбежно появляется. Отправка электронных сообщений, проведение встреч и собеседований — все это может отнимать время участника команды.

• На выбор дат значительное влияние оказывают эмоции человека. Относительная оценка работы позволяет максимально исключить эмоциональную привязанность.

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

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

• Количество очков, которое получат участники команды за решение проблем, зависит от сложности задачи, а не от затраченного времени. Следовательно, участники команды будут заинтересованы в повышении эффективности, а не в расходе времени. 

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

Зачем оценивать сложность в баллах, а не в часах?

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

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

Оценка сложности и покер планирования

Команды, которые только пробуют оценивать сложность в очках, пользуются техникой, которая называется «покер планирования». Покер планирования часто используется в разных подразделениях компании Atlassian. В ходе процедуры команда кратко разбирает каждую задачу из бэклога, после чего каждый участник мысленно выставляет ей оценку. Затем каждый поднимает карточку с номером, который соответствует оценке. Если все приходят к одному мнению, отлично! Если нет, уделите время (не слишком много, пару минут), чтобы понять, чем обоснованы разные оценки. Не стоит забывать, что оценка не должна быть скрупулезной. Если команда зашла в дебри, сделайте короткий перерыв и верните обсуждение на более общий уровень.

Готовы попробовать? 

• Установите приложение Planning Poker

• Подробнее о покере планирования

Будьте умнее — не мудрите

Отдельное задание не должно занимать более 16 часов работы (если вы оцениваете сложность в очках, можете договориться о верхнем пределе, скажем, в 20 очков). Оценить более сложные рабочие задачи с должной долей уверенности практически невозможно. А уверенность очень важна, особенно когда речь идет о задачах с наиболее высоким приоритетом в бэклоге. Если сложность какой-либо задачи выходит за верхний предел команды (16 часов или 20 очков), это сигнал, что ее нужно разбить на более мелкие составляющие и провести оценку повторно.

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

Извлекайте уроки из прошлых оценок

Ретроспективы существуют для того, чтобы команда могла взять на вооружение аналитические данные из прошлых итераций, включая факторы, повлиявшие на точность оценок. Многие инструменты Agile (например, Jira) отслеживают оценки сложности, значительно упрощая их анализ и оптимизацию. Возьмите, например, последние 5 пользовательских историй, которым команда присвоила по 8 очков. Обсудите, затрачено ли равное количество усилий на каждую из этих задач. Если нет, то почему? Используйте полученные выводы в процессе оценки сложности в будущем.

Как и все в методике Agile, оценка — это практика. С каждым разом вы будете справляться лучше и лучше.

Связанные ресурсы

• Ресурсы по управлению проектами

  • Ресурсы по планированию проекта

  • Ресурсы по запуску продукта

  • Стратегии по управлению проектами для выхода на рынок

  • Ресурсы по управлению ресурсами

  • Ресурсы по отслеживанию заданий

  • Управление проектами по разработке ПО