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

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

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

В отличие от традиционных подходов быстрые методологии ориентируются на то, что деятельность по производству программного обеспечения по сути своей является преимущественно креативной, т.е. такой, в которой от разработчиков требуется не только распознавание ситуаций и применение в них известных методов, но и конструирование новых методов действия^{4Слово "преимущественно" в обоих случаях употреблено по той причине, что в реальности любой субъект-исполнитель проекта выполняет целый спектр деятельностей, одни из которых оказываются императивными (так предписано их выполнять), а другие — креативными (вместо предписаний для их выполнения используются указания ситуаций и другие приемы высоких уровней знаний и умений).} . А это другой, более высокий уровень знаний и умений (см. [ 16 ] ). Как отмечает Фаулер [ 24 ] , процесс разработки программного обеспечения, постоянно адаптирующийся к меняющимся требованиям пользователей, принципиально непредсказуем. Это качество обуславливает креативность деятельности не только в начале проекта, но и в течение всего его развития. Непредсказуемость и креативность разработки программного обеспечения указывает на то, что готовых рецептов на все случаи жизни просто не хватит, а потому среди элементов деятельности должны иметь больший удельный вес средства и инструменты, нежели методы^{5Здесь, как и в случае традиционных подходов, говорится о непосредственных методах деятельности, т.е. о тех, которые связывают воедино ресурсы, средства и инструменты в данной деятельности, а не о методах применения инструмента, влияющих на результат косвенно (владение методами применения инструмента — элемент квалификации исполнителя).} .

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

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

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

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

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

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

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

Представленное определение технологии достаточно конструктивно: в любой ситуации, когда элементы деятельности определены, можно задавать вполне конкретные вопросы, позволяющие выяснить технологичность. К сожалению, проверка области разработки программного обеспечения на практике свидетельствует, что технологичность ее деятельностей характеризуется фрагментарностью: отдельные виды работ доведены даже до уровня автоматизации, но комплексной технологии, охватывающей весь процесс, не предлагает никто. Скорее всего, сложность этого производства, а также объективная непредсказуемость его (о чем красноречиво пишет, например, Фаулер [ 24 ] , с чем согласны многие непредвзятые исследователи — см., например, [ 15 ] ) не позволяют говорить об универсальном технологическом процессе на все случаи жизни. Претензии RUP [ 30 ] — не в счет, и в свое время мы еще вернемся к этому вопросу.