Согласно IIBA, сегодня наш день 🥳 🎉 Всем огненных спек, милых девелоперов и покорных кастомеров!
https://www.iiba.org/events/global-events-calendar/celebrate-global-ba-day-in-your-organization

Под шумок профессионального праздника пара насущных вопросов, чтобы лучше понимать актуальную картину о нас любимых 🙂

Если не видели ранее, то вот тут полезные чеклисты от дядюшки Карла: https://www.linkedin.com/posts/karlwiegers_requirements-software-softwaredevelopment-activity-7120770364552486912--MO_

https://www.linkedin.com/posts/karlwiegers_use-case-template-activity-7125846452852981760--Nvs?utm_source=share&utm_medium=member_android
Согласны, или ну его эти юз кейсы нынче? 😊

Всем салют!

Итак, опросы показали такое:
- Confluence - наше всё (75%), на втором месте с грандиозным недобором - гуглодоки. Казалось бы, неудобненькая во многих аспектах работы система, но кушаем кактус (видно, из-за отсутствия достойных альтернатив).
- Figma крайне уверенно доминирует над Axure. Эх... ладно 🙈
- Большинство любят User Stories. Юз кейсы практически покинули чат, но спецификации как явление ещё весьма популярны (30%). Рады за них и за те 30%, кто много стучат по клавишам 🙂

Вполне интересные рассуждения на тему скрама: https://habr.com/ru/companies/ruvds/articles/772618/
А есть те, у кого скрам прямо вот огненно работает и приносит только кайф от работы? 😁

Всем привет! Наш первый публичный блин 🙈: https://www.youtube.com/watch?v=Xfmid0muueo
Надеемся, что это познавательно и интересно, но очень открыты к комментариям и советам 🤗

Донт агри.

Начнем с того, что выше не так:
То, как подавать требования внутри отдельно взятого UC или US - на практике на выбор автора (на что, кстати, намекает наш недавний опрос в группе). Сценарий внутри UC можно описать как "техническим" языком (например, ответы системы описать в терминах UI и включить туда все мельчайшие шаги алгоритмов системы в ответ на действия пользователя), так и "пользовательским" ("простым языком", описывающим только внешне видимый результат для юзера, а не детальные действия системы), причем последнее даже рекомендуется в большинстве теорий (дальше буду называть это "классиками").

Но: вне зависимости от языка внутри UC, они (UC) РОВНО АНАЛОГИЧНО US сфокусированы на потребностях пользователей - это техники взгляда на систему с позиции того, что пользователи могут сделать с системой и какую свою цель закрыть. В отличие, например, от взгляда со стороны features (которые системоцентричны).

Теперь о действительных ключевых различиях между техниками:

1) UC крупнее. UC описывают обособленную полезную операцию (достаточно обособленную, чтобы о ней можно было сказать "я пошёл в систему ради этой операции - сделал действо - ушёл, оставшись довольным"). Позвонить контакту - UC для мобильного телефона. Выбрать контакт из списка контактов - не UC, потому что только ради этого никто в телефон не пойдёт. Это всего-лишь шаг в рамках какого-то UC. Use case slices (UC 2.0) как подход пытался снять эти ограничения, но не прижился.
US такие ограничения не навязывает. Если что-то можно назвать полезным инкрементом системы, это кандидат в US. И в целом, есть такой посыл, что US нужно распиливать и распиливать, пока в принципе пилится (SPIDR), ибо так с ними удобнее работать в плане трэкинга и контроля в плане девелопмента. Выбрать контакт из списка контактов - вполне себе US, если об этом кусочке можно сказать "Раньше этого не было в системе для звонка, а теперь вот, в рамках очередной итерации, добавляем, делая тем самым процесс звонка более удобным".

2) UC имеет меньше свободы в плане детализации. Если отбросить постулат "Аналитик художник, он может творить с любыми техниками все, что угодно", то "классики" рекомендуют определённый формат для UC: предусловия сценария  -сценарии по шагам - постусловия/результаты.
Для US классики ничего не рекомендуют: хоть пишите сценарии внутри, хоть описывайте критерии приемки (что я вижу и получаю - на это, кстати, упор в рекомендациях большинства "классиков"), хоть куски спецификаций внутрь пихайте, хоть ничего не пишите - оставляйте все на устные беседы.

3) US имеет меньше свободы в плане описания. НЕ детализации, а описания. Для US есть такой параметр, как крайне рекомендуемый user story title/statement/description. As a... I want to.. So that... Попросту говоря, практически все "классики" говорят, что, мол, ни в коем случае не забудьте действующее лицо, операцию и ценность, причём объедините это все в такое вот предложение.
UC тут недалеко ушли (актёров и название UC пропускать также нельзя), однако явную формулировку ценности и такой формат склейки "классики" не навязывают (НО рекомендуют где-то в UC это осмысливать и указывать).

4) Последнее и ключевое отличие. Если судить по большинству "классиков" (и у этого есть практическое логичное обоснование), то UC - это целевое состояние системы, набор требований, досконально описывающий то, как операция работает здесь и сейчас. Позвонить контакту - всегда в вашей спецификации требований будет полностью описывать то, как идёт звонок контакту в текущий момент, на 235-ю итерацию разработки. UC - это база знаний. Если в следующей итерации заказчик захочет изменить UC (добавить шаги, поменять название операции и пр.), то в документации UC АКТУАЛИЗИРУЕТСЯ, т. е. МЕНЯЕТСЯ под стать соответствующим новым требованиям.
US -  это постановка задачи, а не целевое состояние или база знаний. Если вкратце, то это связано с тем, что agile - не о красивой документации, а о том, чтобы успешно сделать систему в моменте.

Если в итерации один была US Позвонить контакту, а в итерации 235 заказчик хочет звонить теперь с новыми шагами, то старая US НЕ ТРОГАЕТСЯ (in fact, она вообще забыта после приемки и релиза).  На новые шаги СОЗДАЁТСЯ новая US, которая фактически по своей сути является постановкой задачи команде на ближайшее время: команда, запили теперь вот такие новые шаги.

Буду рад обсудить, ибо между "классиками" и практикой иногда бывает огромный разрыв, плюс надеюсь, что кому-то это позволит не по-детски отжечь на собеседовании 😉