что такое стори поинт
Понимание относительных оценок в 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): декомпозируйте истории, пока они не станут размером с один приемочный тест. После небольшой тренировки, ваши истории станут самого подходящего размера.
Конечно же, на тему оценки есть много других статей. Просто пройдите по ссылке, которую я оставил выше – там больше информации, чем вы можете представить.
Предсказывая будущее
Но … разве не существует вполне закономерной необходимости знать, сколько займет релиз продукта, и разве не нужно для этого оценивать? Возможно оценка и нужна, только не оценка историй. Вероятно, у вас даже не будет требований, проработанных до уровня историй. А если и будут – то наверняка они получатся громоздкими и в основном бесполезными.
Конечно же, если оценки нужно делать, то нужно их делать. То, что я делаю или как я представляю, что вам нужно делать – это всё мои теории. В конце концов – вам решать, как действовать, чтобы достичь успеха в вашей конкретной ситуации. Тем не менее, я думаю, что есть более хороший путь.
Во-первых, подумайте о нескольких самых важных качествах следующего релиза. Обсудите проблемы, которые они решают и как ваше ПО может помочь решить эти проблемы. Обсудите простейшие решения, которые могут хотя бы немного помочь. Нам не нужно решать сразу всё: зачастую, даже небольшая помощь может привести всё в движение.
Во-вторых, подумайте о ближайшем дедлайне, к которому вы могли бы поставить что-то из хороших решений. Установите этот дедлайн и приступайте к работе.
В-третьих, декомпозируйте важные решения на маленькие части и реализуйте их. Наверняка у вас легко получится сделать эти части размером в один день, или меньше. Работайте только над самыми важными частями: не пытайтесь реализовать все решение до упора. Ваша цель – начать думать в ключе “Если мы сделаем вот эту небольшую функцию, то наш Пользователь Джек уже сможет этим пользоваться”. Потом завершите эту функцию и дайте Пользователю Джеку попробовать. Наша цель – максимально приблизиться к непрерывной поставке ценности. И делать это нужно быстро.
Нам важно сделать поставляемую ценность настолько осязаемой, чтобы наш Владелец Продукта или другие стейкхолдеры спешили поскорее вывести это в релиз. Тогда … тогда мы будем на правильном пути, с оценкой историй или без нее.
Подытожим
Что ж, если я и изобрел стори поинты, наверное, мне немного жаль. Но не сильно жаль. Я действительно думаю, что их часто используют неправильно и мы избежим многих проблем, если вообще откажемся от оценок историй. Если в вашей компании стори поинты не несут ценности – я бы предложил от них отказаться, потому что это пустая трата усилий. С другой стороны, если они вам очень нравятся, то, что ж, полный вперёд!
За перевод огромное спасибо Максиму Фролову.
Стори Поинты (Story Points)
Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты. Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.
Ниже — перевод статьи Джеффа Сазерленда Story Points: Why are they better than hours? с сайта Scrum Inc.
Чем Стори Поинты лучше человеко-часов?
Стори поинты дают более точную оценку, существенно уменьшают время планирования, позволяют лучше прогнозировать дату релиза и повышают производительность команд. Традиционная оценка в человеко-часах является менее точной, приводит к лишним потерям времени на оценку, мешает Владельцу Продукта планировать релиз и не позволяет команде понять, какие из внедренных улучшений процесса действительно сработали.
Точность оценок
Последние исследования от Microsoft показывают, что оценка по agile демонстрирует поразительную точность в сравнении с традиционными методами оценки проектов. Подробнее об этом исследовании вы можете почитать здесь:
Scrum + Engineering Practices: Experiences of Three Microsoft Teams
Многим людям, имевшим опыт управления проектами с оценкой в часах, сложно понять, почему стори поинты работают лучше. Им также сложно принять некоторые фундаментальные факты, которые публикуются в профильной литературе уже в течение 60 лет, равно как и последние исследования, которые только подтверждают их правильность.
Успешность проектов
Давайте посмотрим на последние данные по неуспешным проектам. Глобальная финансовая система рушится, и вместе с этим растет процент провальных проектов в IT. Недавно было проведено одно интересное исследование: консалтинговая фирма Standish Group собрала данные об успешности нескольких десятков тысяч проектов, стартовавших за последние десять лет. Аналитика от Standish Group показывает, что процент успешности agile-проектов в три раза превышает успешность проектов, ведущихся традиционным образом. Джим Джонсон рекомендует использование agile-практик на всех без исключения проектах.
Разрыв между оценками сроков и реальностью
Венчурные капиталисты, с которыми я работаю, признаются, что никогда не видели актуальную диаграмму Ганта на встречах правления компаний. Исследуя проблему глубже, они обнаружили, что до внедрения скрама никто из руководства вообще не знал реальной производительности своих команд, и это в 100% случаев озвучивается на встречах правления как главная причина несоблюдения даты релиза.
Дело в том, что для планирования релиза критичным является постоянство пользовательских историй. Три стори поинта сегодня — это те же три стори поинта в следующем году, и для Владельца Продукта эти стори поинты являются измеримой частью релиза продукта. Тогда как количество часов для завершения истории зависит от того, кто ее делает и в какой день. Эти показатели меняются ежедневно. Диаграмма Ганта предполагает фиксированное количество часов на задачу для какого-то гипотетического человека (который зачастую не является фактическим исполнителем задачи) и заведомо известные зависимости (которые на самом деле непрерывно меняются). Исследование восьмидесяти мультимиллионных проектов, проведённое в GSI Commerce (ими сейчас владеет eBay), показало, что лучшие эксперты в компании оказались неспособными правильно оценить время выполнения проекта людьми, которые действительно его реализовывали.
Вам может показаться, что эта статистика могла бы заставить людей поменять своё поведение, но многим компаниям, похоже, проще продолжать терпеть убытки или даже банкротство вместо того, чтобы изменить свои принципы управления проектами.
Вариабельность оценок
Исследование, проведенное Rand Corporation еще в 1940х годах, очевидно продемонстрировало неспособность людей точно проводить оценку в часах, и практический опыт постоянно подтверждает этот факт. Вместо часов для оценки рекомендуется использовать метод «Дельфи», известный в разработке программного обеспечения как техника Wide Band Delphi. Аналогичная техника используется agile-командами и носит название Покер планирования.
Интересные данные по личной продуктивности разработчиков пришли из Йельского Университета. Лучшему разработчику на проекте требуется один час, чтобы сделать задачу, в то время как худшему требуется 10 часов (в рамках его проекта) или даже 25 (если проект незнакомый). Для команд эта разница еще на порядок больше. Данные, опубликованные Ларри Путнемом (Larry Putnam) показывают, что задача, на которую наиболее продуктивной команде требуется час, может превратиться в 2000 часов для наименее продуктивной команды.
Процесс оценки в стори поинтах дает лучшую точность, чем оценка в часах, за счет меньшей вариативности стори пойнтов. Одна компания 5го уровня CMMI определила, что оценка в стори поинтах сокращает время оценки на 80%, что позволяет оценивать больше фич и отслеживать их, в сравнении с каскадной моделью. Другая компания из телеком индустрии заметила, что оценка с помощью стори поинтов и Покера планирования была не только в 48 раз быстрее, чем практики каскадной оценки, но и дала более точные результаты.
Мера прогресса
Для руководства мерой прогресса является законченный функциональный элемент, поэтому важно, чтобы каждая поставка была новым шагом на этом пути. Рабочий функционал является предусловием для получения прибыли, а ведь любая компания создается для увеличения прибыли (даже если при планировании проекта неосознанно делается прямо противоположное). По крайней мере, венчурные капиталисты уверены в том, что компании работают ради денег, и для денег важны скорость производства и качественный продукт. А человеко-часы — это затраты, которые необходимо уменьшать или вообще избавляться от них везде, где это возможно.
Число потраченных часов не дает Владельцу Продукта никакой информации о том, сколько фич можно поставить и когда.
Что действительно является важной метрикой, так это количество стори поинтов, которую команда может поставить за календарный период. Число поинтов за спринт — это производительность команды (velocity). И несмотря на то что все оценки происходят в стори поинтах, Владелец Продукта делает план релизов на основании производительности команды и корректирует его, если эта производительность меняется.
Таким образом, стори поинты быстрее, лучше и дешевле часов, и высокоэффективные команды повсеместно отказываются от оценок в часах как от лишней нагрузки, которая замедляет их и тянет вниз.
Jeff Sutherland, 2013
Диаграмма Сгорания Работ Спринта визуально показывает прогресс Команды в Стори Поинтах по дням спринта. Это графическое представление того, сколько работы уже сделано и сколько еще остается сделать. Диаграмма позволяет Команде прогнозировать успех Спринта и предпринимать меры, чтобы к моменту окончанию Спринта все запланированные задачи были были завершены.
Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований. Такие Элементы можно принять в работу немедленно (они Immediately Actionable). Например, Элементы можно проверять на соответствие критериям I.N.V.E.S.T.
Критерии Приемки (Acceptance Criteria)
Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.
Оценка (Estimation)
Оценка – это прогнозирование усилий, которые потребуются для завершения работы над Элементом Бэклога Продукта. Она обеспечивает Владельцу Продукта и Скрам-мастеру уверенность в дате релиза и является базой для расчета производительности Команды. Существует множество способов оценки усилий Скрам-командой, но при этом всегда используются относительные единицы: например, Стори Поинты. Обычно оценка проводится в рамках Уточнения (Груминга) Бэклога Продукта.
Величина, отражающая количество работы, которое Скрам-команда может выполнить за один Спринт. Является важной метрикой в Скраме. Производительность вычисляется в конце Спринта как сумма Стори Поинтов по всем полностью завершенным Элементам Бэклога Спринта.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми