Команда Windows 7

  • Article

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

Перед тем, как погрузиться в основную тему, давайте более подробно поговорим о том, чего ждать от данного блога. Сначала несколько слов по поводу полученных мной комментариев и писем. Я получил буквально тысячи писем, чьему прочтению я посвятил все выходные. В них наметилось несколько тем. Должен сказать, что реакция на наш блог оказалось в целом положительной, чему я безумно рад. Наиболее распространенной просьбой является просьба обсудить производительность Windows и/или просьба “сделать Windows быстрее”. Собственно, тема очень обширная, поэтому в ближайшие месяцы мы уделим ей немало внимания. Также имеют место пожелания, отражающие известную проблему с различных точек зрения – одни говорят “только не делайте <действие х>”, а другие пользователи заявляют, что “чтобы вы не делали, очень важно сделать <действие x>”. Но с моей точки зрения основная цель данного блога – это диалог о различных аспектах одного и того же вопроса. Даже такое понятие, как «производительность» имеет в своей основе много едва различимых элементов. Так, к примеру, некоторые пользователи считают, что лучшим способом увеличения производительности системы является полный отказ от загрузки служб и приложений до того момента, когда ресурсы ОС не освободились. Другие пользователи заявляют, что задержка в загрузке их приложений ограничивает их возможности и негативно сказывается на возможности моментального включения в работу. Третьи считают, что необходимо включить в ОС менеджер автозагрузки, который позволил бы выбирать, какие приложения загружать. Данная тема, которая без сомнений заслуживает внимания и обсуждения, показывает всю сложность и неоднозначность такого, казалось бы, однозначного понятия.

Во-вторых, к нашему с Джоном удивлению многие из читателей усомнились в “достоверности” первой публикации. Некоторые даже предположили, что данный блог является чьим-то злым умыслом. Так вот, лично я пишу данную статью в Windows Live Writer и нажимаю кнопку Publish. Данный блог реален, как и любой другой блог MSDN — здесь вас ждут и опечатки, и ошибки и многое другое. Данный блог не подвергается цензуре, между мной и вами нет посредников. Просто в нашей команде есть несколько человек, которые также, как и я, смогут писать свои статьи для нашего блога, но авторами тех статей являются те люди, чьи имена написаны под статьей. Чтобы обеспечить безопасность нашему блогу статьи будут публиковаться от имени одного человека, при этом каждая статья внизу будет отмечена именем автора. (Если я буду участвовать в обсуждении какой-то статьи, я подпишусь моим именем, используемым на MSDN, - steven_sinofsky.)

И в-третьих, к вопросу о периодичности публикаций и о том, когда мы перейдем к обсуждению функций Windows 7. Когда мы писали, что публиковать статьи будем на регулярной основе, мы имели в виду, что у нас нет точного расписания по календарю и что мы не желаем писать статьи, чтобы обеспечить ложную периодичность, что вообще противоречит принципу блоггеров. Тем не менее, мы планируем использовать схему публикации, схожую со схемой, используемой в IEBlog. Кстати говоря, еще ни разу меня не обвиняли в отсутствии публикаций на моем внутреннем блоге. :-)

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

Поэтому позвольте представить...

Достаточно разумно сначала поговорить о команде разработчиков Windows как об одном целом, а затем перейти на личности, представляющие эту команду — о тех, кто выступает на конференциях, пишет книги, ведет блог. Внутри Microsoft программный продукт Windows является работой для всей компании, при этом каждый из сотрудников вносит тем или иным образом свой вклад в разработку. Команда разработчиков Windows управляется Джоном и мной. Джон осуществляет руководство группой Core, в чьи задачи входят разработка ядра ОС, инфраструктуры устройств, сетевых возможностей, инструментов и систем. Я же являюсь руководителем группы Windows Client Experience, которая занимается разработкой оболочки и рабочего стола, графики и поддержки мультимедиа.

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

Каждая из этих команд занимается конкретной частью Windows 7 — кодом, функциями, качеством и общей разработкой. В каждой команде ведется работа над своим элементом ОС, что значительно упрощает руководство — представители разных команд могут встречаться для обсуждения каких-либо функций, вместе сходить в кино и т.д. В команде разработчиков насчитывается в среднем 40 человек, но размеры могут существенно отличаться. Мы же поговорим о двух аспектах команд разработки: о том, над чем они работают, и том, кто составляет эти команды.

Команды Windows 7 по сути являются частями Windows, с которыми все вы знакомы. Из-за сложной структуры Windows у нас есть много команд, некоторые из которых фактически не претерпели изменений в течение нескольких последних релизов, а другие являются относительно или совершенно новыми для Windows. Некоторые из команд заняты в разработке для серверной редакции Windows (например, виртуальными машинами), другие же работают над компонентами, которые выходят за рамки Windows 7 (к примеру, Internet Explorer).

В общем, команды разработчиков выполняют разработку комбинаций архитектурных компонентов и сценариев работы Windows. Понятие “функция” всегда трактовалось неоднозначно, поскольку некоторые считают функций элемент интерфейса, другие же – архитектурный компонент (например, TCP/IP). Наша задача – сбалансировать сценарии и архитектуру таким образом, чтобы в итоге получился правильный уровень охвата задач за счет правильной комбинации архитектурных элементов. Мы пытаемся избежать разделения разработки функций и интерфейса, чтобы команды имели полную власть над тем, над чем они работают (например, команда “Поиск и организация информации” ведет работу как над непосредственным индексатором, так и над пользовательским интерфейсом, используемом при поиске информации). Вот несколько основных команд разработки Windows 7:

  • Апплеты и гаджеты (Applets and Gadgets )
  • Технологии содействия и поддержки (Assistance and Support Technologies)
  • Core UX (Core User Experience)
  • Обслуживание пользователя и телеметрия (Customer Engineering and Telemetry)
  • Платформа развертывания и компонентизации (Deployment and Component Platform)
  • Графика (Desktop Graphics)
  • Устройства и носители информации (Devices and Media)
  • Устройства и хранение информации (Devices and Storage)
  • Документы и печать (Documents and Printing)
  • Инжиниринговые системы и инструменты  (Engineering System and Tools)
  • Файловая система (File System)
  • Поиск и организация информации (Find and Organize)
  • Фундаментальные компоненты (Fundamentals)
  • Internet Explorer (включая низкоуровневую поддержку IE 8)
  • Международная поддержка (International)
  • Ядро и виртуальные машины (Kernel & VM)
  • Media Center
  • Сеть – фундаментальные компоненты (Networking – Core)
  • Сеть - корпоративное применение (Networking – Enterprise)
  • Сеть – беспроводные возможности (Networking – Wireless)
  • Безопасность (Security)
  • Платформа пользовательского интерфейса (User Interface Platform)
  • Платформа Windows-приложений (Windows App Platform)

Думаю, что название группы позволяет понять в первом приближении то, чем занимается эта команда, но по мере публикаций в данном блоге разные члены команд разработки Windows 7 будут объяснять, над какими функциями они ведут работу. Это позволит вам понять структуру подсистем Windows, а также то, каким образом мы разбиваем столь крупный проект на более мелкие компоненты. Безусловно, что по мере работы над проектом мы координируем разработку функций между различными командами. Это лишь вопрос практики, поскольку мы, со своей стороны, всегда стараемся создавать эффективный код с высокой производительностью (разработка по принципу снизу-вверх), конечные пользователи могут использовать его в различных сценариях, а ИТ-специалисты – осуществлять управление по принципу сверху-вниз. Признаю, что иногда простому обывателю сложно понять такой подход, поскольку он не знает специфики. Так, к примеру, разработка функций перьевого ввода лежит на плечах команды платформы пользовательского интерфейса наряду с разработкой функций распознования речи, multitouch-функций и специальных возможностей. Причиной тому служит архитектурная потребность в организации общего доступа к инфраструктуре всех механизмов “ввода”, даже если конкретный пользователь никогда в своей жизни не воспользуется всеми этими механизмами. Когда мы разрабатываем API для управляемого ввода информации, разработчики смогут воочию убедиться в преимуществах разных режимов взаимодействия пользователя через единый набор API.

Другим аспектом работы наших команд является правильная комбинация. Каждая команда представлена тремя ключевыми инженерными дисциплинами: инженерами по разработке ПО (иначе sde или dev), тестовыми инженерами по разработке ПО (sdet или test) и программными менеджерами (pm). Наличие трех инженерных дисциплин является уникальным аспектом Microsoft, вызывающим интерес многих исследователей. В моем старом блоге, на который выше я привел ссылки, я уже рассказывал о dev, pm и даже о sdet.

Если вкратце, то dev ответственны за архитектуру и код, pm отвечают за набор функций и спецификацию, а sdet отвечают за проверку, и по сути являются адвокатами пользователей с точки зрения удобства. Каждый ответственен за качество и производительность. Для любой отдельно взятой функции каждый dev, test или pm представляют звенья одной цепи (в буквальном и в переносном смыслах). Это является ключом к “балансу силы”, используемому в разработке Windows 7. Организационно dev-инженеры работают для dev-инженеров, sdet-инженеры — для sdet-инженеров, а pm-менджеры — для pm-менеджеров. Это позволяет оптимизировать работу по двум направлениями — сфокусироваться на разработке отдельных функций, при этом обеспечив уверенность, что финальный продукт будет гармонично объединять функции, а не просто являться набором отдельных, независимых друг от друга элементов.

Мы говорим об этих трех дисциплинах вместе, поскольку мы создаем команды разработчиков с n разработчиками, nтестерами и1/2n программными менеджерами. Такое соотношение сотрудников фактически неизменно в нашей группе. В средней команде разработчиков Windows 7 состоит порядка 40 разработчиков.

В нашей команде также есть ключевые специалисты, которые ведут работу над различными аспектами продукта:

  • Разработка контента – авторы и редакторы, ведущие онлайн-сопровождение, создающие веб-сайты, документы SDK и документацию по развертыванию
  • Планирование продукта – сотрудники, ответственные за исследования, позволяющие осуществить подбор функций, а также координирующие работу с партнерами всей экосистемы
  • Дизайн продукта – разрабатывают общую модель взаимодействия, графический язык и дизайн для Windows 7
  • Исследования и юзабилити – разрабатывают полевые и лабораторные исследования, показывающие, каким образом существующие продукты и предложенные функции воспринимаются пользователями.

Некоторые отметят, что команда Windows достигла столь крупного размера, что это приводит к различным проблемам в разработке. В то же самое время, если взглянуть на комментарии к статьям, можно увидеть, насколько широк диапазон желаемых пользователями функций, которые они хотели бы видеть в Windows. Поэтому для разработки Windows требуются огромные человеческие ресурсы. А наша задача — держать размер команды Windows в полном соответствии с потребностями — это, быть может, и звучит как клише, но я имею ввиду, что команда не должна быть ни большой и ни маленькой — она должна быть эффективно управляемой, чтобы ее достижения в полной мере отражали размеры, а вы видели результаты. Это мне напомнило сцену из фильма «Amadeus », в которой император высказал мнение, что в «Женитьбе Фигаро» “слишком много нот”, на что Моцарт ответил, что “в произведении, Ваше величество, нот столько, сколько требуется, не меньше и не больше”. До того, как император предложил Моцарту избавиться от нескольких нот, Моцарт спросил его, “о каких именно нотах он ведет речь?” Безусловно, от членов нашей команды зависят сроки реализации функций и разработки сценариев, поэтому задача состоит в том, чтобы собрать правильную команду с правильной структурой, которая позволит увеличить возможность выполнения пожеланий пользователей — не меньше и не больше.

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

Стивен