Story points scrum что это
Scrum Story Points. Изобретение дьявола
Привет, искушенный читатель! Если ты вращаешься вокруг проектного управления и Agile, то наверняка слышал о таком понятии как сторипойнты/Story Points. Для краткости их буду указывать по тексту как СП.
Я обозвал их изобретением дьявола потому что они обладают специфическими свойствами, которые легко вводят в заблуждение неокрепшие умы. В этой статье я бы хотел немного рассказать про них и развеять несколько мифов.
СП придумал Рон Джеффрис году эдак в 2001 (точных дат нет), затем их популяризировал Майкл Кон в своей книге Agile: оценка и планирование проектов.
Что забавно, изначально в 1 версии гайда (в 2010 году) предполагалось планирование в идеальных человеко-днях.
В покер-пленнинге использует относительный подход, когда собравшимися выбирается единица отсчета, относительно которой оценивают другие рассматриваемые объекты.
Сами по себе СП не являются относительными изначально.
Казалось бы в чем разница между усилиями и трудозатратами?
Но если разбираться чуть дальше, то окажется что СП состоит из 3 измерений, которые нужно держать в голове при оценке:
Очень известный миф, каждый второй ПМ и СМ путаются так делать. Тут есть 3 момента, которые этому помешают:
Если сторипойнты оценки усилий команды для реализации определенного скоупа, то часы это рабочее время, которая затратит команда на реализацию скоупа. Почему-то строится такое выражение: усилия == рабочее время команды.
Есть два различных показателя. Мы не знаем есть ли между ними связь (например, линейная корреляция), поэтому переводить показатели из одного базиса в другой каким-то выдуманным коэффицентом бессмысленно. Даже если связь есть, то нужно найти формулу перевода, а она может не выражаться алгоритмически, просто нет аппроксимирующей кривой или что еще забавнее временные ряды этих показателей могут не сходиться.
Был оценен хвост кота, насколько он пушистый и крепкий. А теперь давайте по хвосту найдем сколько еды ест в неделю такой кот. Перевод теплое в мягкое.
Выбери примерно 100 задач с оценкой в СП, посчитай сколько на каждую задачу ушло времени (не оцени, а именно посчитай, cycle time от старта работы и до конца). Затем посчитай линейный коэффициент Пирсона между оценкой и временем. Если он больше 0.5, построй кривую по оценке и попробуйте ее аппроксимировать другой кривой по методу наименьших квадратов. Это самый простой способ «в лоб».
Каждая команда уникальна и имеет свой набор навыков. У каждой команды свой контекст и своя производственная среда. И дело не в том что они по разному оценивают, а в том что они просто работают по разному.
Даже если стандартизировать их способ мышления при оценке и способ выполнения работы, то ничего не получится. СП применяют для нематериального производство, которое происходит в разумах людей.
И как в поговорке «к сожалению к рукам сотрудника прилагается и остальной человек».
Не нужно оценивать эффективность по количеству СП и тем более сравнивать 2 команды. ты сравниваешь одни уникальные усилия с другими уникальными усилиями. Оценивайте результат.
При оценке СП участвуют все члены команды, каждый высказывают свою оценку сразу целиком по всей задаче. Даже аналитик, хотя он не разработчик и не знает как это точно «закодить».
Работает такая оценка на опыте и СП предполагает именно усилия команды, а не отдельных ее членов.
Рассматривать команду надо не как группу индивидуумов, временно собранных вместе волею судеб, а как нечто неделимое, чёрный ящик, куда можно забросить задание и получить результат.
Что забавно, СП почти никогда не работает в группах людей, которые не понимают смысла работы друг друга и не работают на единой целью.
Вывод проистекает из мифа 5 и мифа 3. У каждой подзадачи будет свой набор рисков и своя сложность. Складывая 1 и 2 яблока ты получишь просто 3 яблока, а не одно большое.
Ну и плюс немного дополнительных умозаключений:
Можно конечно попробовать складывать, но тут опять вылезает миф 3. Не складывается просто сложность и неопределенность.
Также можно посмотреть математически. Является ли базис СП линейным и обладает ли он свойством аддитивности? Можно ли сложить задачу в 3 СП и 2 СП? Полагаю в твоем случае тоже нет).
Представь что виртуальная «емкость усилий» есть у каждой задачи. Представь в виде ведра. Сложив 4 таких задачи ты просто получишь 4 ведра, а не одно большое ведро.
СП необходимы для оценки усилий и дальнейшего выбора в контейнер времени наиболее важных задач (часто такой контейнер называют спринтом).
А штуки нужны для управления потоком и нагрузки на команду. WIP limit, inflow и вот это все.
Из предыдущего мифа следует простой вывод. СП нужны только на коротком промежутке времени и применяются именно для решения «сколько работы уложится в итерацию». После запуска итерации смысл СП исчезает.
Но Майкл Кон так не думает)
Так как оценка СП выражает объем, риски и сложность, то оценивать весь беклог в них и потом использовать на планировании спринта оценку в СП, которую поставили полгода назад бессмысленно. Даже если объем работы не поменялся, то изменилась сложность (люди не стоят на месте, они развиваются или деградируют + меняется состав команды) + могла изменится неопределенность (какие-то риски ушли, какие-то появились).
Также с точки зрения математики расчет среднего значения по несколькими спринтам есть довольно странное упражнение, которое называют velocity. По распределению скорее всего среднее находится левее медианы, так как подвержено выбросам. То есть вероятность велосити это даже меньше чем «50/50, или сделаем или нет».
Итог: сферический спринт в вакууме стоил 16 сторипоинтов в феврале и 19 в марте.
Так вам эта информация исключительно чтобы понимать сколько усилий вы приложили тогда то и тогда то. Аппроксимировать всего 2 точки не получится.
СП влияют на прогнозирование ваших усилий и выбор задач в спринт, вам мало?)
Владельцы кошельков смогут только оплачивать покупки и штрафы, а также выводить деньги на собственную карту.
Обдумывая стори поинты
Мне нравится говорить, что я, возможно, изобрел стори поинты (story points) и если действительно изобрел, то сегодня мне жаль. Давайте рассмотрим подробнее, что я думаю о стори поинтах сейчас. По крайней мере один из нас точно заинтересован в моих мыслях.
Идея историй (stories) конечно же пришла из XP, а не из Scrum. Неким образом скрам-практики адаптировали эту идею в свою работу. Хотя официальный скрам-гайд говорит лишь об элементах бэклога (backlog items), использовать пользовательские истории в качестве элементов бэклога – очень распространенная в скраме практика.
Распространенная – хотя бы до той степени, в которой скрам-практики понимают истории. Ранее я уже писал о том, как правильно использовать пользовательские истории. Здесь мы обсудим стори поинты.
В экстремальном программировании (ХР), истории изначально оценивались во времени: времени, которое потребуется на завершение разработки истории. Мы быстро начали использовать то, что сейчас называется “идеальные дни”, которые неофициально означали “сколько дней потребуется паре до завершения, если их наконец-таки оставят в покое”. Мы перемножали идеальные дни и “фактор нагрузки”, чтобы получить реальное время до завершения разработки. Фактор нагрузки обычно составлял примерно три: три реальных дня тратилось, чтобы завершить работу одного идеального дня.
Мы называли наши оценки в днях, и обычно не произносили слово “идеальные” вслух. По этой причине, наши стейкхолдеры часто не могли понять, каким образом нам нужно три дня, чтобы завершить работу одного дня, или, с другой стороны, почему мы не могли выполнить 50 “дней” работы за три недели.
Так что, насколько я помню, мы начали называть наши “идеальные дни” обычными “поинтами”. Таким образом, оценка в три стори поинта означала, что историю завершат примерно за 9 дней. Так или иначе, мы использовали поинты только чтобы понять, какой объем работы мы можем взять в итерацию, поэтому когда мы говорили что это примерно 20 поинтов, никто особо не возражал.
Возможно это я предложил изменить название. Если я действительно сделал это, сейчас мне жаль. Вот некоторые из моих нынешних соображений на эту тему. Я писал их своему коллеге Саймону, который спросил:
Ты действительно сожалеешь, что стори поинты были изобретены, или ты просто осуждаешь их неправильное использование, когда люди не полностью понимают относительные размеры?
Сравнение
В первую очередь, даже если команды “почти одинаковые”, у каждой из них есть собственный набор компетенций и своя рабочая среда. Так что если они посмотрят на две истории, которые выглядят одинаково и одна команда скажет, что это двойка, а другая скажет, что это шестерка – это попросту бесполезная информация. И это точно не самый полезный способ сравнения команд.
Теперь попробуем разобраться в ситуации. Сначала посмотрим, а действительно ли обе ситуации сравнения были идентичными, а потом уточним, быть может команд с более высокой оценкой нуждалась в помощи, которую мы могли предоставить. Такой подход был бы отличным примером. Явно или неявно выносить вердикт, что “более медленная” команда неким образом хуже или менее профессиональна – вот это стало бы очень плохим примером, который в реальности, к сожалению, является нормой.
Я думаю, что когда есть две команды, производящие ценность, для менеджеров сравнить их – непреодолимое искушение. Я думаю, что оно настолько непреодолимое, что я готов отказаться от идеи стори поинтов и даже всей концепции оценки историй, где это возможно. Мы еще вернемся к вопросу как работать с меньшим количеством оценок. Кроме того, на эту тему есть другие статьи.
Отслеживание
Для многих менеджеров существование оценки подразумевает существование “реальных трудозатрат”, а значит нужно сравнить оценку и реальные трудозаты и убедиться, что они совпадают. Если не совпадают – значит нужно учиться оценивать лучше.
Для меня важная черта Реального Agile – выбрать несколько вещей в работу, а потом оперативно их сделать. Ключевой вопрос – это как найти самые ценные вещи и как сделать их быстро. Сделать быстро обычно превращается в поставку маленьких кусочков ценности и динамичное итерирование. Оценка стоимости историй не особо в этом помогает, если вообще помогает.
Так что если существование оценки заставляет менеджмент сместить фокус с поставки ценности на улучшение процесса оценки, значит оно забирает внимание с настоящей цели – быстро доставлять реальную ценность.
Из-за этого я прихожу к мысли о том, что оценок, будь то в поинтах или времени, стоит избегать.
Давление
Близко к отношениям оценок и реальных трудозатрат находится закономерное давление из-за желания менеджмента получить “больше”. Сколько бы команда ни поставила ценности, этого мало. Нужно больше, больше, больше.
Лучший способ поставлять ценность – это не больше, больше, больше. Лучший способ – это поставлять ценность часто и маленькими партиями. Если вместо оценивания историй мы поделим их на “достаточно маленькие” кусочки, тогда мы сможем прийти к равномерному потоку поставки ценности, доставляя без перерывов.
Фокусировка на “больше” мешает увеличению ценности. Продавливание увеличенных поставок практически без вариантов приводит к плохому результату: команда пытается ускориться и делает это в ущерб качеству кода или тестированию. Вскоре они начинают поставлять больше дефектов, замедляются из-за увеличенного количества переделок чтобы починить дефекты, замедляются еще сильнее из-за того что качество кода стремительно ухудшается. Положение становится хуже и хуже, давление увеличивается и всё превращается в погоню за провальными ситуациями.
Поскольку оценки связаны с применением чрезмерного давления, я предпочитаю избегать их.
Я скажу больше: я предпочитаю вовсе отказываться от планирования спринтов или итераций. Мы работаем не для того, чтобы освоить бюджет предстоящих недель: мы работаем, чтобы составить короткий список важных вещей для ближайшей поставки.
Предсказывая готовность
Обычная практика – составить список необходимых фич, обдумать их и решить, что они составят следующий релиз нашего продукта. Конечно же, следующий вопрос – “когда всё это будет готово?”.
Ответ на него – никто не знает. Мы можем проделать большую работу над своим незнанием. Иногда этим действительно стоит заняться, например, когда на кону большой контракт, ожидающий оценки. Однако, когда мы работаем в сфере разработки решений для внутренних или внешних заказчиков, лучший вариант – поставлять небольшое количество ценности очень часто, а не ждать монструозных релизов, которые бесконечно отодвигаются на потом.
Намного лучше выбрать для следующего релиза недалёкую дату и включить в этот релиз максимальное количество ценности. Оценка мешает этой задаче, будь она в стори поинтах, Мишках Гамми или даже времени. Если оценки возможно избежать, по моему мнению, надо это сделать.
Декомпозиция
Появляется вопрос, если мне не нравится оценка историй, то что же мне нравится? Отвечаю – мне нравится декомпозиция историй. Это практика нарезания больших историй на маленькие кусочки. Главное – чтобы эти маленькие части несли как можно больше ценности, но требовали минимум времени на реализацию – в идеале, меньше дня или всего пару часов.
Я не буду препираться с читателями на тему оценивания в процессе декомпозиции. Если ваша команда в тайне проводит оценку и никому об этом не говорить – тогда проблем с этой оценкой скорее всего не возникнет, в стори поинтах она или во времени. И конечно же, знать разницу между “наверное достаточно маленькая” и “наверное недостаточно маленькая” и знать как различаются “три дня” и “один день” – это совершенно непохожие вещи.
Кроме того, есть одна хитрость. Я упоминал ее в Getting Small Stories и в Slicing, Estimating, Trimming. Я выучил ее у Нила Киллика (Neil Killick): декомпозируйте истории, пока они не станут размером с один приемочный тест. После небольшой тренировки, ваши истории станут самого подходящего размера.
Конечно же, на тему оценки есть много других статей. Просто пройдите по ссылке, которую я оставил выше – там больше информации, чем вы можете представить.
Предсказывая будущее
Но … разве не существует вполне закономерной необходимости знать, сколько займет релиз продукта, и разве не нужно для этого оценивать? Возможно оценка и нужна, только не оценка историй. Вероятно, у вас даже не будет требований, проработанных до уровня историй. А если и будут – то наверняка они получатся громоздкими и в основном бесполезными.
Конечно же, если оценки нужно делать, то нужно их делать. То, что я делаю или как я представляю, что вам нужно делать – это всё мои теории. В конце концов – вам решать, как действовать, чтобы достичь успеха в вашей конкретной ситуации. Тем не менее, я думаю, что есть более хороший путь.
Во-первых, подумайте о нескольких самых важных качествах следующего релиза. Обсудите проблемы, которые они решают и как ваше ПО может помочь решить эти проблемы. Обсудите простейшие решения, которые могут хотя бы немного помочь. Нам не нужно решать сразу всё: зачастую, даже небольшая помощь может привести всё в движение.
Во-вторых, подумайте о ближайшем дедлайне, к которому вы могли бы поставить что-то из хороших решений. Установите этот дедлайн и приступайте к работе.
В-третьих, декомпозируйте важные решения на маленькие части и реализуйте их. Наверняка у вас легко получится сделать эти части размером в один день, или меньше. Работайте только над самыми важными частями: не пытайтесь реализовать все решение до упора. Ваша цель – начать думать в ключе “Если мы сделаем вот эту небольшую функцию, то наш Пользователь Джек уже сможет этим пользоваться”. Потом завершите эту функцию и дайте Пользователю Джеку попробовать. Наша цель – максимально приблизиться к непрерывной поставке ценности. И делать это нужно быстро.
Нам важно сделать поставляемую ценность настолько осязаемой, чтобы наш Владелец Продукта или другие стейкхолдеры спешили поскорее вывести это в релиз. Тогда … тогда мы будем на правильном пути, с оценкой историй или без нее.
Подытожим
Что ж, если я и изобрел стори поинты, наверное, мне немного жаль. Но не сильно жаль. Я действительно думаю, что их часто используют неправильно и мы избежим многих проблем, если вообще откажемся от оценок историй. Если в вашей компании стори поинты не несут ценности – я бы предложил от них отказаться, потому что это пустая трата усилий. С другой стороны, если они вам очень нравятся, то, что ж, полный вперёд!
За перевод огромное спасибо Максиму Фролову.
Оценка требований в Scrum
Я расскажу о оценке работ(estimation) в скрам. Её рекомендуется проводить дважды — сначала в story points, на уровне user stories, а потом — в часах, на уровне заданий в текущей итерации. Так же я попытаюсь объяснить, почему это делается дважды.
У нас в компании решили более серьёзно отнестись к введению Agile принципов, а конкрентей — Scrum. Мне поручили внедрить это дело в небольшой проект, который должен быть готов к сентябрю, с 4 программистами и веб-дизайнером. Задача проекта — миграция html-сайта в Sharepoint 2010, и добавление многих новых функций.
Раньше мы как-то считали, что утренний Scrum митинг — это уже вполне такой нормальный скрам. Но, немного почитав и поковырявшись, оказалось, что в общем-то не совсем.
Итак, первоначальная оценка — guesstimate
Первоначальная оценка проекта производиться на уровне user stories которые находятся в Product Backlog. User stories рекомендуется писать в слегка незграбной, с первого взгляда, манере:
«Как [тип пользователя] я хочу [выполнить действие] чтобы [причина]» (As a [type of user] I want [some goal] so that [some reason]).
Например, вместо привычного «Студент должен иметь возможность выбрать желаемый курс» — «Как студент, я хочу выбрать желаемый курс чтобы получить нужные знания». С одной стороны, звучит очень искусственно, но с другой — и программист, и представитель бизнеса понимают, кто, что и зачем хочет сделать. В коротком предложении есть контекст, роль, действие и цель, всегда в той же самой структуре. Удобно. Хоть и непривычно.
Мой бэклог состоит из 40 историй такого уровня. Это — недостаточно детальные требования, чтоб произвести точные оценки, но кое-что можно сделать — оценить бэк-лог в story points.
Что такое story points? Это относительная оценка каждой истории. Теория предлагает использовать степень двойки для оценки( 2, 4, 8. ) или ряд Фибоначчи (1, 2, 3, 5, 8. ).
Для того, чтобы оценить, надо сначала выбрать систему, и максимальное значение. Мы решили использовать Фибоначчи, с максимальным значением 21.
Дальше, надо выбрать самую простую историю и оценить её как 1. В нашем случае это история — «Как пользователь, я хочу просмотреть информацию о тренерах, чтобы знать их компетенцию». После этого выбираем самую сложную историю, и оцениваем её как максимум, в нашем случае — 21. Это история «Как подписчик, я хочу заказать курс, чтобы я мог его посетить».
После этого теория предлагает оценить остальные требования, в порядке приоритета. Для этого можно использовать технику типа «Покер планирования» (Planning poker), где каждый программист пишет на листке свою оценку требования, а потом все одновременно показывают, и начинается обсуждение, если оценки сильно разные.
Оценивать весь бэклог не обязательно — достаточно оценить только истории на несколько итераций вперёд. Кроме того, к этой оценке надо будет возвращаться, потому что бэклог постоянно пополняется, меняются приоритеты.
Так почему же story points, а не дни?
Во-первых, на этом этапе не достаточно много известно о требованиях, чтобы провести точное планирование.
Во-вторых, программисты не захотят оценивать такие требования по времени, потому что вы их потом припомните… Им легче ответить вопрос «Настолько это большое?» чем «сколько это займёт?»
В-третьих, в нашем случае команда не знакома с технологией (Sharepoint только вышел), и точных оценок дать просто невозможно.
Во-первых, product owner может пересмотреть свои приоритеты. Раз история А «стоит» 13 очков, а Б всего лишь 2 — давайте сделаем её скорей.
Во-вторых, это помогает планированию. Если мы знаем, что в первом спринте мы сделали 50 story points, во втором — 55, то в третьем наверно тоже сделаем каких 55.
В-третьих, это проще. «А» сложнее «Б», поэтому 21.
А что дальше? Где нормальные цифры?
Обычные человеко-часы начинаются позже.
Первый спринт самый сложный, особенно у нас — с новой командой, новой технологией и новой методологией. Вместе с product owner мы опредилили 9 историй для первой итерации.
Для точной оценки мы сели с самым опытным программистом, и учитывая отсутствие опыта у остальных, провели оценку. По-нормальному и тут надо было в покер играть, но ситуация не та.
Чтобы получить точные оценки, каждую историю надо разбить на задания. Каждое задание должно быть не более 8 часов, чтобы за день было понятно, сделано оно или нет. Мы разбили наши истории на 2-10 заданий, примерно такого рода «Построить UI для страницы тренеров», «Подготовить список тренеров» и т.д. Оценили каждую в часах, и получилось… Что нам надо раза в 3 больше времени! Пришлось уменьшить бэклог итерации.
В итоге мы получили, что в первой итерации мы можем закончить 67 story points. Это — 105 часов работы. То есть, сейчас скорость нашей команды — 67 story points за итерацию. По мере того, как команда ознакомится с новой технолонией, скорость вырастет, и в следующем спринте мы сможем разработать больше story points. Используя оценку в часах, это было бы невозможно, или надо было бы выдумывать какие-то формулы, типа там, «в каждой последующей итерации мы спланируем на 10% больше чем в прошлой».
Story Points — оценка задач и планирование разработки продуктов
Что такое Story Points? Как оценить задачи для разработчиков? Как спланировать дорожную карту?
Story Points или сторипоинты — это бальная система оценки задач и планирования проектов в разработке.
У меня ушло около 10 лет практики руководства командами разработки на то чтобы понять что это и почему это важно.
Вводные
Первое что стоит понять, что сторипониты это не совсем оценка времени. Это скорее бальная оценка задач.
Она частично связана с трудоемкостью, но лишь отчасти.
Если проводить аналогию, то можно взять Шкалу Бофорта из метеорологии.
Там скорость ветра привязывается к баллам. Тоже самое следует делать в разработке — привязать оценку трудоемкости в идеальных днях к баллам или сторипоинтам.
Почему так надо делать? Чтобы что? Это сложные вопросы, на которые попробуем ответить ближе к концу статьи.
Почему проектные подходы ломаются в разработке?
Многие начинающие руководители в разработке пытаются оценивать сроки по задачам или разработчикам. Как это принято делать в старых проектных подходах.
Они просят разработчика оценить сроки по задаче. Это последствия слабого опыта в управлении разработкой.
Важно понять что оценка сроков по задачам и разработчикам — не работает, если вы разрабатываете что то более менее сложное или менее предсказуемое чем сложное.
Что значит менее предсказуемое чем сложное? Ответ на этот вопрос можно узнать если ознакомиться с моделью Киневина.
Сложные системы — это не так уж сложно 🙂 Большинство разработок с кодом — заметно отличаются в методах планирования. Системы типа Хаос или Запутанные — управляются иначе чем Сложные системы. Важно это понять. Модель Киневина — хорошо помогает понять в чем отличие.
Ключевые отличия планирования сроков по задачам и по итерациям
В старых проектных подходах было принято оценивать сроки так:
В подходах на основе Agile, Scrum, Kanban, оценка происходит иначе. Сильно иначе.
Там оценка идет по другим аспектам:
Важно понять что оценка сроков в Agile требует иных навыков и понятий:
Как быть? Что нужно уяснить?
Что такое баллы или сторипоинты?
Вот мы и подбираемся к ключевой идее. Почему нужно использовать баллы вместо трудоемкости или сроков по задачам?
Во первых стоит понять что такое баллы (сторипоинты) и как они связаны с идеальными днями?
В таблице ниже можно понять соотношение идеальных дней и баллов:
Эта таблица похожа на Шкалу Бофорта, только вместо скорости ветра тут идеальные дни, а вместо баллов Бофорта тут баллы истории или сторипоинты.
Важно оценить каждую историю по баллам. Сколько баллов у истории?
Если история слишком крупная — ее надо разбить на более мелкие истории.
Истории могут объединяться в темы (themes) или эпопеи (эпики, epics). Более подробно можно прочитать в книге “Agile: оценка и планирование проектов”.
Как планировать итерации?
Итерации Agile в Scrum принято называть спринтами (sprint).
Итерации обычно бывают на 1 месяц или на 2 недели.
В некоторых случаях применяются квартальные или годовые итерации.
Бывают применяют недельные итерации. Но обычно это про карго-культ, а не про разработку и agile. Могут быть исключения. Если речь идет про очень простые продукты и задачи.
Мы берем список историй, и пытаемся понять сколько из них влезут в следующий спринт или месяц?
Например сколько мы можем сделать историй в августе?
Ответ на этот вопрос не так прост и с ходу не дается.
Что такое скорость и вместимость?
Что такое скорость? Еще ее называют велосити (velocity).
Это то сколько баллов удалось закрыть в прошлых итерациях. Обычно берется 2–4 прошедшие итерации. Если мы за итерацию берем месяц, то речь идет про прошедшие 2–4 месяца. Так мы поймем скорость.
Средняя скорость команды в баллах и есть вместимость 1 итерации.
Предположим что у вас в команде 3 разработчика. А итерация равна 1 месяцу. Идеальную скорость мы можем посчитать через идеальные дни — 20 идеальных дней в месяце, на 3 разработчика — это 60 идеальных дней или 60 баллов — вместимость итерации.
Беда в том что идеальная скорость и вместимость — не достижимы.
Через 2–4 итерации вы узнаете что ваша скорость или вместимость равна в лучшем случае 30–40 баллов. Если все плохо то может быть 20–30 баллов. Если совсем плохо то 10–20 баллов.
Почему идеальная скорость отличается от реальной?
Тут играет куча факторов, которые снижают эффективность команды:
Почему сторипониты это не про идеальные дни?
Причина очень простая. Если слабому менеджеру сказать что сторипоинты это про идеальные дни, то он попытается оценить всех кто в команде. Он будет оценивать тестировщиков, аналитиков и всех кто есть в команде. А это тупиковый путь.
Суть в том что ключевое отличие в принципе оценки по бутылочному горлышку.
Что есть бутылочное горлышко чаще всего? Это программисты. Потому оценка сторипоинтов идет по программистам. Идеальные дни с точки зрения программистов. Сколько там займется времени по задачам у тестировщиков или аналитиков в большинстве случаев не имеет значения.
Хотя я видел ситуации когда мы упирались в тестировщиках. В этом случае было бы лучше оценивать задачи с точки зрения идеальных дней у тестировщиков. Но объяснить это команде было очень сложно. Потому продолжали оценивать как получится. Но это исключительные и очень редкие ситуации.
Потому в большинстве случаев мы просто оцениваем идеальные дни с точки зрения программистов, потому что именно они обычно бывают узким горлышком.
Это еще добавляет сюрпризов с точки зрения подсчета скорости и вместимости.
Но если все сделать правильно, то в конечном итоге скорость и вместимость становятся достаточно понятными, предсказуемыми и позволяют оценивать реальные сроки.
Что такое дорожная карта и Kanban доска?
Важно отличать Канбан доску от Дорожной карты.
Важно еще уметь применять оба инструмента. Это не так просто.
Подробнее про эти понятия можно почитать тут:
А можно без сторипоинтов?
А оно нам надо? Хороший вопрос 🙂 Этот подход далеко не единственный и далеко не всем командам он подходит.
Этот подход хорошо работает в следующих ситуациях:
Когда это все нафиг не надо?
Например если вы работаете над b2c продуктом, у вас 1 000 000 пользователей и все хорошо. Вы просто выкатываете то что выкатываете когда получится. Обычно там лучше применять Agile, Kanban & OKR.
Сторипоинты, короткие итерации, капасити и велосити в этом случае будут излишним усложнением. Конечно могут быть исключения.
Про карго-культ
Многие команды заявляют что используют Scrum или Agile. Но на деле там Срам, Ад-айл и Карго-культ )
Как отличить карго-культ? Какие ошибки часто встречаются?
Сроки спрашиваются по задачам и разработчикам
Руководство говорит о том что мы про Agile & Scrum, но сроки просит называть по разработчика и по задачам 🙂 Также пытаются оценивать метрики эффективности по каждому разработчику — это не про Agile и не про Scrum.
Путают итерацию (спринт) и этап проекта
Вот мы запланировали в итерацию 7 историй, но не успели сделать 2 истории. Давайте продлим срок итерации )) Это тоже карго культ. Итерация — это не этап проекта. У итерации срок не может сдвигаться. Итерация кончилась — посчитали скорость. Если надо — перепланировали следующую итерацию — пляшем дальше.
Отсутствует подсчет скорости
Итерации заканчиваются, а какая скорость получилась — никто не считает. В этом случае итерации бесполезны. Но кого это волнует в карго-культе? )
Ретроспектива не делается или делается в стиле “что было прикольно? а что плохо?”
Типа вот мы кофемашину в офисе поставили — это прикольно. А работы было много — это фигово.
Ретроспектива должна делаться на основе плана историй и итераций. Вот запланировали на итерацию 10 историй, 8 успели, а 2 нет. 8 успели — это круто. А 2 не успели — почему?
Может быть планирование было сделано плохо, или реальную скорость не учли? Или просто эффективный менеджер занимается очковтирательством, пытается показать свою амбициозность перед старшими и загоняет команду в не реальные планы?
В общем есть много различных признаков карго-культа, когда говорят правильные слова, но по факту занимаются имитацией бурной деятельности. Не дай бог попасть в такую команду )
Итого
Давайте подобьем итоги:
Если чего то не поняли — пишите вопросы в комментах. Разберемся)