Читать книгу - "Искусство управления IT-проектами - Скотт Беркун"

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

Там, где проекты усложняются из-за своей объемности или продолжительности, календарные планы делятся на части, каждая из которых имеет собственные периоды проектирования, разработки и тестирования. В экстремальном программировании (Extreme Programming, XP) такие части называются итерациями, в спиральной модели – фазами, а в некоторых организациях их называют этапами. Хотя в XP считается, что эти отрезки времени занимают всего несколько недель, а в спиральной модели счет идет на месяцы, в них заложена одна и та же фундаментальная идея: создание подробных календарных планов для ограниченных периодов времени.

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

Гибкий и традиционный методы

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

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

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

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