Оценка требований в 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 не успели — почему?
Может быть планирование было сделано плохо, или реальную скорость не учли? Или просто эффективный менеджер занимается очковтирательством, пытается показать свою амбициозность перед старшими и загоняет команду в не реальные планы?
В общем есть много различных признаков карго-культа, когда говорят правильные слова, но по факту занимаются имитацией бурной деятельности. Не дай бог попасть в такую команду )
Итого
Давайте подобьем итоги:
Если чего то не поняли — пишите вопросы в комментах. Разберемся)
Оценка задач в 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 спринта оценки могут не соответствовать полученным результатам, помните про эксперимент. Проводите ретро и обсуждайте с командой почему результат показал отклонение от первоначальных ожиданий, с помощью чего его можно улучшить, что необходимо предусмотреть.
Большое спасибо, что вы дочитали до конца! Я очень надеюсь, что мне удалось донести смысл оценочной системы и привести примеры ее работы. Буду рад и благодарен за любые комментарии или критику в свой адрес.