Не совсем. SA занимается технической реализацией на уровне проектирования интерфейсов, интеграций и структур данных — это ближе к аналитике, чем к архитектуре. Архитектор обычно выбирает технологии, определяет масштабируемость системы, стратегию развертывания и т. д. SA фокусируется на деталях, которые позволят реализовать требования, а архитектор — на том, как вся система будет работать в целом.
Бизнес-аналитик исследует рыночные тренды, формирует требования к продукту и согласует их.
Системный аналитик проектирует техническую реализацию: разрабатывает схемы API для платежных шлюзов, настраивает интеграцию с процессинговыми системами или проектирует базы данных для обработки транзакций. BA отвечает за то, «что нужно бизнесу», а SA — за то, «как это реализовать технически».
Отвечает Владимир: – Я с гитлабом с 2020 года, периодически изучаю новые фишки. Компоненты - одна из фишек в которые влюбился с первых строк документации. Да, они чем-то похожи на другие include, но тут много нового с ними добавили.
Они попадают в отдельный CI/CD Catalog, где есть отдельный README и описание каждого параметра компонента. Ну и сами параметры, конечно. Они предлагают более гибкий процесс настройки пайплайнов: их можно использовать не только внутри скриптов или, например, rules, как это бывает с переменными, но с помощью них можно так же задать имя задания, или переопределить целый блок rules.
Выделю ещё downstream pipelines, особенно динамические пайплайны. Недавно открыл для себя уже не такую новую фичу - parallel:matrix. В ней много своих минусов, но там где ей место - встает как влитая.
Рад, что статья понравилась. Успехов в изучении и работе с компонентами!
Работа с таблицей коэффициентов — это, по сути, аналитический инструмент, который помогает на старте проекта (или при его масштабировании) оценить необходимое количество QA-специалистов.
Каждый коэффициент (тип приложения, этап разработки, сложность, критичность) выбирается на основе анализа текущего или планируемого состояния проекта. Это делается совместно с тимлидом, архитектором, QA-лидом и/или проектным менеджером.
Как правило, это происходит на этапе инициации проекта или при масштабировании команды.
Формально это может быть зафиксировано: в проектной документации (например, в разделе о ресурсном планировании), в Confluence или другой wiki-системе команды, в оценке нагрузки QA-команды при планировании спринтов
По количеству возможных аффилированных объектов (при росте сложности растет кол-во проверок)
По количеству логики и вариативности (чем больше комбинаций, тем сложнее логика)
Для анализа можно использовать:
Сравнить оценки похожих задач на самом раннем этапе и на текущем (если похожая задача стала занимать больше времени, то это говорит об увеличении сложности)
Рост модулей/компонентов приложения + сложность этих модулей. Можно использовать матрицу компетенций.
Количество задеваемого функционала в задаче. У нас есть практика, когда разработчик пишет, что может быть задето в той или иной правке.
Согласны, что количество тестировщиков действительно зависит от проекта. В статье перечисляются основные аспекты, которые необходимо учитывать для определения оптимального соотношения: тип приложения, этап разработки, сложность проекта и требования к тестированию.
Добрый день!
Отвечает автор статьи:
Не совсем. SA занимается технической реализацией на уровне проектирования интерфейсов, интеграций и структур данных — это ближе к аналитике, чем к архитектуре. Архитектор обычно выбирает технологии, определяет масштабируемость системы, стратегию развертывания и т. д. SA фокусируется на деталях, которые позволят реализовать требования, а архитектор — на том, как вся система будет работать в целом.
Точно подмечено!)
Добрый день!
Ответим в разрезе финтеха:
Бизнес-аналитик исследует рыночные тренды, формирует требования к продукту и согласует их.
Системный аналитик проектирует техническую реализацию: разрабатывает схемы API для платежных шлюзов, настраивает интеграцию с процессинговыми системами или проектирует базы данных для обработки транзакций. BA отвечает за то, «что нужно бизнесу», а SA — за то, «как это реализовать технически».
Добрый день!
Спасибо за комментарий.
Отвечает Владимир:
– Я с гитлабом с 2020 года, периодически изучаю новые фишки. Компоненты - одна из фишек в которые влюбился с первых строк документации. Да, они чем-то похожи на другие include, но тут много нового с ними добавили.
Они попадают в отдельный CI/CD Catalog, где есть отдельный README и описание каждого параметра компонента. Ну и сами параметры, конечно. Они предлагают более гибкий процесс настройки пайплайнов: их можно использовать не только внутри скриптов или, например, rules, как это бывает с переменными, но с помощью них можно так же задать имя задания, или переопределить целый блок rules.
Выделю ещё downstream pipelines, особенно динамические пайплайны. Недавно открыл для себя уже не такую новую фичу - parallel:matrix. В ней много своих минусов, но там где ей место - встает как влитая.
Рад, что статья понравилась. Успехов в изучении и работе с компонентами!
Добрый день! Спасибо за вопрос!
Работа с таблицей коэффициентов — это, по сути, аналитический инструмент, который помогает на старте проекта (или при его масштабировании) оценить необходимое количество QA-специалистов.
Каждый коэффициент (тип приложения, этап разработки, сложность, критичность) выбирается на основе анализа текущего или планируемого состояния проекта. Это делается совместно с тимлидом, архитектором, QA-лидом и/или проектным менеджером.
Как правило, это происходит на этапе инициации проекта или при масштабировании команды.
Формально это может быть зафиксировано:
в проектной документации (например, в разделе о ресурсном планировании),
в Confluence или другой wiki-системе команды,
в оценке нагрузки QA-команды при планировании спринтов
Если остались еще вопросы, мы на связи!
Добрый вечер! Спасибо!
Сложность приложения оценивается:
По количеству возможных аффилированных объектов (при росте сложности растет кол-во проверок)
По количеству логики и вариативности (чем больше комбинаций, тем сложнее логика)
Для анализа можно использовать:
Сравнить оценки похожих задач на самом раннем этапе и на текущем (если похожая задача стала занимать больше времени, то это говорит об увеличении сложности)
Рост модулей/компонентов приложения + сложность этих модулей. Можно использовать матрицу компетенций.
Количество задеваемого функционала в задаче. У нас есть практика, когда разработчик пишет, что может быть задето в той или иной правке.
Количество легаси кода без документации
Ну вот, в целом как-то так:)
Согласны, что количество тестировщиков действительно зависит от проекта. В статье перечисляются основные аспекты, которые необходимо учитывать для определения оптимального соотношения: тип приложения, этап разработки, сложность проекта и требования к тестированию.