Понимание относительных оценок в Agile. Даёшь Story Points!
В своей работе со Scrum-командами, я столкнулся с непониманием членов команды, как правильно оценивать задачи или user story. Из этого и родилась потребность в написании статьи, с помощью которой (я надеюсь), я смогу уложить знания в своей голове, лучше объяснять методику командам, а также помочь всем, кто будет ее читать эффективно и быстро оценивать задачи в своих проектах.
Зачем нужны относительные оценки
В этой части я не буду отвечать на вопрос «зачем вообще нужны оценки?», надеюсь, что на данный вопрос вы сами знаете ответ или на него уже ответил ваш руководитель, спонсор или инвестор. Я начну рассказ с сравнения относительных и абсолютных оценок.
В старой последовательной «водопадной» методологии разработки программного обеспечения и продуктов, где нельзя начать следующий этап без завершения предыдущего, существовало классическое деление на отделы: отдел разработки, отдел дизайна, отдел аналитики и т.д. Таким образом, техническое задание, пройдя через отдел архитектуры, аналитики, разработки (последовательность и наполнение зависели от организационной структуры и размера конкретной организации), обрастало деталями, дополнительными требованиями, архитектурными изысканиями и тому подобными артефактами. Финально получалась оценка в человеко-днях (или man day — md, терминология использовалась у одного из моих бывших работодателей). Считалось, а где-то до сих пор считается, что данный подход позволяет получить детальный бюджет проекта (смету) с точными абсолютными трудозатратами, на основе чего верстался портфельный бюджет и закладывался весь бюджет организации.
Однако, у данного подхода есть ряд существенных недостатков:
- Начнём с минусов waterfall, как такового. У нас нет времени! — в текущих реалиях, на первое место выходит скорость релиза — выпуска и передачи версии (инкремента) продукта клиенту. Будем долго разрабатывать и выпускать — рискуем, что нас опередят конкуренты, сам продукт будет не интересен клиенту, измениться рыночная ситуация или технология. Долго вникать в детали и оценивать стало недопустимой роскошью.
- Такой метод оценки подходит для крупных компаний со сложной организационной структурой, распределением функций по анализу, разработке, архитектуре, множеством отделов, структурным менеджментом. В современной концепции легких фреймворков (scrum, Kanban), возможности так распределять функционал просто нет. Dev team универсальна. При попытках использования временных абсолютных оценок (фокус-фактор, оценка по 3м точкам и др.) в небольших командах возникают конфликты и непонимания.
- Оценка в 95% неправильная и почти всегда занижена. Я встречал случаи, когда в крупном банке, оценка сразу предоставлялась с примечанием, что погрешность составляет -15%/+75%, т.е. «пальцем в небо», не нужно было вообще оценивать разработку, можно было просто подбросить монетку). Ну и все знают множество кейсов в строительных проектах, когда сроки и бюджет увеличиваются в 2, а иногда и в 10 раз.
- Ну и самый, на мой взгляд критичный недостаток подхода — он требует существенных трудозатрат множества людей, а сам процесс оценки не несет бизнес-ценности, при этом подходе мы постоянно увеличиваем waste.
Как итог: у нас нет времени для детальной и точной оценки, но и ценности в этой оценке, по большому счету нет. Наша основная цель: понять сколько задач команда может взять в итерацию (спринт), для этого нам точно подойдет относительная оценка и дальше я расскажу, что же она из себя представляет применительно к гибким методологиям.
Абсолютная vs Относительная оценка
На тренингах команд я использую пример, который, на мой взгляд, хорошо иллюстрирует относительную оценку и ее применимость в современных реалиях.
Итак, для начала давайте представим себя астрофизиками, которым необходимо решить задачу по определению диаметров планет Солнечной системы:
Сможете сходу назвать диаметр такой планеты, как Уран?
Без помощи Google, ответить на этот вопрос тем из нас, у кого не было пятерки по астрономии будет сложно, задача потребует значительного времени и даже после этого совершенно точно будут разные варианты оценки.
Кто-то вспомнит, что радиус Земли должен быть в районе 5 - 6 тысяч километров и предположит, что диаметр Урана равен 22 000 км.
Кто-то решит, что 22 750
Мы будем спорить и потратим очень много времени, чтобы договориться и выбирать лучший ответ, причём кто-то из команды все равно останется не довольным результатом.
А если я переформулирую вопрос и попрошу ответить, сколько диаметров Земли уместится в одном диаметре Урана? При ответе на этот вопрос, в команде обычно не возникает противоречий и все сходятся на варианте - 4 диаметра, что является верным ответом.
Когда мы сравниваем объекты между собой, оценка становится проще и в команде возникает меньше споров и противоречий.
В этом и есть разница и проблема между абсолютной и относительной оценкой.
В приведенных мною выше примерах использовалась оценка в днях, также есть практика оценки задач в часах, что является примером абсолютной оценки. В Scrum пользовательские истории оцениваются относительно и при оценке используются Story Points.
Абсолютная оценка = Часы
Относительная оценка = Story Points
Story Points
Таким образом, Story Point - это относительная оценка сложности задачи, в которой мы учитываем следующие составляющие:
- Сложность работы
- Объём работы
- Риски и неопределенность
Для того чтобы начать использовать относительную оценку, необходим опыт - пример какого-то уже разработанного простого функционала. Примером из корпоративной разработки может быть разработка одного текстового поля в корпоративном приложении:
Разработка поля не вызвало особых проблем у команды и мы принимаем за основу этот функционал, назначая для него оценку в 1 Story Point. Если нам потребуется оценить разработку 100 текстовых полей, не связанных друг с другом какой-либо логикой, то обьем работ увеличится, но не увеличится сложность, риски и неопределенность, поэтому мы возьмём для этой задачи оценку в 8 SP. В случае, когда для этих 100 полей необходимо применить связанную логику, и каждое из них будет иметь разный формат данных, оценка может повысится до 20 - 30 SP, так как возрастают неопределенность и сложность задачи. В описанных случаях о оценке договаривается сама команда, что полностью соответствует Scrum Guide.
Оставлю здесь видео от Майка Кона - евангелиста Agile, CEO Mountain Goat Software, в котором он рассказывает, что же такое Story Points
Проблемы с относительной оценкой
Story Pointы не имеют физических единиц оценки. Но я сталкивался с ситуациями, когда команды пытаются приравнять их ко времени, например, что 1 SP = 1 часу или дню, тем самым мы просто возвращаемся к абсолютной оценке. Важно помнить о том что мы должны оставаться в относительной шкале и задача Scrum мастера донести эту концепцию до команды и Product Ownera. Можно использовать пример с планетами, стаканом фасоли или другими сравнимыми вещами. Также, при продуктовом подходе, стоит помнить, что мы экспериментируем, мы ещё не знаем будет ли успешен наш продукт на рынке и сделаем ли мы удачный инкремент в этом спринте. Scrum Фреймворк предполагает процесс непрерывного улучшения на основе полученного опыта.
Именно поэтому, при правильном применении он и показывает свою эффективность: мы планируем sprint backlog - задачи на короткую итерацию (спринт), прототипируем наш инкремент (реализуем и тестируем задачи, которые мы взяли на текущий спринт), демонстрируем результат пользователям на Sprint Review, получаем обратную связь, анализируем и внедряем улучшения на Retro и затем снова повторяем цикл.
Эксперимент важен, он позволяет команде постоянно совершенствоваться и становиться эффективнее и относительная оценка помогает в этом, так как за основу оценки, мы берём задачи, которые команда уже делала. Таким образом оценка со временем становится все лучше, а результат все более прогнозируемым.
Принципы оценки
Для себя я выделяю 3 основных принципа, при которых оценка будет эффективна для команды и проекта в целом.
- Высокая скорость оценки. В гибких методологиях и современном цифровом бизнесе скорость наиболее важный индикатор, а сама оценка не несёт бизнес-ценности, поэтому и метод оценки должен быть быстрым.
- Командная работа. Важно, чтобы в оценке принимали участие все члены команды, таким образом мы рассматриваем задачу со всех сторон, учитывая основные риски и разные точки зрения, а всем участникам комфортно, так как их мнение учтено в оценке.
- Относительность. На мой взгляд причин использования относительной оценки я привёл предостаточно, просто напомню, что в современных реалиях это наиболее эффективный вариант.
Методы оценки
Методов относительной оценки множество, описание их механик тянет на отдельную статью. Я склоняюсь к самым простым, чтобы команде можно было быстро и легко начать их использовать. Далее расскажу об одном из них:
«Майки»
Есть множество вариаций метода (собаки, города и пр.), суть от этого не меняется. Есть футболки разных размеров от XS до XL и этими размерами мы и будем оценивать User Story. Для начала можно, текстово, оценить несколько уже выполненных задач из предыдущих спринтов, взять из них самую маленькую и простую - XS, после чего «примеряем» к ней задачи из backlog:
M = S + S
S = XS + XS
И т.д.
Мы, также используем размер XXL когда появляется задача с очень высоким уровнем неопределенности и такую «майку» точно необходимо декомпозировать на более мелкие.
Product Owner рассказывает команде контекст задачи, как он ее видит, после чего все члены команды «вслепую» (исключаем влияние на оценки) дают свои оценки ведущему (Scrum мастеру). Далее, слово предоставляется участнику, давшему самую высокую и самую маленькую оценку задаче. Выслушав их члены команды договариваются готовы ли они повысить или понизить свою оценку на основе услышанного, в итоге команда должна придти к единому мнению.
С чего начать?
Относительные оценки, по моему мнению, эффективный инструмент в современном бизнесе. Основная проблема это донести его ценность до команды. Для начала лучше взять несколько уже реализованных и хорошо знакомых команде задач и сравнить их относительно друг друга. Далее можно постепенно переходить к новым. Не стоит усреднять оценки, если есть небольшая разница, обсуждая оценки, вы обсуждаете функционал и возможные риски - следите за тем, чтобы дискуссия имела конструктивное русло, но была обязательно.
Не меняйте метод оценки часто, важно наблюдать за эволюцией команды, первые 1-2 спринта оценки могут не соответствовать полученным результатам, помните про эксперимент. Проводите ретро и обсуждайте с командой почему результат показал отклонение от первоначальных ожиданий, с помощью чего его можно улучшить, что необходимо предусмотреть.
Большое спасибо, что вы дочитали до конца! Я очень надеюсь, что мне удалось донести смысл оценочной системы и привести примеры ее работы. Буду рад и благодарен за любые комментарии или критику в свой адрес.