Концепции развития проекта

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

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

Концепции развития проекта естественным образом разбиваются на две части:

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

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

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

Общие принципы и положения

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

При описании общих принципов для всех этапов указывается следу­ющее:

• как проверяется корректность получаемых результатов (рабочих продуктов этапа);

• как формируются релизы и версии рабочих продуктов, какая дис­циплина внесения изменений в рабочие продукты рекомендуется, как она контролируется;

• способы оценки продуктивности деятельности и продвижения к цели этапа, а также процедура мониторинга качества рабочих про­дуктов;

• приемы, методы, технологии, а также прототипы, которые исполь­зуются в работах этапа.

Для этапов, связанных с производственной функцией планирова­ния, описывается структура получаемых рабочих продуктов (планов), ин­струменты, применение которых полезно для поддержки составления плана и отслеживания планируемых работ.

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

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

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

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

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

В качестве примера приведем очень часто популяризируемый метод декомпозиции проекта на работы, получивший название построения по­операционного перечня работ [52](WBS — work breakdown structure). Час­то WBS переводится как иерархическая система работ — этим переводом мы будем пользоваться, когда требуется подчеркнуть способ построения WBS. Есть и другие переводы термина. Этот метод считается чуть ли не единственной основой любого проекта. Однако это не так! Он вполне под­ходит проектам, для которых достаточно хорошо известно, что надо полу­чить в результате, или, по крайней мере, существуют способы точно выяс­нить это. Если проект можно рассматривать как детерминировано разви­вающийся {см. лекцию 5), то с помощью метода WBS достаточно техноло­гично строится перечень работ, который позволит разумно оценивать затраты на разработку, распределять ресурсы, осуществлять другие менед­жерские обязанности. Но как только это условие нарушается, возможно­сти качественного применения метода резко падают. С точностью до этого ограничения методику WBS можно рекомендовать для применения в предпроектной деятельности менеджера проектов самых разнообразных областей, в том числе за пределами разработки программного обеспече­ния. Одно из главных ее достоинств в том, что она позволяет выделить в иерархически выстроенных работах проекта, необходимых для его успеш­ного выполнения, уровень операций как частей проекта, допускающих не­посредственное (в наших терминах — обозримое) управление и контроль выполнения заказчиком. Сумма операций проекта — это тот объем работ, о выполнении которого договариваются при составлении контракта.

Методика WBS применительно к концепции развития проекта рас­сматривается в следующем соотношении между общими и специальными принципами и положениями. Факт использования методики и обоснова­ние адекватности ее применения — предмет рассмотрения общих поло­жений концепции, а конкретизация использования, т.е. декомпозиция задач подготавливаемого к реализации проекта, относится к специальной части. Учитывая важность методики WBS для реальных проектов и доста­точно широкую ее распространенность, в следующем разделе мы более детально обсудим ее содержание.

Специальные принципы и положения

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

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

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

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

Первая стратегия, называемая продуктовой декомпозицией проекта, исходит в: деления продукта на подпродукты. Подпродукты в свою оче­редь разбиваются на составляющие до того уровня, на котором продукты реализуются очевидно, т.е. с использованием локального планирования и управления. Считается, что на этом уровне можно определить, какие ре­сурсы нужны для работ, выполнение которых приведет к реализации локального продукта. Сумма потребностей ресурсов определяет общую ре­сурсную потребность проекта. Сумма сроков разработки локальных про­дуктов с учётом возможности распараллеливания работ дает оценку време­ни выполнения проекта. В этой стратегии при построении иерархического разбиения выдерживается принцип ответа на вопрос: «Из чего состоит (разбиваемым) продукт?». Операцией (т.е. неделимым с точки зрения про­екта действием — см. предыдущий раздел) считается работа, необходимая и достаточная для построения листа в иерархии продуктов.

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

для проекта

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

Подробное представление о методе WBS можно получить из книги [27].

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

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

При декомпозиции, связанной с отбором требований, могут возник­нуть проблемы с оцениванием ресурсной потребности для реализации сценариев. Заказчик может недоумевать, почему такое простое с его точ­ки зрения средство разработчиками оценивается как ресурсоемкое. Для преодоления трудности можно снова рекомендовать построение поопе­рационного перечня работ, но уже для каждого из отбираемых сценариев, с последующим слиянием перечней и упорядочением-распределением по итерациям. Следует, однако, иметь в виду, что этот прием резко снижает преимущества сценарной декомпозиции для заказчика — ее понятность. По вполне очевидным причинам пооперационные перечни работ при сценарной декомпозиции оказываются сложнее, чем при построении по­добного перечня для проекта в целом: на уровне обсуждения контракта нет возможности воспроизвести мотивы объектно-ориентированного проектирования, принятые при определении операций.

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

Менеджер вправе включать в концепции дополнительные сведения т своему усмотрению. Такое расширение содержания документа направлено на более точный учет специфики проекта при управлении. Например, не­который заказ предполагает работы, связанные обучением персонала \ заказчика. Чтобы организовать обучение, нужно провести дополнитель­ную работу, определение которой невозможно без сведений о персонале (уровень квалификации, возможности учиться с отрывом и без отрыва о: работы и др.). Соответственно, концепции должны определить принци­пы организуемой деятельности, ее возможные варианты.

Преимущества разделения принципов

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

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

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

• Концепции развития проекта полезно просмотреть в конце проекта, чтобы выделить то, что «работало», а что нет и почему. Документ, в котором общее отделено от частного, допускает гораздо более результативное изучение, нежели разного рода проектно-ориентированные документы.

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

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

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

В первом приближении в качестве постоянной части концепций проекта можно принять предложения MSF [44]. Это не отдельный доку­мент, а комплект материалов, фиксирующий ряд предписаний для орга­низации проектной деятельности:

• модель процессов MSF;

• модель проектной группы MSF;

• дисциплина управления рисками MSF;

• дисциплина управления проектами MSF;

• дисциплина управления подготовкой MSF.

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

В качестве исходного материала для концепции реального проекта, для которого принимается методология экстремального программирова­ния, целесообразно воспользоваться книгой Бека [3]. Другие его книги, обсуждающие принципиальные аспекты этого подхода (тестирование [4J, планирование [5]) помогут при подготовке концептуальной базы проекта. Понятно, что цели пропагандистских монографий не совпадают с целями организации проектной деятельности, а потому не следует принимать на­ши рекомендации буквально.

На фоне предыдущих иллюстраций подход RUR, представленный в книге [30J, выглядит менее концептуальным, поскольку авторы пытают­ся представить все возможные варианты использования системы поня­тий, не фиксируя методологии. Отсюда, несмотря на заверения о привяз­ке «рациональных» процессов к модели жизненного цикла, книга пред­ставляет собой лишь содержательный рассказ о том, как можно приме­нять разработанные соглашения и инструменты (в этом качестве обсуждаемая монография оказывается очень полезной). Гораздо точнее объектно-ориентированное проектирование представлено в монографии [10J, которая излагает шаблоны проектирования без претензий на кон­цептуальное и методологическое обобщение. Если же обратиться к клас­сической для объектно-ориентированного проектирования книге Г. Буча [8], то говорить о ней как об основе концепции развития проекта или хо­тя бы как о ее проектно-независимой части не приходится, но уже по дру­гой причине. Она нацелена на доказательство продуктивности подхода в целом и в этом качестве вполне убедительна и полезна.