Один день системного аналитика

В качестве ретроспективы выкладываю пост, который писал для канала «Один день ITшника», где рассказывал чем занимаюсь на работе. Для тех, кто только вкатывается в профессию, должно быть полезно. За прошедший год подход к работе не поменялся, а вот инструментарий расширился – теперь ведем доку в Git, используя AsciiDoc, PlantUML и OpenAPI. Если будет интересно, расскажу об этом отдельно.

Работаю через галеру, проект финтех, команда интеграций. Состав команды: лид, менеджер, 5 Java разработчиков, 2 QA, 3 SA, 2 Support, DevOps. Работаем по Agile, хотя спринтов нет. Каждый день дейли, 2 раза в неделю груминг, примерно раз в месяц ретро. Раз в 2 недели проводится встреча аналитиков из всех команд, где рассказываем, что было сделано и какие проблемы, делимся опытом.

Команда занимается разработкой интеграций с партнерами (банками). Те присылают API, а мы уже перекладываем на свой процесс. Большинство интеграций укладываются в рамки стандартного процесса, и доработка не требуется (то есть расширять модель данных на прием новых полей, нестандартную обработку существующих не требуется). Но бывают исключения. Вся разработка ведется по техническим спецификациям, которые как раз составляет системный аналитик.

Примеры задач: техдолг, разработка новой интеграции (в рамках существующего процесса), разработка новой интеграции (с доработкой процесса).

Техдолг: самые простые задачи, функционал был реализован когда-то давно, но по нему нет документации. Первым делом иду в Git и смотрю, как функционал был реализован. Потом смотрю API партнера. Если какой-то инфы не хватает, запрашиваю у менеджера (взаимодействие с партнерами (бизнесом) осуществляется через менеджера). Когда получил всю инфу, начинаю составлять спецификацию. Под каждый метод создается отдельная статья в Confluence. У команды есть шаблоны описания спеки, но они стандартные. Из чего состоит спека:
- пример сообщения, которое поступает в адаптер (XML);
- очередь, в которую помещается это сообщение;
- пример сообщения, которое будет отправлено партнеру (JSON);
- описание исходящего сообщения (поля, примеры, типы, обязательность, значение из модели данных);
- пример сообщение, которое получаем в ответ;
- описание входящего сообщения (поля, примеры, типы, обязательность, значение из модели данных);
- парсинг входящего сообщения;
- очередь, в которую входящее сообщение отправляется;
- тестовые и продуктивные урлы.
В процессе тестирую API партнера через Postman, чтобы удостовериться, что он реально работает так, как указано в их доке (чаще всего работает иначе). Если возникают вопросы, смотрю как реализована обработка того или иного сообщения в коде.

В конце составляю Sequence Diagram (диаграмму последовательности) вызовов каждого метода, чтобы можно было легко понять, как это вообще работает.

После выполнения задачи отдаю ее в тестирование. Тестировщик пишет тест-кейсы и на этом техдолг считается закрытым.

Разработка новой интеграции (существующий процесс): процесс разработки спеки аналогичен техдолгу. Разница лишь в том, что, когда какие-то моменты непонятны, вопросы задаются партнеру через менеджера. После написания спеки, она также отдается QA, которые дергают методы партнера и смотрят, что я учел все варианты. Если тестирование успешно, задача попадает на груминг, где разработчики и QA дают свои оценки. Задача уходит в разработку. В процессе могут прилетать вопросы от разрабов, которые решаются либо на месте, либо на дейли с лидом.

Разработка новой интеграции (с доработкой процесса): если интеграция требует доработки бизнес-процесса, например, партнер использует поля, которых нет в модели данных или методы, которые ранее у нас не использовались, и мы понимаем, что это не единичный случай, принимается решение о доработке с нашей стороны. Ставится задача на соседнюю команду, которая расширяет модель данных. Если изменяется бизнес-процесс, например, добавляется новый метод, то изменения вносятся в Camunda (оркестратор бизнес-процессов). Эти доработки делает соседняя команда, аналитики из нашей команды ставят им задачи.