Оценка в Agile должна быть полезным процессом, объединяющим команды и облегчающим работу. Тем не менее, вы часто можете обнаружить, что смотрите на задачу или теряетесь в обсуждении с коллегами, задаваясь вопросом, почему оценка кажется такой сложной головоломкой. Стоит ли это усилий? Сможете ли вы когда-нибудь выставить правдивую оценки? Существует ли более эффективный способ?
Когда оценки в Agile проставляются правильно, они не являются абсолютными и не точны до конца. Они представляют собой примерные показатели для команды, которые указывают, сколько работы может включать в себя определенная задача. Используя оценки, вы планируете работу, принимаете решения и способствуете прозрачности.
К концу этой статьи вы узнаете, как превратить оценку в Agile из бесполезной активности в ценный инструмент, который способствует сотрудничеству, планированию и решению проблем. Вот что мы рассмотрим:
Оценка в Agile - это процесс быстрого предсказания объема работы, необходимой для завершения задачи (также известной в кругах Agile как user story). Все члены команды работают вместе, чтобы дать оценки, и использование такого инструмента как покер планирование, помогает им получить достаточно точные результаты без потери времени. Цель оценки в Agile заключается в согласовании команды относительно того, сколько усилий потребуется для завершения задачи, чтобы лучше планировать работу.
Оценки в Agile учитывают такие факторы, как усилия, риск и сложность, а не только продолжительность выполнения. Обычно они относительные, что означает, что команды приходят к ним, сравнивая user story или задачи друг с другом.
Давайте сравним обувь. Вы не можете точно определить размер обуви, просто посмотрев на нее. Для этого требуется больше усилий и рулетка. Но вы можете видеть, что одна пара обуви примерно вдвое больше другой. Именно то, что команды делают во время оценки в Agile, и обычно это достаточно для их нужд, поскольку оценки не обязательно должны быть на 100% точными.
Команды в Agile оценивают работы для улучшения согласованности команды, лучшего понимания задач, более эффективного совместного взаимодействия и улучшения планирования. Цель оценки в Agile - не точность, а приемлемая точность для планов, принятия решений и обсуждений.
Многие команды оценивают работы для того, чтобы стимулировать дискуссии. Эти дискуссии важнее, чем просто определение абстрактной оценки.
Когда команда смотрит на что-то вместе и принимает решение, что это такое, они достигают общего понимания. Если оценки значительно различаются между членами команды, это может вызвать вопросы и обсуждения. Разногласия указывают на то, что элемент требует большего внимания для выявления сложности, неопределенности или риска.
Совместная работа требует планирования. Когда два или более человека хотят достичь цели вместе, им необходимо согласовать, кто будет делать что и, как правило, до какого времени.
Является ли это большим или маленьким делом? Требуется ли для этого программирование или дизайн? Когда программа готова, чтобы начать дизайн? Когда клиент сможет его использовать?
Планы различаются по масштабу. Некоторые из них могут быть небольшими, как быстрый разговор между двумя людьми. Другие - это многомесячные усилия, например, когда команда из сотен человек готовится строить небоскреб.
Независимо от размера плана, необходимо оценить объем работы. Команда Scrum должна определить, сколько работы включить в спринт. Продажи должны установить цену на то, что они продают. Руководители проектов нуждаются в графиках для заинтересованных сторон.
Оценки используются для планирования, помогая командам согласовываться, преодолевать препятствия и достигать успеха.
Без оценок сложно определить приоритеты задач. Ожидаемое время или усилия, необходимые для завершения чего-либо, обычно играют важную роль при принятии решения о том, работать ли над этим сейчас, позже или вообще не заниматься этим.
Представьте, что у вас есть две задачи, над которыми вы можете работать дальше:
Подводя итог, задача А займет шесть месяцев, а задача Б - всего одну неделю, поэтому, вероятно, вы отдали бы предпочтение задаче Б.
Этот пример утрирован, но он показывает, что без оценок сложно определить приоритеты, если и вовсе невозможно. И такое установление приоритетов происходит повсюду и всегда, будь то руководители, определяющие стратегию компании на следующий год, или отдельные лица, выбирающие, над какой задачей из своего списка дел им следует работать следующей.
Хотя последнее издание Scrum Guide не включает слово "оценка", и оценка или покер планирование не являются официальными событиями Scrum, форма оценки часто происходит во многих командах Scrum.
В руководстве подчеркивается, что команды должны знать, сколько работы они могут выполнить в спринте. Оно также упоминает "размерность", которая является формой оценки.
“Разработчики, которые будут выполнять работу, отвечают за ее оценку. Процесс уточнения бэклога продукта — это деятельность, направленная на разбиение и дополнительное определение элементов бэклога на более мелкие и точные элементы. Это постоянное действие по добавлению деталей, таких как описание, порядок и размер. Разработчики, которые будут выполнять работу, несут ответственность за размеры. ”
— Scrum Guide 2020 года
В книге "Applying Scrum With Kanban" автор и тренер по Agile Энди Хайлс выделяет три вопроса, которые часто задают стейхолдеры:
Без оценок сложно дать ответы на эти вопросы. Однако стоит помнить, что оценки не являются точными и могут изменяться по мере поступления дополнительных данных. Поэтому будьте осторожны при даче строгих обязательств.
Вместо этого рассмотрите возможность дать оценку вероятности, оставляющую пространство для неожиданных затруднений или сложностей.
Команды Agile оценивают работу в начале спринта, во время планирования спринта или в рамках отдельного процесса грумминга задач. Некоторые команды Scrum используют свои оценки для контроля прогресса достижения цели спринта во время дейли.
Существует много способов сделать оценку эффективной, например покер планирование, с использованием последовательности Фибоначчи. Независимо от методов или инструментов, все члены команды должны участвовать в оценке, при этом именно команда разработчиков, а не владелец продукта или скрам мастер, дает окончательные оценки.
Цель оценки всегда одна и та же, независимо от выбранного метода. Однако выбор подхода может привести к разным типам обсуждений и результатам, поэтому полезно понимать, когда использовать каждый метод.
Вот некоторые популярные методы оценки, которые вы можете попробовать с вашей командой:
Метод оценки по размеру футболки представляет собой высокоуровневый подход, при котором используются размеры футболок (XS, S, M, L и XL) для приближенной оценки пользовательских историй. Это один из самых простых методов оценки, потому что шкала проста и понятна для всех.
Когда использовать: Оценка размером футболки полезна, когда вам нужно быстро отсеять слишком большие истории, чтобы разбить их на более мелкие.
Спринт-покер, также известный как покер планирование, позволяет командам проводить точную оценку, способствуя детальному обсуждению задач. Этот метод дает вам число, которое можно преобразовать в часы, если вам это потребуется, в отличие от оценки по размеру футболки.
В покер планировании, каждый участник оценивает объем работы, необходимый для выполнения задачи, играя картами с разными значениями из специальной колоды. После того, как все сыграли свои карты, следует обсуждение оценок, чтобы команда согласовала усилия, необходимые для выполнения работы.
Когда использовать: Покер планирование эффективно для детального обсуждения ограниченного количества историй и предотвращает привязку к исходным оценкам и групповое мышление.
👉️ Попробуйте спринт-покер в Retrius
Метод трех точек предполагает создание трех оценок для каждого рабочего элемента на основе трех разных сценариев: наилучший случай, наихудший случай и наиболее вероятный. Комбинируя эти оценки, можно рассчитать более точную оценку для истории или задачи.
Когда использовать: Метод трех точек помогает командам провести мини-премортем своего спринта, рассматривая наилучший и наихудший сценарии заранее. Этот подход также хорошо работает, если вы склонны быть чрезмерно оптимистичными.
Движение "#NoEstimates" побуждает избегать оценок вообще. В этом движении считают, что оценка - это пустая трата времени, потому что большинство современных работ непредсказуемы. Тем не менее, команды, следующие подходу "#NoEstimates", все равно проводят некоторую оценку и планирование, так как они обычно применяют некоторые из следующих практик:
Когда использовать: Маленькие команды с небольшим количеством внутренних и внешних зависимостей, и готовым клиентом, могут воспользоваться подходом "#NoEstimates". Вы все равно получите довольно точную картину того, что вы можете реализовать в каждом спринте или итерации, экономя время на оценке и планировании.
Единицы и шкалы оценок измеряют и выражают размер, усилия, риски или сложность элемента работы. Когда команды используют их последовательно, их оценки становятся более точными, и снижается вероятность недоразумений.
Существуют три типа единиц, которые используются командами Agile для оценки работ:
Использование альтернативных шкал вместо стандартных 1, 2, 3, 4 и т. д. может ускорить процесс оценки, особенно для более крупных и сложных задач.
Предположим, что ваша команда должна оценить усилия, необходимые для выполнения большого элемента, например, добавления новой функции в ваше приложение. Если вы используете стандартную шкалу и обсуждаете задачу с участниками команды, один выбирает 31, другой 36, а третий 38. Несмотря на то, что разница между их оценками незначительна, это может привести к продолжительным обсуждениям.
Альтернативная шкала, например, последовательность Фибоначчи, предотвращает эту проблему, потому что вам нужно выбрать числа с большим расстоянием между ними. В этом примере новой функции нашего приложения все, вероятно, выберут число 34, так как альтернативы будут 21 или 55.
Вот некоторые популярные шкалы оценок:
Оценки не всегда являются идеальными. Они могут вызывать разочарование и трение из-за принужденных обязательств, нереалистичных ожиданий или предвзятых предположений.
Итак, помните о следующих рисках при работе с оценками в Agile:
В любом случае, помните, что, несмотря на все наши действия, мы не можем контролировать будущее, и оценки - это всего лишь оценки.
"Мы относимся к нашим планам, как будто они веревка, брошенная из настоящего в будущее, чтобы привести его под наш контроль. Но план - это всего лишь намерение настоящего момента. Это выражение ваших текущих мыслей о том, как вы хотели бы использовать свое небольшое влияние на будущее. Будущее, конечно же, не обязано соответствовать этому."
— Оливер Беркман в книге "Четыре тысячи недель"
Ниже мы постараемся ответить на некоторые из самых часто задаваемых вопросов об оценках в Agile.
Самый простой способ оценить задачи в Agile — это использовать специальные методы оценки, которые отдают предпочтение скорости и приемлемой точности, а не детализированной и максимально точной оценке. Популярными методами являются: оценка размером футболки, покер планирование и метод оценки по трём точкам. Эти подходы быстро дают командам достаточно точные оценки для планирования, принятия решений и обсуждений.
Например, при использовании оценки размером футболки (T-Shirt Sizing) команды присваивают задачам размеры, такие как XS, S, M, L или XL, сравнивая элементы друг с другом на основе их относительной сложности или требуемых усилий. Затем участники команды обсуждают задачи, в которых их оценки отличаются, чтобы определить окончательный размер каждого элемента.
Относительная оценка сравнивает рабочие элементы друг с другом, тогда как абсолютная оценка пытается определить конкретное и независимое значение для рабочего элемента (задачи). В Agile, команда обычно использует относительную оценку, потому что она более быстрая и эффективная для планирования и проста в обсуждениях. Абсолютная оценка, с другой стороны, требует больше усилий и менее гибкая.
Оценка больше полагается на суждение, а прогнозирование на данные.
При оценке вы прогнозируете длительность, усилия или стоимость проекта или задачи на основе имеющейся информации и опыта. Этот подход включает разбиение проекта или задачи на более мелкие части, выдвижение предположений и использование исторических данных или экспертного мнения для определения разумной оценки.
Прогнозирование означает предсказание будущих результатов или тенденций на основе данных и статистических моделей. Это требует анализа трендов и паттернов в данных, выявления ключевых факторов изменений и прогнозирования будущих результатов на основе этих факторов.
