Вы устали бороться с оценкой задач? Вам кажется, что идея story points выглядит замечательной лишь на бумаге, но в реальности вызывает путаницу и раздражение?
Story points могут быть сложными для понимания и эффективного использования. Даже когда вы думаете, что вы разобрались с ними, вы можете чувствовать себя запутанным, потому что есть множество способов их неправильного использования. И если этого недостаточно, руководство компании или команды, иногда превращает сторипойнты в показатели производительности, что накладывает еще большее давление на команды.
В этом полном руководстве мы рассмотрим эти и другие проблемы связанные со сторипойнтами. Мы расскажем вам все, что вам нужно знать, чтобы наконец-то правильно использовать и получить ту ценность, которую они всегда обещали.
Вот что мы рассмотрим:
Story points (сторипойнты) - это относительная мера оценки усилий и сложности, необходимых для выполнения задачи или пользовательской истории в гибкой (Agile) разработке программного обеспечения. Обычно они выражаются числом.
Концепция сторипойнтов была первоначально разработана Роном Джеффри в рамках гибкого метода программирования Extreme Programming (XP). Однако они впоследствии начали использоваться командами, работающими в других методологиях, например, Scrum.
При использовании сторипойнтов вместо оценок времени на выполнение задачи, члены команды присваивают определенное количество очков, основываясь на таких факторах, как сложность задачи, уровень неопределенности или риска, а также требуемые навыки и опыт.
Команды разработчиков программного обеспечения используют сторипойнты для более точной и последовательной оценки объема работ, которые могут быть выполнены за один спринт. Однако, более важным является то, что процесс оценки сторипойнтов позволяет командам уточнить объем работ и согласовать представление о завершенности задачи.
Для присвоения сторипойнтов команды сидят вместе и обсуждают размер задачи, присваивая им оценку. Иногда они используют цифровую колоду карт в процессе, называемом покер планирование.
При оценке работ с использованием сторипойнтов можно учесть следующие факторы:
Попытка уместить такое множество факторов в одну оценку может показаться невозможной задачей. Но с практикой это так же просто, как проверить, является ли цена на чашку американо в вашей местной кофейне разумной.
💡 Совет: некоторые agile-коучи, практики и гуру предписывают факторы, которые должны учитываться в ваших оценках. Мы предлагаем вам выбрать те из них, которые наиболее соответствуют обстоятельствам вашей команды, и согласовать их. Если вы сомневаетесь, в самом начале, вы можете использовать: усилия, сложность и риск.
При покупке кофе вы справляетесь с этим за считанные секунды, подсознательно сравнивая цену с различными факторами. Некоторые из них очевидны, такие как цена, ожидаемое качество и ваш опыт в других кофейнях. Но также важны и косвенные факторы, такие как то, подходит ли текущая зарплата или экономическая ситуация для того, чтобы потратить деньги на дорогой кофе.
Процесс оценки сторипойнтов аналогичен этому подходу.
Предположим, ваша команда занимается чисткой автомобилей, и в вашу мастерскую прибывают три машины. Автомобиль A уже достаточно чистый и маленький, поэтому вы все соглашаетесь, что это один сторипойнт. Автомобили B и C больше по размеру, поэтому им присваивается удвоенное количество сторипойнтов.
Кроме того, автомобили B и C очень грязные, что удваивает объем работ и, следовательно, уже становится 4 очка.
Для автомобиля C вам также нужно очистить салон, и вы не можете заглянуть внутрь, прежде чем приступить к работе. Чтобы учесть этот риск, вы добавляете еще два очка для автомобиля C.
Итоговая сумма выглядит следующим образом:
Вы знаете по предыдущему опыту, что вы можете выполнить примерно 30 очков работы за неделю. Поэтому вы сообщаете владельцам, что они смогут забрать свои автомобили через несколько дней.
Если вы попросите свою команду оценить работу по очистке автомобилей в часах, они могут дать разные ответы в зависимости от опыта каждого человека в чистке автомобилей. Или они могут потратить много времени, согласовывая, сколько времени требуется среднему члену команды, чтобы помыть каждую машину, прежде чем дать вам оценку.
Сравнивая автомобили друг с другом и используя произвольное число для выражения различий в ожидаемой работе, вы получаете гораздо более быструю и менее субъективную оценку работы.
Возможно, вы все еще задаетесь вопросом: "почему бы мне не оценивать время выполнения задач вместо использования story points?" Использование очков вместо времени может привести к более быстрым и ценным оценкам. Они также могут спровоцировать полезные обсуждения о задачах и выявить проблемы, которым следует уделить внимание во время ретроспектив.
Вот несколько причин, почему вы можете выбрать оценку с помощью story points:
Сторипойнты могут помочь командам избежать перегрузки работой. Путем измерения вместимости спринта — среднего количества выполненных очков за предыдущие спринты и использования этого числа в качестве ограничения для следующего спринта, команды устанавливают здоровый и устойчивый рабочий ритм. Сторипойнты заставляют команды принимать решение о приоритетах в задачах, о том, как разбить их на подходящие для текущего спринта и что оставить в бэклоге для будущего спринта.
💡 Совет: Команды рассчитывают свою скорость, подсчитывая количество выполненных сторипойнтов. Это число, усредненное за несколько спринтов, помогает командам понять, сколько очков работы они могут завершить за один спринт. Вместимость также служит отправной точкой для обсуждения на ретроспективных встречах, когда это число оказывается значительно выше или ниже обычного.
Как и с любым благонамеренным инструментом, вместимостью спринта можно злоупотреблять. Это привело эту метрику к неоднозначной репутации в agile-сообществах. Вместо того чтобы использовать вместимость как максимум, которого может достичь команда, некоторые организации рассматривают ее как обязательство, которое команда должна выполнять или даже превосходить в каждом спринте.
Вот как в реальности может выглядеть разговор о планировании возможностей команды и сторипойнтов:
"Мы встречались с бизнесом и говорили: «На прошлой неделе мы завершили 23 сторипойнта. Александр собирается уйти в отпуск на следующей неделе, поэтому мы можем предложить вам только 18 очков на этой неделе». Человек из бизнеса сказал: «Хорошо, если у нас только 18 очков, то я хочу выполнить следующие задачи…». и они перечислили задачи примерно на 18 сторипойнтов."
Тим Оттингер, Agile-консультант
Стивен Лангбрук, технический директор в Recarb, не использует story points для планирования. Вместо этого он использует их для начала дискуссий, которые раскрывают сложность, неопределенность или риск. Фактически, люди часто говорят, что они просто являются средством для более качественных разговоров и согласования.
"Числа не имеют значения, важен разговор, который возникает, когда стори пойнты различаются."
Мартен Далмейн, лидер по продуктовому менеджменту в Dalmijn Consulting
Рассмотрение чего-то вместе и принятие решения о том, что это такое, позволяет достичь общего понимания или выявить его отсутствие. Вот как может звучать типичный разговор о сторипойнтах на практике:
"О, эта задача на 13 пойнтов, не осознал сложность. Можем ли мы разбить её на более мелкие задачи, чтобы выполнить их в этом спринте или поручить их нескольким людям? Точно так же, вы думаете, что это 3 балла, но вы приняли во внимание изменения в базе данных, которые вам нужно будет внести? Или это кажется мне незначительным, вы уверены, что мы оба понимаем, каких изменений и испытаний потребует эта задача?»
Дэвид Флинн, разработчик
При оценке сторипойнтов, фактические числа не имеют значения, важно то, как они соотносятся друг с другом. Как пишет гуру Agile Майк Кон:
"Вместо того чтобы присваивать 1, 2 и 3, команда могла бы вместо этого присвоить 100, 200 и 300. Или 1 миллион, 2 миллиона и 3 миллиона. Важны соотношения, а не фактические числа."
Когда оценки команды сильно различаются, проведите разговор об этом. Разнонаправленные оценки являются доказательством того, что вашей пользовательской истории требуется больше обсуждений и уточнений, чтобы все понимали предстоящий объём работы.
Сторипойнты могут служить темами для обсуждения на ретроспективах. Вот несколько способов использования их в этоих целях:
Оценка сложных задач по времени может казаться более естественной, но она имеет некоторые недостатки. Время является одномерным и абсолютным понятием, и оно не может учесть все факторы, которые учитываются при оценке через сторипойнты. При использовании времени также возникают психологические предубеждения, которые заставляют нас завышать скорость выполнения задач.
Сторипойнты не имеют этих недостатков, потому что:
Вы можете использовать сторипойнты для оценки на совещаниях, например при подготовке плана работ, при покер планировании или планирование спринта. Вот пошаговое руководство по их использованию с вашей командой.
Нам понадобилось более 1 500 слов, чтобы достичь общего понимания работы сторипойнтов. Прежде чем захлестнуть вашу команду числами и терминами, такими как "шкала Фибоначчи", убедитесь, что они вообще понимают концепцию сторипойнтов! Рекомендуется поделиться этой статьей перед первым сеансом оценки. 😇
Одна из основных сложностей сторипойнтов заключается в оценке первых задач, без предварительных данных для ориентира. Распространенным подходом является выбор наименьшей задачи, которую вам когда-либо потребуется оценить, и присвоение ему одного пункта. Эта задача становится вашей исходной, к которой вы будете ссылаться в дальнейшем. Защитник DevOps Джонатан Холл называет это "золотым элементом".
Выберите другую задачу из своего списка ожидающих задач и оцените её размер в сторипойнтах относительно вашей исходной задачи. Продолжайте просматривать свой список ожидающих задач, сравнивая их друг с другом, пока вы не оцените наиболее ценные задачи в разных размерах. Вы можете использовать для этого методы оценки, такие как относительная оценка или наш бесплатный инструмент покер планирования.
Если задача является большой и сложно оцениваемой, разбейте ее на более мелкие. Это облегчит оценку, и такие большие истории все равно не поместятся в спринт.
Также помните, что оценка не является точной наукой. Вы не составляете детальный план для следующего спринта. Вы просто пытаетесь примерно понять размер каждого элемента, чтобы спровоцировать обсуждение и убедиться, что вы не берете на себя слишком много работы в следующем спринте.
💡 Хотите узнать, как оценивать задачи в команде? Прочитайте нашу статью о методах оценки в Agile методологии, включая последовательность Фибоначчи, покер планирования, метод трех точек и метод размеров футболок.
Создайте обзор матрицы сторипойнтов различных размеров, которые вы обычно используете. Добавьте одну или несколько справочных задач, чтобы помочь вашей команде. Фактически, вы создаете эталон, на который ваша команда сможет ориентироваться при оценке работы в будущем. Это особенно полезно для команд, у которых есть похожие и повторяющиеся задачи.
Вы также можете создать таблицу, которая показывает, как два основных фактора, которые ваша команда учитывает при оценке задач, влияют на конечное число. В приведенном ниже примере этими факторами является сложность и усилия, но вы можете заменить их на другие.
Теперь вы готовы начать свой спринт. По его окончанию вычислите общее количество сторипойнтов, выполненных вашей командой. Это число является скоростью вашей команды.
После выполнения нескольких спринтов измерьте среднюю скорость вашей команды. Это число показывает, сколько работы вы реалистично можете спланировать для каждого спринта в сторипойнтах.
У вас будет больше данных и опыта в конце каждого спринта, поэтому мы рекомендуем следующее:
В первые несколько спринтов скорость выполнения может колебаться. Со временем средняя скорость выполнения вашей команды может постепенно повышаться или понижаться в зависимости от поставленных целей. Не ожидайте, что скорость выполнения вашей команды будет увеличиваться спринт за спринтом бесконечно; это нереалистично и может привести к выгоранию.
Например, вы можете найти способы улучшить рабочие процессы, позволяющие вам выполнить больше сторипойнтов за спринт и увеличить скорость выполнения. Но вы также можете выбрать меньшее количество работы на спринт, чтобы повысить качество вашей продукции. Это снизит скорость выполнения, но результаты будут положительными.
Story points — изначально могут вызывать определенные сложности, подобно тому, как вы оказываетесь в чужой стране с незнакомой вам валютой и пытаетесь сделать перевод в голове. Следуйте рекомендациям ниже, чтобы избежать типичных ошибок и изучить проверенные временем практиками использования сторипойнтов.
Нет необходимости оценивать весь список задач сразу же. Вам нужно знать только размер задач, которые могут войти в первый спринт.
Оценка слишком большого количества задач является пустой тратой времени, поскольку вам может потребоваться повторно оценивать их позже, по мере изучения вами продукта, потребностей клиентов и возможностей команды. Более того, многие задачи, которые вы оцениваете, могут в конечном итоге не попасть в планирование спринта.
По мере того как ваша команда будет все более знакома со сторипойнтами, вы сможете постепенно приступить к оценке более широкого круга задач.
Чтобы избежать смешения сторипойнтов с часами или днями, новые команды могут использовать не нумерический заменитель, например, объекты разного размера или фрукты, как показано на изображении ниже.
Даже опытные команды могут извлечь пользу из этой практики, поскольку сложно избавиться от привычки оценивать задачи на основе времени. С числами легко начать рассматривать пункты как заменитель часов или дней, но с милыми собаками это уже не так. 🐶
Последовательность Фибоначчи - это серия чисел, которые растут экспоненциально, потому что каждое число является суммой двух предыдущих чисел: 0, 1, 2, 3, 5, 8, 13, 21 и так далее.
Использование чисел Фибоначчи при оценке позволяет избежать траты времени на незначительные различия при определении размера более крупных задач.
Предположим, что ваша команда должна оценить большую задачу, например, добавление новой функции в ваше приложение. При оценке такой задачи, члены команды предлагают 31, 36 и 38. Хотя эти числа похожи, их незначительные различия могут вызывать обсуждения, в том числе и длительные. Такой уровень детализации и обсуждения не является необходимым для большинства ситуаций оценки в Agile методологии.
Последовательность Фибоначчи предотвращает выбор близких друг к другу чисел для более крупных задач. В предыдущем примере большинство людей выберет 34, потому что другие варианты - 21 или 55 (см. рисунок ниже).
Story points — являются локальной валютой для оценки внутри вашей команды, под влиянием ваших уникальных навыков, опыта и рабочего процесса. Вы не можете сделать свои пункты универсальными для нескольких групп, так как в этом случае они становятся не совсем корректными, неиспользуемыми или вводящими в заблуждение.
Например, ваша команда может считать, что создание определенной формы веб-сайта составляет два пункта, тогда как другая группа считает это одним пунктом. Это различие допустимо, пока эти оценки остаются внутри каждой команды.
Проблемы начинаются, когда в дело вступает руководитель и начинает задавать вопросы, почему ваша команда завершила два пункта, а другая только один.
Когда руководители пытаются сопоставлять пункты между командами, это не имеет смысла. Это может создавать давление на команды для завышения чисел, чтобы угодить начальству, или тратить время на синхронизацию оценок.
Опытный консультант по гибкой методологии Тим Оттингер предлагает прекрасное решение для таких ситуаций:
"Я попытался решить эту проблему, попросив команды называть свои сторипойты именами любимых фруктов. Одна команда измеряла скорость в апельсинах, другая - в яблоках, третья - в киви и т. д. Затем, когда руководство неизбежно пыталось сравнивать скорости команд, я говорил им: "Вы не можете сравнивать яблоки с апельсинами".
Оценка в сторипойнтах требует нескольких спринтов для достижения точности, поэтому не отказывайтесь от них после всего одной попытки.
После завершения нескольких спринтов спросите команду, хотят ли они продолжать использовать сторипойнты. Их ответ может вас удивить.
"Недавно я спросил свои команды, хотят ли они отказаться от story points во время планирования. Они единогласно согласились не делать этого. Это меня удивило, но они были ещё в начале спринтов, и они сказали, что они ценят оценку в story points, так как она позволяет понять, нужно ли разбить задачу на более мелкие, если она слишком большая для спринта."
Мэтью Уэйд, руководитель практики Agile, Espire Infolabs
Периодически может возникать желание связать сторипойнты со временем, например, "один пункт = один день", но так делать нельзя, это противоречит их цели. Вы превращаете их в фиксированную единицу времени, а не в относительный размер, учитывающий различные факторы.
Сторипойнты должны быть нечеткими. Задача с оценкой два, скорее всего, больше, чем задача с оценкой один и меньше, чем задача с оценкой три. Но мы никогда не узнаем точный размер задачи - 1,6 или 2,7, и это нормально. Сторипойнты не предназначены для точности, это всего лишь оценки. Такая неопределенность плохо переводится в точность времени и может создавать проблемы.
Что делать, если вам все же необходимо иметь оценки, связанные с временем? Есть два случая, когда такие оценки могут быть необходимы:
Покер планирование - популярная методика оценки, которую используют команды для определения размера пользовательских историй с помощью сторипойнтов.
Каждому участнику команды выдается колода карт с числами. Команда обсуждает пользовательскую историю, а затем каждый участник выбирает карту, представляющую его оценку размера истории. Если есть большие расхождения, группа обсуждает расхождения и повторяет процесс, чтобы достичь общего понимания усилий, необходимых для выполнения работы.
Формат встречи покер планирования от Retrius позволяет командам оценивать истории, в том числе и для удаленных команд, превращая скучную задачу в увлекательный опыт. Покер планирование также облегчает задачу фасилитаторов, позволяя им непосредственно подготавливать список задач еще до самой встречи по оценке задач.
Story Points (сторипойнты) создают много путаницы, даже у опытных команд, поэтому мы собрали самые распространенные вопросы, которые возникают снова и снова и постарались ответить на них.
Story points (баллы историй, сторипойнты) — это числовая мера, которую команды разработки программного обеспечения используют для определения размера работы по сравнению с другими задачами. Значения сторипойнтов уникальны, так как каждая команда может учитывать различные факторы при назначении баллов, такие как сложность, риски и неопределенность.
Команды могут использовать часы или сторипойнты для оценки времени выполнения работы. В то время как часы представляют собой точную и универсальную единицу времени, баллы историй обеспечивают относительное и командное измерение.
Одной из основных проблем использования часов для оценки является то, что они затрудняют учет сложности и неизвестных препятствий. Люди, как правило, недооценивают время, необходимое для выполнения задачи, из-за когнитивного искажения, известного как ошибка планирования. Это искажение может привести к пропуску сроков и переоценке задач.
Сторипойнты предоставляют быстрый и более гибкий способ оценки работы. Вместо попыток достичь точности, они предоставляют быструю и разумную оценку по сравнению с другими задачами. Баллы также учитывают сложность, риски и неизвестные факторы, что трудно сделать с помощью оценки на основе времени.
В спринте нет фиксированного числа баллов историй. Количество баллов, которые команда выполняет за спринт, зависит от различных факторов, таких как способ оценки пользовательских историй, размер команды и опыт и квалификация членов команды.
Команда может получить приблизительную оценку количества баллов историй, помещающихся в спринт, путем расчета скорости спринта (sprint velocity).
Концепция сторипойнтов была изобретена Роном Джеффри в рамках экстремального программирования (Extreme Programming, XP). В видео ниже (на английском), он объясняет, что они использовали систему баллов, чтобы скрыть от менеджеров элемент времени при выставлении оценок.
Вместо того чтобы сообщать количество «идеальных дней», необходимых для выполнения задачи (их первоначальной единицы измерения), они умножали свои оценки в идеальных днях на три. Результат они называли баллами историй и предоставляли эти числа своим менеджерам.
Впоследствии Джеффри извинился за изобретение сторипойнтов из-за возникшей путаницы и злоупотреблений.
Сторипойнты официально не являются частью Scrum, так как в Scrum гайде они не упоминаются. Scrum гайд никогда не упоминал сторипойнты с момента первого издания в 2010 году. Однако многие команды Scrum все равно их используют.
Хотя они могут не фигурировать в Scrum гайде, со-создатель Scrum, Джефф Сазерленд, намекает на них в своей книге «Scrum – Искусство выполнить вдвое больше работы за половину времени», когда говорит о скорости выполнения (velocity):
“У нас есть все эти истории — эти вещи, которые должны быть сделаны. И мы их оценили — эта оценена в восемь баллов, а эта в три балла, и так далее. И потом мы начинаем наш первый спринт. Предположим, он длится неделю. В конце недели мы подсчитываем все истории, которые мы выполнили, суммируем баллы, и это число показывает нам, насколько быстро команда движется, их скорость. И когда у вас есть скорость, вы можете посмотреть, сколько историй осталось и на сколько баллов они оценены, и тогда вы сможете узнать, когда вы закончите следующий спринт.”
