Подписка на закрытый канал для системных аналитиков

Новые подборки полезных материалов теперь будут публиковаться в закрытом канале, который будет доступен по подписке.

Оформить подписку можно через кнопки ниже:
1. Нажимаете на кнопку с выбранным тарифом
2. Бот Donate присылает ссылку на оплату
3. После оплаты вам будет предоставлен доступ к закрытому каналу. Ссылки на чаптер системных аналитиков и канал с тестовыми заданиями будут в описании закрытого канала.

Что будет входить в подписку:
➖2-3 подборки материалов каждую неделю в закрытом канале
➖навигация по всем материалам
➖коммьюнити подписчиков — обмен опытом и общение
➖доступ к каналу с тестовыми заданиями из собеседований
➖тесты для самопроверки
➖(скоро) обновляемая база знаний по ключевым темам системного анализа
➖(скоро) исчерпывающая интерактивная карта навыков системного аналитика со ссылками на материалы из базы знаний

Тарифы:
💩350 ₽ — месяц
💩3400 ₽ — год (283 р/мес)

Что будет с текущим каналом?
Все уже опубликованные материалы в текущем канале (Системный Аналитик) останутся бесплатными. Однако новые материалы будут выходить реже:
— 2-3 полноценные подборки в месяц
— 1-2 конспекта по темам системного анализа еженедельно
— 1 книга каждую неделю

Текущие цены действуют для первых 50-ти подписчиков.

💠 Микрофронтенды – разбираем, что это такое

Микрофронтенды – это применение принципов микросервисного подхода к разработке фронтенда, при котором монолитный фронт разбивается на независимые части.

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

✏️ Пример использования

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

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

✅ Преимущества микрофронтендов

💩Сокращение времени до релиза (time-to-market). Так как команды могут релизить свои части независимо от других, это ускоряет процесс доставки нового функционала.

💩Гибкость и скорость разработки. Команды могут выбирать технологии, которые лучше подходят для их задач, и не зависеть от ограничений монолита.

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

💩Масштабируемость. Микрофронтенды позволяют оптимизировать загрузку и исполнение кода, так как каждая часть загружается и выполняется только тогда, когда нужна.

⛔️ Недостатки микрофронтендов

💩Сложность и накладные расходы. Микрофронтенды требуют большего усилия и ресурсов для разработки и поддержки, так как необходимо обеспечить согласованность и совместимость между разными частями. Также они вводят дополнительную сложность в виде интеграции, координации и мониторинга частей.

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

💩Дублирование кода. В микрофронтендах сложнее переиспользовать код. Конечно, есть решения: сделать библиотеку компонентов, вынести все утилиты в одно место, написать шаблоны, Но всё равно встречаются места, которые идентичны во всех проектах (например, конфиг) и когда наступит время это править, может быть больно.

Подборка материалов по микрофронтендам доступна в базе знаний по системному анализу

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

🔎 Elasticsearch: краткое описание и подборка материалов

Elasticsearch (ES) — это распределенный поисковой и аналитический движок, построенный на основе Apache Lucene. Предоставляет открытый и гибкий интерфейс для хранения, поиска и анализа данных в реальном времени. Условно говоря, ES — это документоориентированная NoSQL БД и гугл одновременно.

Elasticsearch является частью стека ELK (Elasticsearch, Logstash и Kibana).

💩Logstash собирает, обрабатывает и передает данные из различных источников в хранилище, такое как ES. Поддерживает различные источники данных и форматы логов.
💩Elasticsearch индексирует и анализирует собранные данные и производит поиск в них.
💩Kibana предназначена для работы с логами, поддерживает гибкий и сложный поиск по логам. Так же в Kibana можно строить дашборды, отчёты и визуализировать данные.
💩Также есть Beats — легковесные агенты для отправки логов в ES. Они более примитивны, чем Logstash, т.к. только собирают и отправляют данные, без преобразований

Архитектура Elasticsearch распределенная:

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

Как работает ES?

1. Данные отправляются в ES в виде документов JSON с помощью API или инструментов приема, например, Logstash.
2. ES автоматически сохраняет исходный документ и добавляет ссылку на него в индекс кластера, включая возможность поиска.
3. Следом можно найти и извлечь документ, используя API Elasticsearch.
4. Также для визуализации данных и создания интерактивных панелей управления можно задействовать Kibana.

🔨Применение ES

— Мониторинг и логирование. Хранение, поиск и анализ логов для отслеживания работы приложений, системы, серверов .

— Аналитика и BI. Поиск, фильтрация, агрегация, анализ больших объемов данных в реальном времени для выявления паттернов, создания отчетов. Например, компании в финансовой сфере используют ES для анализа данных о транзакциях, инвестициях и рынке

— Поисковые системы. Используется для быстрого и точного поиска. Например, платформы соцсетей используют ES для быстрого поиска, фильтрации и сортировки контента. Или интернет-магазины для поиска товаров. Также у ES есть возможность поиска и анализа данных на основе геолокации.

✅Преимущества ES

💩Быстрый поиск и агрегация данных. Обеспечивает мгновенный доступ к данным и эффективный поиск за счет распределенной архитектуры, индексации и возможности добавлять новые узлы в кластер
💩Отказоустойчивость. Достигается благодаря распределению данных и запросов между различными узлами кластера и шардами. В случае проблем ES автоматически восстанавливает реплики и данные.
💩Масштабируемость и гибкость. ES можно масштабировать горизонтально без потери производительности. Кластеры ES могут расширяться и сжиматься в зависимости от потребностей с помощью добавления новых узлов.
💩Экосистема ELK: входит в стек ELK, предоставляя комплексное решение для обработки, хранения и визуализации данных.

⛔️Недостатки ES

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

⭐️ Подборка материалов по Elasticsearch доступна в базе знаний по системному анализу

#инструменты

Обзор популярных нотаций моделирования

Владение нотациями крайне важно для системного аналитика. Это must have, который встречается практически в любой вакансии

Нотация — это система условных обозначений и правил для представления систем, процессов, участников и взаимосвязей в понятной графической форме.

Зачем нужны нотации

1️⃣ Визуализация сложного в картинках

2️⃣ Моделирование — позволяют создавать описание структуры данных для анализа системных процессов (например, для фиксации требований)

3️⃣ Стандартизация — единый язык для коммуникации между разными специалистами (например, бизнеса, разработки)

Виды нотаций

💩 Структурные нотации: отображают состав объекта и взаимодействие между его частями. Примеры: UML-диаграммы классов, компонентов, кооперации, композитной структуры, развертывания, пакетов, объектов и профилей. К таким нотациям относятся IDEF0, IDEF1x, IDEF4, IDEF5 и IDEF6 из стандарта IDEF.

💩 Динамические нотации: показывают потоки данных или логику выполнения процессов. Примеры: DFD, EPC, BPMN, а также UML-диаграммы деятельности, состояний, вариантов использования и последовательностей.

Примеры распространённых нотаций

🔹 BPMN (Business Process Model and Notation) — используется для моделирования бизнес-процессов. Представляет собой набор графических элементов, которые отображают задачи, события, шлюзы, потоки, пулы, дорожки и т.д. BPMN позволяет наглядно и однозначно описать логику, последовательность, роли и правила выполнения бизнес-процессов.

🔸 eEPC (extended Event-driven Process Chain) — нотация моделирования бизнес-процессов с фокусом на события и их результаты. eEPC показывает, какие события инициируют, контролируют и завершают функции, а также какие ресурсы и данные участвуют в процессах.

🔹 IDEF (Integrated DEFinition) — семейство нотаций (IDEF0, IDEF1, IDEF2 и т. д.) для описания разных видов моделирования, например, функционального, данных, логики и т.д. Одна из старейших нотаций.

🔸 UML (Unified Modeling Language) — это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. UML имеет 12 диаграмм, которые показывают структуру и поведение системы на разных уровнях.

🔹 DFD (Data Flow Diagram): для визуализации и анализа потоков данных в информационной системе. Помогает выявить входы, выходы и обработку данных в различных процессах.

🔸 ERD (Entity-Relationship Diagram) — нотация для моделирования сущностей и их отношений в базах данных. ERD показывает, какие сущности существуют в базе данных, какие атрибуты их описывают, какие связи между ними устанавливаются и какие ключи обеспечивают их идентификацию и целостность.

🔹 С4 (Context, Containers, Components, Code) – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: контекст, контейнеры, компоненты и классы.

🔸 ArchiMate — язык для моделирования архитектуры предприятия. ArchiMate имеет элементы, которые отображают бизнес, приложения, технологию, мотивацию и стратегию. ArchiMate позволяет описать, анализировать и визуализировать архитектуру внутри и за пределами бизнес-процессов. Тесно завязан на архитектурный фреймворк TOGAF.

📎 Ссылки
1. Один пример и три нотации: сравниваем BPMN, EPC и DMN
2. Ликбез по BPMN, EPC и UML activity с примерами для начинающих аналитиков
3. Основные нотации моделирования бизнес процессов и их применение
4. Плюсы и минусы IDEF, eEPC, BPMN
5. ТОП-5 нотаций моделирования архитектуры

⭐️ Подборка материалов по каждой нотации доступна в базе знаний по системному анализу

#проектирование #подборка

User Story vs Job Story

📄User Story – это краткое описание функции с точки зрения пользователя и наименьшая единица работы в Agile. В среднем, команда может выполнить 2-3 user story за двухнедельный спринт

Цель: декомпозировать требования на понятные и выполнимые элементы
Формула: Я, как [тип пользователя], хочу [желание], чтобы [ценность или результат]
Пример: Я, как пользователь сайта, хочу получить трек-номер, чтобы следить за посылкой. Я, как пользователь, могу запросить напоминание пароля, чтобы восстановить пароль

Как составить user story:
➖Определите пользователя, для которого создается функция
➖Сформулируйте результат, который получит пользователь после использования функции
➖Опишите ситуацию, в которой пользователь может использовать функцию
➖Укажите ограничения или условия, при которых функция должна работать

Способ проверки “INVEST”:
➖«I» Independent — независима от других историй
➖«N» Negotiable — обсуждаема, по ней можно спланировать дальнейшие действия
➖«V» Valuable — ценная, отвечает на вопрос «зачем»
➖«E» Estimable — оцениваемая, можно установить критерии успеха
➖«S» Small — маленькая или короткая, описывает одну задачу
➖«Т» Testable — тестируемая - можно получить обратную связь от пользователей и сделать выводы


🎯Job Story (инструмент из концепции Jobs To Be Done (JBTD)) - это описание возможных ситуаций, при которых пользователь хочет воспользоваться нашим продуктом

Цель: определить ситуации, в которых у пользователя возникает потребность в продукте
Формула: Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]
Пример: когда пользователь оплатил заказ на сайте, он беспокоится, доставят ли ему товар и хочет получить трек-номер, чтобы следить за посылкой

Способ проверки:
➖Описывает результат, который получит пользователь
➖Не содержит готовое решение
➖Описывает контекст, в котором человек находится при возникновении проблемы, а не саму проблему
➖Отвечает на вопрос «Почему/для чего?» мы должны это сделать

Отличия:
💩User Story описывает конкретный сценарий с точки зрения пользователя, Job Story - общую задачу, которую он выполняет в системе
💩User Story фокусируется на описании одной задачи, Job Story может включать в себя несколько User Story
💩User Story помогать лучше узнать пользователей, Job Story отвечают на вопрос почему они продолжают пользоваться продуктом и почему приходят новые


Совмещение инструментов:
1. Изучить потребности пользователей
2. Описать потребности по шаблону Job Story, это позволит видеть картину пользователя целиком: его чувства, эмоции, привычные реакции
3. Придумать как удовлетворить потребности, описанные в Job Story
4. Выбрать решение и описать его по шаблону User Story
5. Передать User Story в разработку

Итог:
💩Job Story подходит, если нужны идеи для доработки текущего продукта или создания нового
💩User Story подходит, если нужно декомпозировать и описать уже выбранное решение

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#требоваия

Тест-кейсы: как и зачем писать📝

Тест-кейс — это подробный алгоритм действий, по которому нужно проверять разработанный функционал.

Виды тест-кейсов:

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

❌ Негативные (отрицательные). Показывают, что система умеет работать с некорректными данными
Пример: пользователь при регистрации ввёл простой пароль 12345, а кнопка “Установить пароль” активной не стала, т.к ждёт более сложный

🚫 Деструктивные. Служат для проверки прочности системы
Пример: метод для получения заказов пользователя нельзя выполнить без авторизации


Особенности:
💩Идеально подходят для описания сложных проверок в системе и регрессионного тестирования
💩Помогают автоматизировать ручные проверки, если тестирование занимает много времени
💩Используются для проверки системы не тестировщиками, для онбординга новых людей на проект
💩Помогают определить необходимое время на тестирование
💩Избыточны для небольших задач
💩Требуют много времени на написание и актуализацию
💩Может возникнуть "Эффект пестицида" — когда из-за постоянного повторения одинаковых шагов не получается найти ошибки


Содержание тест-кейса

💫Уникальный номер. Позволит ссылаться на тесты по номеру
💫Заголовок. Отражает цель - что именно нужно проверить
💫Предусловия. Что нужно сделать перед началом тест-кейса
💫Постусловия (редко). Что нужно сделать после проведения проверки. Например, удалить изменения из базы данных
💫Шаги. Что нужно сделать для проверки
💩Не описывать шаги слишком подробно. Например, следует писать «Введите email» вместо «Введите email, нажимая клавиши на клавиатуре».
💩Шаги должны быть конкретными. Написать: “Нажмите на иконку пользователя → Личный кабинет” вместо “Зайдите в личный кабинет”
💩Скриншоты можно использовать только как дополнение к текстовому описанию
💫Ожидаемый результат. Что должно получиться после или во время прохождения шагов
💫Статус. Passed/Failed, то есть Успех/Провал или другой. Отмечается при прохождении кейса тестировщиком


Use Case 🆚 Test Case

🔹 Use Case — детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты. Используют для описания функциональных требований к системе

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


👨‍💻 Аналитик и тест-кейсы
➖На старте проекта кейсы может написать и согласовать аналитик - именно он лучше всех знает требования к системе. Это упростит сдачу проекта в будущем
➖Аналитик подсвечивает тестировщику какую часть функционала нужно оформить в виде кейсов для регрессионного тестирования - что было самым важным в релизе
➖Ревью тест-кейсов — аналитик проверяет, что тестировщик правильно понял задачу и ожидаемый результат соответствует требованиям


Инструменты ведения для тест-кейсов:
➖Zephyr for Jira
➖TestRail
➖Qase
➖Test IT


⭐️ Подборка материалов доступна в базе знаний по системному анализу

#тестирование

Kanban vs Scrum: сравнение методологий

Kanban и Scrum — методологии гибкого управления проектами, используемые для реализации принципов Agile и DevOps при разработке.

Kanban — подход к управлению процессом разработки, который включает следующие практики:

💩Визуализация задач и прогресса с помощью канбан-доски, установление приоритетов задачам
💩Ограничение количества задач со статусом "В работе", или WIP (work in progress). Если лимит превышен, то команда не может взять новую задачу в работу, пока не будет завершена одна из текущих
💩Управление потоком: отслеживание метрик, таких как скорость движения задач между статусами, для устранения «бутылочных горлышек», где процесс замедляется
💩Проведение каденций — встреч членов команды по процессу разработки. Всего выделяют 7 видов встреч. Главная цель — объяснение правил для всех участников команды и сбор обратной связи
💩Непрерывное улучшение процесса на основе обратной связи и анализа метрик

Что общего между Kanban и Scrum

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


✅ Когда лучше применять

Kanban:
💩 в проектах с типовыми повторяющимися задачами, например, техническая поддержка, где задачи обрабатываются по мере поступления и приоритеты могут меняться в зависимости от срочности
💩 команда не является кросс-функциональной
💩 в проектах с высокой степенью неопределенности, где требования часто меняются или неизвестны заранее. Kanban позволяет вносить изменения в любое время без нарушения цикла работы

Scrum:
💩 важен строгий контроль сроков и структура
💩 требуется четкое определение целей и результатов
💩 команда является кросс-функциональной
Пример: Разработка новой версии продукта с фиксированным релизным циклом, например, каждые 3 месяца.


❌ Когда не подойдет

Kanban
💩в проектах, где необходимо строго соблюдать сроки
💩в кросс-функциональных командах
💩когда требуется постоянная обратная связь от клиентов

Scrum
💩 продукт нужен целиком, итерации невозможны
💩 когда нет сплочённой, самоорганизованной и кросс-функциональной команды
💩 для слишком маленьких групп из 1–2 человек, или, наоборот, больших лучше заменить другими методами — SAFe, LeSS.


☯️ Гибрид ScrumBan

Используется в средах, где необходимо управление проектом в условиях неопределенности и частых изменений. ScrumBan легче внедрить, чем Scrum
💩от Scrum: сохраняет ключевые элементы Scrum: спринты, роли (Product Owner, Scrum Master, и команда разработки) и основные события (планирование, ревью, ретроспектива).
💩от Kanban: заимствует концепцию визуализации процесса на доске, ограничения рабочего объема, адаптацию к изменениям в реальном времени и фокус на поток задач.

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#управление_проектами