вопрос, почему работает agile-подход к оценке и планированию. Эта глава является своего рода дополнением к главе 2, где говорится о том, почему традиционные подходы нередко дают неудовлетворительные результаты.
Заключительная часть (VII) также включает в себя только одну главу. Глава 23 представляет собой расширенный анализ примера, который повторяет основные моменты этой книги применительно к гипотетической ситуации.
Часть I
Проблема и цель
Чтобы уяснить суть agile-подхода к оценке и планированию, необходимо ясно понимать цель планирования. Именно этому вопросу посвящена глава 1 данного раздела. В главе 2 рассматриваются основные причины, по которым традиционные подходы к оценке и планированию дают неудовлетворительные результаты. Заключительная глава этого раздела содержит описание обобщенных принципов agile-подхода к оценке и планированию, которому посвящаются последующие части книги.
Глава 1
Цель планирования
Планирование – это все. Планы – ничто.
Оценка и планирование критически важны для успеха проекта по разработке программного обеспечения любого размера и значимости. Планы определяют наши инвестиционные решения: мы можем взяться за проект, на выполнение которого, по нашим оценкам, потребуется полгода и $1 млн[1], и отказаться от этого же проекта, если на него потребуется два года и $4 млн. Планы помогают нам понять, кого нужно привлечь к работам по проекту в течение определенного периода. Планы помогают нам понять, как продвигается создание функциональности, которая нужна пользователям и получения которой они ожидают. Без планов мы открываем ворота для целого ряда проблем.
Процесс планирования, однако, сложен, а планы нередко получаются далекими от реальности. Как результат, команды зачастую впадают в одну из двух крайностей: они либо полностью отказываются от планирования, либо тратят столько сил на составление планов, что начинают верить в их правильность. Команды, которые отказываются от планирования, не могут ответить на такие фундаментальные вопросы, как «Когда это должно быть выполнено?» и «Можем ли мы ожидать выпуск продукта в июне?». Команда, затратившая слишком много сил на планирование, обольщает себя уверенностью в том, что план в принципе может быть «правильным». Ее план может быть тщательно проработанным, но вовсе не обязательно отличаться высокой точностью или полезностью.
Тот факт, что оценка и планирование – дело непростое, не является открытием. Это известно давным-давно. В 1981 г. Барри Боэм построил первую версию того, что Стив Макконнелл (Steve McConnell, 1998) позднее назвал «конус неопределенности». На рис. 1.1 показаны первоначальные диапазоны неопределенности Боэма в разных точках в процессе последовательного развития («каскадный процесс»). Конус неопределенности говорит о том, что на этапе оценки осуществимости проекта оценка обычно отклоняется от истины