Взгляд на разработку изнутри. Функции

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

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

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

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

• Обзор – Что представляет собой данная функция и как она войдет в общее представление о продукте?
• Проблемы – С какими проблемами могут столкнуться разработчики и пользователи, используя данную функцию?
• Возможности – Какие возможности внутри и за пределами Microsoft мы можем задействовать для реализации данной функции?
• Цели – Каким образом мы сможем решать проблемы с данной функцией?
• Ошибочные цели– Какие проблемы находятся вне сферы нашего рассмотрения?

Для меня это является самой сложной частью процесса – подготовка первой рабочей версии может занять более недели. “Страница 1” точно определяет, для чего нужна функция и что она будет представлять собой в финальном релизе продукта. После завершения “Страницы 1” сама страница подвергается множественным обзорам и пересмотрам командой разработчиков. Это этап, на котором программный менеджер имеет возможность показать, из чего он на самом деле сделан. Позвольте, я объясню.

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

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

В команде разработчиков Windows Shell Team есть два типа спецификации – a Feature Spec, которая описывает внешний вид функции и ее поведение, и Developer Design Document, которая описывает технологии, используемые для работы функции, а также способы реализации функции. Программные менеджеры как раз таки и занимаются написанием такой документации.
Когда я готовлю спецификацию, мне важно собрать как можно больше информации, чтобы более подробно описать интерфейс и поведение функции. Сложно передать значимость спецификации для разработчика и тестера.

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

• Как будет выглядеть функция, запущенная с визуальными стилями?
• Как она будет выглядеть в режиме Classic Color Scheme?
• Насколько она доступна? Есть ли ярлыки?
• Как она будет выглядеть в режиме высокого контраста?
• Что произойдет в режиме высокого DPI?
• Каково минимальное разрешение, при котором будет работать функция?
• Как будет работать функция при низком уровне системной памяти?
• Существует ли потенциальные проблемы с безопасностью?
• Есть ли случаи, в которых будут отображаться сообщения об ошибках?
o Если да, то какие сообщения и чем они вызваны?
• Основаны ли изменения функции на SKU?

Следующий перечень вопросов, на которые я должен ответить, связан с непосредственными пользователями функции:

• Для кого предназначена данная функция?
• Сможет ли новичок успешно пользоваться данной функцией?
• Хороша ли функция для опытных пользователей?
• Будет ли дана опытным пользователям возможность ее настройки?
• Сможет ли человек с ограниченными физическими возможностями пользоваться функцией?

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

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

Специальное предложение
Если вам действительно интересен процесс разработки, я подготовил для вас еще кое-что. Впервые за историю компании Microsoft (насколько я знаю) я опубликовал реальную спецификацию существующей функции, чтобы вы получили полное представление о том, как выглядит спецификация. Данная спецификация описывает Aero Wizard. Это одна из самых ранних спецификаций, поэтому прошу не быть слишком критичными. Я уже давно не притрагивался к спецификации, поэтому она несколько неактуальна, но идея все равно будет понятна. Данная спецификация разрабатывалась специально для платформы Windows Platform, поэтому она немного отличается от типичной функции Windows.
Думаю, что это не последняя спецификация, которой мы поделились с сообществом Windows! Наслаждайтесь!

Источник: http://www.shellrevealed.com
Перевод: deeper2k