Файл: Роберт мартин.pdf

Глава 3. Методы взаимодействия с клиентами
122
История «программа должна быть быстрой» не поддается оценке, потому что быстрота не имеет предела . Это сопутствующее требо- вание, которое относится ко всем историям .
z
Компактность (Small) . Пользовательская история должна быть небольшой, чтобы один-два разработчика смогли с ней справиться за одну итерацию .
Не нужно, чтобы одна история огромным одеялом накрывала всю команду в течение целой итерации . Желательно, чтобы в итерации было примерно то же количество историй, что и разработчиков в команде . Если в команде 8 разработчиков, нужно подбирать от
6 до 12 историй для каждой итерации . Вы ведь не хотите завязнуть на одном этапе, верно? Это скорее совет, чем правило .
z
Тестируемость (Testable) . Клиенты должны четко назвать те- сты, позволяющие подтвердить, что история выполнена .
Как правило, эти тесты пишут QA-специалисты . Тесты должны быть автоматизированы, с их помощью выполняется проверка историй на завершенность . Подробнее об этом вы узнаете позже .
А пока что не забывайте, что каждая история должна быть до- статочно конкретной, чтобы можно было подобрать необходимые тесты .
Но, может, это идет вразрез с принципом обсуждаемости? Нет, потому что когда мы пишем историю, то не обязаны знать, какие тесты нужны . Когда возникнет необходимость, тогда и будет написан тест . Хотя я еще не знаю всех нюансов истории вход, я уверен, что ее можно протестировать, потому что вход — это конкретное действие . А теперь посмотрим на историю пригод-
ный к эксплуатации . Ее никак не протестируешь . И даже никак не оценишь . Действительно, прогнозируемость и тестируемость идут рука об руку .

Планирование
123
Оценка историй
Существует множество способов оценки историй . Большинство из них — разновидности подхода Wideband Delphi
1
Один из простейших способов — оценка на пальцах . Разработчики сидят вокруг стола, вчитываются в историю и, если необходимо, обсуждают ее с заинтересованной стороной . Потом разработчики прячут одну руку за спину так, чтобы никто не мог ее увидеть, сги- бают пальцы так, чтобы по пальцам можно было понять, сколько единиц сложности требуется, по их мнению, затратить на выполне- ние истории . После этого кто-нибудь начинает счет, и на счет «три» все одновременно достают руки с зажатыми пальцами из-за спины .
Если все показали одинаковое число пальцев либо отклонение не- велико и в среднем все показывают одно и то же, то число записы- вается на карточке с историей, а команда переходит к следующей истории . Но если между участниками встречи есть значительные разногласия, то разработчики обсуждают причину и повторяют действия до тех пор, пока согласие не будет достигнуто .
Можно оценивать истории по размерам одежды: большие, средние и маленькие . Если хочется задействовать все пять пальцев, про- должайте . С другой стороны, использование шкалы с большим количеством баллов почти всегда абсурдно . Помните, мы хотим дать достоверную оценку, а не наиболее точную .
Покер планирования
2
— похожий способ, но там нужны карты .
Существует много популярных колод карт для такого покера .
1
https://en.wikipedia.org/wiki/Wideband_delphi.
2
Grenning J. W . 2002 . Planning Poker, or How to avoid analysis paralysis while release planning . URL: https://wingman-sw.com/articles/planning-poker.

Глава 3. Методы взаимодействия с клиентами
124
В большинстве из них применяется что-то вроде рядов Фибоначчи .
В одной распространенной колоде содержатся такие карты: ?, 0,
½,
1, 2, 3, 5, 8, 13, 20, 40, 100 и ∞ . Если у вас такая колода, мой совет — уберите оттуда большую часть карт .
Преимущество рядов Фибоначчи в том, что с помощью них можно провести оценку больших историй . Например, вы можете взять 1,
2, 3, 5 и 8, благодаря чему получите восьмикратный размер .
Можно еще взять карты 0, ∞ и ? . В способе с пальцами можно вместо этих знаков показать палец вниз, палец вверх и откры- тую ладонь . Ноль означает «слишком незначительно, чтобы оценивать» . С такими историями нужно быть осторожными!
Возможно, стоит объединить несколько таких историй в одну побольше . Бесконечность (∞) означает, что история слишком большая, чтобы провести ее оценку, а это значит, что ее нужно разделить . И знак вопроса (?) означает неизвестность — нам не от чего отталкиваться .
Разбиение, слияние и костыли
В слиянии историй нет ничего сложного . Можно просто скрепить карточки вместе и рассматривать эти истории как одну . Просто по- считайте сумму единиц сложности . Если есть истории, оцененные в ноль единиц, хорошо подумайте, как оценить их при сложении .
В этом случае пять нолей не могут дать ноль в сумме .
Разбивка историй будет сложнее: нужно сделать так, чтобы исто- рии соответствовали правилам их написания . В качестве простого примера разбиения истории рассмотрим вход . Если мы захотим разбить эту историю на несколько историй поменьше, то можем создать на ее месте вход без пароля, вход с одной попытки, вход
с нескольких попыток и забыли пароль? .

Планирование
125
История, которую нельзя разбить на несколько, — большая ред- кость . Особенно это касается тех крупных историй, которые не можно, а нужно разбивать . Помните, что работа программиста заключается в том, чтобы разбивать истории вплоть до отдельных строк кода . Поэтому разбиение возможно почти всегда . Самое сложное — соблюдать правила написания историй .
Костыль — это метаистория, точнее история для оценки истории .
Ее называют костылем, так как она напоминает длинный тонкий клин, который пронизывает всю разработку программы насквозь, подпирая другую историю .
Допустим, есть история, которую у вас не получается оценить . Пу- скай это будет печать PDF . Почему вы не знаете, как ее оценить?
Потому что до этого вы никогда не использовали библиотеку PDF и у вас нет точного представления, как она работает . Поэтому вы пишете новую историю, которую называете оценка печати в PDF .
Теперь оцениваем уже ее, и ее-то оценить проще . Вы уже знаете, что нужно сделать, чтобы выяснить, как работает библиотека PDF .
Обе истории отправляются в кипу с карточками .
На одной из последующих встреч по планированию заинтересован- ные стороны могут попробовать выбрать карточку печать PDF . Но не тут-то было — костыль встанет им поперек горла . Поэтому при- дется выбрать карточку с костылем . Это позволит разработчикам выполнить работу, необходимую для оценки первоначальной исто- рии, которую можно провести в одной из следующих итераций .
Управление итерацией
Цель каждой итерации — получение данных посредством вы- полнения историй . Команде скорее следует сосредоточиться на

Глава 3. Методы взаимодействия с клиентами
126
историях, чем на задачах, которые под ними скрываются . Предпо- чтительнее выполнить 80 % историй, чем выполнить все истории на 80 % . Сосредоточьтесь на доведении историй до их выполнения .
Как только заканчивается совещание по планированию, програм- мисты должны выбрать истории, за которые будут нести личную ответственность . В некоторых командах выбирают истории, нахо- дящиеся сверху, а остальные откладывают на потом, чтобы взяться за них по выполнении выбранных ранее . Как бы то ни было, про- граммисты сами выбирают и выполняют истории .
Менеджеры и лидеры могут поддаться искушению назначать истории программистам . Но этого нужно избегать . Пускай про- граммисты договорятся между собой .
Например:
Джерри (опытный спец):
— Если не возражаете, я возьму на себя вход и выход. Думаю,
есть смысл выполнить их вместе.
Жасмин (опытный спец):
— Не вопрос, только почему бы вам вдвоем с Альбертом не взять-
ся за базы данных? Он постоянно расспрашивает, как мы ис-
пользуем источники событий. Мне кажется, что вход даст ему
некоторую ясность. Что скажешь, Альберт?
Альберт (стажер):
— О! Звучит круто! Я видел, как это делается. Я даже за выдачу
наличных взяться могу!
Алексис (ведущий программист):
— А почему бы мне не взять выдачу наличных? Альберт! Давай ты
поработаешь над ней вместе со мной. Потом возьмешь перевод.

Планирование
127
Альберт:
— Угу, ладно. Наверное, так будет лучше. Кто сначала перекла-
дывает камешки, потом передвигает горы, ведь так?
Жасмин:
— Ну конечно, Альберт! И остается внесение наличных. Я возьму
это на себя. Алексис, мы с тобой в одной упряжке, нам нужно
поработать над пользовательским интерфейсом, ведь они у нас,
вероятно, мало отличаются. И мы должны иметь возможность
делиться кодом.
В этом примере можно увидеть, как ведущий программист на- правляет новичка, амбициозного стажера, не давая ему взять на себя больше, чем он может, а еще то, как члены команды сообща выбирают себе истории в работу .
Контроль качества и приемочное тестирование
Если QA-специалисты еще не начали писать автоматизированные приемочные тесты, то нужно это делать как можно скорее, прямо после встречи по планированию . Тесты для историй, рассчитанные на быстрое выполнение, должны быть готовы как можно раньше .
Не нужно ждать, пока приемочные тесты созреют для выполнен- ных историй .
Приемочные тесты должны появляться быстро . Мы ожидаем, что их полностью напишут еще до середины итерации . Если к середине итерации готовы не все приемочные тесты, кто-то из разработчиков должен бросить работу над историей и помогать писать тесты .
Это означает, что за эту итерацию не удастся выполнить все за- планированные истории, однако в любом случае без приемочного тестирования ни о каком выполнении не может идти речи . Только

Глава 3. Методы взаимодействия с клиентами
128
убедитесь, что программисты, работающие над какой-либо исто- рией, не пишут приемочные тесты для нее же . Если специалисты по качеству каждый раз не успевают написать тесты к середине итерации, это, вероятнее всего, означает, что соотношение разра- ботчиков и QA-специалистов выбрано неверно .
Если по достижении середины итерации все приемочные тесты написаны, то QA-специалисты должны приняться за тесты к сле- дующей итерации . Это рискованно, поскольку встреча по плани- рованию еще не состоялась, однако заинтересованные стороны могут дать рекомендации насчет историй, которые они выберут с наибольшей вероятностью .
Разработчики и QA-инженеры должны обсудить такие тесты . Мы не хотим, чтобы разработчики молча брали то, что им бросают QA- специалисты . Необходимо обсуждать структуру тестов и писать их сообща, вплоть до парного программирования .
До середины итерации команде нужно постараться выполнить истории, чтобы успеть к промежуточному совещанию . А до конца итерации разработчикам нужно постараться успеть подвергнуть оставшиеся истории соответствующим приемочным тестам .
Если мы говорим, что история выполнена, то подразумеваем, что она прошла приемочное тестирование .
В последний день итерации разработчикам предстоят муки выбора: какие истории стоит завершить, а от каких придется отказаться?
Мы предпочитаем перераспределять усилия . Так получается вы- полнить столько историй, сколько возможно .
Опять же ни к чему заканчивать итерацию с историями, выпол- ненными лишь наполовину, ведь есть возможность пожертвовать какой-то историей, чтобы полностью выполнить другую .

Планирование
129
Здесь не нужна спешка . Нужны конкретные результаты и изме- римость хода работ . Нужны надежные данные . Историю можно считать выполненной, когда пройдено приемочное тестирование .
Когда программист говорит, что выполнил историю на 90 %, в ре- альности непонятно, насколько она готова . Поэтому на графике скорости работ стоит отмечать лишь истории, прошедшие при- емочное тестирование .
Демонстрация
Каждая итерация заканчивается короткой демонстрацией но- вых функций заинтересованным сторонам . Такая встреча должна длиться не больше часа или двух, в зависимости от размера итера- ции . В демо-версии должно быть видно, что истории, в том числе все предшествующие, полностью прошли приемочное и модульное тестирование . Следует также показать свежий функционал, добав- ленный к программе . Лучше всего, если заинтересованные стороны сами проверяют работоспособность программы, чтобы у разработ- чиков не было соблазна скрыть то, что не работает .
Скорость
Завершающий аккорд итерации — обновление графика скорости и диаграммы сгорания задач . На графике нужно отмечать единицы только тех историй, которые прошли соответствующие приемочные испытания . После нескольких итераций графики пойдут на спад .
Спад диаграммы сгорания задач помогает выявить, какого числа будет достигнута следующая важная веха . График скорости же по- казывает нам, насколько хорошо организована работа команды .
Во время начальных итераций график скорости будет довольно неточным, так как команда еще толком не разобралась в основах