учебники, программирование, основы, введение в,

 

Концептуальная база проекта как основа его развития

При разработке программного проекта возникают весьма разнообразные отношения участников (субъекта-исполнителя и всех других инициаторов работ) в связи с процессом производства продукта, его распространения, использования и других сопутствующих деятельностей. Эти отношения влияют на траекторию проектной деятельности по-разному, что в результате может уводить ее из области допустимости. Но если даже формирование целевой области в течение заметного периода не является определенным по результатам, то что уж тогда говорить обо всей системе деятельностей проекта! Ясно, что в данном случае необходимо согласование интересов всех инициаторов работ и что такое согласование целесообразно выделить как специальную деятельность системы. При стихийном характере ее выполнения — а так или иначе выполнять согласование приходится всегда — возникает опасность сделать не то, что нужно, или вовсе не сделать ничего. Мы говорим, что в ходе деятельности согласования формируется концептуальная база проекта, которая организует активность исполнителей проекта таким образом, что намерения успешного выполнения проекта превращаются в конкретные виды согласованной активности, продвигающей работы проекта к конкретизируемым по мере развития проекта целям.
Концептуальная база проекта складывается из очень многих составляющих, большинство из которых остаются на неосознанном уровне. Их роль и место в проекте по большей части определяется спецификой проекта и условиями его выполнения, но есть сведения, без явной фиксации которых в том или ином виде никакое развитие проекта невозможно. Это та часть концептуальной базы, которая определяет общий план проекта. На языке теории деятельности общий план следует рассматривать как метод (см. лекцию 4), поскольку его назначение — предписывать и регламентировать процесс выполнения «глобальной» деятельности проекта. Общий план отражает соглашение о динамике развития проекта и о том, какие траектории его выполнения считаются допустимыми. Из этого, в частности, следует, что для определения общего плана необходимо, чтобы между инициаторами работ было достигнуто соглашение о целевой области операционных маршрутов деятельности проекта. Понятно, что из-за неопределенности с требованиями к большинству программных проектов это соглашение не может быть сформулировано ни до начала проекта, ни в ходе его развитии, пока не будут точно определены потребности деятельностей, использующих результаты. А поскольку потребности развиваются, говорить об определенности планирования в большинстве случаев не приходится. Тем не менее соглашение о принципах планирования, о том, каким должен быть план в его исходном представлении, как он может и должен развиваться, и как он будет контролироваться, необходимо. Это сведения концептуальной базы проекта.
Данная и следующая лекции посвящены изучению намеченных вопросов. Вначале обсуждается соотношение между планами и концептуальной базой. Далее дается представление об обязательных материалах концептуальной базы. Наконец, в следующей лекции представлены специальные составляющие концептуальной базы, касающиеся преодоления рискованных ситуаций в проектной деятельности и обеспечения качества, без которых проектная деятельность не может быть успешной в принципе.

План и концептуальная база
План является основой развития любого проекта, направляющей его к достижению цели. Однако в условиях различных методологий планы проектной деятельности понимаются по-разному. Каждая из методологий предписывает определенный взгляд на то, какие типы задач ставятся перед разработчиками, какая используется модель жизненного цикла, а следовательно, на какие фазы и этапы делится развитие проекта. Планы разработки естественным образом привязаны к этому разделению, в рамках которого задачи этапов разбиваются на работы. Методологии указывают на принципы такого разбиения и на то, как может и должна быть организована коллективная деятельность.
Единственное, на чем сходятся все методологии, — это то, что общий план проекта складывается из планов по направлениям, иными словами, из предписаний и регламентов основных деятельностей системы деятельностей проекта. Но вот сами эти деятельности и, соответственно, процессы их планирования есть предмет установок конкретных методологий. По этой причине мы не будем их здесь рассматривать и ограничимся лишь теми материалами, которые являются необходимыми при любой методологии. Эти же причины обусловливают то, что конкретные сведения об общем плане развития проекта выходят за рамки настоящего курса.
В качестве пояснения места общего плана среди всех материалов проекта приведем метафору проектной деятельности, которой следуют в Центре объектно-ориентированных технологий компании IBM . Согласно этой метафоре, весь проект представляется как большая рабочая книга, разделы которой отражают суть рабочих продуктов всей проектной деятельности. Вводная часть представляет концептуальную базу проекта. Она построена в соответствии со структурой концептуальной базы. Главы основной части отражают сведения о релизах. Они структурируются так же, как выполнение итераций. Заключительная часть представляет деятельность по оценке выполненного проекта. Разделы «пишутся» по мере выполнения рабочих продуктов. Таким образом, общий план развития проекта — это содержание рабочей книги. Представленная метафора замечательна в том отношении, что она отражает параллель между проектной деятельностью и тем, что делает технический писатель, составляя документацию по проекту. При желании, можно считать, что рабочая книга действительно пишется по ходу выполнения проектной деятельности, и это есть одна из методических рекомендаций данного подхода.
В рамках методологических установок определяется конкретное планирование проекта, которое включает в себя распределение сфер ответственности исполнителей и обязанностей в проекте, выделение требуемых ресурсов, установку сроков выполнения заданий, указание способов взаимодействия исполнителей при проведении работ. Не последнее место в планах проекта занимают меры, которые предусматриваются в связи с рисками невыполнения работ, неудач маркетинговой политики и другими рисками. Наконец, планы проекта должны предусматривать меры для обеспечения качества производимых продуктов для потребителя.
Общим моментом любого конкретного планирования является определение форм и методов контроля, оценки результатов работ, а также оценки процесса их выполнения и организационного процесса. Этот аспект планирования должен обеспечивать своевременность воздействий на разработку в случаях отклонений от графика работ, намечающегося перерасхода ресурсов, в других нештатных ситуациях производственного процесса. Здесь главным принципом является упреждение: в каждой ситуации, требующей воздействий, должны быть заранее, т.е. до наступления ситуации, определены и известны варианты проводимых мероприятий. Это создает благоприятный микроклимат в коллективе, чувство уверенности в том, что проект в любом случае принесет успех разработчикам. Как следствие, все материалы, касающиеся планов проекта, должны быть для разработчиков открыты.
План любого проекта опирается на предпроектные решения, которые отвечают на вопросы о стратегиях развития проекта. При правильной организации проекта эти стратегии определят не только возможные, но и предпочтительные варианты. Они показывают, за счет чего проект может быть выполнен и как будут поступать разработчики в непредвиденных ситуациях. Они должны убеждать, что развитие проекта будет вполне управляемым. Кроме того, они указывают на то, какие обязательства готовы взять на себя разработчики. Наконец, должны быть представлены сведения о том, как обеспечивается качество и своевременность реализации замысла проекта. Комплект материалов, в которых фиксируются подобные сведения, мы относим к концептуальной базе проекта. Как минимум, эти материалы фиксируют следующее.

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

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

  • Тестирования и оценивания рабочих продуктов;
  • измерения качества и других показателей продуктов и процесса развития проекта.

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

  • соглашение об отслеживаемых существенных связях.

Если такое соглашение не вырабатывается заранее, то есть опасность стихийного, а значит, ненадежного порядка оперирования связями. Если оно вырабатывается, но не фиксируется документально, то есть опасность банального нарушения соглашения с теми же последствиями, что и в предыдущем случае.
В зависимости от ситуации концептуальная база может быть представлена в различных формах: как единый документ, как комплект отдельных документов или ссылок на уже существующие рабочие продукты (опыт предшествующих разработок). Как правило, обязательны к предъявлению лишь концепции развития проекта и план релизов (в той или иной форме, предписываемой методикой, выбранной для проекта), а также правовые и финансовые нормы и соглашения. Они вместе с определением технических, кадровых и финансовых ресурсов проекта и распределением времени (план-график работ) утверждаются руководством фирмы и заказчиком. Другие материалы концептуальной базы проекта являются факультативными, их не требуется ни предъявлять, ни утверждать. Но это не означает, что соответствующие работы можно игнорировать.
Любая концепция, а концептуальная база проекта есть не что иное, как собрание концепций, относящихся к разным аспектам проекта, — это соглашение между членами определенной группы людей. Для продуктивной деятельности соглашение о ней должно быть принято неукоснительно. По своей сути, это означает если не коллективное авторство, то по крайней мере коллективное одобрение. Достичь же согласия между людьми с разнонаправленными целевыми установками чрезвычайно трудно, а работать без него — неэффективно. Поэтому комфортнее всего подбирать команду под сформулированную концепцию. В то же время это противоречит весьма привлекательной для проекта ситуации, когда уже есть готовый коллектив единомышленников-исполнителей. Выход видится в том, чтобы в этом случае авторство концептуальной базы проекта было коллективным. Иными словами, над ней работают все исполнители проекта, занимающие ключевые роли (см. лекцию 3). Польза от такого решения еще и в том, что у работников появляется впечатление, что они создают проект и от их мнения многое зависит, а значит, разработка становится «своей».
Тем не менее ответственность за концептуальную базу лежит на менеджере. Он организует работы, необходимые для ее формирования, он предъявляет их результаты для утверждения. Как следствие, мы можем считать, что задача разработки концептуальной базы есть задача менеджера, который для ее решения делегирует свои полномочия другим разработчикам, и в первую очередь тем, кто выполняет ключевые роли в проекте. В настоящей лекции по отношению к менеджеру мы выбираем ролевую позицию и будем говорить о том, что именно он выполняет работы по формированию концептуальной базы, игнорируя фактическое делегирование.
Большинство материалов концептуальной базы проекта не являются статическими, т.е. такими, которые после утверждения не меняются. Так, при выборе стратегии итеративного наращивания модификация их в ходе выполнения рассматривается как характерное свойство подхода. Некоторые из работ, относящихся к подготовке концептуальной базы проекта, могут быть выполнены уже в ходе проектных работ (например, методика оценки — на этапе конструирования). Тем не менее рассмотрение их в рамках подготовки к выполнению проекта оправданно и полезно по следующим причинам:

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

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

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

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

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

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

Для этапов, связанных с производственной функцией планирования, описывается структура получаемых рабочих продуктов (планов), инструменты, применение которых полезно для поддержки составления плана и отслеживания планируемых работ.
Для работ, связанных с определением требований и с оперированием на уровне спецификаций, описываются форматы документного представления требований, а также инструменты, помогающие работать с ними: извлекать из проектного задания, из анализа предметной области и т.д., сортировать, выставляя приоритеты по различным критериям. Кроме того, определяется, как заказчик и конечные пользователи смогут влиять на развитие требований к программному изделию.
Для анализа и конструирования специфицируется нотация, применяемая для моделирования (ситуаций использования и сценариев, иерархий классов и системы взаимодействий и т.д.). Вообще говоря, такая нотация нейтральна по отношению к проекту, но она влияет на выбор поддерживающего инструментария и, возможно, на обучение персонала. Желательно, чтобы для проекта использовалась единая нотация и общий инструментарий, а не специальные средства на разных этапах. Обсуждение влияния выбора инструментария и, следовательно, методов работы и нотации на процесс проектирования также полезно представить в концепциях развития проекта, но оно не должно выходить за рамки цели данного документа.
Для программирования специфицируются используемый и целевой языки. Если это признается целесообразным, то описываются требования к генерации объектного кода и система инструментальной поддержки программирования. Принципы интеграции кода также должны быть представлены. Однако эту информацию, обычно относимую к уровню общих принципов концепций, в некоторых (и даже во многих!) проектах следует относить к специальным принципам и положениям.
Для этапа оценки в концепциях развития проекта предусматривается описание принципов верификации, тестирования и средств поддержки тестирования (генерация тестов и база данных тестов), а также аттестации. В этой же части концепций описываются принципы оценки качества программных продуктов и средств поддержки управления качеством. Вообще говоря, в части общих принципов и положений достаточно представлять лишь принципиальную основу этих аспектов проектной деятельности, но если в проекте для них не предусматривается специальных документных форм, то целесообразно осветить в концепциях и сами методики.
Конечно, говорить об «абсолютной» независимости общих принципов от реалий проекта было бы неправильно. В частности, разработчики должны знать и явно использовать постулаты, безусловно верные для данного проекта. Если они не выполняются, то независимая часть для такого проекта в принципе не может быть использована. Об этом обстоятельстве по разным причинам очень часто «забывают», а в результате — неоправданные ожидания успешности метода, методики, методологии в той области, в которой они просто неприменимы.
В качестве примера приведем очень часто популяризируемый метод декомпозиции проекта на работы, получивший название построения пооперационного перечня работ(WBS — work breakdown structure). Часто WBS переводится как иерархическая система работ — этим переводом мы будем пользоваться, когда требуется подчеркнуть способ построения WBS. Есть и другие переводы термина. Этот метод считается чуть ли не единственной основой любого проекта. Однако это не так! Он вполне подходит проектам, для которых достаточно хорошо известно, что надо получить в результате, или, по крайней мере, существуют способы точно выяснить это. Если проект можно рассматривать как детерминированно развивающийся (см. лекцию 5), то с помощью метода WBS достаточно технологично строится перечень работ, который позволит разумно оценивать затраты на разработку, распределять ресурсы, осуществлять другие менеджерские обязанности. Но как только это условие нарушается, возможности качественного применения метода резко падают. С точностью до этого ограничения методику WBS можно рекомендовать для применения в предпроектной деятельности менеджера проектов самых разнообразных областей, в том числе за пределами разработки программного обеспечения. Одно из главных ее достоинств в том, что она позволяет выделить в иерархически выстроенных работах проекта, необходимых для его успешного выполнения, уровень операций как частей проекта, допускающих непосредственное (в наших терминах — обозримое) управление и контроль выполнения заказчиком. Сумма операций проекта — это тот объем работ, о выполнении которого договариваются при составлении контракта.
Методика WBS применительно к концепции развития проекта рассматривается в следующем соотношении между общими и специальными принципами и положениями. Факт использования методики и обоснование адекватности ее применения — предмет рассмотрения общих положений концепции, а конкретизация использования, т.е. декомпозиция задач подготавливаемого к реализации проекта, относится к специальной части. Учитывая важность методики WBS для реальных проектов и достаточно широкую ее распространенность, в следующем разделе мы более детально обсудим ее содержание.


Специальные принципы и положения
Эта часть концепций развития проекта представляет проект с точки зрения предметной области и организации ведения работ. Она включает описание специфичных для проекта этапов жизненного цикла, их место среди общих фаз и этапов. Новые этапы могут быть введены как разбиение какого-либо из существующих этапов, например, для более качественного управления. Дополнительные этапы, объединяющие другие этапы, полезны для определения особых контрольных точек. Возможно выделение в виде этапа специальной работы (например, создание макетного образца). Реорганизация жизненного цикла должна способствовать целенаправленности развития проекта.
Важной задачей части концепций развития проекта, описывающей специальные принципы, является фиксация понятий, обозначений и терминов, общих для проекта. При разработке данного документа эта деятельность имеет целью создание основы глоссария проекта — специального рабочего продукта, который по мере развития разработки постоянно пополняется.
Для планирования необходимо определить декомпозицию проекта на работы, которые в свою очередь разбиваются на составляющие их работы, и то, какой уровень такой декомпозиции будет считаться доступным для непосредственного контроля. Эта задача решается по-разному. В качестве методики, применимой во многих случаях, рассмотрим построение пооперационного перечня работ WBS, упомянутое в предыдущем разделе. Ее основа — применение подхода системного анализа, который предписывает путь достижения целей с помощью разбиения целей на подцели до уровня самоочевидно достижимых целей. В результате построения дерева целей достижение замысла становится обозримым и управляемым: можно выстраивать ту или иную последовательность деятельностей, выполнение которой ведет в конечном итоге к общей цели.
Методика WBS в полном соответствии с принципами системного подхода предполагает, что для получения желаемого продукта необходимо явно выделить, из каких подпродуктов он складывается и с помощью каких действий может быть реализован. В соответствии с этими установками возможны две стратегии построения WBS.
Первая стратегия, называемая продуктовой декомпозицией проекта, исходит из деления продукта на подпродукты. Подпродукты в свою очередь разбиваются на составляющие до того уровня, на котором продукты реализуются очевидно, т.е. с использованием локального планирования и управления. Считается, что на этом уровне можно определить, какие ресурсы нужны для работ, выполнение которых приведет к реализации локального продукта. Сумма потребностей ресурсов определяет общую ресурсную потребность проекта. Сумма сроков разработки локальных продуктов с учетом возможности распараллеливания работ дает оценку времени выполнения проекта. В этой стратегии при построении иерархического разбиения выдерживается принцип ответа на вопрос: «Из чего состоит (разбиваемый) продукт?». Операцией (т.е. неделимым с точки зрения проекта действием — см. предыдущий раздел) считается работа, необходимая и достаточная для построения листа в иерархии продуктов.
Вторая стратегия, называемая работной декомпозицией проекта, исходит из выделения частей работ, необходимых для построения продукта. При построении иерархического разбиения выдерживается принцип ответа на вопрос: «Какие работы нужно выполнить для построения продукта?». Каждая из таких работ производит определенные результаты — продукты соответствующих вершин составляемого дерева, которые в сумме должны обеспечить выполнение проектного задания. И в этом случае можно говорить о суммарных потребностях времени и других ресурсов для проекта.
Совмещение двух стратегий возможно, но это делать не рекомендуется, поскольку повышается уровень риска неуправляемого использования двух отношений при построении иерархий, а значит, и ошибок в иерархической системе работ.
Хорошее представление о методе WBS можно получить из книги.
Оба подхода к построению иерархической системы работ приводят к определению перечня работ всего проекта, который вполне допускает обе методологические стратегии реализации проекта: определение этапов для последовательного развития и сужение задачи проекта путем распределения работ по итерациям (см. лекцию 5). Но, как уже не раз отмечалось, из-за неполноты исходных требований для существенно недетерминированных проектов этот путь ведет в тупик неопределенности.
Альтернативный путь — отбор требований для ближайшей задачи. Он состоит в том, что нужно произвести трансформацию требований, известных на данный момент, до моделей представления сценариев на уровне анализа (см. лекцию 12). Далее согласовываются не работы-операции, а сценарии, которые, по мнению инициаторов работ, следует реализовывать в той или иной последовательности и, значит, распределить их по итерациям и релизам. Сценарии как основа контрактного соглашения легче понимаются заказчиком, чем абстрактные работы-операции, которые предъявляются ему для утверждения. И хотя здесь сразу же встает вопрос о критериях отбора сценариев, в качестве естественной конструктивной основы для его решения можно рекомендовать оценку актуальности сценариев, реализуемых в рамках ближайшей задачи, инициаторами работ. Как мы не раз замечали, понимать актуальность можно по-разному, и именно эти различия выделяют варианты методологий организации проектной деятельности.
При декомпозиции, связанной с отбором требований, могут возникнуть проблемы с оцениванием ресурсной потребности для реализации сценариев. Заказчик может недоумевать, почему такое простое с его точки зрения средство разработчиками оценивается как ресурсоемкое. Для преодоления трудности можно снова рекомендовать построение пооперационного перечня работ, но уже для каждого из отбираемых сценариев, с последующим слиянием перечней и упорядочением-распределением по итерациям. Следует, однако, иметь в виду, что этот прием резко снижает преимущества сценарной декомпозиции для заказчика — ее понятность. По вполне очевидным причинам пооперационные перечни работ при сценарной декомпозиции оказываются сложнее, чем при построении подобного перечня для проекта в целом: на уровне обсуждения контракта нет возможности воспроизвести мотивы объектно-ориентированного проектирования, принятые при определении операций.
Выбор варианта стратегии декомпозиции во многом зависит от специфики проекта и взаимоотношений с заказчиком. Поэтому можно предположить, что он должен быть отнесен к части концепций, отражающей специальные принципы и положения. Однако материалы, на основании которых менеджер выбирает стратегию, в полной мере могут быть использованы и в других проектах. Поэтому факт принятия стратегии декомпозиции целесообразно отнести к общей части концепции, а в части специальных принципов и положений показать допустимость этой стратегии для данного проекта и представить результаты применения ее в виде конкретной декомпозиции до уровня выработки контрактных соглашений.
Менеджер вправе включать в концепции дополнительные сведения по своему усмотрению. Такое расширение содержания документа направлено на более точный учет специфики проекта при управлении. Например, некоторый заказ предполагает работы, связанные обучением персонала у заказчика. Чтобы организовать обучение, нужно провести дополнительную работу, определение которой невозможно без сведений о персонале (уровень квалификации, возможности учиться с отрывом и без отрыва от работы и др.). Соответственно, концепции должны определить принципы организуемой деятельности, ее возможные варианты.

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

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

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

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

Конечно, эти документы для проекта, который решено реализовать по шаблону MSF, нуждаются в конкретизации. Скорее всего, при такой конкретизации потребуется выделить части, относящиеся не к концепциям развития проектов, а к другим материалам концептуальной базы. Но это неизбежная работа с любыми переиспользуемыми материалами, которая необходима, в частности, для того, чтобы решить, подходит ли предлагаемая методология для целей конкретного проекта.
В качестве исходного материала для концепций реального проекта, для которого принимается методология экстремального программирования, целесообразно воспользоваться книгой Бека . Другие его книги, обсуждающие принципиальные аспекты этого подхода (тестирование , планирование ) помогут при подготовке концептуальной базы проекта. Понятно, что цели пропагандистских монографий не совпадают с целями организации проектной деятельности, а потому не следует принимать наши рекомендации буквально.
На фоне предыдущих иллюстраций подход RUP, представленный в книге, выглядит менее концептуальным, поскольку авторы пытаются представить все возможные варианты использования системы понятий, не фиксируя методологии. Отсюда, несмотря на заверения о привязке «рациональных» процессов к модели жизненного цикла, книга представляет собой лишь содержательный рассказ о том, как можно применять разработанные соглашения и инструменты (в этом качестве обсуждаемая монография оказывается очень полезной). Гораздо точнее объектно-ориентированное проектирование представлено в монографии , которая излагает шаблоны проектирования без претензий на концептуальное и методологическое обобщение. Если же обратиться к классической для объектно-ориентированного проектирования книге Г. Буча , то говорить о ней как об основе концепции развития проекта или хотя бы как о ее проектно-независимой части не приходится, но уже по другой причине. Она нацелена на доказательство продуктивности подхода в целом и в этом качестве вполне убедительна и полезна.

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

  • логики поступательного развития;
  • важности постепенного предоставления средств заказчику, которому план дает представление о последовательности удовлетворения требований к изделию.

Следовательно, план выпуска релизов должен составляться менеджером при тесном контакте с системным архитектором, с одной стороны, а с другой — в ходе содержательного обсуждения с заказчиком. В частности, выделение ближайшей задачи проекта (см. лекцию 9) — это не что иное, как планирование первого релиза разрабатываемой системы. И этот релиз не должен противоречить логике развития.
Совместная работа менеджера, архитектора и заказчика над планом релизов особенно важна для больших проектов, когда только за счет постепенности наращивания предоставляемых пользователю средств можно добиться действенной обратной связи для корректировки априорных решений. В то же время и не очень большие проекты, даже такие, которые предусматривают лишь один релиз, нуждаются в аналитическом исследовании, определяющем группировку и дифференциацию итераций, другие элементы декомпозиции. По существу, независимо от масштабов проекта план релизов задает основу общего плана проекта, согласованного с пользовательской потребностью.
Из этого следует, что план выпуска релизов должен составляться и утверждаться как можно раньше. Фактически все обязательные предпроектные работы (составление документов о концепции развития проекта и распределении ресурсов, построение плана-графика работ) исходят из пользовательского представления процесса разработки как последовательности поставок — релизов проектируемого изделия. В частности, при составлении плана выпуска релизов и его согласовании выясняется, какие решения неприемлемы для компании и для заказчика. Если проблемы окажутся неразрешимыми, то это свидетельствует о том, что от заказа придется отказаться, и чем раньше выяснятся подобные обстоятельства, тем менее болезненным будет разрыв отношений со всех точек зрения.
Вообще говоря, работа над планом выпуска релизов — это отбор вариантов на основе анализа общих требований, учитывающий, что из того, что хочется получить заказчику, можно сделать наиболее быстро. Но без детализации требований зачастую невозможно отдать предпочтение тому или иному варианту. Поэтому план выпуска релизов должен быть открыт для включения альтернативных вариантов, которые отсеиваются при детализации на основе опыта развития проекта. Целесообразно производить ревизию плана релизов после завершения работ каждой итерации, т.е. на ее этапе оценки. В это время производятся комплексные измерения проекта, которые уточняют предварительную оценку продуктивности выполнения работ и полезности рабочих продуктов. Полученная информация позволяет корректировать план релизов и сделать его более реалистичным. Новая версия плана утверждается после появления очередного релиза.
При первоначальном составлении плана релизов не стоит стараться слишком детализировать его этапы, если нет четких критериев, когда должен окончиться один этап и начаться другой. Вместо этого проект просто разбивается на 6–8-недельные итерации каждого релиза, исходя из возможностей реализации требуемых функций. Вопрос о том, какие функции к какой итерации должны быть отнесены, решается на основе принципа: ближе к началу проекта относят в первую очередь наиболее приоритетные функции, во вторую очередь — более простые для реализации функции. Последнее делается с целью оставить разработчикам время для более полного изучения предметной области в ходе подготовки первого релиза, а также для решения организационных вопросов. Подробное обсуждение этого вопроса представлено при изложении критериев предпочтения в разделе «Модификация модели фазы—функции» лекции 9.
Чтобы избежать сбоев из-за нарушения плана выпуска релизов при выполнении итерации не следует завершать работу с этим планом в ходе конструирования. Если становится ясно, что по тем или иным причинам рабочие продукты, запланированные к выпуску на данной итерации, не могут быть сделаны вовремя, рекомендуется воспользоваться следующими приемами корректировки плана:

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

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

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика