MS: корпоративная культура разработки ПО

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

Айсберг корпоративной культуры

В книге [1] Люк Хоман (Luke Hohmann) определяет корпоративную культуру как исторически сложившиеся присущие данной организации устойчивые базисные образцы решения проблем внешней адаптации и внутренней интеграции. Думаю, все согласятся с тем, что Microsoft обладает ярко выраженной и весьма специфичной корпоративной культурой, и именно она и позволяет большим и малым формальным и неформальным структурным единицам фирмы ощущать себя единым организмом, целенаправленно и согласованно разрешающим все проблемы на пути к общей цели. Можно выделить следующие компоненты корпоративной культуры:

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

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

Хотя не так давно один из представителей российского отделения Microsoft, ныне пошедший на повышение, попытался просветить на сей счет читателей популярного еженедельника. Видимо, желая как можно доходчивее раскрыть "от противного" то, что он кокетливо обозначил "BBS (Большой Буржуинский Секрет)", он начал с карикатурного и весьма меткого описания "как делаются программные продукты в России". И сам не заметил, как окарикатурил, хотя и с противоположным знаком, технологию, принятую на собственной фирме, представив ее как образцовый, чтобы не сказать - идеальный механизм создания "ВАР (Великих Американских Разработок)".

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

На самом же деле, принятая в Microsoft технология разработки чрезвычайно далека от идеала, если понимать под таковым следование тем научно обоснованным принципам Software Engineering, которым учат в университетах. Для такого вывода вовсе не нужно глубоко проникать в упомянутый BBS (подумаешь, Бином Ньютона!): об этом буквально вопиют многочисленные дефекты в потребительских версиях майкрософтовских продуктов. Другое дело, что эта технология действительно достаточно специфична и вполне подходит для достижения стратегических целей бизнеса именно этой фирмы. А цели эти вполне открыто и отчетливо артикулированы: с помощью максимально быстрого и дешевого создания таких программных продуктов, которые способны de facto приобрести статус промышленного стандарта, добиться как можно более полной доминации на массовом потребительском рынке, постоянно увеличивая на нем свою "долю". И кто скажет, что эта стратегия реализуется плохо?!

И все же даже для такой дьявольски успешной фирмы верна истина, что "дьявол - в деталях"; отсюда и потребность компьютерного сообщества в объективной профессиональной информации, позволяющей сформировать реалистическое представление о технологических аспектах деятельности MS. К счастью, такого рода сведения, добытые и прокомментированные независимыми исследователями, существуют. Пожалуй, наиболее представительное исследование выполнили профессор Массачусетского Технологического Института Майкл Кусумано (Michael Cusumano) и доцент Калифорнийского Университета в Ирвине Ричард Селби (Richard Selby), которые имели возможность в течение двух с половиной лет изнутри изучать работу фирмы. В частности, они подробно проинтервьюировали 38 ключевых сотрудников, включая Билла Гейтса, и изучили тысячи страниц конфиденциальной проектной документации и внутренней отчетности. Результатом этого труда явилась книга [2] и статьи в профессиональных журналах [3,4], которые являются уникальным источником фактического материала.

Между Сциллой хакерства и Харибдой бюрократизма

Microsoft - это чрезвычайно интенсивно работающая фирма (в книге [5] приведено характерное высказывание одного из ветеранов Microsoft: "Над Windows мы работали как лошади" - значит, все-таки эти работящие животные на фирме есть, правда вместо овса и сена они традиционно потребляют гамбургеры и колу". Достаточно сказать, что количество программных продуктов, отмеченных его маркой, приближается к трем сотням. Чем дальше, тем больше охват (чтобы не сказать - захват) все более разнообразных рынков, тем шире диапазон продуктов и все больше среди них таких, что характеризуются очень значительной степенью сложности и соответственно трудоемкостью в производстве. При этом процесс производства находится под постоянным и все возрастающем прессом ненасытного в своей требовательности и очень конкурентного рынка. Поэтому самое, быть может, первое, что следует отметить, говоря о производственном процессе в Microsoft - его большой динамизм и высокая гибкость.

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

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

Шли годы, фирма претерпевала поистине взрывной рост во всех смыслах этого слова. Производимые продукты усложнялись. Исходный код Windows 95 содержит более 11 млн. строк; неудивительно, что только команда непосредственных разработчиков состояла из более чем 200 программистов и тестировщиков, что на порядок превышало количество разработчиков первых версий Windows [5]. Всего же к 1995 г штат MS состоял из 20 тыс. сотрудников, в числе которых были 1850 разработчиков, 1850 тестировщиков, 400 менеджеров по разработке (program managers) и 2100 инженеров службы поддержки клиентов (customer-support engineers). Само по себе соотношение перечисленных категорий сотрудников необычно и очень показательно для принятой в Microsoft технологии. Пока же констатируем, что количественные факторы достигли такого уровня, что казалось бы требовали радикального пересмотра технологии. Пересмотр постоянно происходил, но радикальности в нем не было никогда.

Конечно, не только Microsoft оказалась перед необходимостью качественно иной организации производственного процесса - те же проблемы встали и перед всей программной индустрией. Перманентный "software crisis", идентифицированный на исторической конференции научного комитета НАТО еще в 1968 г и означавший, что программные проекты сплошь и рядом не укладывались в запланированные сроки и бюджет при оставляющем желать много лучшего качестве [7], стал катализатором появления целого ряда серьезных подходов и методов, направленных на совершенствование и упорядочивание процесса разработки с тем, чтобы разрешить классическую триаду проблем с ПО при особом упоре на управление качеством. Эти подходы вошли в учебники; некоторые из них достигли такой степени зрелости, что оформились в виде множества процедур обеспечения качества, ядро которых вошло в международный стандарт ISO-9000 [8]. Предложены подробно разработанные технологические и организационные методики по улучшению процесса разработки. Пожалуй наиболее признанной из них стала предложенная Американским Институтом Программной Инженерии (Software Engineering Institute - SEI) модель зрелости процесса разработки ПО (Capability Maturity Model - CMM).

Модель SEI CMM позволяет на основе оценки принятых в данной организации процессов разработки отнести ее к одному из пяти уровней [9]. Целый ряд известных фирм - производителей ПО посчитали нужным пройти формальную процедуру сертификации на соответствие принятой у них технологии одному из уровней SEI CMM или стандарту ISO 9000-3. Комментаторы между тем глубокомысленно рассуждают, сколько процентов компаний можно отнести к начальному ("Initial") уровню SEI CMM, при котором царит полная технологическая анархия (имеются оценки, что на этом уровне находятся 85% фирм [10]), а сколько к наивысшему - пятому ("Optimized"), которых считанные единицы (здесь преуспели, в частности, подразделения корпорации Motorola).

Надо сказать, Microsoft мало озабочена проблемой получения такого рода сертификатов. Прежде всего, у нее чуть ли не с первых лет работы не было нужды в формальном подтверждении своей репутации. К тому же ее руководители, очевидно, хорошо осознают то, что упускают из виду некоторые пропоненты стандартизованных технологий. Та же SEI CMM создавалась с целью получения обоснованных процедур оценки и последующего развития технологии в тех организациях, которые претендуют на получение заказов по разработке имеющих оборонное значение проектов. Это делалось с подачи Министерства Обороны США (кстати и SEI как таковой находится на бюджете Пентагона). Соответственно SEI CMM в полной мере применима к фирмам, разрабатывающим сложные, часто встроенные и работающие в реальном времени системы с длительным временем жизни, где дефекты в ПО могут иметь критическое значение: например, бортовое ПО, используемое на американских космических "челноках", с объемом в три миллиона строк кода, содержит менее одной ошибки в расчете на 10 тыс. строк кода (разработка одного из подразделений IBM [11]). Для Microsoft такие показатели качества в принципе не нужны, да и не достижимы. Фирма ориентируется на массовый горизонтальный рынок, к которому приложимы совсем иные критерии.

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

Принципы построения жизненного цикла

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

Такой стиль, естественно, несовместим с "каскадным" (или "водопадным" - waterfall) подходом к организации жизненного цикла программного продукта, который предполагает развертывание проекта от четко сформулированной и утвержденной спецификации через последовательное выполнение фаз разработки, каждая из которых начинается по полному завершению предыдущей. Окончательная сборка из готовых компонентов и интегральное тестирование проводятся единожды в конце разработки. Такой подход, бывший в фаворе в 70-е и 80-е гг., имеет ныне не лучшую репутацию из-за своего негибкого, в чем-то даже догматического характера, приводящего к бюрократизации управления, с большим запозданием реагирующего на сигналы рынка. Тем не менее, он остается наиболее распространенным. Далеко не всеми менеджерами бюрократизация рассматривается (не в теории, а на практике!) как негативный фактор - ведь при этом облегчается управление и размывается ответственность, во многом транслируемая с личностного на "бумажный" уровень. К тому же при надлежащей реализации вполне возможно выдерживать заданные критерии качества.

Microsoft следует методологии разработки, опирающейся на "спиральную" (spiral) модель жизненного цикла, хотя и весьма видоизмененную по сравнению с классическим описанием [12], что не удивительно - ведь корпоративная технология вырастала эмпирически, а не из теоретических источников. Можно выделить три ключевых понятия, в совокупности определяющих специфику подхода:

• итеративность (iterativeness), позволяющая многократно проходить одни и те же фазы жизненного цикла каждый раз на новом уровне разработки; при этом фазы разработки могут перекрываться;
• пошаговость изменений (incremental changes) - постепенное добавление функциональных возможностей (features) в разрабатываемый продукт, в противоположность единовременной реализации полной спецификации. Как следствие, появляется возможность иметь "промежуточную" версию (и не одну!) продукта, которую можно тестировать и даже предоставлять "внешним" пользователям, что позволяет замкнуть постоянно действующую обратную связь с рынком;
• параллельность разработки (concurrent development), выполняемой множеством одновременно работающих команд. Естественно, что главная проблема при этом - синхронизация этих, в значительной степени автономных, действий многочисленных структурных единиц всего большого коллектива, работающего над сложным проектом. Синхронизация действий означает, в сущности, синхронизацию внесения разными командами изменений в общий проект; при этом необходимо периодически (а не только в конце всего процесса) "фиксировать" текущее состояние всей разработки. Именно в дисциплине осуществления этих действий по синхронизации и периодической "стабилизации" проекта коренится суть всей майкрософтовской технологии, которой М. Кусумано и Р. Селби дали специальное название "synch-and-stabilize approach".

Весь принятый в Microsoft процесс разработки можно разделить на три фазы:

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

Специфицирование и планирование

Процесс разработки начинается с создания концептуального описания будущего продукта, задающего "по-крупному" его видение (этот документ так и называется "vision statement") в контексте требований рынка. Главным действующим лицом на этом этапе является "менеджер по продукту" (product manager) - специалист-маркетолог, знающий ситуацию на рынке и запросы потенциальных пользователей. Его задача - донести до менеджеров по разработке ПО "видение" будущего продукта, а именно, какие цели и требования необходимо удовлетворить, какие для этого нужны функциональные возможности (product features) и в каком порядке в соответствии с их приоритетной важностью следует их ранжировать.

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

На изменение функциональности будут влиять и внешние факторы, в том числе те реальные и потенциальные продукты конкурентов по рынку, которые так или иначе пересекаются с данным разрабатываемым продуктом. Наконец, на окончательную функциональность будут влиять и такие прозаические факторы, как недостаток ресурсов, отставание от графика или просто изъяны в реализации, которые невозможно или некогда исправлять. В этом смысле корпоративная майкрософтовская культура не предполагает каких-либо комплексов: здесь без колебаний "режут по живому", отдавая приоритет своевременности выброса продукта на рынок. Статистические данные по основным продуктам Microsoft показывают, что в среднем около 25% содержащихся в исходной спецификации (разрекламированных, а потому ожидаемых потребителем) функциональных особенностей исчезают ко времени выпуска продукта; если же считать и то, что добавлено, то конечная функциональность будет отличаться от исходной на 30% и более.

На основе функциональной спецификации менеджеры по разработке, постоянно консультируясь с разработчиками, начинают проектировать - на модульной - основе горизонтальную архитектуру проекта. Главное, что здесь делается - все основные функции продукта разбиваются на несколько групп, которых обычно три или четыре. Соответственно, устанавливаются столько же "подпроектов", работа над которыми будет вестись последовательно. Разбиение производится на основе уже имеющейся классификации функций по степени их важности: наиболее критически важные (составляющие 1/3 часть от общего количества, если групп всего было три) попадают в первый подпроект. Другие, менее приоритетные функции будут реализовываться в рамках второго подпроекта, и, наконец, функции, представляющиеся на данном этапе наименее приоритетными, относятся к последнему подпроекту. Каждый подпроект заканчивается выпуском промежуточной "контрольной" версии продукта (milestone release).

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

Следует обратить внимание на весьма упрощенный подход к разработке архитектуры программного продукта: в сущности, само понятие архитектуры низводится до вспомогательного инструмента, подчиненного интересам удобства организационного планирования и управления. Между тем, с точки зрения современных представлений, построение хорошо структурированной архитектуры продукта есть необходимое условие его успешной разработки и - особенно! - дальнейшего развития. Именно поэтому виднейшие авторитеты в области Software Engineering (например, Гради Буч [13]) рассматривают архитектуру, определяющую логическую и физическую структуры программной системы, как основу для надлежащих стратегических и тактических проектных решений, приводящих к построению качественного продукта.

Давно замечено, что архитектура многих майкрософтовских продуктов, разрабатываемая на шаткой основе заведомо неполной и постоянно изменяемой спецификации, получается во многом ущербной. Именно здесь ключ к удивительным, на первый взгляд, отличиям в последовательных версиях одного и того же продукта, не говоря уже о продуктах разных, но казалось бы преемственных по идеям. Один из многих примеров - реализация механизмов DLE - OLE - ActiveX. Костная "несущая" система, какой и является архитектура, гнется и ломается под грузом малоуправляемых мутаций и деформаций. Это приводит к проблемам в реализации такого желательного принципа разработки как повторное использование кода; достаточно сказать, что 50% кода изменяется каждые 18 месяцев!

Процесс разработки

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

Разработчики выполняют проектирование, кодирование и отладку своего кода. Небезынтересно отметить, что обычно никакой особой проектной документации не ведется - на фирме издавна считается, что ее ведение наложило бы излишние ограничения на динамизм разработки. Функции же документации выполняет сам код; при этом он содержит очень мало комментариев, что всегда и являлось самой, пожалуй, отличительной особенностью хакеров. К примеру, комментарии в коде Excel составили лишь около 1% от его общего объема (эту информацию лучше бы скрыть от наших студентов!). С учетом же того, что команде предоставлена возможность, чтобы не сказать - обязанность, не рассматривать исходную спецификацию как догму, а наоборот, оперативно откликаться на поступающие извне либо генерируемые внутри нее самой предложения по ее изменению, то в конечном счете оказывается, что единственным источником для понимания реализации функции оказывается этот самый скупо откомментированный код. А отдуваться в итоге приходится тамошним техническим писателям, и стоит ли удивляться количеству плохо документированных (и вовсе не документированных) возможностей, которыми традиционно славны майкрософтовские руководства. Стоит отметить, что при данном подходе к кодированию сложно применять такую современную технику, как "инспекция кода", позволяющую резко увеличить количество обнаруживаемых дефектов при сокращении затрат и усилий на тестирование [11].

Команды и отдельные разработчики, имея значительную свободу в процессе реализации подпроекта, должны, тем не менее, следовать нескольким жестким правилам, которые необходимы для синхронизации параллельно протекающей работы, что, собственно, и позволяет им функционировать как единому слаженному коллективу, способному относительно быстро и дешево справиться с масштабным проектом. Коль скоро идет работа над единым проектом, то разрабатываемый продукт всегда существует в виде доступной всем командам централизованной базы данных, содержащей "контрольную" (эталонную) версию файлов с исходным кодом (master version). Действующий в Microsoft механизм работы с единым проектом обычно называют "сборкой" (build), что подразумевает периодическое выполнение процедуры генерации новой текущей версии продукта из частично или полностью законченных разработчиками компонентов. Эта процедура позволяет, не дожидаясь конца разработки, сразу же увидеть как реализованные (реализуемые) отдельные функции работают в контексте всего продукта и оперативно выявлять и корректировать проблемы.

Принятая в Microsoft технология подразумевает ежедневное выполнение процесса сборки (daily build), состоящего из нескольких шагов. Прежде всего любой разработчик имеет возможность "скачать" (check out) необходимые ему для работы файлы из общей базы. После этого он имеет полную свободу по внесению в этот код изменений, необходимых для реализации и отладки той функции, за которую он ответственен. В любой момент разработчик может выполнить свою сборку (private build) и сгенерировать таким образом персональную версию продукта (private release).

Примерно половину своего рабочего времени разработчик тратит на написание кода; другую половину использует на тестирование, отладку и прямое общение с потребителями продукта. При этом нельзя сказать, что типичный майкрософтовский разработчик использует в своей работе самые современные методы и инструменты. Так, очень многие продолжают (как это не покажется в стенах Microsoft удивительным) использовать Unix Source Code Control System - просто потому, что привыкли к этой системе. Это и отражение того факта, что корпоративный менеджмент полагает, что лучше тратить время непосредственно на разработку, чем на освоение нового инструментария. Зато немаловажно, что почти все команды физически сосредоточены в одном месте (в корпоративном кампусе в Редмонде), используют общие языки программирования (в основном это Cи и C++), более того - общий "фирменный" стиль кодирования и стандартизованные средства разработки. Это помогает параллельно работающим командам в обсуждении проектных идей и решений, потому что полностью автономной работы команд над общим проектом достигнуть невозможно.

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

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

Операцию по встраиванию своего кода в общую эталонную базу разработчики имеют право выполнять до определенного назначенного часа; затем в дело вступает специально назначенный разработчик (project build master), который ежедневно генерирует полную "сборку" продукта на основе текущей эталонной версии исходного кода всего продукта. Эта процедура следует "сценарию сборки" (build script) в виде автоматически выполняемой последовательности команд, и включает шаги по полной компиляции кода и получению в конечном итоге одного или нескольких исполняемых файлов. При этом могут создаваться различные "библиотечные файлы", позволяющие конечным пользователям настроить продукт в соответствии со своей спецификой. Таким образом, ежедневно производится выпуск внутренней версии продукта (internal release), генерируемой для каждой платформы (Windows, Mac..), а также для каждого значимого рынка (американский, европейские и т.п.). Вся эта технология, направленная на периодическую интеграцию функций и "стабилизацию" всего кода в его текущем состоянии, позволяет реализовать такой базисный принцип, как постоянное наличие во всех необходимых версиях "готового" (пусть еще далеко не полностью) продукта, который можно предъявить потребителю.

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

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

В конце каждого подпроекта - после истечения срока параллельной работы команд над реализацией назначенных им функций - предусмотрен специальный период "буферное время" (buffer time), во время которого разрешаются всякие непредусмотренные планом, но неизбежно возникающие проблемы, особенно вызванные оперативно вносимыми изменениями в спецификации и взаимозависимостью функций, над которыми работали разные команды. Этот период используется и как тривиальное продление периода разработки подпроекта, потому что выходы за пределы временного графика наблюдаются почти всегда. Для проектов из разряда приложений буферное время занимает 20 - 30 % от всей продолжительности подпроекта, а для системных программ - 50%. Только после этого выпускается очередная "контрольная" версия (milestone release), с которой активно работают пользователи.

Важнейшим механизмом, обеспечивающим эту обратную связь с потенциальными потребителями продукта на протяжении всего процесса разработки, включая даже период работы над первым подпроектом, является институт Лабораторий Пользователя (Usability Lab). Первая такая лаборатория была открыта в 1989 г. и имела четыре тестовых комплекта, каждый из которых включает две разделенные полупрозрачным зеркалом комнаты: тестовую (test room), где пользователь имеет возможность "поиграть" с продуктом, и наблюдательскую (observation room), где располагается сотрудник, в чьи функции входит отслеживание всех деталей работы пользователя. Через три года была введена в действие еще одна лаборатория с пятью тестовыми комплектами; в 1995 г добавили лабораторию, получившую название Microsoft Home и не случайно: чтобы заставить пользователей чувствовать себя в буквальном смысле "как дома", здесь сымитирована домашняя обстановка, включая кухню, столовую и детскую. Наконец, в 1996 г появилась лаборатория с пятью тестовыми комплектами, включающая специальное эргономическое оборудование.

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

Главное, что измеряется и выражается в специальных метриках - это легкость освоения продукта и удобство работы с ним. Упомянем две метрики: первая показывает процент пользователей, которым удалось без обращения к руководствам выполнить некое осмысленное действие; вторая метрика выражает процент корректных шагов на пути к выполнению задачи, сделанных с первой же попытки. Опытным путем установлено, что для большинства продуктов на ранней стадии разработки вторая метрика (correct first-try rate) получается в районе 60%; цель же, которой в конечном счете стараются добиться - это 90%.

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

Эксперименты проводятся не только в корпоративных лабораториях, но и "на выезде" в офисах, школах и университетах, по месту жительства возможных потребителей. Кроме того, в последней фазе разработки - фазе стабилизации - прошедшие всестороннее внутреннее тестирование "beta" версии отправляются для опытной эксплуатации к партнерам корпорации, принадлежащих к категориям OEM и ISV; здесь задействованы и многочисленные добровольцы-индивидуалы. После этого компания приступает к подготовке выпуска финальной версии продукта ("golden master" discs), а также необходимой документации. Но даже после выпуска "финальной" версии работа над продуктом не прекращается. Уже установилась традиция в среднем через 12 месяцев выпускать исправленную и дополненную версию, а через 24 месяца - радикально переработанную (с большим количеством новых функций и измененной архитектурой). Небезынтересно отметить, что работа отвечающих на телефонные звонки и другие обращения о помощи инженеров службы поддержки (имя которым - легион!) финансируется за счет бюджета команд разработчиков данного продукта; поэтому последние заинтересованы в постоянной минимизации дефектов в каждой последующей версии сравнительно с предыдущей.

Маленький секрет большой фирмы

Так что же получается? Неужели для того, чтобы компания смогла повторить успех флагмана индустрии ПО, ей надо просто-напросто не стремиться адаптировать современные методы программной инженерии, не тратить много времени и усилий на проектирование оптимальной архитектуры, не комплексовать по поводу проектных документов и кода без комментариев, а также вообще по поводу качества?

Наверное, не все так просто. И дело не только в том, что не имея стартовой позиции на рынке, сравнимой с нынешним положением Microsoft, вряд ли получится продавать (и недорого!) столько копий продуктов, чтобы позволить себе держать на каждого разработчика персонального тестировщика и инженера по клиентской поддержке. И может ли в принципе появиться еще одна Microsoft? Не самая легкая судьба компании Netscape, имевшей во многом уникальные стартовые условия, не прибавляет оптимизма амбициозным проектам по целенаправленному захвату рынка.

Подводя же итог рассмотрению особенностей принятого в Microsoft процесса разработки, следует еще раз констатировать: это "технологическое" отражение более общих, "корневых" особенностей ее корпоративной культуры, позволяющей фирме реализовывать свою стратегию на конкурентном рынке. По определению Эда Йордона (Ed Yourdon) [14], эта компания имеет "right stuff" (термин восходит к известному роману Тома Вулфа об астронавтах), под которым понимается надлежащая комбинация настроенных на успех механизмов менеджмента и маркетинга, специфических технологических подходов и инструментов разработки, и высококвалифицированного персонала с определенным менталитетом. Можно назвать этот менталитет (как и всю культуру) "хакерским" или "ковбойским" (термин Йордона), но нельзя не признать, здесь налицо попадание в общий контекст современной массовой культуры. В этом и состоит секрет коммерческого успеха.

В эту культуру встроено понимание, что рынок не требует совершенного продукта вообще и программного в частности, он с удовольствием потребляет такой, который при избыточной функциональности прост в освоении, удобен в использовании, относительно дешев, разрекламирован до такой степени, что "его имеют все" и способен к эволюционному развитию в условиях быстро меняющейся технологической и социальной среды (не страшно, если текущая версия оставляет желать лучшего, не за горами следующая, которую можно приобрести со скидкой!). Программные продукты такого рода тот же Йордон назвал "good enough software" [15]. Проблема, однако, в том, что на практике такие продукты, произведенные в том числе (если не в первую очередь) Microsoft, часто не удовлетворяют даже весьма умеренным критериям качества.

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

Будущее с наукой?

Microsoft, которой чего-чего, а динамизма и амбициозности не занимать, активно включилась в борьбу за новые рынки, в частности, ориентированные на мультимедийные технологии и глобальные коммуникации, что предполагает очередной шаг в сложности продуктов и требованиях к ним. Приложения связанные, например, с video-on-demand, должны включать в себя большое количество взаимозависимых компонентов, функционирующих в среде с жесткими временными ограничениями и требующих точных математических моделей для реализации доставки мультимедийных данных надежно и в срок.

Разработка такого рода продуктов предполагает использование более "продвинутых", по сравнению с используемыми фирмой MS сейчас, методов software engineering. Прежде всего речь идет о более жестком планировании разработки и качественно иной процедуре архитектурного проектирования; о внимании к современным механизмам предотвращения дефектов и к практике инспекции кода. Это означает поиск и установку иного баланса между структурированностью процессов разработки и их гибкостью и динамизмом. Имеются признаки, что руководство фирмы понимает эти проблемы. Так, Microsoft стала активным партнером компании Rational Software в процессе специфицирования недавно стандартизованного консорциумом OMG Универсального Моделирующего Языка (Unified Modeling Language - UML), адаптация которого предполагает качественно иной уровень проектирования [7]. О том же говорит и усиление внимания к научному обеспечению инновационных проектов.

Специальное исследовательское подразделение Microsoft Research (MSR) [16] появилось в Редмонде 1991 г. Недавно были открыты еще два отделения в Сан-Франциско и английском Кембридже. Научный штат составляет 250 исследователей и в ближайшие несколько лет должен утроиться. Качественный их состав впечатляет: так, среди сотрудников группы по компьютерной графике числятся Джим Блинн (Jim Blinn), Эндрю Гласснер (Andrew Glassner) и Джим Каджийя (Jim Kajiya) - все имена "из первой пятерки". Стратегическая задача MSR - упрочение репутации компании как лидера в области подлинно инновационных технологий. Проводимые исследования соотносятся с озвученным Биллом Гейтсом видением следующего поколения компьютерных технологий в виде трех основных компонентов:

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

Организационно MSR состоит из трех "метагрупп": "Расширенная Интерактивность и Интеллектуальные Системы", "Методологии и Средства Программирования" и "Системы и Архитектура". Исследовательские разработки затрагивают более 20 областей информатики и смежных наук, в числе которых речевые технологии, зрение, парадигмы программирования, естественный язык, пользовательские интерфейсы и теория принятия решений. Безусловно, фирма заинтересована чтобы результаты научных разработок находили применение в выпускаемых продуктах, и как можно скорее. Однако политика здесь проводится на удивление умная и дальновидная. Каждая группа имеет долгосрочные цели, для достижения которых выполняются не только прикладные, но и фундаментальные исследования, в том числе и такие, которые вовсе не ассоциируются с традиционными майкрософтовскими технологиями. Например, недавно созданная теоретическая группа занимается исследованиями в области статистической и квантовой механики, что может оказаться полезным при решении NP - проблем, возникающих в области сетевых вычислений и криптографии.

На пути к достижению долгосрочных целей научные группы стремятся и немедленно инкорпорировать достигнутые промежуточные результаты в уже выпускаемые продукты. Так, группа по естественному языку, работающая над фундаментальными проблемами машинного перевода и понимания документов, встроила разработанный ею оригинальный синтаксический анализатор в блок грамматического контроля, используемый в Office 97. А результаты работы группы теории принятия решений по байесовским сетям использованы в Answer Wizard в Word 95 и в рамках Office Assistant в Office 97.

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

Всячески поощряется развитие сотрудничества с "внешним" научным сообществом. Сотрудники MSR являются активными участниками научных конференций, некоторые из которых Microsoft и спонсирует. Они входят в редакционные коллегии практически всех ведущих научных журналов. Показательно, что одним из определяющих формальных индикаторов эффективности работы персонала MSR является количество и значимость научных публикаций: руководители компании вполне сознают важность такого рода Public Relations [17].

Сейчас еще рано утверждать, что Microsoft Research внесет такой же вклад в компьютерные технологии, как это сделали такие знаменитые центры корпоративной науки, как Xerox PARC и Lockheed Skunk Works. Однако, если и есть оптимизм по поводу эволюции майкрософтовской корпоративной культуры в плане совершенствования процессов разработки ПО, то он связан именно с новым качеством инновационных технологий, реализовать которые в полной мере без этого будет затруднительно. Что ж, поживем - увидим.

Караван массовой культуры

Ну а пока вернемся к реальностям современного массового рынка. Эд Йордон тонко подмечает, что не только фирмы-производители заинтересованы в скорейшем выбросе на рынок еще не вполне кондиционного, но нового продукта; этого часто требуют потребители, в том числе корпоративные, рассчитывающие получить свои выгоды. Например, системные интеграторы могут вполне быть заинтересованы в новой, пусть уступающей "старой" по качеству, но зато хорошо разрекламированной операционной среде, на базе которой можно предложить наивному заказчику радикальную перестройку его компьютерной системы. И все будут довольны: руководитель заказчика будет счастлив от сознания того, что вверенная ему организация находится на гребне научно-технического прогресса. Местные компьютерные специалисты, занимавшиеся скучной поддержкой стабильно работающей "старой" системы, почувствуют, как их жизнь снова становится интересной, а сами они в своей организации приобретают большую значимость, ведь чего-чего, а стабильной работы от новой системы ожидать не приходится; наконец, интегратор обеспечивает себе большой фронт работ. Вот только результат...А что результат?! Как говорит Жванецкий, "при чем тут борщ, когда такие дела на кухне!".

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

И вот ему уже тесно в малых жанрах, где он добился столь впечатляющих результатов; обнаружилось влечение к крупным формам, и недавно один из лучших оркестров мира исполнил премьеру его симфонии. Это действо сопровождалось невиданной для строгого классического жанра "раскруткой" (будто новая версия Windows вышла!). И пусть музыкальные критики, поминая Чайковского и Бетховена, лепечут что-то о музыкальном качестве масштабного творения, о котором хорошего только и можно сказать, что оно "good enough", но кто воспринимает их непонятные профессиональные термины?! Широкая публика, не замеченная в пристрастиях к произведениям столь "продвинутого" жанра, готова с энтузиазмом платить деньги. Строгим же ценителям - профессионалам остается утешаться сознанием того, что через год об этой симфонии уже и не вспомнят (хотя, вероятно, появится новая того же пошиба), а Бетховен, пусть и без такого рекламного шума, будет исполняться вечно.

Не так ли и с программными продуктами? Недавний опрос, проведенный в США по заказу журнала Fortune, продемонстрировал, что 78% потребителей оценивают качество майкрософтовских продуктов как высокое. Только такие принципиальные динозавры - профессионалы, как Никлаус Вирт, словом и делом выступают против плохо спроектированного, торопливо реализованного, функционально избыточного и ресурсоемкого ПО, которое метко названо "жирным" (fatware) [18]. Борьба эта напоминает схватку Дон Кихота с ветряными мельницами: караван рынка идет, и заставить его перестроиться на выпуск и потребление более качественной продукции могут только рыночные же импульсы, имеющие четкое долларовое выражение.

Литература

1. L. Hohmann "Journey of the Software Professional", - Prentice Hall, 1996
2. M. Cusumano, R. Selby "Microsoft Secrets", - The Free Press/Simon & Schuster, NY, 1995
3. M. Cusumano, R. Selby "How Microsoft Builds Software", - Communications of the ACM, Vol. 40, N. 6, 1997, pp. 53-61
4. M. Cusumano, R. Selby "Microsoft's Weaknesses in Software Development", - American Programmer, Vol. 10, N. 10, 1997
5. S. Knepper, D. Ichbiah "The Making Microsoft", - Prima Publishing, 1993
6. S. Levy "Hackers: Heroes of the Computer Revolution", - Anchor/Doubleday, NY, 1984
7. В. Аджиев "Объектная Ориентация: Философия и Футурология", - Открытые Системы, N. 6 (20), 1996, с. 40-45
8. "Software Engineering Standard Collection", - IEEE Press, 1994
9. IEEE Software, Vol. 10, N. 4, July 1993
10. Дм. Волков, А. Гавердовский, И. Косякин "Заметки о Российском Программировании", Открытые Системы, 1997, N. 3 (23), с. 78-80
11. A. Davis "Fifteen Principles of Software Engineering", - IEEE Software, Vol. 11, N.6, 1994, pp.94-101
12. B. Boehm "A Spiral Model of Software Development and Enhancement", - Computer, Vol. 21, N. 5, 1988, pp. 61-72
13. G. Booch "Object Solutions", - Addison-Wesley, 1996
14. E. Yourdon "Who Has the Right Stuff?", - Software Development, N. 9, 1997
15. "Good-Enough Software", - Application Development Strategies, N. 1, 1996
16. S. Hamilton "Inside Microsoft Research", - Computer, Vol. 31, N. 1, 1998
17. В. Аджиев "Публикуй или Проиграешь", Открытые Системы, N. 2 (22), 1997, с. 55-60
18. Н. Вирт "Долой Жирные Программы", Открытые Системы, N. 6 (20), 1996, с. 27-31

Валерий Аджиев (valchess@gmail.com) -- МИФИ, АО "Аналайз Групп" (Москва).