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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее описаны три простые истины, действующие при руководстве проектами. Если руководствоваться ими, удается справиться со значительной долей нервозности и сбоев, с которыми регулярно приходится сталкиваться в софтверных проектах.

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

Осознавая вторую истину, мы перестаем бояться перемен или избегать их. Мы знаем, что рано или поздно они наступят. Принимаем их такими, какие они есть. И при необходимости корректируем наши планы в соответствии с ними.