Роберт Мартин - Чистый Agile. Основы гибкости

Преимущество рядов Фибоначчи в том, что с помощью них можно провести оценку больших историй. Например, вы можете взять 1, 2, 3, 5 и 8, благодаря чему получите восьмикратный размер.

Можно еще взять карты 0, ∞ и?. В способе с пальцами можно вместо этих знаков показать палец вниз, палец вверх и открытую ладонь. Ноль означает «слишком незначительно, чтобы оценивать». С такими историями нужно быть осторожными! Возможно, стоит объединить несколько таких историй в одну побольше. Бесконечность (∞) означает, что история слишком большая, чтобы провести ее оценку, а это значит, что ее нужно разделить. И знак вопроса (?) означает неизвестность — нам не от чего отталкиваться.

Разбиение, слияние и костыли

В слиянии историй нет ничего сложного. Можно просто скрепить карточки вместе и рассматривать эти истории как одну. Просто посчитайте сумму единиц сложности. Если есть истории, оцененные в ноль единиц, хорошо подумайте, как оценить их при сложении. В этом случае пять нолей не могут дать ноль в сумме.

Разбивка историй будет сложнее: нужно сделать так, чтобы истории соответствовали правилам их написания. В качестве простого примера разбиения истории рассмотрим вход . Если мы захотим разбить эту историю на несколько историй поменьше, то можем создать на ее месте вход без пароля, вход с одной попытки, вход с нескольких попыток и забыли пароль? .

История, которую нельзя разбить на несколько, — большая редкость. Особенно это касается тех крупных историй, которые не можно, а нужно разбивать. Помните, что работа программиста заключается в том, чтобы разбивать истории вплоть до отдельных строк кода. Поэтому разбиение возможно почти всегда. Самое сложное — соблюдать правила написания историй.

Костыль — это метаистория, точнее история для оценки истории. Ее называют костылем, так как она напоминает длинный тонкий клин, который пронизывает всю разработку программы насквозь, подпирая другую историю.

Допустим, есть история, которую у вас не получается оценить. Пускай это будет печать PDF . Почему вы не знаете, как ее оценить? Потому что до этого вы никогда не использовали библиотеку PDF и у вас нет точного представления, как она работает. Поэтому вы пишете новую историю, которую называете оценка печати в PDF . Теперь оцениваем уже ее, и ее-то оценить проще. Вы уже знаете, что нужно сделать, чтобы выяснить, как работает библиотека PDF. Обе истории отправляются в кипу с карточками.

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

Управление итерацией

Цель каждой итерации — получение данных посредством выполнения историй. Команде скорее следует сосредоточиться на историях, чем на задачах, которые под ними скрываются. Предпочтительнее выполнить 80 % историй, чем выполнить все истории на 80 %. Сосредоточьтесь на доведении историй до их выполнения.

Как только заканчивается совещание по планированию, программисты должны выбрать истории, за которые будут нести личную ответственность. В некоторых командах выбирают истории, находящиеся сверху, а остальные откладывают на потом, чтобы взяться за них по выполнении выбранных ранее. Как бы то ни было, программисты сами выбирают и выполняют истории.

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

Например:

Джерри (опытный спец):

— Если не возражаете, я возьму на себя вход и выход. Думаю, есть смысл выполнить их вместе.

Жасмин (опытный спец):

— Не вопрос, только почему бы вам вдвоем с Альбертом не взяться за базы данных? Он постоянно расспрашивает, как мы используем источники событий. Мне кажется, что вход даст ему некоторую ясность. Что скажешь, Альберт?

Альберт (стажер):

— О! Звучит круто! Я видел, как это делается. Я даже за выдачу наличных взяться могу!

Алексис (ведущий программист):

— А почему бы мне не взять выдачу наличных? Альберт! Давай ты поработаешь над ней вместе со мной. Потом возьмешь перевод.

Альберт:

— Угу, ладно. Наверное, так будет лучше. Кто сначала перекладывает камешки, потом передвигает горы, ведь так?

Жасмин:

— Ну конечно, Альберт! И остается внесение наличных. Я возьму это на себя. Алексис, мы с тобой в одной упряжке, нам нужно поработать над пользовательским интерфейсом, ведь они у нас, вероятно, мало отличаются. И мы должны иметь возможность делиться кодом.

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

Контроль качества и приемочное тестирование

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

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

Это означает, что за эту итерацию не удастся выполнить все запланированные истории, однако в любом случае без приемочного тестирования ни о каком выполнении не может идти речи. Только убедитесь, что программисты, работающие над какой-либо историей, не пишут приемочные тесты для нее же. Если специалисты по качеству каждый раз не успевают написать тесты к середине итерации, это, вероятнее всего, означает, что соотношение разработчиков и QA-специалистов выбрано неверно.

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

Разработчики и QA-инженеры должны обсудить такие тесты. Мы не хотим, чтобы разработчики молча брали то, что им бросают QA-специалисты. Необходимо обсуждать структуру тестов и писать их сообща, вплоть до парного программирования.