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

В гибкой разработке под журналом пожеланий (master story list)[1] понимается список задач, которые предстоит решить программисту. В нем упоминаются все важнейшие функции (пользовательские истории, user stories) – пожелания, предъявляемые клиентом к программе. Приоритетность тех или иных функций определяет сам пользователь, ваша команда разработчиков оценивает эти приоритеты и закладывает базовый план проекта.

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

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

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

И если реальность идет вразрез с планом, нужно менять план. Адаптивное планирование – это краеугольный камень гибкой разработки.

Пока это все, что требуется сказать о гибком планировании. Такой метод планирования будет подробнее рассмотрен в главе 8.

Если сроки поджимают, то, как говорится, «надо – значит надо». Просто советую убедиться, что вы жертвуете собой ради стоящего дела, а не ради совершенно нереального обещания, данного примерно год назад при обзоре показателей эффективности работы.

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

При гибкой разработке необходимость в чудесах такого рода отпадает, так как вы собираетесь работать с клиентами открыто и честно с самого начала – рассказываете, что предстоит сделать, и позволяете принимать осознанные решения о функционале программы, финансировании и сроках.

Все дело в выборе. Можете продолжать веровать в миф о том, что все раз – и получится. Или можно разработать вместе с клиентом такой план, в который поверите и вы и он.

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

♦ составит отчет о том, как он спланировал работу с граблями;

♦ предложит элегантный метод работы;

♦ составит тщательный и полный план тестирования?

Ничего подобного! Парень не получит ни копейки, пока не уберет листья, не уложит их в мешок и не отнесет куда следует.

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