Часть 8 (Работа с Quality Gates)

В предыдущей публикации мы говорили о контроле рисков в нескольких проектах одновременно. Сегодня мы поговорим об отслеживании качественных характеристик (Quality Gates).
Давайте задумаемся об этом на мгновение. Скажем, когда мы приступали к разработке Orcas (Visual Studio 2008), кто-то на самом верху давал указания:

1. VS2008 не будет иметь производительность хуже, чем VS2005.
2. Мы покроем 70% кода автоматическим тестированием.

Это всего лишь два требования, но зато самые большие. Как можно быть уверенным в том, что 3,000 человек добавит сотни новых функций в следующие 2-3 года, и эти указания будут выполнены?
Нашим ответом были Quality Gates. При работе над Orcas мы установили 16 таких ворот, от простых, как «Вы должны иметь письменные спецификации», до численных, например: «70% кода должно покрываться автоматическим тестированием».
В рабочем элементе типа Feature мы посвятили Quality Gates целую форму.

Отслеживание множества проектов.

Сегодня я собираюсь показать вам, как наш программ-менеджер отвечает за управление всеми проектами при помощи TFS, используя отчеты для отслеживания изменений в нескольких проектах сразу.
Для начала, позвольте мне рассказать вам немного о самом процессе.
Каждую неделю мы проводили встречи менеджеров, целью которых была проверка здоровья проектов, над которыми мы работали.
Проводил эти митинги Джим Бойл (Jim Boyle), который являлся программным менеджером нашей группы. Он – великолепный программ-менеджер с огромным опытом контроля за выполнением работы.
Каждую неделю Джим показывал нам отчет, который выглядел как этот. Он отображал все проекты, над которыми мы работали.

Планирование релиза

В предыдущих постах я рассказывал о том, как мы используем TFS для реализации процессов.
В этом, мы поговорим о том, как мы планировали релиз.
В записи рабочего элемента Feature (Функционал) мы добавили закладку «Planning» (Планирование):

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

Мы используем рабочие элементы (work items) для отслеживания информации, представленной ниже.

Одной из проблем, с которой Майкрософт столкнулся при работе с большими объемами данных, была такой: когда мы управляли 1200 различными тех. заданиями, все они работали на основе единого базового кода. При таких объемах невероятно трудно управлять качеством базового кода, пока отдельные команды сосредоточены на выполнении собственных задач в то же самое время. Наш ответ — модель функционирования команды. Эту модель мы позаимствовали у команды разработчиков Microsoft Office.

Данный и последующие топики с таким названием являются переводом блога Грегга Боера (Gregg Boer) из Microsoft Development Division, в котором Грегг рассказывает об использовании Team Foundation Server в процессе работы над проектом «Orcas».