Agile: оценка и планирование проектов - [29]

Используя сайт SwimStats в качестве примера, сначала кратко рассмотрим ситуацию, в которой переоценка не требуется. Предположим, что у нас есть истории, представленные в табл. 7.1. В первой итерации реализуются первые две истории. Команду это не устраивает, поскольку она считает, что должна реализовывать в два раза больше пунктов (12 вместо шести) за итерацию. Она считает, что каждая из реализованных историй была в два раза больше или сложнее, чем казалось вначале, и именно поэтому на них потребовалось в два раза больше времени, чем предполагалось. Команда принимает решение удвоить количество пунктов, связанных с каждой историей. В результате скорость становится равной 12 (две истории по шесть пунктов), что более приемлемо для команды.

До начала проекта, однако, команда сочла все четыре истории в табл. 7.1 равными по размеру и сложности и оценила каждую в три пункта. Поскольку команда по-прежнему считает эти истории равноценными, оценки историй 3 и 4 также необходимо удвоить. Команда увеличивает количество получаемых пунктов за реализованные истории, а это, в свою очередь, приводит к удвоению скорости. Вместе с тем из-за того, что она также удваивает количество оставшейся работы в проекте, ее положение остается таким же, как если бы она оставила оценку равной трем, а скорость — шести.

Скорость — великий уравнитель

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

Рассмотрим другой пример. Предположим, что проект состоит из 50 пользовательских историй, каждая из которых оценена в один пункт. Для простоты будем считать, что я — единственное лицо, работающее над этим проектом, и что я реализую одну историю размером один пункт за рабочий день. Таким образом, за двухнедельную итерацию я предполагаю реализовать 10 историй и добиться скорости, равной 10. Кроме этого, я рассчитываю завершить проект за пять итераций (10 недель). За первую итерацию, однако, мне удалось реализовать не 10, а только пять историй. Если с учетом скорости, которая оказалась в два раза ниже планируемой, скорректировать мое ошибочное представление, то на проект потребуется 10 итераций.

Посмотрим, что произойдет, если провести переоценку. Допустим, я переоцениваю пять реализованных историй и присваиваю каждой из них оценку «два». Моя скорость теперь составляет 10 (пять реализованных историй, каждая по два пункта), а объем оставшейся работы — 45 пунктов. При скорости 10 и оставшихся 45 пунктах я рассчитываю завершить проект за 4,5 итерации. Проблема здесь состоит в смешивании пересмотренной и первоначальной оценок. Я задним числом переоценил реализованные истории и назначил каждой два пункта. К сожалению, глядя на оставшиеся 45 историй, я не могу предсказать, какие из этих однопунктовых историй мне захочется переоценить задним числом в два пункта.

Когда выполнять переоценку

Продолжим работать с сайтом SwimStats, в этот раз пользовательские истории и оценки приведены в табл. 7.2.

Первые три истории связаны с построением графика для пользователя. Допустим, команда запланировала включить в первую итерацию истории 1, 2 и 6 из табл. 7.2. Ее плановая скорость составляет 13. Однако к концу итерации она реализовала только истории 1 и 6. По словам членов команды, они сделали меньше предполагаемого потому, что история 1 оказалась значительно более трудоемкой, чем ожидалось, и должна оцениваться «как минимум в шесть пунктов». Предположим, что команда недооценила не одну историю, а трудоемкость построения графиков в целом. В этом случае, если история 1 оказалась в два раза более трудоемкой, чем ожидалось, мы должны быть готовы повысить также и трудоемкость историй 2 и 3.

Рассмотрим три сценария развития событий.

Сценарий 1: переоценка не производится

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

Сценарий 2: производится переоценка завершенной истории

Посмотрим, поможет ли переоценка одной лишь истории 1 устранить проблему. После завершения итерации команда понимает, что история 1 оказалась в два раза более трудоемкой, чем ожидалось первоначально. Поэтому она принимает решение повысить оценку этой истории до шести. Это означает, что скорость в предыдущей итерации составила 11 — шесть пунктов для истории 1 и пять пунктов для истории 6.