Критерии приемки: как четко задавать границы User Story

Критерии приёмки — это четкие условия, по которым можно определить, действительно ли завершена и работает User Story. Они приносят пользу как команде разработки, так и заказчику. С помощью критериев приёмки можно:
— Очертить границы задачи, чтобы никто не додумывал
— Достигнуть общего понимания как внутри команды, так и с бизнесом
— Сделать оценку и планирование более точными
— Подготовить тестирование заранее, ещё до разработки
— Учесть негативные сценарии, которые иначе могут всплыть только на проде

Подходы к описанию критериев приёмки
Существует несколько подходов к тому, как формулировать критерии приёмки. Чаще всего используются два формата, которые могут применяться как по отдельности, так и вместе:
1️⃣ Свод правил. Перечисление требований и условий списком, своего рода чек-лист того, что должно быть реализовано для выполнения истории.
2️⃣ Сценарный подход. Описание поведения системы через пользовательские сценарии, например, в формате Given/When/Then (Gherkin).

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

🔹 Критерии приёмки как свод правил

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

Как сформировать такой список? Обычно аналитик и команда прорабатывают пользовательскую историю, задавая уточняющие вопросы заказчику и друг другу. Например, возьмём историю: «Как пользователь, я хочу искать товары в пределах заданного диапазона цен, чтобы найти подходящие мне по стоимости товары.» Чтобы сформулировать критерии приёмки для этой функции поиска по цене, команда выясняет детали:
— Какие границы цен может указать пользователь?
— Как именно пользователь задаёт диапазон — движком-ползунком или вводом точных значений с клавиатуры?
— Нужно ли нажимать кнопку для начала поиска или результаты должны обновляться автоматически?
— Как обрабатывать неверно указанный диапазон (пустой ввод, перепутанные границы)? Какое сообщение об ошибке показать?
— Как отображать результаты поиска: сколько элементов на странице, как реализовать пагинацию, сортировку?
— Учитывать ли товары, которых нет в наличии, или те, что скоро поступят?

🔹 Сценарно-ориентированный подход (Given/When/Then)

Сценарный подход описывает критерии приёмки через конкретные ситуации использования системы. Чаще всего его реализуют с помощью языка Gherkin, используя конструкции Given/When/Then (в русской адаптации – «Допустим/Когда/То»). Такой формат представляет собой набор сценариев, написанных на понятном для бизнеса языке, и отлично подходит для методик BDD (Behavior Driven Development).

Преимущества сценариев:
— Они понятны всем участникам проекта. Сценарии легко читаются и заказчиком, и разработчиками, что улучшает коммуникацию.
— Ориентация на поведение пользователя гарантирует, что разработка ведётся исходя из реальных требований и кейсов использования, а не абстрактных технических условий.
— Готовые сценарии можно использовать для автоматизированного тестирования. Повторное применение шагов (степов) из сценариев ускоряет написание тестов и снижает дублирование.

На воркшопе «Бизнес-анализ. Разработка пользовательских требований и постановка задач на разработку» у вас будет возможность на практике познакомиться с критериями приемки и многими другими техниками, которые помогают в описании постановки задачи на разработку ИТ-системы. Подробнее тут.

#воркшоп@systems_education #популярные_посты

Опубликовали запись доклада Влада Хононова на тему «Как найти оптимальную связанность компонентов при проектировании ПО» с третьей онлайн-конференции Systems Design Online

Тайм-код доклада:
00:00 О докладе
01:46 Что такое сложность?
04:48 Что вызывает сложность?
05:49 Влияние сложности
07:14 Сложность vs модульность
08:16 Что такое модульность?
09:59 Связанность
15:12 Сила интегрирования
16:05 Интеграция через вторжение
18:09 Функциональная связанность
20:20 Связанность через модель
23:00 Связанность через контракт
24:09 Модель интеграционной силы
25:14 Расстояние
27:34 Интеграционная сила vs расстояние
32:50 Что такое волатильность?
33:48 Модель поддоменов
35:30 Модель сбалансированной связанности
36:30 Заключение
37:42 Вопросы

Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК

✍️ Если вам интересна тема доклада, рекомендуем рассмотреть курс «Архитектура ИТ-решения: Проектирование и реализация MVP» (подробнее)

#конференция@systems_education

🌳 Дерево текущей реальности

Дерево текущей реальности Голдратта — инструмент, который превращает набор симптомов в строго проверяемую цепочку «причина → следствие» и выявляет одну–две корневые причины большинства нежелательных явлений.

Что даёт дерево:
— показывает, на какие факты реально стоит влиять
— создаёт общий язык для команды
— определяет, куда попадут показатели успеха после улучшений

Алгоритм построения дерева текущей реальности:
1. Соберите нежелательные явления. Записывайте только подтверждённые факты в утверждительной форме и с отрицательным контекстом, каждое явление — отдельная карточка.
2. Соедините карточки причинно-следственными стрелками «если … то …». При необходимости вставляйте промежуточные явления.
3. Проверьте каждую связь по восьми категориям правомерных оговорок:
— слова понятны и однозначны?
— существует ли это явление на самом деле?
— приводит ли причина к следствию?
— одной причины достаточно?
— есть ли ещё фактор, без которого следствие не возникает?
— не перепутаны ли направление стрелки?
— есть ли другие эффекты, которые должны проявиться, если связь верна?
— нет ли логического круга?
4. Найдите коренные причины — узлы, в которые не входят другие стрелки.
5. Поднимитесь к последствиям, задавая вопрос «и что тогда?». Эти верхние узлы фиксируют ущерб для денег, клиентов или сотрудников и позже станут ключевыми показателями эффективности.

🔔 В следующем посте мы расскажем, как использовать эту методику в качестве промта для ИИ

На курсе «Бизнес-анализ + ИИ. Разработка требований к ИТ-решению с использованием нейросетей» мы обучаем строить дерево текущей реальности на реальном бизнес-кейсе логистики. Подробнее тут.

#бизнес_анализ@systems_education #ИИ@systems_education

Ошибки рисования потоков данных: почему стрелки иногда вредят

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

📌 Перегрузка стрелок: визуальный шум

Симптомы:
— Каждая пара компонентов соединена стрелкой в обе стороны.
— Доска заполняется сеткой из линий, которые пересекаются и накладываются.
— Невозможно проследить ни один конкретный поток данных без огромных усилий.

В этот момент участники теряют суть разговора, а собрание фокусируется на ненужных деталях.

Как исправить:
— Выделяйте только ключевые потоки. Отмечайте стрелками лишь те взаимодействия, которые критичны для бизнес-функции или архитектурного решения.
— Группируйте компоненты. Если несколько компонентов обмениваются похожими данными, покажите общий шлюз или шину сообщений вместо десятка стрелок.
— Используйте стили стрелок. Разные типы линий (пунктир, толстая линия) помогут разграничить синхронные запросы, асинхронные события и «человеческие» коммуникации.

📌 Фиксация стрелок вместо событий

Симптомы:
— Постоянное рисование «от А к Б» блок-схем, где забыты ключевые события домена
— Стрелки заполняют место, где должны висеть стикеры с бизнес-событиями

Так теряется смысл Event Storming, и фокус смещается с «что происходит» на «как соединить»

Как исправить:
— Начинайте с событий. Сначала фиксируйте все события на таймлайне, а только потом рисуйте самые важные связи.
— Используйте стрелки для интеграции, а не для каждого события. Эвенты остаются на месте, а стрелками отмечаете только вызов новых обработчиков или сервисов.
— Чётко разделяйте зоны Event Storming и Data Flow Design. Делайте два этапа: сначала «нарисовать события», затем «нарисовать только критичные потоки данных».

Чтобы предотвратить возможные ошибки:
— Фильтруйте только ключевые потоки, группируя остальное
— Разграничивайте типы взаимодействий (команда, запрос, событие, ответ)
— Не забывайте об ошибках и обратных путях
— Сначала фиксируйте события, затем — минимальные связи для интеграции
— Чётко указывайте инициатора и направление каждого потока

Приглашаем вас на воркшоп: «Event Storming как техника моделирования предметной области и выявления микросервисов». На нем вы освоите все этапы моделирования, от Big Picture до System Design, и научитесь применять Event Storming в команде.
Регистрация

#воркшоп@systems_education
#event_storming@systems_education

Опубликовали запись вебинара на тему «Что может пойти не так в микросервисах»

На вебинаре Аким Мамедов, Software Engineer с опытом проектирования и реализации корпоративных систем, разобрал:
— что такое монолит, а что — микросервис
— почему не стоит сразу писать на микросервисах
— когда действительно нужно переходить на микросервисы
— как выглядит ад микросервисов на практике
— какие задачи придётся решать в микросервисной архитектуре: логгирование, трейсинг запросов, observability

Тайм-код вебинара:
00:00 Введение
02:03 План вебинара
02:25 Два вида архитектуры
03:49 Юзкейсы для микросервисов
09:02 Сложности микросервисов
11:02 Детали реализации
14:58 Выводы
17:16 Вопросы и ответы

Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК

Курс, который может быть вам интересен — Проектирование микросервисов

📌 Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

#вебинары@systems_education

Представьте: проект в разгаре, а перед запуском его в прод вдруг получается, что нет функционала, потому что на этапе проектирования системы требование недовыявили… Итог — аврал, доработки и сдвигающиеся сроки. Знакомо? Каждый такой «сюрприз» — потерянные время, деньги и нервы. Недаром говорят: доработать требования в начале проекта куда легче, чем переписывать потом тысячи строк кода. Как предотвратить эти ситуации? Один из проверенных способов — формализация требований с помощью Use Case.

Как именно Use Case помогает избежать ошибок в требованиях и сэкономить на доработках, рассказали ниже.

1️⃣ Помогает выявлять скрытые сценарии и исключения на раннем этапе. Прописывая различные варианты использования системы, аналитик заранее замечает нетривиальные пути. Use Case вынуждает продумать альтернативные потоки и исключения, которые иначе проявились бы только ближе к релизу. В результате скрытые требования и зависимости обнаруживаются заранее, а решение выходит более полным и устойчивым. Никаких внезапных «ой, а что если пользователь сделает X?» на финальных стадиях — эти вопросы вы закрываете еще на этапе анализа.

2️⃣ Упрощает коммуникацию с командой разработки. Это общий язык, который понятен аналитику, тестировщику и разработчику. Сценарии использования служат эффективным средством коммуникации: они снимают разночтения, помогают совместно уточнить требования и границы проекта. В итоге и ожидания клиента, и план реализации синхронизированы.

3️⃣ Диаграмма Use Case формирует общую картину того, как можно пользоваться системой: от входа в систему до достижения цели. Это не разрозненные пожелания, а связное повествование о работе системы. Такой подход дает целостное видение функциональности: какой функционал доступен конкретной роли; какие смежные системы задействованы в каждом отдельном варианте; для каких функций необходимо участие пользователя, а какие выполняет сама система при срабатывании триггера. Такой подход позволяет отследить по функциям различия в ролевой политике, а также «логику» распределения доступов и функционала. При этом процесс контроля полноты выделенных Use Case также становится проще, позволяя избежать ситуаций, когда «упустили какую-то часть процесса».

Применение Use Case снижает вероятность некорректного понимания требований. Если при описании требования в виде конкретных Use Case соблюдены все правила формирования качественных требований, то они перестают быть расплывчатыми тезисами. Каждый Use Case — это четкое однозначное описание поведения пользователя и системы в каждом отдельно взятом варианте. Такая конкретика повышает точность понимания системы и уменьшает риск разных трактовок со стороны участников проекта. В итоге - у всех единое видение, что именно должно быть реализовано, и заказчик получает то, что ожидал увидеть.

Четкое выделение шагов в Use Case позволяет однозначно определить и оценить результат, который должен быть на каждом шаге достигнут. Это дает возможность тестировщикам качественно подготовиться к тестированию функционала заранее, еще на этапе проектирования, что положительно влияет на соблюдение сроков и качества процесса разработки.

Use Case — это не лишняя бюрократия. Эта диаграмма может стать отличным помощником всей команде разработки. Научиться, как правильно описывать требования с помощью Use Case, Вы можете на нашем воркшопе «Use Case: основы».

Подробнее

#воркшоп@systems_education #системный_анализ@systems_education #требования@systems_education #Use_Case@systems_education

27 июня (пт) в 18:00 мск проведём вебинар в формате круглого стола на тему «Аналитик 1С: Границы ролей и технологий»

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

▫️Кому будет полезен вебинар?
— Аналитикам 1С всех специализаций
— Системным аналитикам и solution-архитекторам, которые периодически сталкиваются с проектами на 1С
— Бизнес-аналитикам и product-/project-менеджерам, отвечающим за формулирование требований и выбор технологической стратегии
— Разработчикам 1С и full-stack-инженерам, которые нередко совмещают кодинг с аналитической работой
— IT-директорам, руководителям цифровых проектов, владельцам процессов, стремящимся сократить «дистанцию» между бизнес-потребностью и реализацией
— HR- и L&D-специалистам

▫️Участники круглого стола
— Михаил Максимов, Продакт, Бизнес-аналитик. Кандидат экономических наук. Автор и ведущий YouTube-канала для системных и бизнес-аналитиков. TOGAF certified.
— Татьяна Рыловникова, Старший аналитик 1С в OZON Банк. В 1С с 2016 года, работала с очень широким спектром конфигураций (от бухгалтерии предприятия до ERP, по дороге захватив общепит, тоир, университет и не только).
— Илья Отькало, Ген. директор «CORS Academy». Автор Курса Аналитика 1С. Автор книги «Автоматизация бизнес-процессов».
— Денис Богданов, Руководитель группы развития анализа в BIA Technologies. Более 15 лет в IT на разных позициях (разработчик, руководитель проектов, product owner, full-stack аналитик) в B2B и B2G.

👥 У всех слушателей будет возможность задать вопросы в режиме реального времени

Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

Регистрация обязательна
❗️Если у вас не открывается страница регистрации в браузере Telegram, перейдите в любой другой браузер — это должно решить проблему.


▫️Рекомендации SE
— Для аналитиков 1С, которые хотят перейти в другой стек — Курс «Интеграция систем. Разработка требований и основы проектирования»
— Для системных аналитиков, кто хочет перейти в 1С — Курс Аналитика 1С

#вебинар@systems_education

Event Storming + C4: как эффективно использовать их вместе?

▫️Event Storming — однозначный must-have для аналитиков

Event Storming зарекомендовал себя как незаменимая техника для быстрого изучения сложных доменов. Практика это подтверждает: собирая в одной комнате бизнес-экспертов и разработчиков, эта методика творит чудеса понимания. Из хаотичного моря оранжевых стикеров постепенно проступает стройная картина процессов и событий.

Однако после яркой и продуктивной сессии возникает логичный вопрос: что делать со всей этой информацией дальше? На стене — красочное полотно из стикеров, в головах участников — масса инсайтов. Известно, что по итогам Event Storming бизнес-процесс виден на схеме, но еще более важно знание, которое возникло в умах участников. Вот тут и таится проблема: как сохранить и передать это знание тем, кто не был на сессии, и не утратить важные детали?

▫️Нотация C4 в таких случаях становится мостом от домена к архитектуре

Нотация C4 — легковесный стандарт для описания программной архитектуры. Контекстная диаграмма (C4 Level 1) отлично подходит для структурирования знаний сразу после сессии Event Storming'a. Она берет то общее видение, что родилось на стикерах, и оформляет в понятную картину системы и ее окружения. По сути, мы переводим язык событий и акторов в язык компонентов и связей.

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

▫️Комбинация Event Storming + C4 — это полезный тандем, который позволяет не только быстро разобраться в бизнес-домене, но и закрепить понимание в виде четкого плана системы. Event Storming дает энергию и глубину инсайтов, C4 — структуру и наглядность.

В нашей школе у вас есть возможность на практике познакомиться с двумя этими техниками на практике.
Подробнее о воркшопе по C4
Подробнее о воркшопе по Event Storming

#воркшоп@systems_education