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

 

Методологические стратегии

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

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

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

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

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

Жесткие и гибкие стратегии в методологиях программирования
Определяя стратегии последовательного и итеративного развития проектов, мы исходили из того, что контроль деятельности проекта — задача, требующая специальных организационных подходов. Общей целью является превращение создания программного продукта в упорядоченный процесс, в рамках которого развитие проекта можно сделать более прогнозируемым и эффективным. Для этого обычно создается детальное описание процесса разработки системы, особое место в котором занимает планирование. Иначе говоря, создается метод, с помощью которого предполагается конструировать систему. Удачные методы обобщаются, в результате опыт их применения превращается в методику, или, как сейчас принято говорить, методологию. Нередко при таком формировании методики-методологии фиксируются частные и случайные решения, оказавшиеся полезными из-за специфики удачных проектов. Наряду со всем полезным эти решения объявляются обязательными, стандартными, их вынуждены применять и тогда, когда исходные предпосылки утрачены. Чтобы следовать таким методологиям, приходится выполнять множество различных предписаний, что замедляет темп основных программистских работ. Поэтому их называют тяжеловесными, жесткими или, согласно , монументальными.
Жесткие методологии привлекательны для заказчиков программных проектов, которые всегда могут проверить, действительно ли процесс разработки упорядочен и результаты соответствуют планам. Естественно связывать эту возможность с организацией, которая получает заказ и обеспечивает его менеджмент, поскольку помимо благих пожеланий (чаще всего они-то и нарушаются!) в организации возможен административный контроль.
В настоящее время разработаны стандарты зрелости процессов разработки программного обеспечения в организациях. Среди них наиболее развитым является предложение Института программной инженерии при Университете Карнеги–Меллона — так называемая модель SW-CMM (Capability Maturity Model for Software). Эту модель можно считать общепринятой, поскольку на нее чаще всего ориентируются заказчики, в частности из Министерства обороны США, предлагая проекты только тем организациям, которые сертифицированы на уровнях зрелости 4 и 5 (мы еще будем обсуждать эту модель). Как замечено в , модель CMM была сформирована при существенном влиянии практики военных заказов с их жесткой процедурой контроля и отчетности. Предложения CMM для определения зрелости организации опираются на то, какие процедуры управления программными проектами, отслеживания их развития и другие менеджерские методы приняты в качестве фирменного стандарта. Методологии программирования, построенные на базе этих предложений, часто рассматривают как эталон жесткости.
В противовес жестким методологиям в последнее время сформировался компромиссный подход, методологии которого объединены общим термином agile development. На русский язык его переводят как быстрое развитие, гибкие методологии (см. перевод статьи М. Фаулера) и даже «шустрые технологии». В новом подходе пытаются предоставить возможность облегченной организованной работы программистских коллективов, когда перегруженность стандартизованного процесса препятствует эффективности. Они претендуют на то, что их применение возможно даже когда не удается достаточно точно представить проект при его зарождении, т.е. в довольно типичной ситуации неопределенности реальной пользовательской потребности. В этих случаях предлагается привлечение заказчика к формированию задач и корректировке предположений в течение всего развития проекта. С его помощью пытаются выявлять наиболее точно и без излишних бюрократических процедур актуальные потребности пользователей, сложившиеся на текущий момент. В результате появляется возможность указать именно те требования, реализация которых необходима и допускает максимально короткие сроки выпуска релиза.
Все методологии быстрого развития ориентируются на стратегию итеративного наращивания возможностей системы, но с частичным отказом от постулата неизменности априорной архитектуры (как следствие, не только допускается, но даже предполагается, что архитектура системы, а значит, и программный код будут меняться при переходе от релиза к релизу). Все они предоставляют разработчикам значительно большую свободу, чем, к примеру, требования стандартов CMM. Но не следует думать, что этот подход полностью отменяет жесткие методологии. Как указывают Боэм и Тюрнер, необходим баланс между свободой быстрых методологий и дисциплиной.
Охарактеризовать все методологии быстрого развития по отдельности не представляется возможным — слишком различны их исходные принципы, слишком зависимы они от специфики коллективов, занимающихся разработками программного обеспечения, от зачастую стихийно складывающихся предпочтений, привычек. На стратегическом уровне их действительно объединяет так называемый Agile Manifesto , принятый энтузиастами в феврале 2001 года в местечке Сноуберд (США), который сводится к четырем постулатам:

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

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

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


Таблица 5.1. Сопоставление жесткой и быстрой стратегий в методологиях программирования

Жесткие методологии

Быстрые методологии

Ориентация на предсказуемые процессы разработки программного обеспечения с четко обозначенными целями

Осознание того, что процессы разработки программного обеспечения в принципе непредсказуемы

Распознавание ситуаций и применение готовых методов

Распознавание ситуаций и конструирование методов для работы в них

Планирование, в котором определяются этапы с объемом работ, ресурсами, сроками и уровнем качества работ

Соблюдение баланса между параметрами проекта: объем работ, ресурсы, сроки и уровень качества работ

Заказчик — внешний по отношению к проекту субъект, влияющий на разработку только через предоставление ресурсов и контроль результатов, в том числе по поэтапным срокам выполнения проекта

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

Ролевое разделение труда работников проекта

Совместная деятельность сотрудников и деперсонифицированная ответственность

Дисциплина и подчинение

Самодисциплина и сотрудничество

Обезличенный процесс, исполнители которого определяются только по квалификационным требованиям

Процесс, максимально учитывающий личностные качества исполнителей

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

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

В определении явно просматривается использование понятий треугольника менеджмента проектов и элементов деятельности, но дополнительное в нем то, что оно фиксирует детерминированный процесс производства, в котором нет места творчеству. Именно творчество препятствует гарантиям получения ожидаемого результата в заданные сроки.
Когда говорят о детерминированной деятельности, обычно под этим понимают, что отсутствуют непредусмотренные, а значит, и не обеспеченные методами действий ситуации. В контексте понятия технологии, кроме того, следует выделить и другой аспект детерминизма: связку методов и целей, которой подчинены заданные средства и инструменты. Когда детерминизм нарушается, т.е. приходится решать проблемы выбора или сталкиваться с непредвиденными ситуациями, наступает конец технологии, и разработка вступает в область ремесленного производства, которое, быть может, и более привлекательно (за счет творческой составляющей), и вполне может приводить к повышению качества, но не гарантирует ни результата, ни соблюдения сроков.
Разработчики жестких методологий старательно и последовательно изгоняли недетерминизм из производства программного обеспечения. Там, где это не удавалось, они выставляли своеобразные ограждения: с одной стороны, это типовые приемы, указания и рекомендации, а с другой — измерения процесса и результатов, контрольные мероприятия и многое другое.* Но, несмотря на появление разнообразных методик, средств и инструментов поддержки управления, которые вынуждены применять менеджеры (что как раз и стало предметом критики сторонников облегченных методологий), особого успеха добиться не удалось. Причина тому – и уже не раз упоминавшаяся изменчивость требований, и свойственная природе человека склонность допускать ошибки на всех уровнях работы. Ограждать ситуации от возможных ошибок, помогать их поиску, использовать средства автоматизации, способные ликвидировать многие рутинные операции, мы научились, а потому можно говорить о некоторой технологизации. Но от этого креативный процесс программирования не стал подобен тому, что демонстрирует материальное производство или, к примеру, бухгалтерский учет.
Представленное определение технологии достаточно конструктивно: в любой ситуации, когда элементы деятельности определены, можно задавать вполне конкретные вопросы, позволяющие выяснить технологичность. К сожалению, проверка области разработки программного обеспечения на практике свидетельствует, что технологичность ее деятельностей характеризуется фрагментарностью: отдельные виды работ доведены даже до уровня автоматизации, но комплексной технологии, охватывающей весь процесс, не предлагает никто. Скорее всего, сложность этого производства, а также объективная непредсказуемость его (о чем красноречиво пишет, например, Фаулер, с чем согласны многие непредвзятые исследователи — см., например, ) не позволяют говорить об универсальном технологическом процессе на все случаи жизни. Претензии RUP — не в счет, и в свое время мы еще вернемся к этому вопросу.

 

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