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

Правильная оценка сложности очень важна: она помогает владельцам продуктов оптимизировать процессы для повышения эффективности и качества результатов. 

Dan Radigan Dan Radigan
Просмотр тем

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

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

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

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

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

Agile-оценка — это командная работа

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

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

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

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

При традиционном подходе команды разработчиков ПО оценивают сложность работы во временном исчислении: дни, недели, месяцы. Многие agile-команды, напротив, предпочитают оценку сложности в очках. С их помощью можно оценить относительные трудозатраты по шкале, напоминающей последовательность Фибоначчи (0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100). Может показаться, что это далеко не самый понятный способ, однако он полезен, потому что заставляет команды принимать более точные решения по сложности работы. У этой системы оценки есть и другие преимущества.

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

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

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

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

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

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

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

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

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

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

продолжение темы
Metrics