Можно оценивать истории по размерам одежды: большие, средние и маленькие. Если хочется задействовать все пять пальцев, продолжайте. С другой стороны, использование шкалы с большим количеством баллов почти всегда абсурдно. Помните, мы хотим дать достоверную оценку, а не наиболее точную.
Покер планирования[39] — похожий способ, но там нужны карты. Существует много популярных колод карт для такого покера. В большинстве из них применяется что-то вроде рядов Фибоначчи. В одной распространенной колоде содержатся такие карты:? 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 и ∞. Если у вас такая колода, мой совет — уберите оттуда большую часть карт.
Преимущество рядов Фибоначчи в том, что с помощью них можно провести оценку больших историй. Например, вы можете взять 1, 2, 3, 5 и 8, благодаря чему получите восьмикратный размер.
Можно еще взять карты 0, ∞ и?. В способе с пальцами можно вместо этих знаков показать палец вниз, палец вверх и открытую ладонь. Ноль означает «слишком незначительно, чтобы оценивать». С такими историями нужно быть осторожными! Возможно, стоит объединить несколько таких историй в одну побольше. Бесконечность (∞) означает, что история слишком большая, чтобы провести ее оценку, а это значит, что ее нужно разделить. И знак вопроса (?) означает неизвестность — нам не от чего отталкиваться.
Разбиение, слияние и костыли
В слиянии историй нет ничего сложного. Можно просто скрепить карточки вместе и рассматривать эти истории как одну. Просто посчитайте сумму единиц сложности. Если есть истории, оцененные в ноль единиц, хорошо подумайте, как оценить их при сложении. В этом случае пять нолей не могут дать ноль в сумме.
Разбивка историй будет сложнее: нужно сделать так, чтобы истории соответствовали правилам их написания. В качестве простого примера разбиения истории рассмотрим вход. Если мы захотим разбить эту историю на несколько историй поменьше, то можем создать на ее месте вход без пароля, вход с одной попытки, вход с нескольких попыток и забыли пароль?.
История, которую нельзя разбить на несколько, — большая редкость. Особенно это касается тех крупных историй, которые не можно, а нужно разбивать. Помните, что работа программиста заключается в том, чтобы разбивать истории вплоть до отдельных строк кода. Поэтому разбиение возможно почти всегда. Самое сложное — соблюдать правила написания историй.
Костыль — это метаистория, точнее история для оценки истории. Ее называют костылем, так как она напоминает длинный тонкий клин, который пронизывает всю разработку программы насквозь, подпирая другую историю.
Допустим, есть история, которую у вас не получается оценить. Пускай это будет печать PDF. Почему вы не знаете, как ее оценить? Потому что до этого вы никогда не использовали библиотеку PDF и у вас нет точного представления, как она работает. Поэтому вы пишете новую историю, которую называете оценка печати в PDF. Теперь оцениваем уже ее, и ее-то оценить проще. Вы уже знаете, что нужно сделать, чтобы выяснить, как работает библиотека PDF. Обе истории отправляются в кипу с карточками.
На одной из последующих встреч по планированию заинтересованные стороны могут попробовать выбрать карточку печать PDF. Но не тут-то было — костыль встанет им поперек горла. Поэтому придется выбрать карточку с костылем. Это позволит разработчикам выполнить работу, необходимую для оценки первоначальной истории, которую можно провести в одной из следующих итераций.
Управление итерацией
Цель каждой итерации — получение данных посредством выполнения историй. Команде скорее следует сосредоточиться на историях, чем на задачах, которые под ними скрываются. Предпочтительнее выполнить 80 % историй, чем выполнить все истории на 80 %. Сосредоточьтесь на доведении историй до их выполнения.
Как только заканчивается совещание по планированию, программисты должны выбрать истории, за которые будут нести личную ответственность. В некоторых командах выбирают истории, находящиеся сверху, а остальные откладывают на потом, чтобы взяться за них по выполнении выбранных ранее. Как бы то ни было, программисты сами выбирают и выполняют истории.
Менеджеры и лидеры могут поддаться искушению назначать истории программистам. Но этого нужно избегать. Пускай программисты договорятся между собой.
Например:
Джерри (опытный спец):
— Если не возражаете, я возьму на себя вход и выход. Думаю, есть смысл выполнить их вместе.
Жасмин (опытный спец):
— Не вопрос, только почему бы вам вдвоем с Альбертом не взяться за базы данных? Он постоянно расспрашивает, как мы используем источники событий. Мне кажется, что вход даст ему некоторую ясность. Что скажешь, Альберт?
Альберт (стажер):
— О! Звучит круто! Я видел, как это делается. Я даже за выдачу наличных взяться могу!
Алексис (ведущий программист):
— А почему бы мне не взять выдачу наличных? Альберт! Давай ты поработаешь над ней вместе со мной. Потом возьмешь перевод.
Альберт:
— Угу, ладно. Наверное, так будет лучше. Кто сначала перекладывает камешки, потом передвигает горы, ведь так?
Жасмин:
— Ну конечно, Альберт! И остается внесение наличных. Я возьму это на себя. Алексис, мы с тобой в одной упряжке, нам нужно поработать над пользовательским интерфейсом, ведь они у нас, вероятно, мало отличаются. И мы должны иметь возможность делиться кодом.
В этом примере можно увидеть, как ведущий программист направляет новичка, амбициозного стажера, не давая ему взять на себя больше, чем он может, а еще то, как члены команды сообща выбирают себе истории в работу.
Контроль качества и приемочное тестирование
Если QA-специалисты еще не начали писать автоматизированные приемочные тесты, то нужно это делать как можно скорее, прямо после встречи по планированию. Тесты для историй, рассчитанные на быстрое выполнение, должны быть готовы как можно раньше. Не нужно ждать, пока приемочные тесты созреют для выполненных историй.
Приемочные тесты должны появляться быстро. Мы ожидаем, что их полностью напишут еще до середины итерации. Если к середине итерации готовы не все приемочные тесты, кто-то из разработчиков должен бросить работу над историей и помогать писать тесты.
Это означает, что за эту итерацию не удастся выполнить все запланированные истории, однако в любом случае без приемочного тестирования ни о каком выполнении не может идти речи. Только убедитесь, что программисты, работающие над какой-либо историей, не пишут приемочные тесты для нее же. Если специалисты по качеству каждый раз не успевают написать тесты к середине итерации, это, вероятнее всего, означает, что соотношение разработчиков и QA-специалистов выбрано неверно.
Если по достижении середины итерации все приемочные тесты написаны, то QA-специалисты должны приняться за тесты к следующей итерации. Это рискованно, поскольку встреча по планированию еще не состоялась, однако заинтересованные стороны могут дать рекомендации насчет историй, которые они выберут с наибольшей вероятностью.
Разработчики и QA-инженеры должны обсудить такие тесты. Мы не хотим, чтобы разработчики молча брали то, что им бросают QA-специалисты. Необходимо обсуждать структуру тестов и писать их сообща, вплоть до парного программирования.
До середины итерации команде нужно постараться выполнить истории, чтобы успеть к промежуточному совещанию. А до конца итерации разработчикам нужно постараться успеть подвергнуть оставшиеся истории соответствующим приемочным тестам.
Если мы говорим, что история выполнена, то подразумеваем, что она прошла приемочное тестирование.
В последний день итерации разработчикам предстоят муки выбора: какие истории стоит завершить, а от каких придется отказаться? Мы предпочитаем перераспределять усилия. Так получается выполнить столько историй, сколько возможно.
Опять же ни к чему заканчивать итерацию с историями, выполненными лишь наполовину, ведь есть возможность пожертвовать какой-то историей, чтобы полностью выполнить другую.
Здесь не нужна спешка. Нужны конкретные результаты и измеримость хода работ. Нужны надежные данные. Историю можно считать выполненной, когда пройдено приемочное тестирование. Когда программист говорит, что выполнил историю на 90 %, в реальности непонятно, насколько она готова. Поэтому на графике скорости работ стоит отмечать лишь истории, прошедшие приемочное тестирование.
Демонстрация
Каждая итерация заканчивается короткой демонстрацией новых функций заинтересованным сторонам. Такая встреча должна длиться не больше часа или двух, в зависимости от размера итерации. В демо-версии должно быть видно, что истории, в том числе все предшествующие, полностью прошли приемочное и модульное тестирование. Следует также показать свежий функционал, добавленный к программе. Лучше всего, если заинтересованные стороны сами проверяют работоспособность программы, чтобы у разработчиков не было соблазна скрыть то, что не работает.
Скорость
Завершающий аккорд итерации — обновление графика скорости и диаграммы сгорания задач. На графике нужно отмечать единицы только тех историй, которые прошли соответствующие приемочные испытания. После нескольких итераций графики пойдут на спад. Спад диаграммы сгорания задач помогает выявить, какого числа будет достигнута следующая важная веха. График скорости же показывает нам, насколько хорошо организована работа команды.
Во время начальных итераций график скорости будет довольно неточным, так как команда еще толком не разобралась в основах проекта. Но после первых нескольких итераций точность графика возрастет и достигнет уровня, позволяющего четче определить истинную скорость выполнения работ.
Мы ожидаем, что после нескольких первых итераций угол наклона приблизится к нулю, то есть график примет горизонтальный вид. Мы не ждем от команды ускорения или замедления в долгосрочной перспективе.