Часть 8 (Работа с Quality Gates)
В предыдущей публикации мы говорили о контроле рисков в нескольких проектах одновременно. Сегодня мы поговорим об отслеживании качественных характеристик (Quality Gates).
Давайте задумаемся об этом на мгновение. Скажем, когда мы приступали к разработке Orcas (Visual Studio 2008), кто-то на самом верху давал указания:
- VS2008 не будет иметь производительность хуже, чем VS2005.
- Мы покроем 70% кода автоматическим тестированием.
Это всего лишь два требования, но зато самые большие. Как можно быть уверенным в том, что 3,000 человек добавит сотни новых функций в следующие 2-3 года, и эти указания будут выполнены?
Нашим ответом были Quality Gates. При работе над Orcas мы установили 16 таких ворот, от простых, как «Вы должны иметь письменные спецификации», до численных, например: «70% кода должно покрываться автоматическим тестированием».
В рабочем элементе типа Feature мы посвятили Quality Gates целую форму.
Давайте рассмотрим ее поподробнее.
Первые четыре точки базировались на документации. Поэтому документ должен был существовать и быть одобренным, чтобы пройти через эти ворота.
Остальные ворота отслеживались путем одобрения и установки статуса.
Прежде, чем команда разработки могла изменить статус на «выполнено», они должны были убедиться, что все качественные характеристики достигнуты. Чтобы показать, что данный критерий достигнут, они выставляли поля Quality Gates в «met» («достигнут»), либо «not applicable» («не применимо»), либо «exempted» («изъят»). Правила работы не допускали установки статуса в «Завершено», пока все статусы полей не будут установлены. Если хотя бы одно поле имело статус «Exception» («исключение»), поле «Exception Authorization» («Подтверждение исключения») становилось обязательным, в котором ответственное лицо должно было утвердить исключение.
Это было эффективно с точки зрения электронного документооборота. Если вы устанавливали показатель в «достигнут», эта информация сохранялась в истории рабочего элемента и была, своего рода, вашей подписью.
Это вызывает вопрос: как вы удерживали людей от жульничества просто взять и установить Quality Gate в «met»? Ответ прост: просто этого никто не делал. Могу ли я быть уверен, что все функции, помеченные, как выполненные, действительно были выполнены к моменту изменения статуса? Нет. Такая уверенность потребовала бы массу времени на проверку деталей каждой новой функции. Эта система была основана на доверии. Мы доверяли людям в том, что они делают все правильно и, я думаю, в большинстве случаев так оно и было.
Другой проблемой была необходимость перепроверки Quality Gate на основной ветке. Например, все тестирование, связанное с локализацией (Quality Gate «Pseudo Loc» выше), все тестирование производительности, автоматическое тестирование проходили в основной ветке на регулярной основе. Если кто-то сохранял код в системе контроля версий, который не удовлетворял требованиям, такая информация отображалась в отчетах, получаемых из основной ветки.
Для отслеживания состояния качественных характеристик мы использовали такой отчет:
Этот отчет строился в Excel и включал в себя весь функционал, находящийся в разработке и использовал функции Excel 2007 для вывода желтого/зеленого/красного/черного индикаторов для каждого из Quality Gates (где черный цвет означал – не приступали к выполнению).
Как и в случае с другими отчетами, еженедельно наш менеджер проекта задавал нам такие вопросы:
- Я слышал, что вы близитесь к завершению работы над данным функционалом (колонка RI на отчете выше), однако вы еще не начали работу с Quality Gates. Потрудитесь объяснить – почему?
- Вы установили некоторые Quality Gates в красный цвет. Почему? Чем мы можем помочь?
То, что мы делали – отнюдь не конструирование ракет (rocket science – нечто высоко технологичное), и магии никакой. Работая с Quality Gates нужно было просто держать других в курсе событий. Однако без поддержки TFS/Work Items я не вижу как мы, как организация (или любая другая организация, для которой это важно) могли быть успешными в выполнении задач, имеющих такое важное значение и влияние на культуру команды, какой были Quality Gates.
В следующей публикации мы поговорим об отчетах, которые мы создали, чтобы иметь четкую картину состояния всех задач.
Gregg Boer
Часть 9 (Прозрачность в отчетности)
Ниже – контрольная панель нашего подразделения:
Возможно, вы помните, в одной из предыдущих публикаций мы говорили о Value Props (ценностях), связанных с Experience (опытом), которые в свою очередь связаны с Features (функционалом). Картинка выше является моментальным снимком статуса DevDiv, работающего с ними.
Верхняя часть отчета показывает прогресс работы с Value Props. Value Props, как вы помните, является базовыми точками для подразделения. В Orcas их у нас было примерно 10.
Если щелкнуть на элементе (выделено серым прямоугольником выше), то откроется статус соответствующего Experience:
Здесь вы можете увидеть статус всех элементов, связанных с данным Value Prop. Спускаемся ниже к Experience.
Данный отчет показывает прогресс работы над функционалом, связанным с выбранным Experience. Идем еще ниже:
и получаем отчет в браузере, который показывает данные по функционалу.
Этот набор отчетов позволяет персоналу любого уровня отслеживать статус всего релиза. Он также обеспечивает прозрачность, влияющую на культуру команды на всех уровнях, а все это – изменения к лучшему.
