Ну какой же банальнейший и тупой пост, кому вообще это надо, любой джун и даже «вкатыш» всё знает про эти инструменты для формализации требований. Отписька 🔥
Скажешь ты и будешь абсолютно прав(а) 🤝
Но как бы смешно нам не было, вопросы на эту тему на собесах продолжают задавать, даже на позиции уровня senior... 🍅 Если честно, не всегда именно на тех. интервью, иногда вопросом по UC и US профилируют милейшие девушки (иногда не менее милейшие мужчины) HR, тем не менее – это 🌟
Чаще, наверное, только спрашивают про SOAP🧼 и REST🤟
Публикации на тему UseCase и UserStory у меня не было, поэтому держи памятку, сохраняй, расчехляй при поиске работы. Еще можешь поделиться ей и обязательно поставить реакции.
Итак, UseCase — это сценарий использования, описание взаимодействия пользователя с системой.
Пример:
Название: Просмотр истории операций
Акторы: Пользователь
Предусловия: Пользователь авторизован в приложении
Основной поток:
Пользователь входит в приложение
Заходит в блок с историей операций
Выбирает интересный ему промежуток дат и времени
Проверяет свои траты
Альтернативные потоки:
Если необходимо пользователь может активировать фильтры нужных ему видов или типов трат
Если пользователь выбирает промежуток без операций или фильтры, при применении которых операции отсутствуют, необходимо отобразить экран заглушку с предложением отменить фильтры/сменить промежуток.
Постусловия: отсутствуют
Исключения: Если при загрузки операций произошла ошибка, необходимо уведомить пользователя и предложить повторить попытку.
UserStory — короткое неформальное описание функциональности с точки зрения какой-то роли.
Пример:
Как пользователь, я хочу видеть историю операций, чтобы понимать сколько и на что уходит денег.
Состоит из:
Роль – пользователь
Действие – хочу видеть историю операций
Цель – чтобы понимать сколько и на что уходит денег
Ну, и чтобы памятка стала более законченной, делюсь еще методом для оценки качества пользовательских историй – INVEST:
Independent (Независимая) – История должна быть независимой от других историй.
Negotiable (Обсуждаемая) – Она должна отражать суть, а не детали, без указания конкретных шагов реализации.
Valuable (Ценная) – Эта история должна быть полезной для клиентов, бизнеса или/и стейкхолдеров.
Estimable (Оцениваемая) – Её можно оценить по сложности или другим параметрам(время, деньги).
Small (Компактная) – Команда может завершить эту историю за один спринт.
Testable (Тестируемая) – У нее есть различные критерии для проведения тестов.