В настоящее время мы можем наблюдать, что в процессе разработки продукта командам приходится быть все более гибкими, так как условия и требования постоянно меняются. В такой ситуации очень легко упустить момент, когда процесс разработки и сам продукт перестают соответствовать необходимым стандартам качества.
Сегодня мы рассмотрим одну из best practices, которая может помочь в такой ситуации – Quality Gates.
Quality Gates – это заранее определенные этапы, во время которых проект проверяется на соответствие необходимым критериям для перехода к следующему этапу. Quality Gates являются важным компонентом официальных процессов управления проектами, используемых различными организациями.
Цель Quality Gates – обеспечить следование набору определенных правил и передовых практик, чтобы предотвратить риски и увеличить шансы на успех проекта. С помощью качественных Quality Gates организации могут гарантировать, что руководители проектов выполняют свою работу и не пропускают никаких важных шагов.
В своей практической реализации Quality Gates организованы в виде совещаний, которые запланированы в конце каждого этапа проекта. Вот как это обычно выглядит:
Quality Gates основаны на чек-листах, по которым менеджеры проектов должны пройти на разных этапах жизненного цикла проекта. Эти чек-листы включают в себя ряд вопросов, касающихся различных аспектов проекта, включая объем работ, бюджет, заинтересованные стороны, риски и соответствие требованиям.
Перед совещанием по вопросам качества руководитель проекта изучает соответствующий чек-лист по определенным Quality Gates и отвечает на каждый вопрос, принимая во внимание текущий статус проекта. Он также предоставляет заполненный чек-лист соответствующим лицам, принимающими решения, чтобы дать им достаточно времени для изучения информации до совещания по качеству.
Во время совещания участники знакомятся с чек-листом и обсуждают наиболее важные пункты чек-листа. Менеджер проекта предоставляет контекст и отвечает на любые возникающие вопросы.
Обсуждение в основном вращается вокруг вопросов, которые не были завершены – пунктов чек-листа, на которые были даны ответы “Нет” или “В процессе”. Возможно, какая-то роль в проекте еще не заполнена или бюджет еще не подписан клиентом.
В зависимости от темы и серьезности проблемы, команда Quality Gates, состоящая в основном из руководства, спонсора проекта и ключевых заинтересованных сторон, может начать предпринимать различные действия. Если у кого-то из команды на данный момент нет работы, это не проблема, и проект может продолжаться. Однако, если бюджет проекта все еще обсуждается, проект следует приостановить до тех пор, пока не будут утверждены расходы.
Человек, который контролирует соблюдение Quality Gates, может также потребовать принятия дополнительных мер для конкретных пунктов чек-листа. Если, например, одна из заинтересованных сторон выражает озабоченность по поводу того, соответствует ли планирование ресурсов правилам управления персоналом, она может отправить запрос, чтобы отдел кадров проверил план ресурсов проекта.
Рассмотрим Quality Gates для каждой из фаз разработки продукта (SDLC).
Важно отметить, что только после устранения блокеров, критических и серьезных проблем приложение разрешается допустить в продакшн, интегрироваться с другими приложениями и источниками данных, опубликовать в Интернете.
Фаза SDLC | Необходимые практики | Quality gates |
Фаза исследования продукта | Тренинг для разработчиков | Команда разработчиков прошла тренинг Tech Lead/Dev Lead есть на проекте |
Анализ требований | Анализ рисков | Определен Product Data Owner Проведена классификация данных Определены требования и их соответствие Проведен анализ рисков по приложению |
Разработка дизайна | Произведена оценка архитектуры приложения Произведено моделирование архитектуры Созданы макеты приложения | Созданы документы по архитектуре приложения Создана модель возможных угроз |
Разработка продукта | Статический анализ кода Code Review | Произведен анализ найденных дефектов Найдены угрозы и риски, разработаны шаги по нивелированию их воздействия Все дефекты должны быть устранены либо должны быть приняты компенсационные меры |
Тестирование продукта | Acceptance Testing Динамический анализ кода Функциональное тестирование | Все устраненные дефекты проверены Произведен анализ причин возникновения дефектов с приоритетом Medium и выше |
Развертывание продукта | Оценка конфигурации деплоймента Финальный анализ продукта | Формальная приемка продукта в процессе финального анализа продукта |
