Разработка Windows 7: вид изнутри

или процесс разработки Windows 7 глазамиразработчиков

С удовольствием представляю вам Ларри Остермана ( LarryOsterman ), одного из самых опытных разработчиков командыWindows , работающего вMicrosoftс 80 -х годов прошлого столетия . Во всей командеWindows есть лишь три человека, которые работают в Microsoftдольше него ! Я узнал о Ларри, когда в 1989 году сам начинал работать в компании – помню, как он работал над « мультимедиа » в те времена, когда мы являлись организаторами конференцииCD - ROMConference , и он был одним из тех, кто получил от Билла Гейтса ( BillGates ) награду в честь пятилетия компании. Что касаетсяWindows 7, то здесь Ларри представляет командуDevicesandMedia , в которой мы ведем работу над звуком, видео, Bluetoothи некоторыми другими вещами для подключения различных устройств кWindows .

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

Хотел бы поделиться своими впечатлениями от работы над Windows 7 (в противоположность другой технической информации, которая публиковалась здесь до сих пор), и сравнить их с впечатлениями, полученными при разработке Windows Vista. Еще раз обратите внимание, что это мои впечатления. У других разработчиков они могут отличаться, но я надеюсь, что они также поделятся ими в этом блоге.

Мой опыт разработки Windows 7 существенно отличается от опыта разработки Vista. Основные принципы разработки продукта не изменились, но с организационной точки зрения процесс стал гораздо грамотнее.

При разработке Windows Vista я входил в состав группы WAVE (Windows Audio Video Excellence). Группой руководил старший менеджер (lead manager), ответственный за выполнение поставленных задач. Далее по иерархии шли менеджер по тестированию (test lead), менеджер по разработке (development lead) и программный менеджер (program management lead), которые подчинялись старшему менеджеру. Процесс разработки функции проходил примерно по такой схеме: старшие менеджеры решали, какие функции будут реализованы в Windows и какие из программных менеджеров будут ответственны за конкретные функции. Менеджеры по разработке принимали решение, кто из разработчиков будет отвечать за разработку функции. Программный менеджер по конкретной функции создавал функциональную спецификацию, в которой описывалась функция и принцип ее работы. Обратите внимание, на данном этапе участие тестеров было необязательно. Разработчики, ответственные за функцию, писали спецификацию дизайна, в которой содержался способ реализации этой функции. А тестеры, со своей стороны, разрабатывали тестовый план, который объяснял, как тестировать функцию. Затем программный менеджер или разработчик прорабатывали модель угроз.

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

После того, как программирование функции завершено, и код проверен, функция отправляется в ветку «winmain». Для справки: исходный код Windows поделен на несколько «ветвей» (branch), при этом «winmain» – это корневая ветвь исходных кодов, которые стали Windows Vista. Каждый разработчик работает в так называемых «ветвях функций» (feature branches), которые впоследствии сливаются в «совокупные ветви» (aggregation branches), которые, в свою очередь, объединяются в winmain.

Как только код функции готов, тестеры его тестируют, разработчики исправляют найденные ошибки, а программные менеджеры за этим следят. По мере увеличения функций в продукте становится все труднее и труднее отлавливать ошибки и интегрировать функции в winmain (каждое исправление может вызвать возвращение на предыдущую стадию, поэтому следует четко представлять, какой риск несет в себе каждое исправление, тогда и допустимая величина риска будет постепенно снижаться). Команда, ответственная за управление данным процессом, встречается в так называемой «комнате выпуска» (ship room, не путать с build room!), где ежедневно принимаются решения об изменениях, которые будут реализованы в продукте, и тех, от которых решено отказаться. На этот счет в нашей компании ходит огромное количество слухов – часто дебаты длятся по несколько часов, когда различные команды, ответственные за качество, обсуждают достоинства и недостатки конкретного исправления.

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

В Windows 7 руководство решило внести изменения в инженерную структуру организации Windows, в частности в отдел WEX (Windows Experience), в котором я работаю. Вместо вертикальной иерархии Стивен Синофски разделил группу на три части, каждая из которых отвечала за одну дисциплину: разработку, тестирование и программный менеджмент. В каждой подгруппе по шесть разработчиков/тестеров/программных менеджеров. Этим менеджерам второго уровня, в свою очередь, подчинялись еще полдюжины менеджеров, которым рапортовали от 5 до 15 сотрудников. Такая структура отчетности (несмотря на свою неоднозначность), по моему скромному мнению, оказалась на удивление успешной.

Еще одним изменением является появление концепции «триад». «Триада» – это группа представителей подгрупп, состоящих из разработчиков, тестеров и программных менеджеров. Теперь вся работа организована по триадам. Если возникала необходимость сконцентрировать усилия в какой-то области, за это бралась триада. Этим обеспечивалось одновременное участие всех трех дисциплин. Каждый уровень управления представлен триадой, то есть вверху каждой группы WEX была триада, на втором уровне старшие менеджеры также формировали триаду и т.д. Над моей группой (Devices and Media) была триада, известная как DKCW ( по инициалам входящих в ее состав менеджеров). В команде, занимающейся звуком (в которой, собственно, я и работаю), была другая триада – SNN. Были триады, ответственные за безопасность, производительность, совместимость и т.п.

Менеджеры по трем дисциплинам собирались и решали, каким будет список функций. Затем организовывались «команды функций» (feature crews), которые занимались реализацией конкретных функций. Как правило, в состав такой команды входили один-два разработчика, программный менеджер и пара тестеров.

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

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

Функция не могла пройти проверку и быть интегрированной в ветвь winmain до тех пор, пока работа над ней не была завершена. Под «завершена» следует понимать, что функция выполняла все свои задачи, ее интерфейс был готов и т.д. В случае, если функция имела зависимость от другой функции Windows 7, разработчики обеих функций должны были подписывать сервисное соглашение (service level agreement или SLA), подтверждающее что обе команды знают о наличии зависимостей. Если вдруг команда разработчиков решит изменить дизайн или отказаться от каких-либо элементов функции, другая команда не будет удивлена (расстроена – да, но не удивлена). Это, в результате, позволяет обеспечить более тесную интеграцию между компонентами системы.

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

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

Ну что ж, хватит истории (плохо когда половина статьи о Windows 7 посвящена Windows Vista, но это необходимо для установки точки отсчета). Как сказано в начале, целью статьи является рассказ о моем опыте работы в качестве разработчика Windows 7. В ходе разработки Windows 7 я работал в трех командах. Первая вела работу над двумя функциями, вторая – над восемью незначительными, а третья – над тремя важными и парой менее значительных функций. Я также занят в работе команды WEX Devices and Media, благодаря которой появилась серия статей о моделировании угроз. Кроме того, я принимаю участие в триаде по разработке сценариев «end-to-end», в чьи задачи входит, в частности, проверка соответствия сценариев, определенных командой Sound в начале процесса планирования Windows 7, тому, что получилось, и насколько легко изменения обнаружить конечному пользователю.

Поскольку команда тестеров с самого начала участвовала в процессе планирования, ей удалось внести значительный вклад в этот процесс, а мы, со своей стороны, создавали функции, завершенные не только с точки зрения кода, но и с точки зрения тестов (в Vista этого удавалось добиться далеко не всегда). Участие тестеров гарантировало, что создаваемые нами функции могут быть проверены (звучит глупо, но вы не представляете, как порой бывает сложно протестировать некоторые функции). В ходе планирования мы осознали, что некоторые особенности одной из функций, подлежащей разработке на этапе M2, не могут быть реализованы на данном этапе. Поэтому до того, как работа была завершена, мы удалили эту функцию (или точнее, изменили систему так, чтобы новый код не являлся частью продукта). В ходе следующего этапа разработки после того, как тестовая команда завершила создание программы тестирования, функция была вновь задействована. Мы остались верны философии разработки – по завершении любого этапа все, что проходило проверку для ветви «main» должно быть законченным – код готов и оттестирован. Поэтому даже если б мы решили выпустить Windows 7 без этапа M3, это было бы вполне возможным. И в этом кроется фундаментальное отличие от Vista, в которой код по завершении программирования код интегрировался, а тестерам приходилось это тестировать. За счет вовлечения тестовой команды в процесс планирования мы решили множество проблем. Это обеспечило полный контроль над процессом разработки. Но обратите внимание, что процесс создания некоторых функций мог растягиваться на несколько этапов. На самом деле, перед командой Sound была поставлена задача реализовать одну функцию в течение трех этапов, поэтому команда очень осторожно планировала свою работу, чтобы к завершению своей работы выдать поистине достойный результат.

У команд, в которых я работаю, совершенно разные задачи – одна из функций, над которой я работаю, относится к инфраструктуре аудиосистемы, другие – к изменениях в UX (user experience – система взаимодействия с пользователем), третьи являются компонентами более высокого уровня. Ввиду того, что все этапы четко разграничены, на каждом из них мне удалось поработать над совершенно разными элементами системы, чего ранее не удавалось.

В Windows 7 руководство оказывало серьезную поддержку командам разработки в принятии сложных решений, в частности при отказе от реализации функции, чье исполнение не отвечало поставленной планке качества. Следует отметить, что в ходе разработки Vista было гораздо сложнее убедить менеджеров в отказе от труднореализуемых в заданные сроки функций. При разработке Win7 руководство часто принимало сторону разработчиков, даже если им приходилось принимать сложные решения. Одна из идей, которую они последовательно проводили «cutting is shipping» (усечение означает поставки), и они были правы. Если функция не интегрируется в систему обычно лучше отказаться от нее, чем позволить поставить под угрозу своевременный выпуск всей системы. В любом релизе Windows присутствуют тысячи новых функций, поэтому было бы очень обидно, если одна или две из них приведут к задержке выпуска всей системы.

Процесс сборки 7 также оказался на удивление прозрачным – несмотря на то, что я нахожусь внизу иерархической лестницы и далек от принятия решений, я имею представление о том, как это делается. Большая прозрачность, в свою очередь, означает, что как исполнитель я способен принять лучшее решение по планированию. Эта прозрачность является прямым следствием решения руководства дать командам разработки возможность самостоятельно принимать решения, а вовлечение их в процесс планирования лишь укрепило эту возможность.

Безусловно, процесс разработки стал прозрачным в обоих направлениях. Не только разработчики могли принимать участие в процессе планирования, но благодаря тому, что руководство ввело стандартизованные механизмы отчетов, руководители на каждой ступени иерархии смогли отслеживать прогресс на таком уровне, как никогда. С точки зрения отдельно взятого разработчика накладные расходы не были обременительными – как правило, не чаще одного раза в неделю было необходимо обновить статус своей работы. Затем эта информация сводилась в несколько таблиц и веб-страниц, которые позволяли каждому менеджеру отслеживать успехи всех команды по отдельности и общий прогресс по отношению к намеченному плану. То есть руководство могло с легкостью определить те команды, у которых возникли трудности, и предпринять действия для устранения проблем (упростить дизайн, перераспределить разработчиков или иное).

В общем, работа над Windows 7 была сплошным удовольствием. Мы реализовали поистине уникальные функции, при этом нам удалось удерживать систему в стабильном состоянии на каждом из этапов разработки.

Ларри Остерман