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

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

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

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

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

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

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

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

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

• Настройте свой первый scrum-проект с помощью этого интерактивного обучающего материала.
• Узнайте, как оценивать сложность пользовательских историй в очках и отслеживать процессы.

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

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

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

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

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

• Установите приложение Planning Poker
• Подробнее о покере планирования

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

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

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

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