#требования #инструменты
У нас тут организовались ламповые посиделки об использовнии Requirements Yogi. Рады всем, кто хочет поделиться своим опытом или болью.
Вторник 18.05 в 19:00 по МСК

https://us02web.zoom.us/j/83151438146?pwd=VGFEQlMrTWx2YWlNWlIrTVBlaWtPQT09
Meeting ID: 831 5143 8146
Passcode: 279720

Приблизительная повестка:
1. История команды, которая планирует использовать RY. Какие проблемы хотят решить, почему смотрят на йогу.
2. Как мы используем RY и чем недовольны.
3. Опыт архитектора. Успешные кейсы использования RY.
4. Свободная дискуссия.

#интеграция #API #конференция
Analyst Days 12
Материалы, которые обещал участникам воркшопа по проектированию API.

https://microservice-api-patterns.org - коллекция паттернов проектирования API

https://twirl.github.io/The-API-Book/docs/API.ru.html - книга о проектировании API. Если все читать лень, то в контексте воркшопа можно ограничиться главами 10 и 11

http://www.servicedesignpatterns.com - книга и о проектировании web-сервисов. В большой степени ориентирована на разработчиков и архитекторов, но хорошо написано о поллинге и коллбеках и других полезных штуках

https://habr.com/ru/company/yandex/blog/442762/ - статья от яндекс такси об ужасах идемпотентности

Решил зарегаться на GetMentor. Пишите, если интересно пообщаться.
https://getmentor.dev/andrey-burakov-299

#мышление #требования
Еще один пример мышления письмом. Особенно полезно это упражнение аналитикам, когда формулируем сложные требования. Ибо требование есть мысль.

“Поймал себя на мысли, что пишу очень сложные предложения, длинные и сильносвязные. Полез проверять у классиков: Толстой, Чехов и другие - обнаружил, что доля сложносочиненных предложений очень невелика, а сложноподчинённые короткие. В итоге стал себя заставлять писать короткими предложениями. Оказалось, что пока ты стараешься укоротить предложение или разбить его на связные части - прокручиваешь изначальную мысль несколько раз. А ещё seo-плагин вордпреса умеет ругать статьи в бложеке по этой причине. Тоже меняю текст:) Как результат - сильный рост доступности и понятности текста. И вывих мозга” - утащено из одного чатика, автор @dumtest

Пока попробовал только в переписке, но уже чувствую результат.
Как-то у меня была заметка о подходе к переписке: https://t.me/another_sa/37

#конференция
В ближайшее воскресение расскажу на ЛАФ о терминологическом хаосе вокруг REST. Кратко об этом уже писал тут, теперь погрузимся в тему глубже. У кого будет желание - пишите, познакомимся😏

#требования #мышление #анализ
Анна Абрамова рассказывает о том, как аналитику научиться видеть задачу целиком, и не продалбывать важные моменты.
https://www.artofba.com/post/how-to-see-whole-picture

Конспектировать не буду, ибо ее cnjbn прочитать и обдумать самостоятельно. Несколько тезисов, которые особо зацепили:

О ценности аналитика
По моему глубокому убеждению, задачей аналитика является видеть риски и явно описывать ограничения. Аналитик работает с огромным количеством информации на разных уровнях абстракции и видит пробелы и нестыковки, которые не могут увидеть другие.

Об инструментах анализа: UML, Use Cases, User Stories и т.п.
Для меня идеальный подход к проработке каждой задачи – использовать 2-3 инструмента, обязательно включающие текстовое и графическое представление информации. Это заставляет мозг работать в разных режимах и рассматривать разные аспекты, не теряя общей картины.

О выборе и валидации решения
Рассматривать несколько решений, в том числе решение, что ничего не нужно делать.

Об организации процесса работы
Мы пришли к выводу, что аналитику нужно минимум два часа в день «на подумать» без прерываний на вопросы от команды, переговоры и другие задачи.

#анализ
Среда 7 июля в 19:00

Люблю критику, ибо она часто помогает понять, как улучшить нашу работу. Вечером в среду Филипп поделится фидбеком, который мы сможем вместе обсудить, присоединяйтесь😏

Первую часть проведем в формате интервью, вторую - в режиме общей дискуссии.

https://compractice.timepad.ru/event/169456

Уже через час обсудим с Филиппом проблемы при работе с аналитиками, подключайтесь

https://us02web.zoom.us/j/89499320249

#анализ #манагерское

Почему системный аналитик в компании - это bad smell?

https://youtu.be/__CS7ogpMks
Конспект писать не буду, но пару мыслей из обсуждения хочу вынести:

⁃ Системным аналитиком называем роль, которая занимается техническим дизайном (проектированием API, БД, UI, внутренней логики приложений), проработкой пользовательских требований (user story, пользовательские сценарии и т.п.) и выполняет кучу других функций, которые получится на него повесить.
⁃ Залезать в техдизайн СА не стоит, т.к. для этого нужны технические компетенции уровня разработчика с 5-10 годами опыта.
⁃ Работа с пользовательскими требованиями - это функции product owner/manager’а. Можно похоливарить на тему, почему относим эти функции продукту, но сейчас это распространенная трактовка.
⁃ При этом работа СА на интеграционных задачах вполне допустима, т.к. здесь аналитик выступает как архитектор решений на минималках, что не требует глубокого погружения в технику.
⁃ Если в разработки продукта есть выделенный СА, то это указывает на проблемы в процессах команды или компании. В частности, в коммуникациях между разработкой и бизнесом. При этом налаживать процессы может оказаться сложнее или дороже, чем привлечь СА.
⁃ По опыту Филиппа 2/3 разработчиков способны и готовы коммуницировать с бизнесом и погружаться в предметную область, если у них есть возможность.

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

По итогам хочу еще поисследовать тему с другими представителями индустрии. Кому-нибудь еще интересен такой формат? Дайте знать в комментах, плз.

#архитектура

Монументальная подборка материалов от архитектора для будущих архитекторов

https://t.me/bpmn2ru/668

#интеграция #очереди

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

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

Здесь рассматривают реализацию с помощью кафки, в начале статьи общее описание идеи со схемками:
https://callistaenterprise.se/blogg/teknik/2018/10/26/synchronous-request-reply-over-kafka/

Может пора доклад запилить на тему?

#интеграция #очереди
Две статьи, чтобы сформировать общее понимание, что такое Kafka, и чем она отличается от других брокеров.

Совсем просто с картинками и выдрами:
https://habr.com/ru/post/563582/

Чуть глубже уже на техническом языке:
https://habr.com/ru/company/vivid_money/blog/534858

#хантинг
Минутка хантинга на нашем канале.

Ищу в команду сильного бизнес аналитика, который хочет решать проблемы бизнеса. Мы FoodTech проект, который занимается быстрой доставкой продуктов для американского рынка. Это как Вкусвилл, Я.Лавка и Самокат, только на другой стороне океана.

Чем нужно будет заниматься:
⁃ Много общаться с владельцами продуктов и реальным бизнесом: бухгалтерия, закупки, логистика, курьерская служба и т.п.
⁃ Выявлять боли и потребности бизнеса. Не только, когда они сами приходят к нам, но и действовать на опережение
⁃ Автоматизировать существующие процессы и запускать новые сервисы
⁃ Предлагать бизнесу альтернативные способы решения задач, анализировать их сильные и слабые стороны
⁃ Формировать карту развития бизнесов-процессов
⁃ Проектировать метрики, по которым можно отслеживать эффективность процессов и находить в них узкие места

Наши пожелания:
⁃ Самое важное - это стремление находить и предлагать решения бизнес-задач, а не записывать под диктовку со слов бизнеса
⁃ Мы используем Camunda для автоматизации процессов, поэтому полезно знать BPMN, либо быть готовым подружиться с ним

Если интересно, пишите в личку @and_burakov, расскажу все, что интересно.

#архитектура
Александр Поломодов из Тинькова начал публиковать вводный курс по архитектуре.
https://apolomodov.medium.com/essential-arch-course-intro-693682064cd6

На данные момент доступны 2/5 статей:
• Лекция про архитектуру и архитектора
• Лекция про код
• Лекция про данные
• Лекция про архитектурные стили и распределенные системы
• Лекция про распределенный архитектурный процесс и роль архитектора в нем

#интеграция #REST #API

Завершил священный поход на тему REST. Что в итоге получилось:
https://t.me/another_sa/57 - небольшая заметка, с которой все началось
https://youtu.be/DB2SER51mcU - запись вебинара на тему
https://systems.education/what-is-rest - конспект на основе вебинара

#API #интеграция

OpenRPC
При работе с JSON-RPC API становится больно, когда нужно его как-то задокументировать. В сваггере это делать жутко неудобно, ибо приходится засовывать все методы API под один эндпоинт и использовать вложенные anyOf. Резко теряется информативность и польза от визуализации. Да и не всегда мы используем http как транспорт. Как альтернатива неплохо заходит JSON-Schema, но она позволяет определить только структуру сообщений, а не методы API.

В поисках счастья нашел OpenRPC - детище ребят из эфира, которые решили запилить аналог сваггера для JSON-RPC.
Что внутри:
⁃ https://spec.open-rpc.org - схема для описания JSON-RPC API, предельно похожа на сваггер, только проще. Если писать ручками, то перейти будет довольно просто.
⁃ https://playground.open-rpc.org - удобный редактор, который красиво визуализирует схем и позволяет вызывать реальные сервисы.

Выглядит симпатично, но есть нюанс. С инструментами для генерации схем из кода и наоборот все грустно. Судя по активности в гитхабе и размерам комьюнити, в обозримом будущем ситуация особо не изменится. Так что, единственный сценарий использования OpenRPC - разработка красивых доков ручками. Но кому-то и это может быть полезно.

#API #интеграция

JSON-RPC
Раз уж в комментах спрашивают, то пусть будет и здесь.
Статья для быстрого знакомства с JSON-RPC, плюс его сравнение с REST-like подходом:
https://habr.com/en/post/441854/

Официальное описание стандарта: https://www.jsonrpc.org

#анализ

Наконец-то, кто-то написал, кем является бизнес-аналитик на самом деле, и чем он занимается:
“Таким образом аналитик в такой компании-подрядчике анализирует не бизнес, и даже не процессы, а запросы клиента на автоматизацию отдельных участков бизнеса”.

Кстати, это одна из причин, почему я стараюсь избегать разделения системных и бизнес аналитиков в работе.
https://beskov.medium.com/lies-statistics-and-ba-in-it-1bd10484a706

#анализ

Обычно рассказы о НФТ повествуют нам о 100500 видов требований, но редко отвечают на вопрос, как добыть конкретные значения. Да еще чтобы они были связаны с реальностью, а не спустились с потолка.

В докладе Сергей предлагает несколько практических способов расчета НФТ:
⁃ что можно добыть в гугле
⁃ как оценить требования к производительности системы
⁃ элементарная статистика, и чем она полезна при расчетах

Имхо, один из лучших докладов на эту тему
https://youtu.be/x0E0DrE5Fmo

#интеграция #API

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

⁃ версионирование апи и согласование релизов
⁃ разделение логики между бэкендом и мобильным фронтом
⁃ влияние качества связи на логику взаимодействий
⁃ передача чувствительных данных по открытым каналам

https://habr.com/ru/company/yandex/blog/583332/

#анализ #манагерское

Интересный подкаст о проблемах разработки. Редко можно услышать, как представители итшечки критикуют позицию своих собратьев в битве IT vs Бизнес
https://open.spotify.com/episode/6zJuQT6xCEYB7ggNYl1MGx?si=8_Q4fkzgT_C09v-4NVfpuA

Особенно откликнулась мысль о типичной позиции разработчика по отношению к бизнесу: “Я умный, а они все там идиоты, зачем с ними разговаривать?” Часто это сопровождается убежденностью в том, что “вот мы бы маркетинг-продукт-процессы сделали нормально, если б только захотели-могли”.

В этом году удалось пообщаться с четырьмя командами/компаниями, где решили создать выделенную роль системного аналитика. В трех из них мотивация была в духе: “Хотим как-то оградить разработчиков от того бреда, который несет бизнес, когда просит запилить очередную хрень”. Не буду гдадать, на сколько силный антагонизм между ит и бизнесом у этих ребят, но история вполне обыденная.

Думаю, это тот самый кейс, когда системные аналитики - это костыль, которым пытаются полечить проблемы процессов и коммуникаций в компании. Нечто подобное обсуждали с Филиппом в эфире Почему системный аналитик в компании - это bad smell?
Возможно, именно это пытались лечить скрамы и прочие аджайлы, вводя в единую команду разрабов, продуктов и бизнес-экспертов.

К чему все это? Аналитик, если ты связываешь бизнес и разработку, помогая им понять друг друга - далеко не всегда это повод для гордости.
*Не относится к заказной разработке.