Благодарю Боба Мартина за включение этой книги в свою серию. Дядя Боб – один из моих любимых писателей еще с той поры, когда он был редактором журнала C++ Report. Боб сделал для распространения идей agile-подхода в сообществе разработчиков программного обеспечения столько, что попасть в его серию книг – большая честь. Также я хочу поблагодарить Джима Хайсмита из Cutter Consortium и Габриэля Бенефилда из Yahoo! за предисловия. Работа с ними была удовольствием.

Что бы я ни сказал, этого будет мало, чтобы выразить признательность моим близким, создавшим условия для работы над этой книгой. Предполагалось, что значительную часть подготовки рукописи я проделаю во время своих поездок. Однако все сложилось иначе. Лоре, моей жене и партнеру во всех начинаниях, пришлось не покладая рук заниматься моими делами, делами нашей компании и этой книгой. Она многократно читала и перечитывала каждую главу. Без ее помощи я бы не сделал и десятой части того, что мы сделали вместе. Мои чудесные дочери Саванна и Делани настолько привыкли к постоянному уединению своего отца в кабинете, что мое появление стало казаться им странным. Я благодарю их за нежные объятия и поцелуи и за то, что они такие, какие есть.

Эта книга в основном посвящена планированию, под которым я понимаю ответ на вопрос «Что необходимо сделать и к какому сроку?». Однако ответ на него требует ответа на вопросы, связанные с оценкой («Насколько это объемно?») и составлением календарного графика («Когда это должно быть сделано?» и «Сколько будет готово к этому моменту?»).

Книга состоит из семи частей, в ней 23 главы. Каждая глава завершается обобщением ключевых моментов и вопросами для обсуждения. Поскольку оценка и планирование – это виды деятельности, которыми занимается команда в целом, я предполагаю, что книгу будут читать все ее члены, а потом собираться (возможно, раз в неделю) для обсуждения прочитанного и вопросов в конце каждой главы. Учитывая, что agile-подход к разработке программного обеспечения популярен во всем мире, я старался избежать чрезмерной концентрации внимания на США. С этой целью в книге используется универсальное обозначение валюты и денежные суммы выглядят как $500, а не $500, €500 и т. п.

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

В части II представлено основное правило оценки, требующее, чтобы оценки размера и срока никогда не смешивались. Главы 4 и 5 знакомят читателя с пунктами и идеальными днями – двумя показателями, подходящими для оценки размера разрабатываемых компонентов. В главе 6 описываются методы оценки в пунктах и идеальных днях и дается представление о покере планирования. Глава 7 посвящена тому, когда и как проводить переоценку, а в главе 8 приводятся рекомендации, что лучше выбрать – пункты или идеальные дни.

Часть III «Планирование на основе стоимости» содержит рекомендации для проектной команды относительно того, как создать наилучший конечный продукт. В главе 9 перечислены факторы, которые необходимо учитывать в процессе приоритизации функций. В главе 10 представлен подход к моделированию финансовой отдачи от отдельной функции или набора функций, а также методы сравнения финансовой отдачи, с тем чтобы в первую очередь разрабатывались наиболее ценные функции. В главу 11 включены рекомендации по оценке и последующей приоритизации желательности функцией для пользователей продукта. Глава 12 завершает раздел обсуждением вопроса о том, как разбивать крупные функции на более мелкие части, которыми легче управлять.

В части IV мы переключаем внимание на вопросы, связанные с составлением календарных графиков для проекта. Глава 13 открывается обзором этапов составления календарных графиков для сравнительно простого, выполняемого одной командой проекта. В следующей главе (14) рассматривается вопрос планирования итераций. Главы 15 и 16 посвящены выбору длины итераций для проекта и оценке первоначального темпа продвижения команды. В главе 17 детально разбирается составление календарных графиков для проекта с высоким уровнем неопределенности или с высокой чувствительностью к некорректности графика. Раздел завершается главой 18, в которой описываются дополнительные этапы при оценке и планировании проекта, осуществляемого несколькими командами.

После составления плана необходимо проинформировать о нем всю организацию и использовать его для мониторинга прогресса разработки. Именно этим вопросам посвящены три главы части V. В главе 19 рассматривается мониторинг плана релиза, а в главе 20 – плана итераций. В последней главе этого раздела (21) разбираются вопросы информирования о плане и процессе его выполнения.

Часть VI состоит всего из одной главы – 22, в которой рассматривается вопрос, почему работает agile-подход к оценке и планированию. Эта глава является своего рода дополнением к главе 2, где говорится о том, почему традиционные подходы нередко дают неудовлетворительные результаты.

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

Чтобы уяснить суть agile-подхода к оценке и планированию, необходимо ясно понимать цель планирования. Именно этому вопросу посвящена глава 1 данного раздела. В главе 2 рассматриваются основные причины, по которым традиционные подходы к оценке и планированию дают неудовлетворительные результаты. Заключительная глава этого раздела содержит описание обобщенных принципов agile-подхода к оценке и планированию, которому посвящаются последующие части книги.

Оценка и планирование критически важны для успеха проекта по разработке программного обеспечения любого размера и значимости. Планы определяют наши инвестиционные решения: мы можем взяться за проект, на выполнение которого, по нашим оценкам, потребуется полгода и $1 млн[1], и отказаться от этого же проекта, если на него потребуется два года и $4 млн. Планы помогают нам понять, кого нужно привлечь к работам по проекту в течение определенного периода. Планы помогают нам понять, как продвигается создание функциональности, которая нужна пользователям и получения которой они ожидают. Без планов мы открываем ворота для целого ряда проблем.

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

Тот факт, что оценка и планирование – дело непростое, не является открытием. Это известно давным-давно. В 1981 г. Барри Боэм построил первую версию того, что Стив Макконнелл (Steve McConnell, 1998) позднее назвал «конус неопределенности». На рис. 1.1 показаны первоначальные диапазоны неопределенности Боэма в разных точках в процессе последовательного развития («каскадный процесс»). Конус неопределенности говорит о том, что на этапе оценки осуществимости проекта оценка обычно отклоняется от истины на 60–160 %. Иначе говоря, на проект, который, как ожидается, должен занять 20 недель, может потребоваться от 12 до 32 недель. После формулирования требований в письменном виде оценка может отклоняться на ±15 % в любом направлении, т. е. плановый срок 20 недель может сократиться до 17 недель или вырасти до 23 недель.