kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Спринт 9/18: Agile-практики → Тема 5/7: DEEP-критерии бэклога продукта → Урок 1/2
Оценка бэклога продукта
В прошлых уроках вы научились записывать истории, теперь пришло время научиться оценивать их размер.
Оценка
В контексте разработки ПО оценка может определять:
- Срок реализации бэклога продукта.
- Размер работы, необходимой для реализации бэклога продукта.
В каскадной модели разработки ПО команды не оценивают размер бэклога продукта, а сразу называют заказчику оценку срока. Эти оценки связаны, при этом срок реализации бэклога продукта зависит от множества дополнительных факторов. Например, если предоставить выполнение одного и того же бэклога продукта разработчикам с разным опытом, они завершат его в разное время. Ещё сроки реализации проекта зависят от размера команды разработки: команде из пяти человек может понадобиться полгода, тогда как команда из десяти человек может справиться за три месяца.
Представьте, что команде нужно собрать морковь с грядок. Участники команды посмотрели на грядки и сразу сказали заказчику, что на выполнение этой работы им понадобится два дня. В этом случае команда предоставила заказчику оценку сроков.
В гибкой модели команды разработки разделяют оценку размера элементов бэклога продукта и оценку срока их реализации.
Теперь представьте, что команда сначала определила площадь грядок и рассчитала, что десять грядок занимают площадь 20 квадратных метров. В этом случае команда сначала оценила размер.
Затем, чтобы предоставить заказчику срок, команда измерила, сколько времени ей понадобилось на сбор моркови с одного квадратного метра грядки, на погрузку моркови в тележку и раскладывание моркови по коробкам. Определив, что для этого ей нужно 30 минут, команда рассчитывает срок, поделив 20 квадратных метров грядок на 30 минут. Только после этого команда предоставила заказчику оценку срока: 10 часов на сбор моркови.
Таким образом, команда разработки сначала оценивает общий размер элементов бэклога продукта, затем измеряет темп реализации, то есть суммарный размер реализованных за итерацию элементов. Только после этого она делит общий размер элементов бэклога продукта на темп реализации и называет срок реализации всего бэклога продукта.
Подходы к оценке
Оценить размеры элементов бэклога продукта можно с помощью абсолютной или относительной оценки.
Абсолютная оценка
В каскадной модели разработки ПО команды разработки оценивают размер элементов бэклога продукта в абсолютных величинах. Например, это могут быть календарные дни или часы, по истечении которых команда планирует закончить работу.
Представьте мандарин, грейпфрут, дыню и арбуз. Для того чтобы дать абсолютную оценку этим фруктам, мы можем использовать их вес или диаметр.
Например, вес мандарина — 100 грамм, грейпфрута — 200 грамм, дыни — два килограмма, а арбуза — шесть кило. При этом не все одинаковые фрукты имеют одинаковый вес: арбуз может весить как шесть килограмм, так и семь или пять. Если команда разработки использует абсолютные оценки, ей необходимо учитывать эту разницу и присваивать каждому элементу бэклога точную абсолютную оценку.
Используя абсолютную оценку, команда разработки может оценить один элемент бэклога в два часа, другой — в три часа. Элементы бэклога могут быть очень близки по размеру, но они всегда будут иметь разные абсолютные оценки.
Относительная оценка
В гибкой модели разработки ПО команды разработки оценивают размер элементов бэклога продукта, сравнивая их друг с другом. Иными словами, используя относительную оценку.
Относительная оценка отражает размер работы, которую команде разработки необходимо выполнить, чтобы реализовать элемент бэклога продукта.
При использовании относительных оценок у команды разработки нет необходимости точно определять размер каждого элемента бэклога продукта по отдельности. Достаточно сравнить элемент с остальными и определить его относительный размер.
Например, те же мандарин, грейпфрут, дыню и арбуз можно оценить относительно друг друга.
Мандарин — самый маленький из всех фруктов. Грейпфрут примерно в два раза больше мандарина, но меньше дыни и гораздо меньше арбуза. При этом не все арбузы имеют строго одинаковый размер, он может варьироваться в зависимости от сорта или зрелости, но арбуз всегда будет больше мандарина.
Можно выразить относительный размер фруктов в мандаринах, приняв их за единицу измерения для всех остальных фруктов:
- Грейпфрут = 2 мандарина
- Дыня = 4 мандарина
- Арбуз = 8 мандаринов
Во время оценки элементов бэклога команда разработки также сравнивает их между собой. Например, если один из элементов бэклога больше другого примерно в два раза, команда разработки может присвоить меньшему элементу оценку в 1 условную единицу, а большему — 2 условных единицы.
С помощью относительной оценки можно сравнивать и оценивать элементы бэклога продукта, которые не будут идентичны друг другу. Добавим к примеру банан. У него не шарообразная форма в отличие от остальных фруктов. Хотя банан отличается по форме, его всё еще можно сравнить с другими фруктами: банан однозначно меньше дыни, но больше мандарина. Таким образом, банан можно соотнести с грейпфрутом и выразить его размер в 2 мандаринах.
Относительная величина отражает относительный размер работы над элементом бэклога продукта в сравнении с другими элементами. Такая величина не имеет веса сама по себе — то, что принято за единицу измерения в одной команде, не будет работать в другой. Поэтому некорректно сравнивать относительные оценки размера элементов бэклогов продуктов разных команд.
Преимущества относительной оценки
Может показаться, что абсолютная оценка позволяет сделать более точный прогноз. Но есть несколько причин, по которым стоит использовать относительную оценку:
- Команда разработки никогда не сможет заранее дать точную и верную абсолютную оценку размера для элемента бэклога продукта. В процессе работы неизбежно будут появляться новые обстоятельства, а абсолютная оценка будет стремительно терять свою актуальность.
- Людям гораздо проще дать относительную, чем абсолютную оценку. Представьте, что вас просят оценить три расстояния: от вашего дома до ближайшего магазина, от России до Танзании, от Земли до Солнца. Чтобы дать абсолютную оценку, придётся высчитать точное количество километров. В случае относительной оценки достаточно сказать, что расстояние до магазина будет самым маленьким, а вот чтобы добраться до Солнца придётся максимально попотеть. Таким образом, команда разработки будет тратить меньше времени на оценку размера бэклога продукта, используя относительную оценку.
- Невозможно заранее составить безупречный список элементов бэклога. В гибкой модели разработки ПО бэклог продукта постоянно изменяется в соответствии с новой информацией, которую получает команда разработки и другие заинтересованные лица. Используя относительные оценки, команда разработки будет тратить меньше времени впустую: на оценку элементов, которые могут быть удалены из бэклога продукта.
Расставьте электронные устройства в порядке возрастания их относительного размера.
Стиральная машина
4 место
Стиральную машину можно сравнить с пылесосом и холодильником: она явно меньше холодильника, но больше пылесоса.
Утюг
2 место
Утюг больше компьютерной мыши, но меньше пылесоса.
Компьютерная мышь
1 место
Компьютерная мышь имеет самый маленький размер относительно других устройств.
Холодильник
5 место
Холодильник имеет самый большой размер относительно других устройств.
Пылесос
3 место
Размер пылесоса — среднее между утюгом и стиральной машиной.
Story Points
Story Points («баллы истории», сторипоинты) — это единица измерения общего относительного размера элемента бэклога продукта. Сторипоинты выражаются цифрами и числами, например 5 Story Points (5 баллов).
Использовать сторипоинты для оценки размера работы предложил Рон Джеффрис. Он же, как вы помните, придумал сокращение 3С («три си») для составляющих пользовательских историй.
При использовании этой единицы измерения команда разработки присваивает определённое количество Story Points каждому элементу бэклога продукта.
Величина исходных размеров не играет никакой роли. Важны относительные размеры. Элемент, которому присвоено два Story Points, должен быть в два раза больше, чем элемент, которому присвоен один Story Point.
Количество Story Points, присвоенных элементу, представляет общий размер работы над этим элементом. Формулы определения размера не существует — каждая команда сама определяет, как выставлять оценки.
Что влияет на размер работы
Story Points отражают общий размер работы, который необходимо выполнить команде разработки, чтобы реализовать элемент бэклога продукта. Размер в Story Points — это сочетание:
- количества работы,
- сложности работы,
- рисков и неопределённости, присущих этой работе.
Чтобы оценить размер элемента бэклога в Story Points, нужно сравнить этот элемент с другим, уже оценённым элементом. При этом сравнивать их нужно по всем трём факторам.
Каждый из факторов сказывается на размере работы, который необходимо выполнить команде, чтобы реализовать элемент бэклога. Чем больше количество работы, которую необходимо выполнить команде, тем выше оценка. Чем выше сложность работы, тем выше оценка. Наличие сопутствующих рисков и неопределённости также повышает оценку элемента бэклога.
Рассмотрим каждый фактор поподробнее.
Количество работы
Чем больше работы требуется выполнить для реализации элемента бэклога продукта, тем больше будет оценка его размера в Story Points.
Например, команде нужно вспахать землю для будущих посевов. Сравним количество работы:
вспахать одну грядку vs. вспахать одно поле.
Суть задачи одинакова — вспахивание земли. Но чтобы вспахать одну грядку, потребуется значительно меньше работы, чем для целого поля.
Представьте, что команде разработки нужно реализовать два экрана. На первый экран нужно добавить одно текстовое поле ввода и его название. На втором экране должны располагаться 100 точно таких же полей. Реализовать второй экран не сложнее, чем первый. На нём просто больше точно таких же полей, а значит, количество работы больше.
Таким образом, второму экрану нужно присвоить больше Story Points. Конечно, не в 100 раз больше, чем первому экрану, ведь часть работы будет одинаковой для обоих экранов. Например, разработчику нужно разработать сам экран, на котором должны располагаться одно или сто полей. Кроме того, скорее всего, после размещения первого поля, разработчику не потребуется много времени для копирования оставшихся 99 полей. Размер работы, связанный со вторым экраном, будет всего лишь в два или в три раза больше, в крайнем случае в десять раз, но никак не в 100 раз.
Сложность работы
Представим, что теперь команде необходимо обработать два поля земли. В этой ситуации количество работы одинаково. Однако команда должна учесть новые обстоятельства:
Вспахать одно поле, усеянное камнями и пнями, vs. вспахать одно чистое поле
В первом случае на пути к достижению цели перед командой лежат камни и пни, которые однозначно усложняют задачу. Команда должна учесть эту сложность в оценке, увеличив количество Story Points.
Представьте, что команде разработки нужно реализовать два экрана с сотней полей ввода на каждом. На первый экран нужно добавить только простые, несвязанные друг с другом текстовые поля ввода. А на втором экране должны быть расположены поля с валидациями и масками ввода. Например, поля для выбора даты и адреса, поля для ввода номера телефона и электронной почты, поле с валидацией номера карты и другие. Ещё второй экран будет включать реализацию связей между полями. Например, экран должен отображать название банка, зашифрованное в введённом пользователем номере карты.
Несмотря на то, что на обеих страницах по 100 полей ввода, реализовать вторую страницу будет труднее. Поля на ней более сложные, при их реализации выше вероятность, что разработчик допустит ошибку. Таким образом, второму экрану нужно присвоить больше Story Points, ведь связанная с ней работа более сложная.
Риски и неопределённость
Перед командой стоит всё та же задача — вспахать поле, но появились новые обстоятельства:
Вспахать одно поле, которое команда уже вспахивала в прошлом году, vs. вспахать одно поле, которое команда никогда не видела.
В первом случае поле уже хорошо знакомо команде, она знает все его нюансы, каждый пень и камень, которые на нём есть. А во втором случае поле для команды — загадка. Она не знает, насколько сложным для вспахивания оно окажется, поэтому может столкнуться со следующими рисками и неопределённостью:
- Поле может быть усеяно деревьями, и команде придётся сначала срубить их и только потом приступать к вспахиванию — риск.
- Команда не может определить, насколько непредсказуемым окажется процесс вспахивания неизвестного ей поля — неопределённость.
И риски, и неопределённости команда разработки обсуждает в процессе оценки. Наличие таких факторов будет увеличивать количество Story Points, присвоенных элементу бэклога продукта.
Например, если заинтересованные лица не уверены в своих ожиданиях от реализации элемента бэклога продукта, то эта неопределённость должна увеличить количество Story Points, присвоенных этому элементу.
Или если реализация элемента потребует изменений в незнакомом для разработчиков программном коде, то соответствующая степень риска должна увеличить количество Story Points, присвоенных этому элементу.
Определение количества и сложности работы не должно зависеть от конкретного исполнителя, который будет заниматься этой работой.
Допустим, в команде разработки есть младший и старший разработчик. Можно предположить, что опытному сотруднику справиться с реализацией гораздо проще, чем новичку. Но этот факт никак не должен влиять на определение оценки размера элемента бэклога продукта.
Перед вами три пары задач, где первая имеет оценку меньше, чем вторая. Определите, что повлияло на увеличение размера одной задачи по сравнению с другой.
Перебраться на другой берег реки Волга по пешеходному мосту. Оценка = 3.
Перебраться на другой берег реки Волга вплавь. Оценка = 5.
сложность работы
Сложность работы
Переплыть реку сложнее, чем перейти её же по пешеходному мосту. Вторая задача получила большую оценку из-за большей сложности работы.
Перебраться на другой берег реки Волга по пешеходному мосту. Оценка = 3.
Перебраться на другой берег реки. Оценка = 5.
риски и неопределённость
В первой задаче мы точно знаем, какую реку и как нам нужно пересечь. Во второй задаче мы не знаем ни того, ни другого. Река из второй задачи может быть гораздо уже Волги, и через неё будет проложен траволатор. А может, это будет река Ла-Плата (самая широкая река в мире), или эту реку можно пересечь только вплавь. Вторая задача получила большую оценку из-за рисков и неопределённости, связанных с работой.
Переплыть реку Волга поперёк. Оценка = 3.
Переплыть реку Волга вдоль. Оценка = 5.
Переплыть реку Волга вдоль. Оценка = 5.
количество работы
Сложность работы в этих задачах одинакова: нужно переплыть реку. Однако длина реки Волга гораздо больше её ширины, поэтому плыть вдоль придётся дольше. Вторая задача получила большую оценку из-за большего количества работы.
Какую шкалу использовать
Шкала оценивания
Чаще всего команды разработки используют следующие две шкалы оценки:
- ряд Фибоначчи,
- простое удвоение.
В основе каждой из этих шкал лежит своя логика.
Ряд Фибоначчи
Ряд Фибоначчи — ряд чисел, в котором каждое последующее число является суммой двух предыдущих: 1, 2, 3, 5, 8, 13, 21, 34, 55 и так далее до бесконечности.
Как правило, команды используют «модифицированную» версию последовательности Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.
В некоторых случаях команды добавляют к своей шкале нулевую оценку. Такая оценка присваивается историям настолько незначительным по размеру, что даже наименьший из возможных Story Points кажется завышенным.
Однако не стоит забывать, что бесплатный сыр бывает только в мышеловке. Если команда разработки принимает решение присваивать нулевые оценки историям, следует внимательно следить за количеством таких историй в бэклоге итерации. Несмотря на свой незначительный размер, масса таких историй может в совокупности дать огромный прирост к количеству усилий, которые придётся потратить на их выполнение.
Причина популярности этой последовательности среди команд разработки — постепенно прогрессирующее увеличение чисел. Чем больше размер работы, тем с меньшей точностью человек способен её оценить, поэтому постепенно возрастающие порядки чисел как нельзя лучше соответствуют этой особенности.
Проценты иллюстрируют, как при использовании ряда Фибоначчи увеличивается относительный размер элементов бэклога в зависимости от оценки. Так, размер элемента бэклога с оценкой в 5 Story Points примерно на 67% больше размера элемента бэклога, оценённого в 3 Story Points.
Если команда оценивает историю в 8 и более Story Points, ей стоит задуматься о необходимости вертикально декомпозировать такую историю.
Простое удвоение
Похожим образом работает простое удвоение, когда каждое следующее число в последовательности в два раза больше предыдущего, например: 1, 2, 4, 8, 16, 32.
В этом случае прогрессия чисел на увеличение идёт значительно активнее, чем в последовательности Фибоначчи.
Это не всегда соответствует темпу роста рисков и неопределённостей, связанных с размером работы. Поэтому команды разработки выбирают шкалу оценок, ориентируясь на особенности своей работы.
Процесс оценки
Теперь, когда вы разобрались с понятием Story Points и выделили его составляющие, вам осталось только присвоить нужное значение каждого элемента.
Оценка в Story Points всегда проводится с участием всей команды разработки. Каждый из членов команды выдвигает своё предположение о размере работы над элементом бэклога, основываясь на объёме и сложности задачи, а также учитывая риски и неопределённость.
В процессе оценки предположения разных членов команды могут отличаться друг от друга. Представим, что половина участников предложила оценку «3», а другая половина оценку «5». Самое важное — не усреднять оценку и не записывать «4». Разница в оценках может быть сигналом о том, что не все поняли размер работы или кто-то заметил обстоятельства, которые не видны остальным. В таком случае следует дать каждому члену команды возможность высказаться и обосновать своё мнение, после чего снова предложить свои оценки.
Оценку в Story Points можно представить в виде шкалы, которая отражает возрастающий размер работы, и команда разработки пытается найти место на этой шкале для каждого элемента бэклога продукта.
В зависимости от того, использовала ли ранее команда разработки Story Points для оценки, существует два подхода, которые могут помочь ей при оценке.
Команда оценивает бэклог продукта в первый раз
Если оценка проводится в первый раз, то определить относительную оценку размера элемента бэклога продукта на данном этапе не представляется возможным: ни один из элементов бэклога продукта ещё не оценён. В таком случае рекомендуется взять приблизительно средний по размеру элемент среди прочих и присвоить ему среднее значение из выбранной шкалы Story Points.
Например, команда разработки решила использовать для оценки ряд Фибоначчи. Тогда среднему элементу она может присвоить 4 Story Points. Предположим, что следующий элемент оказался явно меньше. Сравнив его со средним, команда может предположить, что он примерно в два раза меньше первого, и присвоить ему оценку 2 Story Points. И так далее.
Таким образом, после нескольких оценённых элементов бэклога продукта команда сможет сформировать общее понимание шкалы оценок в Story Points.
Команда оценивает бэклог продукта в течение проекта
Если команда уже проводила оценку, то каждый новый элемент бэклога продукта будет оцениваться относительно ранее оценённых. Причём лучше работает не поиск похожих по размеру элементов и присвоение аналогичной оценки, а сравнение оцениваемого элемента с несколькими другими. Такой метод называется триангуляцией. Его суть заключается в сравнении оцениваемого элемента бэклога с двумя другими: меньшего и большего размера.
Например, команде разработки необходимо оценить новую пользовательскую историю. Внимательно посмотрев на неё, команда понимает, что её размер явно больше размера дефекта с оценкой 1 Story Point, но меньше, чем пользовательская история с оценкой в 3 Story Points. Таким образом, команда может оценить новую пользовательскую историю в 2 Story Points.
Сравнение оценок разных команд разработки
Представим две разные команды разработки, которые используют Story Points для оценки элементов своих бэклогов продуктов. У каждой из этих команд есть по одной истории с оценкой 1 Story Point. Эти истории имеют одинаковые оценки, но они не будут иметь одинаковый размер относительно друг друга, потому что их оценивали разные команды относительно разных историй: первая команда относительно своих, а вторая команда относительно других.
Скорость команды разработки
В гибкой модели команда включает в бэклог только те элементы, которые предполагает реализовать во время итерации. Чтобы определить, что войдёт в бэклог итерации, необходимо оценить каждый элемент. Для этого команда учитывает темп реализации элементов бэклога продукта за каждую итерацию.
Сумма всех Story Points, присвоенных каждому элементу бэклога продукта, которую команда разработки реализовала в течение итерации, называется скоростью (velocity). Например, если она реализует десять элементов, каждый из которых оценивается в 3 Story Points, то её скорость будет равна 30.
Если команда разработки выполнила работу размером 30 Story Points в течение предыдущей итерации, то она может предположить, что в следующей итерации она также выполнит работу размером 30 Story Points.
Скорость может быть фактическая и прогнозируемая.
Фактическая скорость отражает размер всех элементов бэклога продукта (функций, дефектов, технической работы и работы для получения знаний), которые команда разработки успела реализовать за итерацию.
Прогнозируемая скорость отражает предположение команды разработки о том, сколько элементов бэклога продукта она успеет реализовать в будущей итерации.
Начиная новую итерацию, команда разработки прогнозирует её скорость на основе фактических скоростей нескольких прошлых итераций. Поэтому важно фиксировать фактическую скорость после каждой итерации.
Команда разработки не может включить элемент в бэклог без оценки, так как без оценки невозможно спрогнозировать скорость реализации.
Прогноз скорости будущей итерации важен не только команде, но и всем заинтересованным лицам. Они должны иметь возможность планировать свою работу с учётом прогноза команды разработки.
Например, в будущей итерации команда планирует автоматизировать формирование выписки по счёту. Руководство банка ожидает, что функция будет реализована в срок, поэтому может начать:
- Перенаправлять сотрудников, которые раньше формировали выписки вручную, на другую работу внутри банка.
- Готовить рекламные материалы об этой функции для клиентов.
- Обновлять базу знаний службы поддержки клиентов.
Вам даны различные животные и необходимо дать оценку в Story Points каждому из них.
Размером в данном случае будет являться высота животного, а в качестве шкалы оценки используется модифицированный ряд Фибоначчи до 8: 1, 2, 3, 5, 8.
Подсказка: попробуйте начать с определения среднего по размеру животного и присвоить ему среднюю оценку (3).
Кошка
2
Кошка явно выше мыши и ежа, но ниже собаки (хаски). Поэтому её оценка будет между ними (2).
Мышь
1
Мышь — одно из самых низких животных из примера. Можно смело присваивать ему наименьшее значение (1).
Ёж
1
Ёж — одно из самых низких животных из примера. Можно смело присваивать ему наименьшее значение (1).
Собака (хаски)
3
Хаски явно выше кошки и курицы, но ниже лошади или медведя. Поэтому её оценка будет между ними (3).
Курица
2
Курица явно выше мыши и ежа, но ниже собаки (хаски). Поэтому её оценка будет между ними (2).
Слон
8
Слон — самое высокое животное из примера. Можно смело присваивать ему наибольшее значение (8).
Лошадь
5
Лошадь явно выше собаки (хаски), но ниже слона. Поэтому её оценка будет между ними (5).
Медведь
5
Медведь явно выше собаки (хаски), но ниже слона. Поэтому его оценка будет между ними (5).
Подведём итоги
Присваивание оценок — это обязательный шаг в процессе составления бэклога продукта команды разработки.
Одним из способов определения и отображения размеров элементов бэклога продукта является использование Story Points, или баллов истории. Эта оценка является относительной величиной, отражающей количество усилий, необходимых для реализации элемента бэклога продукта.
Размер в Story Points это сочетание:
- количества требуемой работы,
- сложности работы,
- рисков и неопределённостей, связанных с работой.
Чаще всего команды разработки используют для оценки две шкалы:
- модифицированный ряд Фибоначчи: 0, 1, 2, 3, 5, 8,
- простое удвоение: 1, 2, 4, 8, 16, 32.
Основные правила при проведении оценки историй в Story Points:
- Оценка не зависит от уровня профессиональных навыков конкретного члена команды разработки.
- Оценка осуществляется всей командой разработки. В случае различных оценок среди членов команды оценка не усредняется, а уточняется путем дискуссий и аргументации внутри команды разработки.
- Оценка определяется относительно других историй, например, методом триангуляции.
Системный аналитик участвует в оценке элементов бэклога продукта вместе с остальными членами команды разработки. Часто системный аналитик выступает источником информации о деталях будущей работы и может поделиться ею с командой во время определения размера элементов бэклога продукта.
Чат поддержки