Agile: оценка и планирование проектов - [79]
Информация по национальным рекордам и рекордам по возрастным группам хранится в базе данных на удаленном объекте национальной ассоциации по плаванию. Доступ к этой базе данных не так прост, как хотелось бы командам, и национальная ассоциация собирается сменить поставщиков баз данных в ближайший год-два. По этой причине владелец продукта и команды разработчиков согласились с тем, что нужно разработать API (интерфейс прикладного программирования) для доступа к базе данных. Это должно значительно упростить переход к другому поставщику баз данных. Первоначальные пользовательские истории и их оценки приведены в табл. 18.1.
Скорость оценивается как 20 пунктов на итерацию для одной и другой команды. Поскольку объем работ составляет 110 пунктов, команды должны поставить полную функциональность за три итерации. Вместе с тем 30 пунктов приходятся на разработку API, а еще 40 пунктов (три последние истории в табл. 18.1) можно реализовать только после разработки API. Это приводит к такому распределению работ, которое представлено на рис. 18.1, где взаимозависимость команд обозначена стрелкой между реализацией API первой командой и работой над индивидуальными результатами, выполняемой второй командой.
Возможно, вы помните, что в главе 13 «Основные аспекты планирования релиза» я рекомендовал показывать в плане релиза детали только следующих двух итераций. Объясняется это тем, что такой подход нередко достаточен для поддержки взаимозависимостей, с которыми имеют дело многие команды. Когда нескольким командам приходится работать вместе, план релиза следует обновлять с тем, чтобы показывать и координировать работу в следующих двух или трех итерациях. Точное число итераций, конечно, зависит от частоты и серьезности взаимодействий команд. После завершения итераций связанные с ними детали удаляют из плана. Таким образом, план релиза становится скользящим опережающим планом, который всегда отражает ожидания относительно нескольких новых итераций. Лауфер (Laufer, 1996) называет это «заглядывание вперед».
На рис. 18.1 показана ситуация, в которой команды обмениваются информацией между итерациями. Это менее рискованно, чем планирование на основе информации, передаваемой во время осуществления итерации. В начале очередной итерации каждая команда идентифицирует работу, которую она может выполнить, и принимает обязательства по ее выполнению. В случае, представленном на рис. 18.1, в начале третьей итерации команда 2 может принять полноценное обязательство по реализации пользовательской истории, связанной с данными по индивидуальным результатам, поскольку она знает о завершении API. Предположим вместо этого, что команда 2 планирует свою третью итерацию, когда API еще не разработан, а завершение работы над ним ожидается через несколько дней. Даже если бы команда 2 могла завершить историю, связанную с данными по индивидуальным результатам, без API в первый же день, ее обязательство было бы более шатким, и весь календарный график подвергся бы значительному риску. Командам нередко приходится принимать обязательства на основе результатов середины итерации. Тем не менее в той мере, в какой это возможно, им следует ограничиваться обязательствами, связанными с работами, которые завершены до начала очередной итерации.
Включение в план поддерживающих буферов
Для большинства команд в большинстве ситуаций скользящий опережающий план вполне уместен. Однако бывает, что взаимодействия команд настолько сложны или часты, что простого скользящего опережающего планирования, описанного в предыдущем разделе, недостаточно. В таких случаях первое, что нужно сделать, это попытаться сократить количество взаимодействий до уровня, при котором скользящее опережающее планирование станет реальным. Если добиться этого не удается, попробуйте включить в итерацию поддерживающий буфер, который даст свободу, необходимую другим командам. Поддерживающий буфер, как и временной буфер, описанный в предыдущей главе, защищает своевременную поставку набора новых возможностей. Это довольно сложный способ сказать простую вещь: если вашей команде требуется что-либо от моей команды к 8:00, то моей команде не следует планировать завершение этого на 7:59. Иначе говоря, нам нужен план вроде того, что представлен на рис. 18.2.
На рис. 18.2 поддерживающий буфер вставлен между завершением API командой 1 и началом работы команды 2 с использованием API над пользовательской историей, связанной с данными по индивидуальным результатам. Поддерживающий буфер защищает дату начала работы над историей, связанной с данными по индивидуальным результатам, от задержек в реализации API.
Чтобы включить поддерживающий буфер в план релиза, нужно всего лишь временно планировать работу с расчетом на более низкую скорость команды, которая поставляет определенную возможность другой команде. В случае, представленном на рис. 18.2, усилия команды 1 равномерно делятся между завершением API и поддерживающим буфером так, чтобы гарантировать команде 2 возможность приступить к работе над индивидуальными результатами с самого начала третьей итерации. Это не означает, что команда 1 получает возможность не торопиться в процессе второй итерации. В действительности от нее ожидают, что она выполнит связанную с API работу в 10 пунктов, использует только часть буфера и начнет работать над пользовательской историей, связанной с национальными рекордами, уже во второй итерации.
