Майк Кон - Agile: оценка и планирование проектов

Существует два общепринятых подхода к оценке размера в пунктах. Первый заключается в выборе наименьшей истории среди тех, с которыми вы будете работать, и присвоении ей размера, равного одному пункту. Второй предполагает выбор истории среднего размера и присвоение ей значения из середины того диапазона пунктов, который вы будете использовать. Я лично предпочитаю использовать диапазон от 1 до 10. (Причина этого объясняется в главе 6 «Методы оценки».) Иначе говоря, я выбираю историю среднего размера и присваиваю ей значение 5 пунктов. После того как вы произвольным образом установили количество пунктов для первой истории, каждая последующая история оценивается относительно первой или любой другой уже оцененной истории.

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

• лабрадор-ретривер;

• терьер;

• немецкий дог;

• пудель;

• такса;

• немецкая овчарка;

• сенбернар;

• бульдог.

Прежде чем читать дальше, прикиньте, сколько пунктов вы бы присвоили каждой породе. Если проделать это, то наши последующие рассуждения станут понятнее.

Мои оценки приведены в табл. 4.1. Я присваивал эти значения, начиная с лабрадора-ретривера. Размер собак этой породы, на мой взгляд, можно отнести к среднему, поэтому я присвоил им значение 5. Немецкий дог будет, пожалуй, в два раза выше, поэтому он получает 10. Сенбернар значительно выше лабрадора, но чуть ниже дога — он получает 9. Такса по росту самая маленькая и больше чем на 1 не тянет. Бульдог повыше, но тоже не вышел ростом, поэтому я даю ему 3. Если бы я присваивал пункты по весу собак, то бульдог получил бы больше.

Agile-проект нередко начинается с итерации с неполным набором требований, детали которых выясняются в процессе работы. Так или иначе, нам нужно дать оценку всем историям, в том числе и тем, которые сформулированы нечетко. Вы уже видели, как это делается на примере присвоения пунктов пуделю и терьеру. Без дополнительной информации оценить их было бы трудно. Как известно, есть карликовые, средние и стандартные пудели и все они разного размера. Аналогичным образом терьеры — это группа, включающая в себя более двух десятков пород. Одни терьеры (белый высокогорный терьер, норвич-терьер, норфолкский терьер) имеют в холке менее 30 см, а другие (эрдельтерьер) — почти 60 см.

Когда вам дают свободно изложенную пользовательскую историю (или описание собаки), вы делаете определенные допущения, строите предположения и принимаете решение. В табл. 4.1 я выдвинул предположения в отношении терьера и пуделя и присвоил им по 3 пункта. По моему разумению, даже самые крупные из них меньше лабрадора-ретривера, а самые мелкие не заслуживают больше 1–2 пунктов. Поэтому среднее значение, равное 3, выглядит довольно правдоподобным.

Чтобы понять, в чем польза оценки в безразмерных пунктах, введем новое понятие — «скорость». Скорость — это показатель темпа продвижения команды. Для ее определения суммируют количество пунктов, присвоенных каждой пользовательской истории, которую команда реализовала в течение итерации [3] Такого определения в данный момент достаточно. В следующей главе мы будем говорить об идее оценки в идеальных днях как об альтернативе оценки в пунктах. Команда, которая осуществляет оценку в идеальных днях, определяет скорость как сумму оценок реализованных историй в идеальных днях. . Если команда реализует три истории, каждая из которых оценивается в 5 пунктов, то ее скорость равна 15, а если две истории по 5 пунктов — 10.

Если команда выполнила работу объемом 10 пунктов в течение предыдущей итерации, то мы можем предположить, что она выполнит работу объемом 10 пунктов и в течение текущей итерации. Поскольку пункты характеризуют относительный размер, такое предположение будет справедливым, если команда реализует и две истории по 5 пунктов, и пять историй по 2 пункта.

Во введении к настоящей части этой книги модель, представленная на рис. 4.1, использовалась для демонстрации того, как оценку размера превратить в оценку срока и календарный график. Здесь мы ее приводим, чтобы показать, как она сочетается с пунктами и скоростью.

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

Ключевой момент agile-подхода к оценке и планированию заключается в том, что мы оцениваем размер и определяем на его основе срок. Предположим, что мы оценили все пользовательские истории и сумма этих оценок составила 100 пунктов. Это расчетный размер системы. Допустим, из прошлого опыта нам известно, что скорость команды составляет 10 пунктов за двухнедельную итерацию и что команда обеспечит такую же скорость в данном проекте. Зная расчетный размер и нашу скорость, мы можем определить срок выполнения 10 итераций — 20 недель. Отсчитаем 20 недель в календаре и получим календарный график.

Это предельно упрощенное объяснение процедуры планирования релиза. Мы рассмотрим ее более подробно в части IV «Составление календарных графиков». Кроме того, данный пример такой простой по той причине, что мы использовали прошлую скорость команды. Это не всегда возможно — иногда приходится оценивать саму скорость. Определение скорости может оказаться сложным делом, однако существуют определенные методы расчета, помогающие найти ее. Мы рассмотрим их в главе 16 «Оценка скорости».

К счастью, как только команда начинает продвигаться в реализации проекта, первые несколько итераций наглядно демонстрируют ее скорость. Прелесть использования пунктов для оценки размера заключается в том, что ошибки планирования автоматически корректируются в результате применения показателя скорости. Предположим, что команда оценивает размер проекта в 200 пунктов. Первоначально она исходит из того, что сможет выполнять 25 пунктов за итерацию и, таким образом, завершит проект за восемь итераций. Однако с началом работ выясняется, что фактическая скорость составляет всего 20 пунктов. Без переоценки каких-либо работ команда безошибочно определяет, что для выполнения проекта потребуются 10 итераций, а не восемь.