#капитаночевидность #аналитик #системныйанализ #бизнесанализ
#инструменты #userstory #usecase

Вернёмся к #теория
Избитая всеми тема, какой подход лучше выбрать в фиксирование требований User Story или Use Cases.

Мало того, что многие не различают эти понятия, так ещё и не думают, а что лучше? Такое впечатление, что User Story это некая мода, поэтому не поддается анализу и логике их применение.

Ещё возникает постоянно вопрос, а какого чёрта вы не делаете микс? Почему на многих проектах забывают про существование Use Cases? Ой, мол как сложно. Надо думать. Я лучше буду херачить в своей песочнице...

В России постоянно всё из крайности в крайность. Но водку пьём, то торты едим. Точнее, то ТЗ на 100 страниц по ГОСТу канцелярским языком пишем, то на полстраницы User Story. Ни то, ни другое не даёт картины проекта. А ещё есть и противники UML. Я наоборот топлю за проектирование и описание функционала, как многослойного "торта" по диаграммам разного уровня детализации. Чтобы всегда можно было вернуться на тот уровень, который необходим.

"У нас нет времени" - вот что я постоянно слышу. Живя в Москве всю жизнь, могу сказать, что его никогда нет и оно есть всегда))) Опять же имхо, есть вещи без которых проект не сдвинуть, ну либо херак-херак и в продакшн. Тогда уже и о развитии сложно говорить и об системном анализе. Какие выводы делать по user story?

Тем кому тема близка и кто ломает голову, что лучше, посмотрите выступление с конференции, ссылка ниже.

Именно отсюда я знала о User Story 2.0, как раз когда появляется прослойка Use Cases и на них мапятся User Story. Вот так применяешь и то и другое и даже не знаешь, что это уже 2.0)))) Все когда-нибудь приходят к такой схеме работы с требованиями.

https://analystdays.ru/ru/talk/71737

#мысливслух #рассуждения #usecases #мойопыт #менторство #замечено #выводы #системныйанализ

Почему аналитики плохо пишут use cases?

Очень часто на курсах по интеграции в ШСА, да и не только, на менторстве тоже, и на собеседованиях встречается общая проблема по use cases. Аналитики плохо пишут сценарии вариантов использования.

👉1.Во первых, есть аналитики, кто не делает различий между use cases и user story. Вместо того, чтобы спрашивать аналитиков различие между Soap и Rest, на собеседование, лучше спросить различие между use cases и user story.
👉2.Во вторых, сценарии, как техника, используются на разных уровнях абстракции и не только аналитиками, но и тестировщиками, проектировщиками интерфейсов, продактами, да всеми)) Удобно.
👉3.Действительно, на системном или на уровне проектирования взаимодействия систем, мало кто из аналитиков грамотно может описать use cases. Это уже уровень архитектора, проектировщика, разработчика. Но он часто необходим на проектах, особенно если речь едет об интеграции.
👉4.Часто идёт ещё и смешение понятий функция и сценарий использования. Хотя use case вполне можно считать спецификацией функции.
👉5.Ну и плюс очень часто мы стараемся оперировать каноничным подходом, который был у Коберна (по крайней мере я всех к нему отправляю). И ещё пытаемся смаппить use cases и user story, я об этом писала, аж в 2020 году, что есть такое понятие как use cases 2.0 - https://t.me/start_in_IT/257

В самой технике сценариев, нет ничего сложного. Вот тебе основной, happy, поток, вот тебе расширения, где есть альтернативы и обработки исключений. Сюда же ещё и циклы включают. И получается, что есть канон, и есть реальность. И как сценарий эволюционировал мало кто знает, да и просто нет времени, надо делать работу)))

В итоге мы получаем высокоуровневые, часто до конца не проработанные сценарии. Их бы ещё детализировать и ещё докручивать и докручивать.

Выводы у меня следующие:
✅1.Высокоуровневые, на уровне бизнеса и взаимодействия пользователь - система, аналитики вполне отлично справляются.
✅2.Если аналитик не имеет базы, фундамента, плохо пишет алгоритмы, блок-схемы, то и сценарии также идут плохо. Везде в основе теория графов, сети Петри.
✅3.Сюда же я отнесу абстрактное мышление, это прям бич. Переключаться с одного уровня на другой самая большая проблема. Сложно понять где мы находимся, и где наши границы и рамки описания сценариев.
✅4.Сценарии на уровне взаимодействия модулей, систем требует знаний словаря данных, модели данных, что кому передаёт, как, в каком формате, по каким протоколам, синхронно, асинхронно, или файлами, или голубиной почтой.
✅5.Плюс сценарий не панацея и часто его нужно дополнять описанием алгоритмов, функций, а это математика. И я опять возвращаюсь к базовым, фундаментальным знаниям.
✅6.И ещё сюда добавлю обзор архитектурных решений. Потому что нужно хотя бы на пальцах понимать, как выстроено решение, к которому мы пишем уже на системном уровне требования, а точнее проектируем на языке требований, функций, что объединяет в себе целый комплекс знаний.

Итого: круг замыкается снова на том, что системный анализ инженерия, и даже в таком простом, с первого взгляда, инструменте, как use cases, собирает целый комплекс знаний.