18 лекция

Лекция 18. Результативность программистской проектной деятельности

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

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

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

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

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

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

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

Рабочие продукты

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

• познаваемость продукта — необходимо, чтобы пользователь был в состоянии понимать:

• что можно получать, используя предлагаемую программную си­стему;

• чего нельзя ожидать от нее;

• как активизировать функции системы;

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

• познаваемость процесса разработки продукта — необходимо, чтобы разработчики были в состоянии:

• развивать проект;

• принимать согласованные решения;

• сбалансировано выполнять коллективную работу.

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

Прежде чем обсуждать их, рассмотрим одну любопытную точку зре­ния (метафору) на программный проект, высказанную еще в конце семи-1есятых годов Ф.Я. Дзержинским [13]. Суть ее в том, что любая документация оказывалась бы ненужной, если бы можно было сопровождать каждую поставку программы ее автором. Иными словами, идеальная доку­ментация — это разработчик программного продукта; он в состоянии давать адресные и самые квалифицированные консультации, конструк­тивно отвечать на вопросы пользователей. Таким образом, в точке зрения Дзержинского отражен взгляд на документацию как на заместителя раз­работчика при используемой программе. Отсюда следует и критерий каче­ства документации: она тем лучше, чем точнее имитирует непосредствен­ное взаимодействие разработчиков с пользователями. Взгляд на докумен­тацию как на заместителя разработчика позволяет сделать явным разгра­ничение между видами документов для разных вариантов использования: в разных ситуациях требуются различные консультации и разъяснения.

Подобная точка зрения на документацию высказывалась и ранее (см., например, [2]), но потом была почему-то забыта. И очень часто на составление документов, сопутствующих программам, смотрят как на обузу, заслуживающую внимания лишь постольку, поскольку она требует­ся стандартами приемки программ. Нередки высказывания о том, что се­годня система помощи заменяет документацию. Но даже если оставить в стороне качество систем помощи, то все равно очевидно, что она в прин­ципе не решает вопросы познаваемости процесса производства и отвеча­ет требованию познаваемости продукта лишь в той части, которая касает­ся непосредственного применения.

В первом приближении можно указать на следующие виды рабочих продуктов проекта.

• Программные продукты. Это не только целевая программная систе­ма, но и компоненты программного обеспечения, выделенные дл* внешнего применения (библиотеки, библиотеки классов и др.)- *

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

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

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

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

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

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

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

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

Есть еще одна группа продуктов, которая выделяется в связи с дея­тельностью наблюдения за производственным процессом, формированием целевых продуктов и их применением. Эта деятельность оказывает опосре­дованное влияние на процесс, предоставляя ему свои результаты. Но эти же результаты могут использоваться независимо от проекта. Таким образом, выделяется группа продуктов, отражающих наблюдение за проектом.

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

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

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

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

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

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

Уровни зрелости процессов разработки программного обеспечения

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

Этот аспект замечен и зафиксирован в модели зрелости процессов разработки программного обеспечения SW-CMM [18] (см. лекцию 5). По­скольку одной из основных целей модели является построение организа­ционной процедуры сертификации организаций, разрабатывающих про­граммное обеспечение, она исходит из стандартизованной классифика­ции организаций, распределения их по нескольким уровням. На каждом из уровней в принципе может достигаться определенная результативность проектов, отслеживание которой — задача специальной деятельности, обеспечивающей процедуру сертификации достоверной информацией. Исходным материалом для этой деятельности являются все рабочие про­дукты проектов, в частности документы, отражающие процесс развития и контроля реализации проекта. Ее основной сертификационный резуль­тат — отнесение организации к одному из пяти уровней зрелости:

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

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

2. Определенный (defined) уровень, или уровень становления. На этом уровне в организации принят стандарт проведения разработки и со­провождения программного обеспечения, в рамках которого обес­печена интеграция процессов построения и управления. Разработ­ка и сопровождение полностью документированы, что позволяет организовать наблюдение и контроль выполнения проектов. В ма­териалах СММ такой стандарт называется стандартным производ­ственным процессом организации. Для конкретных проектов стан­дартный производственный процесс адаптируется с целью учета его особенностей, в результате чего определяются критерии готовно­сти, качества и т.д., а также механизмы контроля. За счет ясной оп­ределенности процессов руководство организации получает точную картину развития проектов. Продуктивность производственного процесса на определенном уровне характеризуется как стандартная и согласованная. На этом уровне к рабочим продуктам каждой из групп предъявляются дополнительные требования: они должны быть представлены таким образом, чтобы специфика проекта явно отделялась от стандартизованного содержания, то есть чтобы при производстве рабочих продуктов максимально повышалась воз­можность их независимого от проекта применения.

Управляемый (managed) уровень. Согласно СММ, этот уровень ха­рактеризуется внедрением в организацию количественных пока­зателей качества как для программных продуктов, так и для про­цессов их разработки. Производственные процессы управляемого уровня оснащены средствами для проведения четко определенных и согласованных измерений. Продуктивность производственного процесса на управляемом уровне характеризуется как предсказуе­мая, так как процесс функционирует в заданных и измеряемых пределах. Иначе говоря, предполагается, что за счет количествен­ных показателей качества удается организовать наблюдение за любой проектной деятельностью, которое позволяет удерживать траекторию в области допустимости. Дополнительные требования к рабочим продуктам этого уровня заключаются в том, что конкретизируется и получает статус обязательного стандарта группа продуктов, отражающих измерения и наблюдение за проектом*. 5. Оптимизирующий (optimizing) уровень. Работа над прожектами ве­дется как на управляемом уровне, но организация в целом сосре­доточена на усовершенствовании производственного процесса. Она обладает средствами выявления слабых мест процесса и его улучшения с цельно предотвращения дефектов. Внедряются нов­шества, использующие передовые методы программной инжене­рии, которые распространяются для улучшения качества разрабо­ток всех проектов.. В рамках оптимизационного уровня налажены механизмы оценки не только выполненных проектов (это идет от предыдущего уровня), но и возможны* новаций во всех аспектах проектирования**. Таким образом, ассортимент используемых ра­бочих продуктов не ограничивается тем, что появляется по ходу выполнения целевых проектов. Необходимые для оптимизирую­щего уровня продукты могут разрабатываться специально. Нес­колько иронично оптимизирующий уровень иногда называют «нирваной проектной деятельности» [47].

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

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

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

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

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

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

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

К сожалению, на этом пути встречаются три проблемы.

• Искушение распространения удачного опыта за пределы его области применимости.

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

В качестве примера рассмотрим каноническую для объектно-ори­ентированного подхода с использованием UML рекомендацию со­ставлять три вида диаграмм классов: концептуальные, специфици­рующие и реализационные, которые отражают разные стадии уточнения разрабатываемой системы классов [25]. Обычно указы­вают, какие из средств UML нужно применять для диаграмм каж­дого вида. Однако UML-нотация — это универсальная система, и нет никакой возможности объяснить ей, что вот сейчас составля­ются концептуальные диаграммы, а потом нам потребуются спе­цифицирующие и далее реализационные диаграммы. Во всех трех случаях используются одни и те же средства, а значит, один метод, различия классов диаграмм системно не поддерживаются, т.е. ме­тодическая рекомендация остается на уровне пожелания, которое могут игнорировать.

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

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

Все это с очевидностью прослеживается в истории стандартизации производственных процессов в области разработки программных систем, и модель СММ в полной мере отражает обе проблемы. • Третья проблема может быть охарактеризована как груз стандартов. Суть ее в том, что по мере развития методических предложений и рекомендаций и превращения их в стандартизованные предписа­ния, которые нужно выполнять неукоснительно, появляется все больше обязательных требований к процессу ведения проекта. Если бы программирование можно было рассматривать как импе­ративную деятельность, то обязательность требований к процессу была бы вполне мотивирована*. Однако, как мы уже отмечали в разделе «Жесткие и гибкие стратегии в методологиях программи­рования» лекции 5, креативность процесса разработки программ делает эту мотивацию несостоятельной. Обязательные требования к процессу не дают преимуществ, а лишь усложняют его, делая «монументальным», громоздким и негибким. Естественная реак­ция на такое положение — отказ от тяжеловесных стандартов — от­ражена в концепциях быстрых методологий, зафиксированных в Agile Manifesto [31].

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

* В связи с этим хочется привести аргумент из реального спора с одним из апологетов импера­тивности программистской деятельности: «Мы вправе не знать, почему летает самолет, но если будем поступать так-то и так-то, как поступают при строительстве самолетов в ком­пании «Боинг», то в результате получим машину, которая непременно полетит. Также и с про­граммами: мы знаем, какие практики хорошо себя зарекомендовали, а потому давайте следо­вать им неукоснительно». На возражение, что в этом случае мы сможем строить только та­кие программы, которые придуманы ранее, был ответ (не лишенный логики!): «Именно это и требуется со стороны практического применения программных систем».