Адаптивный стиль управления программными проектами

Менеджеры программных проектов смогут добиться большего, если будут применять методы управления, характерные для киноиндустрии. «Что за ересь! — скажете вы. —Программные проекты нуждаются в повышении, а не в снижении уровня дисциплины технического управления». Впрочем, прежде чем с гневом отвергнуть данное заявление, полезно рассмотреть следующие соображения.

Руки профессиональных программистов не связаны какими-либо физическими законами или свойствами материалов, накладывающими ограничения на их решения — их ограничивают лишь воображение, рамки бюджета и производительностью платформы (отдельные разработчики встроенного программного обеспечения являются редким исключением).
В программном проекте всегда можно изменить планы, финансирование, этапы, требования, дизайн, тесты.
Метрики и меры, применяемые к программным продуктам, весьма субъективны и не имеют атомных эталонов. Лучшей мерой успеха программного обеспечения оказывается экономическая эффективность, более характерная для сферы услуг. Она измеряется на основе не стоимости производства, а потребительской стоимости для пользователя.

Эти тезисы, вероятно, звучат противоестественно для менеджеров проектов с инженерным складом ума, занятых производством самолетов, мостов, искусственных сердечных клапанов, ядерных реакторов, небоскребов и спутников — если только их проекты не требуют больших объемов программирования и не являются первыми в своем классе. Однако подобные рассуждения вполне правомочны по отношению к профессиональным кинопродюсерам, которые создают уникальные интеллектуальные продукты, ограниченные лишь замыслом и творческим потенциалом.

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

Итеративный подход

Экономическую эффективность программных продуктов трудно измерить одним простым показателем, но за последние пять лет лишь каждый третий проект укладывался в рамки бюджета и графика с той или иной степенью предсказуемости [2]. Похоже, что-то подобное можно сказать и об экономической эффективности кинопроизводства.

В традиционных подходах к руководству крупными программными проектами не поощряются корректировки, необходимые для адаптации к высоким уровням неопределенности:

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

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

Современные подходы к управлению программными проектами известны как итеративные методы разработки [3-5]. Они не подразумевают строгого следования детальному долгосрочному плану и ведут программные проекты через минные поля неопределенностей, свойственных разработке современных программных приложений, продуктов и услуг. Для успешной реализации проектов в рамках графика и бюджета требуется сочетание творчества, продуктивности, трезвой оценки и адаптивного стиля руководства. А для этого, в свою очередь, необходимы активная вовлеченность в производственный процесс, частые корректировки курса, направленные на получение наилучших результатов, и сотрудничество всех заинтересованных лиц для достижения изменяющихся целей.

IBM Rational Unified Process (RUP), признанный эталон итеративного процесса разработки, создает основу сбалансированного развития, способствующую управлению неопределенностями и рисками [6]. Он состоит из четырех фаз, каждая из которых завершается ощутимым результатом.

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

Каждая из фаз представляет собой скорее состояние проекта, чем этап последовательного продвижения по традиционному маршруту «разработка требований — проектирование — кодирование — тестирование — поставка».

Итеративный стиль управления ориентирован на результаты, а не на действия для их достижения. А в мире программного обеспечения реальными результатами являются исполняемые программы. Все остальные артефакты (требования, сценарии использования, модели проектирования, тестовые примеры, планы, процессы, документы и ревизии) — это просто средства достижения цели. Как в киноиндустрии, где главные усилия направлены на производство фильмов, в области создания программных продуктов нужно материализовать этапы разработки в исполнимой форме, чтобы оценить прогресс и качество. При этом придется, отбрасывая заведомо неудачные варианты, неоднократно переделывать оставшиеся, прежде чем удастся найти работоспособное решение и свести вклады многих людей в единый интеллектуальный продукт.

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

Детализация и точность

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

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

Обычная схема провала — разработка спецификации с точностью «до пяти знаков», хотя все заинтересованные лица понимают проблему, решение или план с точностью лишь «до одного знака». Длительные усилия по детализации требований или плана только отдаляют достижение более точного понимания важных архитектурных проблем. Над сколькими пугающе толстыми томами требований или продуманными до мельчайших деталей планами вы корпели, совершенствуя их и без конца пересматривая? И сколько из них приходилось полностью переделывать всего через несколько месяцев, когда проект давал первые осязаемые результаты, проливающие свет на реальные противоречия и проблемы? Распространенную практику ранней детализации метко называют «дурной работой».

Четыре схемы адаптивного управления

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

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

Управление содержанием проекта. Решения развиваются из пользовательских спецификаций, а пользовательские спецификации развиваются на базе предлагаемых решений (антисхема: требования точно и полностью определяются заранее).
Регламентированность процесса. Регламентированность процесса и средств контроля меняется от слабой до сильной (антисхема: на всем протяжении проекта степень регламентированности остается неизменной).
Добротность прогресса. Для успешных проектов характерно чередование продвижений и отступлений (антисхема: по мере слепого выполнения заранее составленного плана без заметных отступлений осваиваются 90% выделенных средств).
Контроль над качеством. На протяжении всей работы над проектом тщательно тестируются промежуточные версии (антисхема: тестирование рассматривается как нечто второстепенное и откладывается до завершающих этапов).

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

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

Управление содержанием проекта

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

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

Ранее уже упоминалось, что слово «требование» в нашей отрасли занимает первое место по неправильности использования. «Требуемые» означает «необсуждаемые, неизменяемые безусловные», и все же почти в каждом успешном проекте фигурируют измененные, компромиссные и договорные требования. Измененное требование подвергается тщательной ревизии, поскольку оно обычно является частью контракта между заинтересованными лицами. Лучше вместо «требование» использовать слово «спецификация», поскольку спецификация изменчива и рассматривается как текущее состояние нашего понимания.

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

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

Регламентированность процесса

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

Большинство менеджеров проектов согласятся с тем, что достаточно строгая регламентация процессов необходима в следующих случаях:

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

В последнем случае речь идет о выборе между скоростью и свободой гибких методов, с одной стороны, и качеством и последовательностью строго регламентированных методов, с другой. Регламентированность процесса должна действовать подобно гравитации: чем вы ближе к выпуску продукта, тем сильнее влияние процесса, инструментов и средств контроля на повседневную деятельность. И чем вы дальше от даты выпуска, тем слабее такое влияние. В специальной литературе эта аксиома сильно недооценивается или даже вовсе опускается.

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

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

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

Добротность прогресса

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

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

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

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

Тем не менее разработчик должен взять на себя ответственность в каждой следующей версии демонстрировать осязаемые усовершенствования. Объективная количественная оценка изменений, поправок и модернизаций обеспечивает подлинные индикаторы прогресса и качества. Для разрешения проблем в дальнейшем необходима открытая и тщательная систематическая работа. При адаптивном стиле руководства успех порождает успех. На основе цепочки ощутимых промежуточных результатов вы можете точнее спрогнозировать конечный результат. Постоянное отсутствие прогресса или застойная последовательность результатов — признак того, что нужно пересмотреть ресурсы проекта, его содержание или целесообразность.

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

Контроль качества

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

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

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

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

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

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

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

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

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

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

Экономические выгоды адаптивного управления

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

Типовое развитие событий при обычном техническом стиле руководства проектом таково:

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

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

При традиционном способе управления примерно 40% всех ресурсов проекта расходуются на интеграцию и испытания, причем часто — впустую. Современные проекты с их итеративным процессом разработки и адаптивным стилем управления позволяют выдать продукт при расходовании на те же цели примерно 25% бюджета.

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

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

ЛИТЕРАТУРА

P. Graham, Hackers and Painters: Big Ideas from the Computer Age. O?Reilly, 2004.
Standish Group International CHAOS Chronicles, 2004.
W.E. Royce, Software Project Management: A Unified Framework. Addison-Wesley Longman, 1998 (имеется перевод: Уокер Ройс, Управление проектами по созданию программного обеспечения. М.: Лори, 2002).
M. Cantor, Software Leadership. Addison-Wesley, 2002 (имеется перевод: Марри Кантор, Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения. М.: Вильямс, 2002).
J. Marasco, The Software Development Edge: Essays on Managing Successful Projects. Addison-Wesley, 2005.
P. Kroll, P. Kruchten, The Rational Unified Process Made Easy: A Practitioner?s Guide. Addison-Wesley Longman, 2003; (имеется перевод: Пер Кролл, Филипп Крачтен, Rational Unified Process — это легко. Руководство по RUP для практиков. М.: Кудиц-Образ, 2004).

Уолкер Ройс (weroyce@us.ibm.com) — вице-президент IBM Worldwide Rational Services Organization. Автор книги Software Project Management: A Unified Framework. Внес ключевой вклад в философию управления, являющуюся основой процесса RUP.