Майк Кон - Agile: оценка и планирование проектов

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

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

Agile-команды стремятся устранять все ошибки в той итерации, в которой они обнаруживаются. Это становится возможным с приобретением опыта работы в режиме коротких итераций, в частности в результате применения автоматического тестирования. Когда программист дает оценку задачи по кодированию чего-либо, он включает в нее время на устранение ошибок, выявленных в процессе реализации, или выделяет этот процесс и оценивает его как отдельную задачу («Устранение ошибок»). Я предпочитаю представлять это в виде отдельной задачи, но не считаю ее завершенной до тех пор, пока не будут выполнены все тесты.

С дефектом, обнаруженным позже (или не устраненным во время итерации, в которой он был выявлен), поступают точно так же, как и с пользовательской историей. Устранение дефекта следует приоритизировать в последующей итерации так, как приоритизируют любую другую пользовательскую историю. За пределами итерации идея дефекта в целом начинает сходить на нет. Устранение ошибки и добавление функции становятся двумя разновидностями описания одного и того же.

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

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

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

Чтобы команда SwimStats могла сделать это, во время планирования итерации ей необходимо идентифицировать несколько задач, которые не появились бы, если бы эти две истории реализовывались в естественном порядке. Например, если бы возможность добавлять пловцов уже существовала, команде не нужно было бы включать задачу «Разработка таблиц базы данных для информации об индивидуальных пловцах». Вместе с тем, поскольку истории реализуются не в естественном порядке, такую задачу включить придется.

Означает ли это, что работа не в естественном порядке увеличивает срок выполнения проекта? Ответов может быть два: «не обязательно» и «это не имеет значения».

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

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