Постигая Agile

Действительно, написание модульных тестов требует времени, и очень часто разработчики считают, что это напрасный труд[55]. Но самое забавное происходит, когда программисты все-таки начинают заниматься разработкой через тестирование. В какой-то момент модульный тест дает сбой, тем самым выявляя маленькую, но неприятную ошибку, которая потом могла бы отнять массу времени. Несколько подобных случаев переубедят любого скептика. Когда это происходит, многие agile-разработчики говорят, что вы «заражаетесь тестами», и разработка через тестирование становится естественным способом создания программного обеспечения.

Необходимо помнить еще об одном: в разработке через тестирование гораздо больше смысла, чем кажется на первый взгляд. В главе 7 вы узнаете, что написание модульных тестов до создания кода может иметь огромное влияние на то, как команда разрабатывает программное обеспечение. Те, кто эффективно использует разработку через тестирование, создают более качественное ПО не только потому, что отлавливают ошибки, но и благодаря тому, что начинают думать иначе.

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

Я программист, и все это кажется мне чем-то неопределенным. Обычно я получаю задание, поэтому представляю, чем должен заниматься. Откуда же я узнаю, что мне делать дальше?

Если вы привыкли работать по плану-графику или диаграмме Ганта, то ХР-подход к ежедневному планированию может показаться вам необычным. Ежедневно вы получаете список задач, каждую из которых нужно выполнить и после этого отметить галочкой. Так работать удобно, потому что вы всегда видите свой прогресс. Руководителю и менеджеру проекта это также подходит – они легко могут видеть состояние проекта по проставленным галочкам.

Разработчику, привыкшему к такому режиму, поначалу трудно приспособиться к зрелой ХР-команде. Потому что в командно-административной среде кто-то уже проанализировал исходные требования и составил на их основе список задач, которые команда должна выполнить. Это задает строгий порядок действий каждого программиста, поскольку все решения были приняты в начале проекта.

XP-команды не занимаются предварительным планированием. Они обсуждают темы и истории при планировании квартального цикла, но работают по очень коротким, недельным итерациям. Индивидуальные задания планируются только на ближайшую неделю. В этом и заключается «экстремальность» экстремального программирования – в принятии решения в последний ответственный момент. И разработчику, привыкшему, чтобы все было запланировано заранее, кажется, что решения принимаются слишком поздно.

Есть еще одна ситуация, когда ХР-команда может вызвать ощущение «дезорганизации» у тех, кто раньше использовал гораздо более жесткое планирование: пары постоянно меняются и люди не определяют заранее, кто какое задание должен делать. Решение о том, кому выполнять ту или иную работу, принимается непосредственно перед ее началом. Это отличается от методов scrum-команд, у которых есть ежедневные совещания, оценивающие ход работ по спринту, и назначение задач происходит способом самоорганизации. Поскольку XP-команда имеет короткие итерации и петли обратной связи, она может «свалить» свои задачи в кучу, и, когда пара готова к следующему заданию, она просто вытягивает его оттуда.

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

Нет. И это еще одна область, в которой XP помогает команде совершенствоваться. В начале недельного цикла команда выбирает истории, которые собирается делать, и разбивает их на задачи. Поскольку разработка ведется итеративно, в конце цикла они поставляют работающее программное обеспечение, которое действительно сделано, а все частично завершенные истории переносятся в следующий цикл. Но они не планируют, кто какую задачу будет делать. Вместо этого задачи «сваливаются» в кучу, ставятся в очередь или организуются иным образом. После того как пара заканчивает текущее задание, она выбирает следующее из очереди.