Мы все видели, как спортивные команды побеждают, несмотря на ошибки одного из участников. Мы также видели, как отдельные игроки замечательно себя чувствуют, в то время как их команда безнадёжно проигрывает. Таким образом, успех или поражение отдельного человека никак не связаны с успехом или неудачей группы в целом. Таков изъян ситуации, лишь обостряющий любую зарождающуюся тенденцию к конкуренции.
Контрастирующий пример – хор или музыкальная группа, создающие практически идеальную связь между успехом или неудачей одного человека и успехом или неудачей всей группы. (Никто и никогда не поблагодарит вас за хорошее пение, если хор в целом пел отвратно.)
Так что мы должны запоздало сообщить, что музыкальный ансамбль – более подходящая метафора для слаженной рабочей группы. Конечно, мы не единственные, кто использует слово «команда» для описания подобной группы. Здесь имеет значение не название – «команда», «ансамбль» или «гармоничная рабочая группа», – но осознание всеми участниками того факта, что успех отдельного человека неизменно связан с успехом коллектива в целом.
29. Программы модернизации процессовТе замечательные ребята, что в восьмидесятых познакомили нас с Методологией с большой буквы М, без дела не сидели. Их последнее новшество – Движение За Улучшение Процессов, более современное, более всеобъемлющее, оно лучше, в нем больше лоска, оно ещё более амбициозно… но по сути это все то же старьё. Ваша локальная Программа Модернизации Процессов – все та же Методология, но переродившаяся. На этот раз подход «универсального размера» достиг апогея: один размер теперь подходит не только всем в вашей компании, он ещё и всем во всем мире. Способности вашей организации измеряются в контексте жёсткой модели. Чем точнее вы соответствуете модели, тем выше ваш балл. Чем выше, тем лучше. Самый высокий балл – лучше всего. Если бы все организации получали самые высокие баллы, они все были бы лучшими, и (так уж получается) выполняли бы свою работу абсолютно одинаково – лучшим способом. Лучший – он и в Африке лучший, тут нет разницы между веб-приложениями для Yahoo и подпрограммами учёта пенсий в Aetna. По крайней мере, в теории…
Краткий исторический экскурс
На случай, если последние пятнадцать лет вы прожили на другой планете, мы представляем новейшую хронологию усовершенствования процессов:
1984: Министерство обороны США (U.S. Department of Defense, DoD) создаёт Институт программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги-Меллон. На институт возлагается миссия «создания стандартов совершенства в разработке программного обеспечения».
1987: SEI публикует первую пятиуровневую схему оценки «зрелости программного обеспечения».
1988: Опубликована важнейшая работа Уоттса Хамфри (Watts Humphrey) «Characterizing the Software Process: A Maturity Framework» (Описание процесса разработки программного обеспечения: общая схема зрелости) в журнале IEEE Software за март 1988 года. Проведены и опубликованы первые оценки. Первые свидетельства о существовании СММ (Capability Maturity ModelSM – модели зрелости потенциала).
1989: Создание групп разработки стандартов и первых организаций методологической поддержки. Публикация книги Хамфри «Managing the Software Process» (Управление процессом создания ПО).
1990-е: Распространение СММ в Минобороны США и за пределами ведомства. Создание целевых уровней СММ во многих, если не во всех, крупных организациях, участвующих в разработке ПО.
Ядром СММ является упорядоченное множество ключевых областей процесса (Key Process Areas, KPAs), каждую из которых характеризует определённый отраслевой опыт, связанный с уровнем СММ. Исходя из качества опыта в ключевых областях, шкала делится на пять уровней организационной «зрелости». Переход на уровень определяется не только количеством накопленного опыта, но также порядком накопления этого опыта (скажем, заслугой не является накопление опыта Уровня 4, если организация ещё не достигла Уровня 3).
Парадокс модернизации процессов
Стандарты – это хорошо. Слава Богу, у нас есть стандарты, ибо без них мы не могли бы вставить кассету Kodak в фотоаппарат Minolta, штепсель кофеварки не подходил бы к розетке на стене, сигнал, передаваемый местной радиостанцией, не был бы принят вашим приёмником, ваш новый телефонный аппарат не подошёл бы для работы с вашей телефонной компанией, компакт-диски не помещались бы в проигрыватель, факсы невозможно было бы разобрать, размеры одежды и обуви стали бы бессмысленными, новые покрышки не подходили бы к старым автомобилям, а сеть Интернет оставалась бы доступной лишь людям, которые её изобрели.
Такие стандарты полезны, но следует отметить, что великий триумф стандартов в современном мире – это практически всегда успех стандартных интерфейсов. Стандарт на резьбу, на пальчиковую батарейку или кассету с плёнкой содержит много сведений о конечном продукте – о том, как он взаимодействует с другими частями, но ни слова о процессе создания этого продукта. Батарейка имеет тип АА, если отвечает стандарту соответствующего интерфейса (по форме, размеру, отказоустойчивости, электрическим характеристикам и т. д.), независимо от того, создана ли она под водой, роботами или обученными обезьянами. Из успеха стандартов на интерфейсы можно лишь с некоторой натяжкой делать вывод, что процессы тоже следует стандартизировать.
И все же огромной привлекательностью обладает поиск идеального процесса. Работы Хамфри, Полка (Palk) и других представителей SEI вдумчивы, профессиональны, амбициозны и искренни:
Когда мы с Тимом составляли сборник «Software State-of-the-Art: Selected Papers» (Современное программное обеспечение: избранные статьи), Dorset House, 1990, перед нами стояла задача отобрать наиболее значимые работы восьмидесятых. Работа Уоттса Хамфри «Characterizing the Software Process» была среди первых . В тот год в статье для «American Programmer» я задался целью выбрать лучшую из работ, вошедших в сборник. Без тени сомнения из тридцати одной статьи я выбрал статью Хамфри. Воздействие его работы в последующие годы, по моему мнению, подтвердило правильность такого выбора.
