Джонатан Расмуссон - Гибкое управление IT-проектами. Руководство для настоящих самураев

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

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

А если вас все же пугает перспектива работать в темпе «на все про все неделя» – не отчаивайтесь. Большинство команд, работающих в гибком режиме, начинает с двухнедельных проектов (а если команда очень большая – то с трехнедельных).

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

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

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

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

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

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

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

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

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

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

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

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