Post #577

Нельзя сказать, что в методах системного анализа ничего не происходит. Вот, например, Ивар Якобсон совместно с Алистером Коберном на днях выпустили новое(!) руководство по юскейсам: Use Cases 3.0 (pdf) Версия 3.0! Кто-то слышал про Use Cases 2.0? Там появилась такая идея, как "слайсы" — срезы юскейсов, напоминаюшие чем-то разбивку юзер-сторей, про которую я рассказывал на Flow в 2022 году. Вообще, я и Ивара и Алистера очень уважаю, но ещё первая книге Коберна звучала как монолог из советского фильма: "Не будет ни театра, ни кино — одно сплошноетелевидение одни сплошые use cases!", ничего, кроме юскейсов, вам для описания системы не нужно, и юскейсами можно описывать всё на любом уровне — от бизнеса до глубоко внутренних процессов внутри системы, и, конечно же, интеграции. Собственно, Use Cases 3.0 ровно об этом. Они вводят 10 принципов: 1. Юзкейсами можно описывать любые системы: и бизнес, и ИТ-системы, и физические; 2. Юзкейсы помогают увидеть "картину в целом": назначение системы и как ей пользоваться; 3. Юзкейсы фокусируются на ценностях: целях пользователя и как лучше всего достичь их; 4. Вовлечение стейкхолдеров обязательно: соберите их всех; 5. Юзкейс рассказывает историю, от начального события до получения ценности или неудачи, включая все альтернативы и проблемы; 6. Юзкейс должен вызывать обсуждения — только так вы обнаружите все пропущенные шаги и расширения; 7. Приоритет — удобство чтения. Цель — представить общую картину всем вовлеченным сторонам, получить комментарии, подсветить все пробелы, получить все согласия; 8. Формат юзкейса и уровень детализации может быть очень разным: вы можете начать с наброска последовательности событий и добавлять детали постепенно; 9. Юзкейс реализуется поэтапно: сначала разрабатываются ключевые сценарии, потом более редкие и менее критичные; 10. Система может быть разработана через "слайсы" юзкейсов, каждый слайс добавляет свою часть архитектуры, кода и тестов. Ну, если не брать слайсы, ничего особо нового тут нет — всё это и раньше говорилось. Разве что подчеркну акцент на сторителлинге, принцип 5: юзкейс — это история. Поэтому, собственно, не может быть юзкейса "отредактировать заявку" или "удалить документ" — сложно про такие элементарные действия рассказать историю. А начнете рассказывать — уровень формулировки юзкейса сразу повысится. Что ещё нового: использование юзкейсов описано в терминах Essence, как практика (с Альфами, их состояниями — жизненным циклом — и всяким таким). А вот что на самом деле интересно: авторы наконец-то дают ответ на вопрос, как юзкейсы связаны с user story. Оказывается, вот как: диаграмма юзкейсов описывает всю систему, отдельный юзкейс описывает одну цель пользователя, слайс юзкейса описывает один из способов достижения этой цели с возможными ограничениями, а user story — это, оказывается, единица работы, которую нужно выполнить, чтобы реализовать этот слайс (на один слайс может приходиться несколько юзер сторей). Единицей работы может быть также задача (task) или фича. В общем, для меня вся эта история выглядит, как попытка объяснить всем, что наш метод ещё ого-го! И вовсе он не устарел! И очень даже он крутой! А то, что вы там какие-то юзер-стори наизобретали, или job story, или ещё какой хипстерский способ описания — мы сейчас вам докажем, что это ерунда, и нужно использовать проверенный дедовский метод. Впрочем, если брать не юзер стори как таковые, а User Story Map — то там как раз довольно явно становятся видны юзкейсы (как шаги процесса в шапке карты), и юзер-стори, представляющие собой отдельные шаги или требования к шагам. Возможно, что-то в этом есть, и в руководстве приводится даже пример такого сочетания слайса и USM. Заодно обращу внимание, что никаких "пакетов юзкейсов" или "системных юзкейсов" в этом руководстве нет (но есть "инфраструктурные юзкейсы"!) В общем, если вы интенсивно используете в работе юзкейсы — вам должно быть любопытно, как их создатели видят их на исходе 2024 года (почти через 30 лет после изобретения). UPD: Добавил картинку с юзкейсом и юзер-сторями