Как реализовать Scrum за 10 шагов. Шаг второй. Как оценивать ваш Product Backlog.

В первом шаге (первой статье этой серии) было описано, «как содержать Product Backlog в порядке». Если вы прошли первый шаг, примите наши поздравления, это был самый сложный шаг, фундаментальный для всех последующих, несмотря на то, реализовали ли вы Scrum или нет!

Если вы не завершили первый шаг,  мы вам не рекомендуем изучать остальные.

Итак, начинаем Шаг №2: Как оценить Product Backlog…

Высокоуровневые оценки

Для того, чтобы получить информацию о размере вашего Product Backlog, вам необходимо предоставить некоторые начальные высокоуровневые оценки.

Эти оценки полезны потому, что помогают понять приоритеты, значимость и полезность этих фич, а с точки зрения руководства, даёт видение, насколько большой должна быть команда, коммерческое разрешение.

Но, пока что, на данном этапе вы мало знаете о пунктах в Product Backlog. У Вас нет чёткого понимания, для чего предназначены фичи. Вы не знаете, что нужно, чтобы завершить задачи, а также вы не знаете, как вы будете их реализовывать.

И так, Вам нужно выполнить самый верхний  уровень, сверху вниз, индикативную оценку. По факту, это “Guestimate” (оценка, базирующаяся на приблизительных и неокончательных данных, или ограниченном опыте). То есть и не оценка вовсе.

Сколько раз вы слышали “не волнуйся, я не заставлю тебя придерживаться этой оценки; Мне всего лишь нужна примерная прикидка”? И конечно же, они заставляют вас придерживаться её. Заставляют ведь!

Оценивайте Product Backlog в единицах

Ответ: Оценивайте свой product backlog в единицах, но не в единицах времени.

Повторите: Оценивайте свой product backlog в единицах, но не в единицах времени.

Нет-нет, я не сошел с ума. Я знаю, это звучит немного странно. Но я хочу попросить вас довериться мне в этом, так как этому действительно есть свои основания, некоторые из которых прояснятся  позже, в последующих выпусках.

Тем временем, я прошу вас согласиться, что команды разработчиков более охотно могут дать приближенные оценки ‘порядка’, не давая оценку в единицах времени, к которому они могли бы привязаться, и без наличия всех грязных деталей.

И так, мы не спрашиваем команду “Сколько это займет времени?” Мы спрашиваем “На сколько большой этот проект?”

Я также прошу вас согласиться, что Владельцы продуктов более склонны принять такую оценку как оценку порядка -  чем она и является – а не принимать её как необдуманное обязательство.

Теперь я понимаю, что единицы оценки могут показаться бесполезными для Владельца продукта с точки зрения создания экономического обоснования для финансирования. Конечно, до тех пор, пока команда имеет список, и мы только примерно знаем, сколько единиц она, как правило, доставляет за итерацию. Но я вернусь к этому позже. Конечно же, такие приблизительные оценки по-прежнему ценные для определения приоритетов, и могут объяснить Владельцу продукта относительный размер фич.

Используйте систему единиц

И так, какую размерность вы будете использовать для вашей системы единиц?

Лично мне нравятся Числа Фибоначчи.

Для умных людей, нажмите на ссылку выше, чтобы понять, что такое Числа Фибоначчи. Для людей попроще, таких, как я : это простая последовательность чисел, в которых очень старые и умные люди (в основном, как всегда, итальянцы), нашли слегка жуткий, но очень научный смысл. И этот смысл имеет отношение к физике и законам распределения.

Более подробное описание чисел Фибоначчи действительно выходит за рамки этой статьи, но они предоставляют собой знаменательную последовательность чисел, где каждое число является суммой двух предыдущих. Например:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987 ...

Для простоты, во время использования этих чисел для обозначения размера, я бы порекомендовал вам использовать числа из диапазона 1-21. Конечно же, для исправления багов и улучшений продуктов в цикле BAU (Business As Usual), у вас будет обоснованный диапазон. Можно взять с запасом 987 для глупых запросов, которые вы иногда получаете, например, слетать на луну и обратно в коробке из-под мороженного

Ключевое слово здесь – относительность.

Каждый пункт бэклога описывает фичу. Например, это отчет. Вы делали подобные отчеты раньше, но в этой фиче имеется некоторая сложность с форматом данных, таким образом, вы решаете присвоить оценку 3.

Следующим по бэклогу идет другой отчет. Вы оцениваете этот отчет относительно другого, больше ли он, или меньше. Несомненно, 21 – на много больше, а 2 – немного меньше, и так далее.

Чтобы убедиться, что эта шкала приносит вам пользу, я предлагаю вам начать с определения того, что вы считаете самой маленькой частью в бэклоге. Присвойте этому пункту 1. Потом найдите пункт, который вы считаете самым большим в бэклоге. Присвойте ему 21.

Теперь у вас есть свои маркеры, размер бэклога, работающий сверху, с использованием чисел Фибоначчи.

Когда вы продвигаетесь вниз по бэклогу, вы достигнете места, где пункты действительно довольно нечетки и с довольно низким приоритетом. На самом деле вы не уверены, что когда-нибудь доберетесь до них в своей жизни.  Пожалуйста, не думайте, что вы должны измерить весь бэклог! Оценивайте только такое количество пунктов, чтобы было возможно увидеть себя в обозримом будущем. Помните, что пункты расположены в порядке приоритетности. Так что убедитесь, что работаете с ними сверху.

Оценивайте, как Команда

Измеряйте ваш бэклог как команда. Существует целая философия о Мудрости Толп. Две головы лучше, чем одна, и так далее. Если у вас есть большие сомнения по этому поводу, можете подискутировать на эту тему, чтобы выяснить, почему. Мог ли один  человек видеть проблемы и сложности, которых другой человек не видел? Видел ли один человек хороший и простой подход, которого не видели другие?

Обсудите игру в Planning Poker. Это забавная методика, которая гарантирует, что люди не влияют друг на друга. Каждый участник команды пишет свою оценку на карточке, и все вскрывают карты в одно время. Такой подход помогает гарантировать, что менее опытные члены команды одинаково вовлечены и не находятся под влиянием более опытных членов команды. Также эта игра помогает менее опытным оценщикам учиться у других, а также позволяет избежать влияния «красноречивости» людей на результат.

И так, договаривайтесь о размере каждого пункта в бэклоге как команда.

Пересматривайте приоритеты

Как только вы оценили весь бэклог (или достаточную часть), попросите Владельца продукта еще раз взглянуть на приоритеты. Возможно сейчас, увидев относительный размер фич, которые запросил, он сможет изменить свой взгляд на приоритеты. “Вау, если эта фича 21, я бы предпочел другую вместо неё”, или “Если это всего-лишь 2, давайте сделаем её в следующем релизе”. Если какие-нибудь приоритеты меняются, просто переместите пункт в другое место, чтобы упорядочить бэклог по приоритетности.

Палка с программой

Боритесь с желанием, адаптировать этот шаг. В книге Кена Швебера “Agile Software Development with Scrum” (которая, кстати, очень рекомендуется к прочтению), говорится: “Если Вы еще не являетесь экспертом в предмете (читать Scrum), не пытайтесь адаптировать его. Scrum – адаптивный процесс. Но у вас нет никаких шансов адаптировать его, пока Вы не узнаете его хорошо, и не испытаете его в действии”.

Оценивая Product Backlog единицами, я бы призвал вас не адаптировать процесс до тех пор, пока вы не испытаете его в течение нескольких итераций, так что начинайте и исследуйте результаты.

Источник: agileguru.ru