Качество требований в IT-проектах — тема, которая редко обходится без болезненных вопросов и неочевидных ответов. Эта статья — не о критериях идеальных требований (их мы касаться не будем), а о том, как можно выстроить работу команды, чтобы этих критериев достигнуть. В основе статьи реальный кейс: я расскажу о конкретных сложностях, с которыми мы столкнулись на одном из проектов, о причинах этих проблем и методах, которые помогли не только исправить положение, но и применить данный подход на других командах.  

Теперь немного о самом проекте. Компания-заказчик впервые работала с внешними вендорами, а мы впервые сотрудничали с этим клиентом. Казалось, что мы хорошо подготовились: собрали сильную команду — опытных аналитиков, разработчиков, тестировщиков. Из явных проблем: у заказчика не было своего аналитика. Вернее, он появился, но пришел практически одновременно с нами и разбирался в проекте даже меньше нашего. 

Когда мы начали проект и приступили к работе, неожиданно столкнулись и с проблемами в подготовке качественных артефактов — тех самых User Story, которые нужно было передать разработчикам. На груминге (у нас в команде «Story Refinement») постоянно возникали вопросы: истории одна за другой отправлялись на доработку по разным причинам. Позже, уже на этапе разработки, часть требований вновь возвращалась с замечаниями: требовались дополнительные уточнения. 

Мы начали анализировать ситуацию и осознали, что команда теряет очень много времени. Например, на груминг собирались все 9 участников, обсуждали User Story, но в итоге понимали, что она не готова — её нельзя отдать в разработку, а значит, нужно вернуть аналитикам на переработку. Нас это категорически не устраивало: такие циклы требовали огромных затрат времени. 

Привет, Хабр!  

В прошлой статье мы начали разговор о паттернах микросервисов (Часть 1). Ну что ж, давайте продолжим!

Паттерн «API-шлюз» (API Gateway)

Итак, следующим популярным шаблоном является паттерн API Gateway, который часто упоминается в контексте микросервисной архитектуры. Этот шаблон основывается на использовании шлюза, находящегося между клиентскими приложениями и микросервисами, предоставляя единую точку входа для всех клиентских запросов.

Привет, Хабр!

Меня зовут Сергей Громов, я работаю в IT уже 30 лет. Прошел путь от программиста на Assembler и преподавателя до ведущего системного аналитика.

В этой статье мы разберемся с некоторыми основами проектирования микросервисов. Моя цель — объяснить принципы проектирования начинающим и тем, кто работает с уже готовой микросервисной архитектурой. Порой новичкам архитектура сервиса кажется неочевидной. На самом деле, все не так страшно. Есть определенные принципы, которые помогают в этом разобраться.