Что такое story point в scrum
Оценка задач в Story Points для больших и молодых команд разработки
У разработчиков, которые давно работают вместе, обычно нет проблем в оценке задач. В таких командах процессы настроены, а люди хорошо понимают друг друга, и любому новичку, попавшему в такую команду, быстро объяснят, научат и покажут, как работать в команде.
Но на старте проекта (или при реформировании бизнес юнита) часто собираются новые команды. И в таких новых командах жизненно необходимо быстро и правильно построить методологию оценки задач; в ином случае, процесс планирования будет бесполезным, и даже примерно предсказать, когда будет сделана фича, станет невозможно.
В этой статье я расскажу, к чему пришел за годы практической разработки и управления командами. Естественно, это не правда в последней инстанции, а лишь то, что успешно работало у меня.
Мой опыт управления командами разработки
Я в разработке уже более 10 лет, за это время поменял несколько ролей. Работал и без процессов совершенно, работал работником, которому объясняют, как работать, работал в команде, где помогал настраивать процессы, и, наконец, помогал настраивать процессы сразу нескольким десяткам команд. Сегодня я — Android-лид в Кошельке, где продолжаю настраивать процессы.
Очень редко получается, что команда несколько лет подряд успешно работает одинаковым составом по одинаковым процессам. Постоянно что-то меняется: люди, их роли, проекты и так далее.
Новая команда, старые трудности
Команда Кошелька сейчас активно расширяется, стало больше людей и больше задач. Много новеньких пришло за последние 4 месяца. Как следствие, люди плохо знают друг друга и проект. Поэтому задачи, которые изначально кажутся небольшими и лёгкими, выполняются долго. Возникает вопрос, как прогнозировать разработку в таких условиях?
Необходимая теория: Оценка задач и её точность
Самый ценный и расходуемый ресурс во время разработки — время. Точно сказать, сколько уйдет времени на одну задачу, невозможно, пока она не будет выполнена. Поэтому мы оцениваем задачу приблизительно.
Точность зависит от знаний оценивающего о задаче и контексте, в котором она должна выполняться. Такие знания можно получить в результате предварительного анализа. Чем глубже анализ, тем более точную оценку мы сможем дать.
Таким образом, оценка — это предсказание, сколько будет стоить решение задачи. А нужна она, чтобы сформировать ожидания, когда будет получен результат.
От чего зависит оценка?
От ответов на два главных вопроса:
Ответ на вопрос «что?» формулируется при составлении задачи. Это смысл задачи, проблема, которую она должна решить. Перед началом работы нужно убедиться, что основные требования необходимы, достаточны и понятны.
Ответ на второй вопрос сложнее. Он зависит как от проблемы, которую нужно решить, так и от контекста, в котором её нужно решать. Контекст — это текущее состояние проекта. И он меняется с каждым новым изменением в коде проекта.
Решение почти любой задачи можно разбить на такие этапы:
Очевидно, что чем дальше мы продвинулись в решении, тем более точную оценку мы можем дать. Также очевидно, что оценивать сложность выполнения задачи уже во время тестирования бесполезно. Обычно адекватно оценить задачу можно во время начала этапа проектирования.
Оценка по времени
Сначала кажется, что время это очевидная мера оценки, ведь мы тратим на разработку именно часы и дни.
Плюс такого способа в том, что такая оценка всем понятна. Если задачу оценили в 8 часов, то её решение ожидается через 1 рабочий день, а за спринт ожидается решение 10 задач такого размера.
Минус в том, что в этом варианте невозможно учесть увеличение погрешности оценки с увеличением размера задачи. Ожидается, что 10 задач по 8 часов будут сделаны за то же время, что и 1 задача на 80 часов. Но более объемная задача, как правило, имеет больше подводных камней, которые не видны на ранних этапах проектирования.
Также не стоит забывать про разный уровень разработчиков в команде. Например, Senior сможет оценить и сделать задачу за 8 часов, тогда как Junior ту же задачу может оценить и сделать за 40 часов. Как следствие, оценка во времени актуальна, только если задачу будет делать тот, кто оценивал. Это может сработать, если в команде был, есть и будет один разработчик. Если разработчиков хотя бы два, то рассчитать среднюю производительность команды в часах будет трудно.
Как правило при оценке все забывают учитывать время на рутинные задачи, создание задачи, создание пулл-реквеста, время на ревью и исправление замечаний. А так как в оценке указано конкретное время, то и выполнение задачи ожидается именно за это время.
На практике задача, оценённая в часах, крайне редко выполняется вовремя.
Оценка в Story Point
Вместо оценки в часах и днях хорошо подходит оценка объема задач в относительных величинах. Такие величины называются story point. Ниже я расскажу о двух подходах к восприятию story points и оценке в них.
SP с эталонной задачей
Чтобы вся команда одинаково понимала значение единицы SP, можно придумать и описать эталонную задачу в 1 story point. Каждый сравнивает свою задачу с этим эталоном и дает оценку в зависимости от того, насколько она больше или меньше эталона.
Какие проблемы?
Проблем у такого подхода несколько:
Изменения. Контекст постоянно меняется, поэтому эталонная задача может быстро потерять актуальность. Со временем команда перестанет понимать, почему эта задача была когда-то эталонной.
Кросс-платформенная разработка. Если в команде есть несколько платформ, например, iOS и Android, то каждая платформа выбирает себе свою эталонную задачу. Так оценка перестаёт быть единой для всех, а члены команды, относящиеся одновременно к нескольким платформам (например, QA или аналитики), могут запутаться в понимании значения 1 SP.
Не учитывается погрешность оценки. Эталонная задача не учитывает прогрессию возрастания сложности. Если хотим оценить задачу в 3SP, то это вроде бы значит, что оцениваемая задача в 3 раза объёмнее эталонной. Это то же самое, что сделать 3 задачи по 1SP? На практике — нет. Чем сложнее задача, тем менее вероятно, что мы её оценим правильно.
SP со временем
Чтобы учесть проблемы предыдущих способов оценки, можно использовать story points с оценкой по времени. Важно понимать, что мы используем не просто время, а восприятие времени. То есть оцениваем не сколько часов будет выполняться конкретная задача, а за сколько часов в идеальном мире её можно выполнить.
Чтобы понять, за какое время мы сделаем задачу или сколько SP мы сделаем за спринт, нужно посчитать, сколько в среднем SP-ов мы делали в предыдущих спринтах. Так, если в предыдущих спринтах мы делали по 7SP, а в спринте 10 рабочих дней, то 1 SP — это 1,4 дня, а если по 14 SP, то 1 SP — это 0,7 дня.
Чтобы с чего-то начать, можно использовать такую шкалу:
0.5 SP — менее, чем за день
1 SP — до 2 дней
2 SP — около недели
3 SP — около одного спринта
5 SP — можно сделать за спринт, если всё будет идеально и никто не будет отвлекать
8 SP — 2 спринта
Задачи 5 и 8 SP в спринт брать нельзя, их нужно декомпозировать на более мелкие, чтобы снизить погрешность оценки. Задачи на 2 и 3 SP достаточно большие, их сложно сделать на одном дыхании, их лучше тоже декомпозировать. Но это не всегда оправданно или возможно.
Задачи с оценкой в 0.5 и 1 SP должны занимать основную часть спринта. Это довольно точные оценки, по ним всегда будет, что сказать на стендапе. Задач меньше, чем 0.5 SP, просто не бывает: всегда требуется время на описание задачи, на мерж-реквест, на тестирование и т.д.
Важно помнить, что в приведенной выше шкале время используется только для того, чтобы оценить, сколько SP стоит задача, но не за сколько она реально будет сделана. Как следствие, чтобы понять, сколько задач будет сделано за спринт, нужно смотреть, сколько в среднем среднем SP делали в предыдущих спринтах.
Какие проблемы?
Минусы такого подхода в том, что при оценке учитывается время. А это значит, что Junior и Senior оценят задачу по-разному, так как им нужно разное время на её выполнение. Эта проблема решается усреднением оценки по команде — например, с помощью покер-планирования.
При оценке в SP с использованием времени важно не учитывать, кто именно будет делать задачу. Иначе возникает соблазн включить в оценку индивидуальные особенности разработчика: его “синьористость”, отпуск, вынужденные выходные. Это повлияет на среднюю ёмкость спринта, а SP превратятся из оценки объёма задачи в оценку работы разработчика.
Текущий курс — стабилизация процесса
Как я уже писал, моя команда в Кошельке — новая, кроссплатформенная и большая. У нас объёмные и сложные задачи, нам нужно их быстро решать.
Уже несколько месяцев мы используем подход с оценкой в SP с привязкой ко времени. А последние несколько спринтов нам удаётся сжигать SP практически в ноль.
Мы следим за статистикой, мы обсуждаем то, что мы делаем, мы пытаемся лучше понимать друг друга. И мы становимся лучше с каждой итерацией.
Понимание относительных оценок в Agile. Даёшь Story Points!
В своей работе со Scrum-командами, я столкнулся с непониманием членов команды, как правильно оценивать задачи или user story. Из этого и родилась потребность в написании статьи, с помощью которой (я надеюсь), я смогу уложить знания в своей голове, лучше объяснять методику командам, а также помочь всем, кто будет ее читать эффективно и быстро оценивать задачи в своих проектах.
В этой части я не буду отвечать на вопрос «зачем вообще нужны оценки?», надеюсь, что на данный вопрос вы сами знаете ответ или на него уже ответил ваш руководитель, спонсор или инвестор. Я начну рассказ с сравнения относительных и абсолютных оценок.
В старой последовательной «водопадной» методологии разработки программного обеспечения и продуктов, где нельзя начать следующий этап без завершения предыдущего, существовало классическое деление на отделы: отдел разработки, отдел дизайна, отдел аналитики и т.д. Таким образом, техническое задание, пройдя через отдел архитектуры, аналитики, разработки (последовательность и наполнение зависели от организационной структуры и размера конкретной организации), обрастало деталями, дополнительными требованиями, архитектурными изысканиями и тому подобными артефактами. Финально получалась оценка в человеко-днях (или man day — md, терминология использовалась у одного из моих бывших работодателей). Считалось, а где-то до сих пор считается, что данный подход позволяет получить детальный бюджет проекта (смету) с точными абсолютными трудозатратами, на основе чего верстался портфельный бюджет и закладывался весь бюджет организации.
Однако, у данного подхода есть ряд существенных недостатков:
Как итог: у нас нет времени для детальной и точной оценки, но и ценности в этой оценке, по большому счету нет. Наша основная цель: понять сколько задач команда может взять в итерацию (спринт), для этого нам точно подойдет относительная оценка и дальше я расскажу, что же она из себя представляет применительно к гибким методологиям.
На тренингах команд я использую пример, который, на мой взгляд, хорошо иллюстрирует относительную оценку и ее применимость в современных реалиях.
Итак, для начала давайте представим себя астрофизиками, которым необходимо решить задачу по определению диаметров планет Солнечной системы:
Сможете сходу назвать диаметр такой планеты, как Уран?
Без помощи Google, ответить на этот вопрос тем из нас, у кого не было пятерки по астрономии будет сложно, задача потребует значительного времени и даже после этого совершенно точно будут разные варианты оценки.
Кто-то решит, что 22 750
Мы будем спорить и потратим очень много времени, чтобы договориться и выбирать лучший ответ, причём кто-то из команды все равно останется не довольным результатом.
Когда мы сравниваем объекты между собой, оценка становится проще и в команде возникает меньше споров и противоречий.
В этом и есть разница и проблема между абсолютной и относительной оценкой.
В приведенных мною выше примерах использовалась оценка в днях, также есть практика оценки задач в часах, что является примером абсолютной оценки. В Scrum пользовательские истории оцениваются относительно и при оценке используются Story Points.
Абсолютная оценка = Часы
Относительная оценка = Story Points
Story Pointы не имеют физических единиц оценки. Но я сталкивался с ситуациями, когда команды пытаются приравнять их ко времени, например, что 1 SP = 1 часу или дню, тем самым мы просто возвращаемся к абсолютной оценке. Важно помнить о том что мы должны оставаться в относительной шкале и задача Scrum мастера донести эту концепцию до команды и Product Ownera. Можно использовать пример с планетами, стаканом фасоли или другими сравнимыми вещами. Также, при продуктовом подходе, стоит помнить, что мы экспериментируем, мы ещё не знаем будет ли успешен наш продукт на рынке и сделаем ли мы удачный инкремент в этом спринте. Scrum Фреймворк предполагает процесс непрерывного улучшения на основе полученного опыта.
Эксперимент важен, он позволяет команде постоянно совершенствоваться и становиться эффективнее и относительная оценка помогает в этом, так как за основу оценки, мы берём задачи, которые команда уже делала. Таким образом оценка со временем становится все лучше, а результат все более прогнозируемым.
Для себя я выделяю 3 основных принципа, при которых оценка будет эффективна для команды и проекта в целом.
Методов относительной оценки множество, описание их механик тянет на отдельную статью. Я склоняюсь к самым простым, чтобы команде можно было быстро и легко начать их использовать. Далее расскажу об одном из них:
Мы, также используем размер XXL когда появляется задача с очень высоким уровнем неопределенности и такую «майку» точно необходимо декомпозировать на более мелкие.
Product Owner рассказывает команде контекст задачи, как он ее видит, после чего все члены команды «вслепую» (исключаем влияние на оценки) дают свои оценки ведущему (Scrum мастеру). Далее, слово предоставляется участнику, давшему самую высокую и самую маленькую оценку задаче. Выслушав их члены команды договариваются готовы ли они повысить или понизить свою оценку на основе услышанного, в итоге команда должна придти к единому мнению.
Не меняйте метод оценки часто, важно наблюдать за эволюцией команды, первые 1-2 спринта оценки могут не соответствовать полученным результатам, помните про эксперимент. Проводите ретро и обсуждайте с командой почему результат показал отклонение от первоначальных ожиданий, с помощью чего его можно улучшить, что необходимо предусмотреть.
Большое спасибо, что вы дочитали до конца! Я очень надеюсь, что мне удалось донести смысл оценочной системы и привести примеры ее работы. Буду рад и благодарен за любые комментарии или критику в свой адрес.
Обдумывая стори поинты
Мне нравится говорить, что я, возможно, изобрел стори поинты (story points) и если действительно изобрел, то сегодня мне жаль. Давайте рассмотрим подробнее, что я думаю о стори поинтах сейчас. По крайней мере один из нас точно заинтересован в моих мыслях.
Идея историй (stories) конечно же пришла из XP, а не из Scrum. Неким образом скрам-практики адаптировали эту идею в свою работу. Хотя официальный скрам-гайд говорит лишь об элементах бэклога (backlog items), использовать пользовательские истории в качестве элементов бэклога – очень распространенная в скраме практика.
Распространенная – хотя бы до той степени, в которой скрам-практики понимают истории. Ранее я уже писал о том, как правильно использовать пользовательские истории. Здесь мы обсудим стори поинты.
В экстремальном программировании (ХР), истории изначально оценивались во времени: времени, которое потребуется на завершение разработки истории. Мы быстро начали использовать то, что сейчас называется “идеальные дни”, которые неофициально означали “сколько дней потребуется паре до завершения, если их наконец-таки оставят в покое”. Мы перемножали идеальные дни и “фактор нагрузки”, чтобы получить реальное время до завершения разработки. Фактор нагрузки обычно составлял примерно три: три реальных дня тратилось, чтобы завершить работу одного идеального дня.
Мы называли наши оценки в днях, и обычно не произносили слово “идеальные” вслух. По этой причине, наши стейкхолдеры часто не могли понять, каким образом нам нужно три дня, чтобы завершить работу одного дня, или, с другой стороны, почему мы не могли выполнить 50 “дней” работы за три недели.
Так что, насколько я помню, мы начали называть наши “идеальные дни” обычными “поинтами”. Таким образом, оценка в три стори поинта означала, что историю завершат примерно за 9 дней. Так или иначе, мы использовали поинты только чтобы понять, какой объем работы мы можем взять в итерацию, поэтому когда мы говорили что это примерно 20 поинтов, никто особо не возражал.
Возможно это я предложил изменить название. Если я действительно сделал это, сейчас мне жаль. Вот некоторые из моих нынешних соображений на эту тему. Я писал их своему коллеге Саймону, который спросил:
Ты действительно сожалеешь, что стори поинты были изобретены, или ты просто осуждаешь их неправильное использование, когда люди не полностью понимают относительные размеры?
Сравнение
В первую очередь, даже если команды “почти одинаковые”, у каждой из них есть собственный набор компетенций и своя рабочая среда. Так что если они посмотрят на две истории, которые выглядят одинаково и одна команда скажет, что это двойка, а другая скажет, что это шестерка – это попросту бесполезная информация. И это точно не самый полезный способ сравнения команд.
Теперь попробуем разобраться в ситуации. Сначала посмотрим, а действительно ли обе ситуации сравнения были идентичными, а потом уточним, быть может команд с более высокой оценкой нуждалась в помощи, которую мы могли предоставить. Такой подход был бы отличным примером. Явно или неявно выносить вердикт, что “более медленная” команда неким образом хуже или менее профессиональна – вот это стало бы очень плохим примером, который в реальности, к сожалению, является нормой.
Я думаю, что когда есть две команды, производящие ценность, для менеджеров сравнить их – непреодолимое искушение. Я думаю, что оно настолько непреодолимое, что я готов отказаться от идеи стори поинтов и даже всей концепции оценки историй, где это возможно. Мы еще вернемся к вопросу как работать с меньшим количеством оценок. Кроме того, на эту тему есть другие статьи.
Отслеживание
Для многих менеджеров существование оценки подразумевает существование “реальных трудозатрат”, а значит нужно сравнить оценку и реальные трудозаты и убедиться, что они совпадают. Если не совпадают – значит нужно учиться оценивать лучше.
Для меня важная черта Реального Agile – выбрать несколько вещей в работу, а потом оперативно их сделать. Ключевой вопрос – это как найти самые ценные вещи и как сделать их быстро. Сделать быстро обычно превращается в поставку маленьких кусочков ценности и динамичное итерирование. Оценка стоимости историй не особо в этом помогает, если вообще помогает.
Так что если существование оценки заставляет менеджмент сместить фокус с поставки ценности на улучшение процесса оценки, значит оно забирает внимание с настоящей цели – быстро доставлять реальную ценность.
Из-за этого я прихожу к мысли о том, что оценок, будь то в поинтах или времени, стоит избегать.
Давление
Близко к отношениям оценок и реальных трудозатрат находится закономерное давление из-за желания менеджмента получить “больше”. Сколько бы команда ни поставила ценности, этого мало. Нужно больше, больше, больше.
Лучший способ поставлять ценность – это не больше, больше, больше. Лучший способ – это поставлять ценность часто и маленькими партиями. Если вместо оценивания историй мы поделим их на “достаточно маленькие” кусочки, тогда мы сможем прийти к равномерному потоку поставки ценности, доставляя без перерывов.
Фокусировка на “больше” мешает увеличению ценности. Продавливание увеличенных поставок практически без вариантов приводит к плохому результату: команда пытается ускориться и делает это в ущерб качеству кода или тестированию. Вскоре они начинают поставлять больше дефектов, замедляются из-за увеличенного количества переделок чтобы починить дефекты, замедляются еще сильнее из-за того что качество кода стремительно ухудшается. Положение становится хуже и хуже, давление увеличивается и всё превращается в погоню за провальными ситуациями.
Поскольку оценки связаны с применением чрезмерного давления, я предпочитаю избегать их.
Я скажу больше: я предпочитаю вовсе отказываться от планирования спринтов или итераций. Мы работаем не для того, чтобы освоить бюджет предстоящих недель: мы работаем, чтобы составить короткий список важных вещей для ближайшей поставки.
Предсказывая готовность
Обычная практика – составить список необходимых фич, обдумать их и решить, что они составят следующий релиз нашего продукта. Конечно же, следующий вопрос – “когда всё это будет готово?”.
Ответ на него – никто не знает. Мы можем проделать большую работу над своим незнанием. Иногда этим действительно стоит заняться, например, когда на кону большой контракт, ожидающий оценки. Однако, когда мы работаем в сфере разработки решений для внутренних или внешних заказчиков, лучший вариант – поставлять небольшое количество ценности очень часто, а не ждать монструозных релизов, которые бесконечно отодвигаются на потом.
Намного лучше выбрать для следующего релиза недалёкую дату и включить в этот релиз максимальное количество ценности. Оценка мешает этой задаче, будь она в стори поинтах, Мишках Гамми или даже времени. Если оценки возможно избежать, по моему мнению, надо это сделать.
Декомпозиция
Появляется вопрос, если мне не нравится оценка историй, то что же мне нравится? Отвечаю – мне нравится декомпозиция историй. Это практика нарезания больших историй на маленькие кусочки. Главное – чтобы эти маленькие части несли как можно больше ценности, но требовали минимум времени на реализацию – в идеале, меньше дня или всего пару часов.
Я не буду препираться с читателями на тему оценивания в процессе декомпозиции. Если ваша команда в тайне проводит оценку и никому об этом не говорить – тогда проблем с этой оценкой скорее всего не возникнет, в стори поинтах она или во времени. И конечно же, знать разницу между “наверное достаточно маленькая” и “наверное недостаточно маленькая” и знать как различаются “три дня” и “один день” – это совершенно непохожие вещи.
Кроме того, есть одна хитрость. Я упоминал ее в Getting Small Stories и в Slicing, Estimating, Trimming. Я выучил ее у Нила Киллика (Neil Killick): декомпозируйте истории, пока они не станут размером с один приемочный тест. После небольшой тренировки, ваши истории станут самого подходящего размера.
Конечно же, на тему оценки есть много других статей. Просто пройдите по ссылке, которую я оставил выше – там больше информации, чем вы можете представить.
Предсказывая будущее
Но … разве не существует вполне закономерной необходимости знать, сколько займет релиз продукта, и разве не нужно для этого оценивать? Возможно оценка и нужна, только не оценка историй. Вероятно, у вас даже не будет требований, проработанных до уровня историй. А если и будут – то наверняка они получатся громоздкими и в основном бесполезными.
Конечно же, если оценки нужно делать, то нужно их делать. То, что я делаю или как я представляю, что вам нужно делать – это всё мои теории. В конце концов – вам решать, как действовать, чтобы достичь успеха в вашей конкретной ситуации. Тем не менее, я думаю, что есть более хороший путь.
Во-первых, подумайте о нескольких самых важных качествах следующего релиза. Обсудите проблемы, которые они решают и как ваше ПО может помочь решить эти проблемы. Обсудите простейшие решения, которые могут хотя бы немного помочь. Нам не нужно решать сразу всё: зачастую, даже небольшая помощь может привести всё в движение.
Во-вторых, подумайте о ближайшем дедлайне, к которому вы могли бы поставить что-то из хороших решений. Установите этот дедлайн и приступайте к работе.
В-третьих, декомпозируйте важные решения на маленькие части и реализуйте их. Наверняка у вас легко получится сделать эти части размером в один день, или меньше. Работайте только над самыми важными частями: не пытайтесь реализовать все решение до упора. Ваша цель – начать думать в ключе “Если мы сделаем вот эту небольшую функцию, то наш Пользователь Джек уже сможет этим пользоваться”. Потом завершите эту функцию и дайте Пользователю Джеку попробовать. Наша цель – максимально приблизиться к непрерывной поставке ценности. И делать это нужно быстро.
Нам важно сделать поставляемую ценность настолько осязаемой, чтобы наш Владелец Продукта или другие стейкхолдеры спешили поскорее вывести это в релиз. Тогда … тогда мы будем на правильном пути, с оценкой историй или без нее.
Подытожим
Что ж, если я и изобрел стори поинты, наверное, мне немного жаль. Но не сильно жаль. Я действительно думаю, что их часто используют неправильно и мы избежим многих проблем, если вообще откажемся от оценок историй. Если в вашей компании стори поинты не несут ценности – я бы предложил от них отказаться, потому что это пустая трата усилий. С другой стороны, если они вам очень нравятся, то, что ж, полный вперёд!
За перевод огромное спасибо Максиму Фролову.