Каждой методологии - свое время

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

Краткий обзор дискуссии

Эта статья - логическое продолжение предыдущих работ: "Characterizing people as first-order, non-linear components of software development" [Co1] (в русском переводе: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения") и "A methodology per project" [Co2] (в русском переводе: "Каждому проекту своя методология"), где обсуждалась возможность создания гибкой "человекоцентричной" методологии для отдельно взятой команды, причем непосредственно в процессе работы над проектом.

Суть изложенного в этих статьях материала сводится к следующему:

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

Можно, конечно, начинать давать рекомендации, основываясь только на принципах конструирования методологии (даже притом, что относительно самих этих принципов до сих пор нет единого мнения). Впрочем, один из них гласит, что в любом проекте человеческий фактор может легко возобладать над процессом (см. [Co1], [Wei]). Легкие методологии, основанные на межличностных коммуникациях, представляют собой довольно прочные структуры (см. [Co2]). Их оптимальный "вес" может разниться от проекта к проекту, в зависимости от количества занятых в работе людей и близости их физического размещения, а также ущерба от возможного сбоя системы (см. [Co2]).

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

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

Данная работа состоит из следующих частей:

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

"Каждому проекту своя методология" и свойства человеческой натуры

Первая из двух статей, на основе которых я написал эту, называется "Characterizing people as first-order, non-linear components of software development" [Co1] (в русском переводе: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения"). Заканчивается она следующим образом:

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

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

Во-первых, мы, люди, весьма сильно реагируем на временную синхронизацию и модальности коммуникации. Я считаю, что физическая досягаемость собеседника и удобство общения имеют здесь решающее значение.

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

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

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

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

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

Второй статьей была "A methodology per project" [Co2] (в русском переводе: "Каждому проекту своя методология"). Она заканчивается такими словами:

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

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

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

Объединив и то, и другое, получаем:

1. Каждый проект заслуживает своих собственных процесса и методологии, созданных специально для него.
2. "Легкость" и непосредственное общение являются весьма желательными их атрибутами.
3. Наиболее эффективно люди общаются непосредственным образом - лицом к лицу.
4. Непостоянство, непоследовательность и лень представляют собой самые заурядные человеческие слабости, которые всегда нужно учитывать при конструировании методологии (ключевая фраза: "процессы, требующие высокой дисциплины, обречены на хрупкость").
5. Процесс разработки должен строиться на положительных качествах человеческой натуры: чувстве гражданской ответственности, способности ориентироваться в обстановке, общаться друг с другом и проявлять инициативу.

Источники

Эта статья основывается на результатах работы над реальными проектами, а также исследованиях и опросах, проведенных мною в период с 1991 по 1999 гг. Большая часть собранных материалов так или иначе представлена в работах [Co1], [Co2] и [Co3].

Все эти идеи подтвердились после опроса тех организаций, которые сумели добиться таких же успехов, разрабатывая аналогичные методологические подходы. В Великобритании IBM Object Technology Practice уже несколько лет проводит семинар по так называемой "настройке методологии" в начале каждого проекта. Что-то подобное делает в Мюнхене Siemens. А один из военных субподрядчиков во Флориде рассказал, как его сертифицированная по ISO-9000 группа разработчиков создает особый легкий процесс для каждого вида работ (при помощи контрольных таблиц для процесса).

Я также использовал работу Керта (Kerth), [Ke], где рассматривается техника ретроспективного анализа работ (обычно их называют "разбором полетов", но этот автор использует понятие "послеродовый осмотр").

С процессом осуществления изменений в структуре и в принципах работы команды в конце каждого инкремента я впервые познакомился во время работы над проектом "Ingrid", [Co3] в 1992. Тогда без этого было просто не обойтись. С тех пор я внес в метод некоторые дополнения, а именно объединил его с правилом "настраивать" методологию еще и в середине инкремента. После я открыто использовал этот принцип в работе над проектом "Winifred" [Co3], и когда работал в Центральном Банке Норвегии [Co2]. Кроме того, мой коллега использовал принцип "настройки" методологии в конце каждого инкремента, работая над проектом "Insman" в Германии [Co2]. Все три проекта окончились успешно, причем применение такой методологии явно повлияло на качество результата.

В течение многих лет при разработке ПО использовались самые разнообразные методологии (как в случае уже упомянутых IBM и Siemens, а также описанные в работах [MO] и [Gr]). Однако, насколько мне известно, первой методологией, которая рекомендует динамически менять процесс во время проекта, является Crystal.

Идея заменить письменную документацию непосредственным личным общением была высказана давным-давно. Ее отстаивал в конце 60-х Вайнберг (Weinberg [Wei]), а в конце 70-х - Демарко (и снова он, но уже в 90-х [De1], [De2]). С тех пор многие использовали эти идеи как "секретное оружие", а недавно вышли из подполья - независимо и сразу в нескольких местах:

• в методологии под названием eXtreme Programming ([Be] (в русском переводе "Экстремальное программирование", "Питер", СПб, 2002)
• в семействе легких методологий Crystal [Co4]
• в методологии Adaptive Software Development ([Hi])
  
  
  
  

  Предыдущая страница - Следующая страница »