«Quality Gates»

Методология agile изначально создавалась для маленьких команд, которые делают продукт под ключ в режиме end-to-end и сами отвечают за его качество. Но как быть, если разрабатываешь высококритичные банковские системы, над которыми трудятся десятки agile-команд?

Нужно внедрять Quality Gates

Quality Gates — набор автоматизированных проверок, встроенных в devops-пайплайн каждой системы.

С чего начать?

1. Опишите весь процесс разработки целиком. От идеи до релиза. Укажите артефакты успеха к каждому шагу.

2. Оставьте всё то, что действительно важно и критично. Всё остальное сразу на полку. Хорошо поможет инструмент - https://miro.com/mind-map/

3. Договоритесь о правилах со всеми участниками процесса. Со всеми — это со всеми, а не только с разработчиками или тестировщиками. Правил не должно быть много на старте. Зафиксируйте.

4. Составьте роадмап автоматизации правил. С роботом спорить никто не будет. Все что нельзя автоматизировать пока отложите. Заведите задачи в Jira.

5. Забудьте про тучу документов и регламентов - их не будут читать.

Quality gates как фреймворк

Когда вы будете составлять роадмап , все должны понимать процесс как единый и комплексный подход. Это основная задача руководителя — объяснить. Далее оптимизировать по мере развития.

Не бросайтесь делать все и сразу, и уж тем более в одного. Разбейте на этапы, выделите рабочую группу и назначьте ответственного. Обозначьте сроки. Этапы отсортируйте по критичности. Начинайте оттуда, где больше всего проблем.

Вот несколько рабочих инструментов (кратко):

Аналитика — можно перевести всю работу в Git. Описывать через псевдокод UML. Правила встраивать в пайплайны. Интеграция с Jira или Сonfluence получается нативная. https://plantuml.com/ru/

Тестирование — любая современная ТМС имеет открытое API, через которое мы можем нанизать правила и триггеры. Тестовые устройства, на которых работают тестировщики, имеют возможность передавать события, из которых мы можем понимать процент прохождения ТК. Автотесты должны жить в пайплайнах с момента внедрения. Как пример https://docs.testit.software/user-guide/work-with-api.html

Архитектура — тоже можно перевести в Git. И точно так же единый репозиторий с едиными пайплайнами. Как пример - https://structurizr.com/

Разработка — SonarQube или Codecov + линтеры. https://www.sonarsource.com/products/sonarqube/

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

Мой канал тг - https://t.me/carbonka