🧐 Выбор между User Story и Use Case

Вопрос о предпочтении одного метода описания требований перед другим — User Story или Use Case — регулярно всплывает среди участников команд разработки и в профильных чатах. Давайте попробуем разобраться, какой метод действительно лучше выбрать, и можно ли вообще комбинировать оба подхода?

🚩 Что такое User Story?

User Story (пользовательская история) описывает поведение системы с точки зрения конечного пользователя, причём простым языком. Это короткое предложение, которое обычно формулируется следующим образом: "Как <роль>, я хочу <действие>, чтобы достичь <цель>".

▌ Плюсы:
- простота формулировки;
- фокусировка на потребностях пользователей;
- гибкость и традиционность для Agile-проектов.

▌ Минусы:
- отсутствие детализации и технических аспектов;
- требует постоянного взаимодействия с командой разработки для выяснения деталей;
- может вызвать ложное чувство простоты реализации.


🚩 Что такое Use Case?

Use Case (сценарий использования), напротив, представляет собой структурированное описание сценариев взаимодействия пользователя с системой. Оно включает детальное изложение шагов действий, условий, альтернативных путей и исключений.

▌ Плюсы:
- ясность сценариев и выполняемых взаимодействий;
- подходит для сложных систем с множеством ролей и вариантов поведения;
- идеально подходит для документирования традиционных водопадных проектов.

▌ Минусы:
- более сложный процесс подготовки и согласования;
- может показаться излишне бюрократичным для небольших команд и гибких подходов;
- в наглядности значительно уступает средствам визуализации вроде BPMN.

🕯Это, если тезисно и с определённой долей условности. Но как с этим работать — об этом далее.


🚩 User Story и/или Use Case?

🚩 Когда выбирать один из методов?

Выбор зависит от контекста проекта.

- Если команда работает по Agile, где важны короткие итерации и постоянная обратная связь, User Stories будут логичным выбором.
- Для больших и комплексных систем с высоким уровнем неопределëнности или критическими требованиями рекомендуется использовать Use Cases.

Что важно: выбор следует делать осознанно, но, одновременно с этим, приведённые ранее доводы — это не догма, а только отправная точка. Реальная практика может меняться в зависимости от обстоятельств и получаемой в процессе обратной связи.

🚩 Можно ли совмещать методы?

Да! Часто целесообразно комбинировать подходы. Здесь можно придерживаться следующей логики.

1⃣ Начните с высокоуровневых User Stories, чтобы быстро настроиться на образ результата, определить границы реализуемой функциональности и расставить приоритеты.
На этом этапе некоторые команды дополнительно создают диаграмму вариантов использования UML (Use Case Diagram), чтобы иметь возможность обозреть всю функциональность.

2⃣ Углубитесь в отдельные аспекты с помощью подробных Use Cases, особенно там, где требуются точные спецификации (например, обработка ошибок, неочевидное поведение или граничные условия).
Обычно одна User Story детализируется одним Use Case, при этом User Story в данном случае выступает своего рода заголовком для Use Case.

3⃣ При необходимости дополните Use Cases диаграммами процессов в релевантной нотации.
Так, на практике даже можно встретить подход, при котором каждый Use Case ограничивается несколькими ключевыми ветками сценария, а самая детальная логика представляется в виде развесистой диаграммы на BPMN.

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


🚩 И напоследок

Если требуется углубиться в вопрос разработки User Story или Use Case, советую ознакомиться с моей подборкой видео (ссылка), а точнее — с её 4-м разделом.

#требования #методыуправления #термины #статьи #гайды #визуализация

🥤🍔 Продуктовые метрики

Каждый, кто работает в продуктовой команде, время от времени слышит "мау", "ретеншн" и прочие кажущиеся заклинаниями слова 🧙🏻‍♀️🔮🪄. Не всем и не всегда они понятны, поэтому сегодня я решил этому вопросу посвятить отдельный пост.

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

Но, поскольку творчество и любознательность не стоят на месте, было придумано множество различных метрик на разные случаи жизни. И с достаточно внушительным перечнем можно ознакомиться в прикреплённой статье (ссылка).

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

1️⃣ Активность пользователей (DAU/MAU/WAU)

🔜 Описание: ежедневная активность (Daily Active Users), месячная активность (Monthly Active Users), недельная активность (Weekly Active Users) — показывают количество уникальных активных пользователей за соответствующий период времени.
🔜 Цель: измерение популярности и вовлечённости пользователей продукта.

2️⃣ Удержание пользователей (Retention Rate)

🔜 Описание: процент пользователей, продолжающих пользоваться продуктом спустя определённое время после первого взаимодействия.
🔜 Цель: оценка лояльности аудитории и качества продукта.

3️⃣ Отток пользователей (Churn Rate)

➡️ Описание: доля клиентов, прекративших использование продукта за указанный промежуток времени.
➡️ Цель: выявление проблемных зон и улучшение удержания пользователей.

4️⃣ Время жизни клиента (Lifetime Value, LTV)

➡️ Описание: совокупная прибыль, которую приносит клиент за весь срок пользования продуктом.
➡️ Цель: оптимизация расходов на привлечение🔥 новых клиентов и повышение доходности каждого пользователя.

5️⃣ Коэффициент конверсии (Conversion Rate)

🔜 Описание: отношение числа целевых действий (регистрация, покупка, подписка и др.) к общему числу посетителей сайта или приложения.
🔜 Цель: оценить эффективность маркетинговых усилий и удобство интерфейса продукта.

☝😒 Зачем это знать аналитику?

А затем, чтобы:
— общаться с PO на одном языке;
— понимать потребности бизнеса;
— принимать обоснованные решения при проектировании систем.

#статьи #продукт #термины

🌟 if pow (аналитик, 2) == архитектор

Часто замечаю, что в обсуждениях нет-нет да и возникает вопрос: куда расти аналитику? И, что примечательно, довольно популярной ответ – в архитектора решений.

Но стоит ли аналитику в действительности грезить карьерой solution-архитектора? Или эти две роли настолько разные, что одна из другой никак не вырастает?

Я рассуждаю так.

Системный аналитик – это как опытный следопыт🕵🏻‍♂️, шаг за шагом исследующий лес проблем заказчика и клиентов. Он знает каждую тропинку, ловушку и даже растяжку, старательно установленную смежниками😉 на пути. Но каким бы аналитик ни был выносливым, возможность прочесать весь лес всё же малореальна.

А вот архитектор решений – это как Маша из сказки "Маша и мелведь". Он высоко сидит и далеко глядит. 🔭 Его задача – увидеть общую архитектуру проекта, функциональной области или даже компании в целом, учесть риски и планы по трансформации ИТ-ландшафта. Поэтому архитектор с высоты физически может не видеть всех "тропинок", а некоторые из них просто сливаются в одну большую трассу.

Так что с того? Ответ, как мне предоставляется, таков: обе профессии важны и нужны, но они разные. Это всё равно что отоларинголог из вашей поликлиники мечтал бы вырасти до терапевта (или наоборот). Звучит странно? Вот то-то и оно! Потенциально возможно? Конечно! Если инвестировать время в приобретение соответствующих знаний, то любой переход становится возможным, если, конечно, есть такое желание.

Согласны ли вы с моей логикой? Делитесь мыслями в комментариях! ✨

⚖ Сравнение SOA и MSA

Время от времени в различных ситуациях возникает вопрос, чем отличается сервис-ориентированная архитектура (SOA) от микросервисной (MSA).

Кто-то говорит, что MSA это частный случай SOA. Иные убеждены, что вопрос только в размере интегрируемых систем или сервисов.

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

Не смотря на то, что последняя позиция мне кажется концептуально более верной, предлагаю обратиться к книге Криса Ричардсона "Микросервисы. Паттерны разработки и рефакторинга" (см. обзор) как к авторитетному источнику. В ней приводится следующее сравнение.

🟣Межсервисное взаимодействие

⚙️ SOA: Умные каналы, такие как сервисная шина предприятия (ESB), с использованием тяжеловесных протоколов вроде SOAP и других веб-сервисных стандартов
☸ MSA: Примитивные каналы, такие как брокер сообщений, или прямое взаимодействие между сервисами с помощью легковесных протоколов наподобие REST или gRPC

🟣Данные

⚙️ SOA: Глобальная модель данных и общие базы данных
☸ MSA: Отдельные модель данных и база данных для каждого сервиса

🟣Типовой сервис

⚙️ SOA: Крупное монолитное приложение
☸ MSA: Небольшой сервис

#архитектура #интеграции #сервисы

🧊 Куб масштабирования

Куб масштабирования (Scale Cube) — модель, которая указывает три принципиально возможных направления (аспекта) для масштабирования IT-систем.

Модель была разработана Мартином Фаулером и Джеймсом Льюисом, хотя одним из основных её популяризаторов по праву считается небезызвестный Крис Ричардсон. Экскурс в историю закончен, теперь перейдём к сути.

Модель куба масштабирования включает три типа масштабирования: по осям X, Y и Z.

🔤 Масштабирование по оси X
Запускается несколько одинаковых экземпляров приложения за балансировщиком нагрузки. Недостатки: увеличенное потребление памяти и отсутствие решения проблем, обусловленных сложностью приложения.

🔤 Масштабирование по оси Y
Приложение делится на отдельные независимые сервисы, каждый из которых отвечает за свою область функциональности. Возможны разные подходы к декомпозиции: на основе действий ("глаголы") или объектов ("существительные"). Недостатки: сложность управления множеством сервисов и рост зависимости от сетевой инфраструктуры.

🔤 Масштабирование по оси Z
Каждому серверу выделяется своя часть данных (разделение может выполняться по географическому признаку, по идентификационным номерам клиентов и т.д.), запросы автоматически направляются на нужный сервер. Недостатком является сложность реализации маршрутизации и потенциальная неравномерность распределения нагрузки.

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

💡 При этом важно отметить, что на практике масштабирование крупных систем часто выполняется сразу по нескольким осям.

#архитектура #интеграции #сервисы

Друзья, поздравляю всех с Днём системного аналитика! 🎂

Желаю, чтобы у вас полными были не только требования, но и банковские счета. Чтобы баги обходили стороной код вашей команды, а дедлайны становились такими же мягкими, как уютный диван после тяжёлого трудового дня.

Пусть каждый день приносит радость первооткрывателя. И пусть ваша зарплата растёт быстрее, чем список изменений в пожеланиях заказчиков!