Методологии разработки программного обеспечения за последние несколько десятилетий быстро эволюционировали, перейдя от тяжеловесной, предварительной документации по методологии водопад к легким, итеративным гибким практикам. Долгое время традиционный «Случай использования» — основной элемент объектно-ориентированной разработки программного обеспечения — считался несовместимым с современнымигибкими фреймворками таких как Scrum и Kanban. Его часто критиковали за чрезмерную ориентацию на документацию и медленную работу.
ПоявляетсяUse-Case 2.0. Представленный Иваром Якобсоном, Ианом Спенсом и Брайаном Керром, этот современный фреймворк переосмысливает классический случай использования, делая его легким, масштабируемым и универсальным. Он разработан для моста между структурными преимуществами случаев использования и гибкостью гибкой разработки.
Use-Case 2.0 — это современная эволюция подхода к случаям использования, разработанная специально для преодоления ограничений традиционного сбора требований. В отличие от своего предшественника, который часто требовал исчерпывающих деталей до начала кодирования, Use-Case 2.0 фокусируется на основных аспектах, итеративной доставке и вертикальной нарезке.
Ключевым нововведением этого фреймворка является способность разбивать случаи использования на более мелкие, управляемые части, известные каксрезы случаев использования. Это позволяет командам сохранять «общую картину» архитектуры системы, одновременно обеспечивая доставку ценности в небольших, размером с спринт, этапах, совместимых с Scrum, SAFe и Disciplined Agile.
Use-Case 2.0 основан на шести руководящих принципах, которые обеспечивают, что процесс остается эффективным и ориентированным на ценность:
Чтобы понять, как Use-Case 2.0 вписывается в Agile, необходимо понять его артефакты. Фреймворк упрощает громоздкую документацию прошлого, сводя её к трем основным компонентам.
Use-Case по-прежнему описывает целенаправленное взаимодействие между актором (пользователем) и системой. Однако в версии 2.0 он не детализируется полностью заранее. Он начинается с названия, краткого описания и основного сценария успеха. Детали, касающиеся альтернативных потоков и исключений, добавляются «вовремя», когда они приоритизируются для разработки.
Слайс Use-Case — это наиболее важное нововведение в этом фреймворке. Слайс — это вертикальный разрез по Use-Case, который представляет собой полный поток ценности. Он включает часть повествования (историй), соответствующие тест-кейсы, и код, необходимый для его реализации.
Разбиение позволяет одному Use-Case (например, «Обработка заказа») разбить на несколько спринтов:
Каждый слайс выступает как элемент бэклога — он поддаётся оценке, тестированию и может быть доставлен в рамках итерации.
В то время как слайсы обрабатываются в повседневной работе, модель Use-Case остаётся картой. Это совокупность всех Use-Case, обеспечивающая контекст и архитектурный обзор, которые часто отсутствуют у отдельных User Stories. Это решает распространённую проблему Agile, при которой команда завершает сотни историй, но теряет контроль над общим поведением системы.
Многие команды испытывают трудности с выбором между User Stories и Use-Case. Use-Case 2.0 утверждает, что вам не нужно выбирать; он предлагает структуру Use-Case с гибкостью историй.
| Аспект | Классические Use-Case (до 2.0) | Истории пользователей | Сценарии использования 2.0 |
|---|---|---|---|
| Предварительные усилия | Высокая (детальные спецификации) | Очень низкая | Низкая → поэтапная |
| Общая картина | Да | Часто теряется | Да (через модель сценариев использования) |
| Итеративная способность | Плохая | Отличная | Отличная (через срезы) |
| Следимость | Сильная | Слабая | Сильная (переходит в тесты) |
| Фокус на тестировании | Ручное / на поздних этапах | Критерии приемки | Встроенная по срезам (TDD) |
| Лучшая среда | Водопад / структурированная | Простые агильные проекты | Сложные / корпоративные агильные проекты |
Применение этой методологии включает циклический рабочий процесс, который идеально вписывается в стандартные агильные спринты:
Use-Case 2.0 особенно эффективен для корпоративных систем, регулируемых отраслей или сложных областей, где простые пользовательские истории недостаточны.
Он обеспечивает масштабируемость за счет возможности команд начать с минимальной нагрузки и добавлять формальность только там, где это необходимо. Он обеспечивает фокус на ценности заставляя команды думать о полном пользовательском пути, а не об изолированных технических задачах. Наконец, он решает проблему долга документации; поскольку модель использования обновляется итеративно, документация развивается вместе с кодом, выступая в роли «живого» набора требований, а не устаревшего архива.