Часть 8 (Работа с качественными воротами) В предыдущей публикации мы говорили о контроле рисков в нескольких проектах одновременно.
Сегодня мы поговорим об отслеживании характеристик качества (Quality Gates).
Давайте на мгновение задумаемся об этом.
Скажем, когда мы начали разработку Orcas (Visual Studio 2008), кто-то на самом верху дал инструкцию:
- Производительность VS2008 не будет хуже, чем VS2005.
- Мы покроем 70% кода автоматическим тестированием.
Как можно быть уверенным, что 3000 человек добавят сотни новых функций в ближайшие 2-3 года и этим инструкциям будут следовать? Наш ответ: Quality Gates. Работая над Orcas, мы установили 16 таких гейтов, начиная от простых вроде «У вас должны быть написаны спецификации» до числовых вроде «70% кода должно быть покрыто автоматическим тестированием».
В рабочем элементе «Функции» мы посвятили целую форму «Воротам качества».
Давайте посмотрим на это поближе.
Первые четыре пункта основывались на документации.
Следовательно, документ должен был существовать и быть одобрен, чтобы пройти через эти ворота.
Остальные гейты контролировались утверждением и установкой статуса.
Прежде чем команда разработчиков смогла изменить статус на «завершено», они должны были убедиться в достижении всех качественных характеристик.
Чтобы показать, что этот критерий был соблюден, они установили в полях «Ворота качества» значение «соответствует», «неприменимо» или «освобождено».
Правила эксплуатации не позволяли установить статус «Завершено» до тех пор, пока не будут установлены все статусы полей.
Если хотя бы одно поле имело статус «Исключение», поле «Разрешение на исключение» становилось обязательным, требуя от ответственного лица утверждения исключения.
Это было эффективно с точки зрения электронного документооборота.
Если вы установили для метрики значение «достигнуто», эта информация сохранялась в истории рабочего элемента и была своего рода вашей подписью.
Возникает вопрос: как уберечь людей от мошенничества, просто установив для параметра «Ворота качества» значение «удовлетворительно»? Ответ прост: просто никто этого не сделал.
Могу ли я быть уверен, что все функции, помеченные как завершенные, действительно были завершены при изменении статуса? Нет. Такая уверенность потребует много времени на проверку деталей каждой новой функции.
Эта система была основана на доверии.
Мы верили, что люди поступают правильно, и я думаю, что в большинстве случаев они так и поступали.
Еще одной проблемой была необходимость перепроверки Quality Gate на основной ветке.
Например, все тестирование, связанное с локализацией (Quality Gate «Pseudo Loc» выше), все тестирование производительности, автоматическое тестирование проходило в основной ветке на регулярной основе.
Если кто-то передал в систему контроля версий код, который не соответствует требованиям, эта информация отобразится в отчетах, полученных из основной ветки.
Для отслеживания состояния качественных характеристик мы использовали следующий отчет: 
Этот отчет был построен в Excel и включал в себя все функциональные возможности, которые находились в разработке, и использовал функции Excel 2007 для отображения желтых/зеленых/красных/черных индикаторов для каждого из показателей качества (где черный цвет означал - не запущен).
Как и в случае с другими отчетами, наш менеджер проекта каждую неделю задавал нам следующие вопросы:
- Я слышал, что вы приближаетесь к завершению этой функциональности (колонка RI в отчете выше), но вы еще не начали работать с Quality Gates. Потрудитесь объяснить, почему?
- Вы установили некоторые ворота качества на красный цвет. Почему? Как мы можем помочь?
Работа с Quality Gates сводилась к тому, чтобы держать других в курсе событий.
Однако без поддержки TFS/Work Items я не понимаю, как мы как организация (или любая другая организация, для которой это важно) могли бы добиться успеха в выполнении задач, которые столь же важны и влияют на командную культуру, как и качество.
Гейтс был.
В следующем посте мы поговорим об отчетах, которые мы создали, чтобы иметь четкое представление о состоянии всех задач.
Часть 9 (Прозрачность отчетности)
Ниже представлена панель управления нашим отделом:
Возможно, вы помните в одном из предыдущие публикации мы говорили о Value Props (ценностях), связанных с Experience (опытом), которые, в свою очередь, связаны с Features (функциональностью).
На рисунке выше показан снимок состояния DevDiv, работающего с ними.
В верхней части отчета показан прогресс в работе с ценностными реквизитами.
Ценностные реквизиты, как вы помните, являются базовыми точками подразделения.
В Оркасе их было около 10.
Если нажать на элемент (выделен серым прямоугольником выше), откроется статус соответствующего Опыта: 
Здесь вы можете увидеть статус всех элементов, связанных с этим ценностным предложением.
Перейдем к разделу «Опыт».
В этом отчете показан ход работы над функциональностью, связанной с выбранным Опытом.
Пойдем еще ниже: 
и получите в браузере отчет, в котором показаны данные о функционале.
Этот набор отчетов позволяет персоналу любого уровня отслеживать статус всего выпуска.
Это также обеспечивает прозрачность, которая влияет на командную культуру на всех уровнях, а именно на перемены к лучшему.
Теги: #microsoft #tfs
-
Ноутбук: Звук Через Наушники И/Или Динамики
19 Oct, 24 -
Обзор: Варшава И Ее Мать Польша
19 Oct, 24 -
Ложная Пустота
19 Oct, 24 -
Как Часто Ты Смотришь Телевизор?
19 Oct, 24 -
Очевидное Рядом
19 Oct, 24
