USE-CASE 2.0. Неофициальный перевод

 

Перевод Шамрай А.В.

Содержимое Об этом руководстве Как читать это руководство Что такое сценарий использования 2.0? Базовые принципы Принцип 1: Сохранять их простыми, рассказывая истории Принцип 2: Понимать общую картину Принцип 3: Сосредотачивать внимание на значении Принцип 4: Строить систему слайсами Принцип 5: Поставлять систему инкрементами Принцип 6: Адаптировать под потребности команды Сценарий использования 2.0 – содержимое С чем работать Рабочие продукты Что делать Использование Сценария Использования 2.0 Сценарий Использования 2.0: применим для всех типов систем Сценарий Использования 2.0: обрабатывает все виды требований Сценарий использования 2.0: применим для всех подходов разработки Сценарий Использования 2.0: масштабирование под ваши потребности Заключение Приложение 1. Рабочие продукты Вспомогательная информация Тестовый сценарий Модель сценариев использования Повествование сценария использования Реализация сценария использования Глоссарий Благодарности Общие Людям Библиография Об Авторах

USE-CASE 2.0. Заключение

<<Содержание

Сценарий использования 2.0 существует как проверенные и хорошо определенные практики, которые совместимы со многими другими практиками разработки программного обеспечения, такими как непрерывная интеграция, преднамеренная архитектура и разработка через тестирование. Он также работает со всеми популярными практиками управления. В частности, он довольно легкий и гибкий для поддержки команд, которые работают на гибкой основе. Он также довольно полон и строг, чтобы поддерживать команды, которые работают в более формальных условиях или используют водопад.

Сценарий использования 2.0:

• Легкий – в его определении и применении.
• Масштабируем – и подходит для команд и систем всех размеров.
• Универсален – и подходит для всех типов систем и подходов разработки.
• Прост в использовании – модели сценариев использования могут быть быстро сформированы и слайсы созданы для покрытия требований команды.

Сценарии использования 2.0 в этом руководстве является бесплатным и публичным. Разделы Сценария использования 2.0 «С чем работать» и «Что делать» являются договорными. Хотя возможно применить только части Сценария использования 2.0, результаты будут неопределенными и практика не будет являться Сценарием использования 2.0.

Это руководство намеренно представлено легким и может быть недостаточным для вас, чтобы адаптировать практику. Дополнительная информация доступна в виде полностью задокументированных практик и веб-публикаций на сайте www.ivarjacobson.com. Она предлагается как отдельный веб сайт или расширение для EssWork.

Это первая из многих публикаций по Сценарию использования 2.0, но вы можете найти много других статей, технических документов и блогов по этому вопросу, опубликованных на www.ivarjacobson.com.

USE-CASE 2.0. Об Авторах

<<Содержание

Ивар Якобсон

Доктор Ивар Якобсон — отец компонентов и архитектуры компонентов, сценариев использования, аспектно-ориентированной разработки программного обеспечения, современного бизнес инжиниринга, Unified Modeling Language и Rational Unified Process. Его последним вкладом в индустрию программного обеспечения является концепция формальной практики, которая продвигает практики как «объекты первого класса» в разработке программного обеспечения и рассматривает процесс просто как совокупность практик. Он является основным автором шести влиятельных и самых продаваемых книг. Он является основным спикером на многих крупных конференциях по всему миру и обучил несколько консультантов по улучшению процессов.

Айян Спенс

Айян является главным техническим директором в Ivar Jacobson International, где он специализируется на гибком применении Unified Process. Он является сертифицированным практиком RUP, ScrumMaster-ом и является опытным тренером, поработав в 100-е проектов внедрения итеративный и гибких методов. Он имеет более чем 20 лет опыта в индустрии программного обеспечения, который охватывает полный жизненный цикл разработки, включая определение требований, архитектуру, анализ, проектирование, разработку и управление проектами. Его вопросами специализации являются итеративные проекты, работа с гибкими командами и управление требованиями через сценарии использования. В роли технического директора Айян способствует техническому направлению Ivar Jacobson International и работает с технологическим офисом компании для определения следующего поколения современных, активных практик разработки программного обеспечения. Он является лидером проекта и процессным архитектором разработки Essential Unified Process и практик, которые он содержит. Когда он не работает над исследованиями, поиском и определением практик, он проводит свое время, оказывая помощь компаниям в создании и выполнении программ изменений для повышения потенциала разработки программного обеспечения. Он является соавтором книги Addison Wesley «Use Case Modeling» и «Managing Iterative Software Development Projects».

Биттнер Курт

Курт – главный технический директор Ivar Jacobson International Северной и Южной Америки. Он проработал в индустрии программного обеспечения более чем 25 лет в различных ролях, включая разработчика, руководителя группы, архитектора, руководителя проекта и бизнес-лидера. Он вел гибкие проекты, запустил большой отдел разработки программного обеспечения для компании, спас и развил несколько стартапов, выполнял приобретения и работал с клиентами в различных отраслях промышленности, включая аэрокосмическую, финансы, энергетику и электронику. Он внес ключевой вклад в раннюю разработку Rational Unified Process, а также, совсем недавно, проект IBM Jazz. Его опыт включает в себя значительную работу в банковской сфере и финансов, проектирование и разработку архитектуры систем реляционных баз данных, консалтинг и наставничество широкого спектра клиентов по улучшении стратегии и подходов разработки программного обеспечения. Он является соавтором книг «Use Case Modeling», «Managing Iterative Software Development Projects» и «The Economics of Iterative Software Development».

USE-CASE 2.0. Библиография

<<Содержание

Object Oriented Software Engineering: A Use Case Driven Approach

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, Gunnar Overgaard

Оригинальная книга, которая представила миру сценарии использования.

• Publisher: Addison-Wesley Professional; Revised edition (July 10, 1992)
• ISBN-10: 0201544350
• ISBN-13: 978-0201544350

The Object Advantage: Business Process Reengineering With Object Technology

Ivar Jacobson, Maria Ericsson, Agneta Jacobson

Полное руководство по использованию сценариев использования для реинжиниринга бизнес-процессов.

• Publisher: Addison-Wesley Professional (September 30, 1994)
• ISBN-10: 0201422891
• ISBN-13: 978-0201422894

Software Reuse: Architecture, Process and Organization for Business Success

Ivar Jacobson, Martin Griss, Patrik Jonsson

Полное руководство по повторному использованию программного обеспечения, включая углубленное руководство по использованию сценариев использования для разработки производственных линий и взаимосвязанных систем.

• Publisher: Addison-Wesley Professional (June 1, 1997)
• Language: English
• ISBN-10: 0201924765
• ISBN-13: 978-0201924763

Use-Case Modeling

Kurt Bittner and Ian Spence

Полное руководство для создания модели сценариев использования и написания хороших вариантов использования.

• Publisher: Addison-Wesley Professional; 1 edition (August 30, 2002)
• ISBN-10: 0201709139
• ISBN-13: 978-0201709131

Aspect-Oriented Software Development with Use Cases

Ivar Jacobson and Pan-Wei Ng

Книга, которая представила миру слайсы сценариев использования в их первом облике как модули сценария использования.

• Publisher: Addison-Wesley Professional; 1 edition (January 9, 2005)
• ISBN-10: 0321268881
• ISBN-13: 978-0321268884

USE-CASE 2.0. Благодарности

<<Содержание

Общие

Сценарий использования 2.0 подготовлен на основе признанных передовых практик, используемых и проверенных десятилетиями. Мы хотели бы поблагодарить десятки тысяч людей, которые повседневно используют сценарии использования в своих проектах, и в частности тех, которые делятся своим опытом внутри и вне их собственных организаций. Без всей их напряженной работы и энтузиазма мы не имели бы мотивации или понимания необходимости эволюции этой техники. Мы надеемся, что вы найдете это небольшое электронное пособие полезным и продолжите оценивать и адаптировать способы применения сценариев использования.

Людям

Мы также хотели бы поблагодарить всех, кто непосредственно способствовал созданию этой книги, включая, но без определенного порядка: Пол Мак-Магон, Ричард Скафф, Эрик Лопес Кардосо, Сванте Лидман, Крейг Люций, Тони Людвиг, Рон Гартон, Буркхард Перкинс-Голомб, Арран Хартгровес, Джеймс Гэмбл, Брайан Хупер, Стефан Байлунд и Пан Вэй Нг.

USE-CASE 2.0. Глоссарий

<<Содержание

Альтернативный поток: Описание варианта или необязательного поведения в рамках повествования сценария использования. Альтернативные потоки определяются в отношении к основному потоку сценария использования.

Аспектно-ориентированное программирование: Технология программирования, которая стремится повысить модульность через обеспечение разделения сквозных ответственностей (см. http://en.wikipedia.org/wiki/Aspect-oriented_programming).

Диаграмма сценариев использования: Диаграмма, показывающая набор субъектов и сценариев использования и их взаимосвязи.

Заинтересованное лицо: Лицо, группы или организация, которая затрагивает или затрагивается программной системой.

Заказчик: Заинтересованная сторона, которая оплачивает развитие системы или которая, как ожидается, купит систему после ее завершения.

История: Способ использования системы, который имеет значение для пользователя или других заинтересованных сторон. В Сценарии использования 2.0 история описана как частью повествования сценария использования, одним или более потоками, специальными требованиями и одним или несколькими тестовыми сценариями.

Модель сценариев использования: Модель всех полезных способов использования системы и значение, которое они будут обеспечивать. В основном модель сценариев использования состоит из ряда субъектов, набора сценариев использования и схемы, иллюстрирующей их взаимоотношения.

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

Повествование сценария использования: Описание сценария использования, которое рассказывает историю о том, как система и ее субъекты работают вместе для достижения определенной цели. Она включает в себя последовательность действий (включая различные варианты), выполняемые системой и ее субъектами для достижения цели.

Пользователь: Заинтересованное лицо, которое взаимодействует с системой для достижения своей цели.

Поток: Описание некоторых полных или частичных путей через повествование сценария использования. Всегда есть по крайней мере основной поток, а также могут быть альтернативные потоки.

Приложение: Компьютерное программное обеспечения, призванное помочь субъектам в выполнении конкретных задач.

Программная система: Система, состоящая из программного обеспечения, оборудования и цифровой информации, которая обеспечивает свое основное значение при выполнении программного обеспечения. Программная система может быть частью большего программного обеспечения, аппаратного обеспечения, бизнес или социального решения.

Разделение ответственности: Процесс расщепления системы для сведения к минимуму дублирования функциональности (см. http://en.wikipedia.org/wiki/Separation_of_concerns).

Система: Группа вещей или частей, работающих вместе или соединенных некоторыми методами для формирования единого целого. Обычно используется для обеспечения проблематики модели сценариев использования: продукт, который будет построен.

Слайс сценария использования: Слайсом сценария использования является одной или несколько историй, отобранных из сценария использования в форме рабочего элемента, который имеет понятное значение для Заказчика.

Субъект: Субъект определяет роль, которую пользователь может представлять при взаимодействии с системой. Пользователь может быть лицом или другой системой. Субъекты имеют имя и краткое описание, и они связаны со сценариями использования, с которыми они взаимодействуют.

Сценарий использования: сценарий использования – это все пути использования системы для достижения определенной цели для определенного пользователя.

Сценарий использования 2.0: Масштабируемая, гибкая практика, которая использует сценарии использования для определения набора требований и направления инкрементальной разработки системы для их реализации.

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

Требования: Что программная система должны делать для удовлетворения заинтересованных сторон.

Элемент системы: Единица набора элементов, который представляет собой систему (ISO/IEC 15288:2008).

USE-CASE 2.0. Приложение 1. Рабочие продукты

<<Содержание

В этом приложении содержатся определения и дополнительная информация о рабочих продуктах, используемых в Сценарии Использования 2.0.

Это следующие рабочие продукты:

• Вспомогательная информация
• Тестовый сценарий
• Модель сценариев использования
• Повествование сценария использования
• Реализация сценария использования

Вспомогательная информация

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

Вспомогательная информация:

• Помогает обеспечить общее понимание описываемого решения.
• Фокусируется на понятиях и терминах, которые должны быть понятны всем, кто участвует в работе, и, в частности, на эти термины ссылаются сценарии использования.
• Описывает важные глобальные требования и атрибуты качества, такие как поддерживаемые платформы и доступность системы, которые не относятся к отдельным сценариям использования.
• Детализирует любые стандарты, которые должны быть выдержаны. Например, написание кода, презентации, язык, безопасность и другие отраслевые стандарты, которые применяются к системе.
• Помогает определить дополнительные истории, которые сложно идентифицировать непосредственно из сценариев использования, например, которые будут использоваться для демонстрации различных поддерживаемых платформ или желаемого уровня доступности.

Роль вспомогательной информации заключается в поддержке развития сценария использования и реализации слайсов сценариев использования. Их описание дополняет вашу модель сценариев использования и помогает избежать недопонимания между членами команды. Информация может собираться из многих источников, например, другие документы с описанием требований, спецификации и обсуждения с заинтересованными сторонами и экспертами в предметной области. Можно также включить модель предметной области, модель процесса и другие бизнес-модели, если они помогают в изучении модели сценариев использования и системы, которую она описывает.

Вспомогательная информация может документироваться различными уровнями детализации, начиная от простого набора базовых определений до всеобъемлющих и полностью описанных наборов определений, стандартов и атрибутов качества. Вспомогательная информация может быть представлена на следующих уровнях детализации:

	Инициирована: Промежуточный уровень детализации, который указывает на то, что это простое описание наиболее очевидных терминов и затрагиваемых областей. В дальнейшем описание должно быть сделано более подробным, если информация используется для поддержки успешной идентификации и подготовки правильных слайсов сценариев использования.
	Выполнены простые определения: Все термины, которые используются в повествовании сценариях использования, должны быть определены и должны быть четко указаны глобальные атрибуты качества системы. На этом уровне детализации они описываются как простые списки декларативных определений, некоторые из них используются в глоссарий данной книги. Это легкий уровень детализации, который обеспечивает поддержку для разработки слайсов сценариев использования. Он также определяет глобальные требования системы, которые позволяют группе рассказать, что после реализации ее слайсов система действительно может использоваться, а доступна не только для демонстрации. Такой уровень подходит для большинства команд, особенно для тех, которые тесно сотрудничают с пользователями и могут заполнить любую отсутствующую информацию на основе общения с ними.
	Выполнены модели и иллюстрации: Больше детализации для вспомогательной информации может быть добавлено через преобразование основных определений в модели, которые точно отображают определения, их атрибуты и их отношения, а также через реальные уточняющие примеры. На этом уровне детализации мы выходим за рамки простого определения и начинаем использовать взаимодополняющие методы, такие как каталоги бизнес правил, информационное моделирование и моделирование предметной области. Это особенно полезно для поддержки моделей сценариев использования, где непонимание требований может иметь серьезные последствия для безопасности, а также в финансовой или юридической областях.
	Полностью определена: Иногда необходимо уточнить информацию, предоставляя больше детальных объяснений и вспомогательных материалов, таких как полные примеры, выводы и перекрестные ссылки. На этом уровне детализации вспомогательная информация становится более сложной, более точной, с большим количеством перекрестных ссылок, а также используются методы формальной спецификации.

Вспомогательная информация обеспечивает центральное расположение для терминов и сокращений, которые могут быть новыми для команды, и для глобальных атрибутов качества, которые каждый в команде должен понимать. Это является существенным дополнением для модели сценариев использования. Без вспомогательной информации будет невозможно понять, что означает для системы быть удобной и готовой к использованию.

Вспомогательная информация обычно представляется как простой список терминов и их определений. Список часто разделен на разделы, такие как определения терминов, бизнес-правила, операционные ограничения, ограничения проектирования, стандарты и глобальные системные требования. Список может быть опубликован как часть вики-сайта для упрощения доступа и обслуживания.

Тестовый сценарий

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

Тестовые сценарии:

• Предоставляют строительные блоки для проектирования и выполнения тестов.
• Предоставляют механизм для выполнения и проверки требований.
• Позволяют описать тесты до начала реализации.
• Предоставляют способ для оценки качества системы.

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

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

Тестовые сценарии могут быть представлены следующими уровнями детализации:

	Тестовые идеи сформулированы: Легкий уровень детализации, который просто описывает первоначальную идею, формирующую тестовый сценарий. При определении тестового сценария должно быть ясно, что такое идея тестового сценария и к какому фрагменту требований она применима. В дальнейшем описание должно быть сделано более подробным, когда тестовый сценарий должен стать исполняемым.
	Сценарий выбран: Чтобы иметь возможность выполнить тест, тестировщик должны быть ознакомлен с тестовым сценарием. Структура повествования сценария использования гарантирует, что каждый слайс сценария использования представит для тестировщика хотя бы один или более кандидатов для тестовых сценариев. Искусством создания эффективных тестовых сценариев является возможность выбрать правильный набор потенциальных тестовых сценариев для покрытия тестовой идеи и четкого определения готовности слайса. Это легкий уровень детализации, который обеспечивает исполняемый тестовый сценарий. После того, как сценарий был выбран, тестовый сценарий формируется на уровне, который достаточен для поддержки произвольного и исследовательского тестирования. Такой подход может быть очень полезным в начале жизненного цикла проекта, когда видение, предоставляемое через тестирование системы, достаточно ценное, но спецификации (и решение) могут быть не достаточны стабильны для поддержки формального, структурированного тестирования.
	Переменные идентифицированы: Тестовый сценарий принимает входные данные, манипулирует состоянием системы и производит некоторые результаты. Эти переменные появляются как входные переменные, внутренние состояния и выходные переменные в соответствии с требованиями. На этом уровне детализации явно определены приемлемые диапазоны для ключевых переменных сценария. Такой уровень детализации подходит для тех случаев, когда мнение тестировщика является неотъемлемой частью теста, например, при проведении тестирования удобства использования. Может также использоваться, когда произвольное и исследовательское тестирование требуют более высокого структурирования.
	Значения переменных установлены: Тестовый сценарий может дорабатываться, явно предоставляя конкретные значения для всех переменных, участвующих в тестовом сценарии. Такой уровень детализации подходит для ручных тестовых сценариев, где вся информация, которая необходима для тестировщика для неоднократного и последовательного выполнения тестовый сценария, находится в одном месте.
	Шаги детализированы / Автоматизирован: Если тестовый сценарий будет использоваться много раз или поддерживать множество различных тестов, то стоит потратить усилия для детализации шагов сценария или его автоматизации. На этом уровне детализации тестовый сценарий может быть выполнен без какого-либо вмешательства или принятия дополнительных решений.

Тестовые сценарии являются наиболее важным рабочим продуктом, связанным со сценарием использования. Помните, что именно тестовые сценарии определяют, что означает завершение разработки сценария использования, а не его повествование. Поэтому тестовые сценарии являются наилучшей формой требований, которую вы можете иметь.

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

Повествования сценариев использования являются коллекциями из историй, которые система должна поддерживать, и для каждой истории, описанной в повествовании сценария использования, будет необходим, по крайней мере, один тестовый сценарий. Создавайте тестовые сценарии в одно и то же время с подготовкой слайсов сценария использования для разработки.

Модель сценариев использования

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

Модель варианта использования:

• Позволяет команде согласовать требуемую функциональность и характеристики системы.
• Четко устанавливает границы системы, предоставляя полную картину своих субъектов (вне системы) и сценариев использования (внутри системы).
• Обеспечивает гибкое управление требованиями.

Модель сценариев использования в основном состоит из ряда субъектов, сценариев использования и схемы, иллюстрирующей их отношения. Модель сценариев использования может быть определена различными способами, включая часть вики-сайта, на доске или флип чарте, набор слайдов PowerPoint, документ MS Word или выполнена в средстве моделирования.

Модели сценариев использования могут быть представлены на различных уровнях детализации:

	Значение установлено: Первым шагом к завершению модели сценариев использования является выявление наиболее важных субъектов и сценариев использования, которые являются наиболее приоритетными. Это те сценарии, которые обеспечивают значимость системы. Это легкий уровень детализации. Он подходит для большинства проектов, в частности для тех, которые добавляют новые функциональные возможности существующим системам, где не имеет смысла моделировать все функции системы.
	Границы систем установлены: Главные действующие лица и сценарии использования описывают суть зачем система разрабатывается. Они показывают, как пользователи будут получать пользу от системы. Они могут не обеспечивать достаточной значимости при настройке системы и поддержке ее работы. В этих случаях вторичные субъекты и сценарии использования должны быть включены для поддержки эффективного функционирования системы. Такой уровень детализации полезен при моделировании совершенно новых систем или новых поколений существующих систем. На этом уровне детализации все системные субъекты и сценарии использования определяются и моделируются.
	Структурированы: Модель сценариев использования часто содержит избыточные сведения, например, общие последовательности или шаблоны взаимодействий. Структурирование модели сценариев использования является методом сокращения этой избыточности. Для больших и сложных систем, особенно тех, которые используются для предоставления схожей функциональности во многих различных контекстах, структурирование моделей сценариев использования может помочь понять избыточность, ликвидировать излишки и помочь вам найти элементы повторного использования.

Если ваша модель сценариев использования явно показывает пользу, которую заинтересованные стороны будут получать от вашей новой или обновленной системы, то она выполняет свое предназначение. При детализации модели следует соблюдать осторожность. Продвигайтесь к уровням «Границы системы установлены» или «Структурированы» только если эти уровни детализации явно могут добавить значимости и помогут вам поставить новую систему более эффективно.

Повествование сценария использования

Цель повествования сценария использования – рассказать историю о том, как система и ее субъекты работают вместе для достижения определенной цели.

Повествования сценария использования:

• Наброски историй, которые используются для изучения потребностей и выявления слайсов сценария использования.
• Описывают последовательность действий, включая варианты, которые может выполнять система и ее субъекты для достижения цели.
• Представлены в виде набора потоков, которые описывают как субъект использует систему для достижения цели, и что система делает для субъекта, чтобы помочь ему достичь эту цель.
• Фиксируют информацию о требованиях, необходимую для поддержки разработки.

Повествования сценария использования могут быть зафиксированы многими различными способами, включая как часть вики-сайта, карточки, документы MS Word или с помощью одного из многих коммерчески доступных инструментов управления работой, управления требованиями или инструментов моделирования.

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

	Кратко описаны: Легкий уровень детализации, который просто фиксирует цель сценария использования и какой субъект его запускает. Такой уровень детализации подходит для сценариев использования, которые вы решили не реализовывать. В дальнейшем описание сценария должно быть сделано более подробным, если он должен быть нарезан на слайсы для реализации.
	Маркированные наброски: Сценарий использования должен быть выписан в достаточной детализации для понимания его размера и сложности. Такой уровень детализации также позволяет эффективно управлять границами, т.к. такое описание позволяет различным частям сценария использования установить относительно друг друга приоритеты и, при необходимости, ориентировать их на различные выпуски. Это легкий уровень детализации, который позволяет начать нарезать сценарий использования и запустить разработку. Он подходит для тех команд, которые тесно сотрудничают с пользователями и в состоянии пополнить любые отсутствующие детали через обсуждение и выполнение сопровождающих тестовых сценариев.
	Существенно описаны: Иногда необходимо уточнить ответственности системы и ее субъектов во время определения сценария использования. Маркированные наброски фиксируют их обязанности, но четко не определяют за какие части сценария использования ответственна система, а за какие субъект(ы). На этом уровне детализации повествование становится описанием диалога между системой и ее субъектами. Это особенно полезно при создании архитектуры новой системы или попытке создать новый пользовательский опыт.
	Полностью описаны: Повествование сценария использования может использоваться для предоставления весьма подробной спецификации требований, выводя их на более полный уровень детализации: «Полностью описаны». Дополнительные данные могут быть необходимы для покрытия отсутствия опыта команды, отсутствие доступа к заинтересованным сторонам или для эффективного обмена сложными требованиями. Такой уровень детализации особенно полезен для тех случаев, где непонимание содержимого может иметь серьезные последствия для безопасности, а также финансовые или юридические последствия. Он также может быть полезным при офшорной и аутсорсинговой разработке программного обеспечения.

Повествование сценария использования является очень гибким рабочим продуктом, который может быть расширен для фиксирования различного количества деталей, которые вам необходимы для успешности независимо от ваших обстоятельств. Если вы являетесь частью небольшой рабочей группы, сотрудничающей с клиентом, в исследовательском проекте, то маркированные наброски обеспечат довольно простой метод знакомства с требованиями. Если вы работаете в более жесткой среде, где существует ограниченный доступ к реальным экспертам, то могут использоваться уровни «Существенно описаны» или «Полностью описаны», чтобы закрыть пробелы в знаниях команды.

Не каждое повествование сценария использования должно быть на одном и том же уровне детализации. Не редко бывает, что наиболее важные и рискованные сценарии использования являются более подробными, чем другие. То же можно применять для разделов повествования сценария использования, т.е. самые главные, сложные или рискованные части сценария использования описаны более подробно, чем другие.

Реализация сценария использования

Реализация сценария использования призвана показать, как элементы системы, такие как компоненты, программы, хранимые процедуры, файлы конфигурации и базы данных таблиц, взаимодействуют вместе при выполнении сценария использования.

Реализация сценария использования:

• Определяет элементы системы, вовлеченные в сценариях использования.
• Фиксирует обязанности элементов системы при выполнении сценария использования.
• Описывает взаимодействие элементов системы для выполнения сценария использования.
• Переводит бизнес язык, используемый в повествовании сценарии использования, в язык разработчика, используемый для описания реализации системы.

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

Создавайте реализации сценария использования для каждого сценария использования, чтобы определить элементы системы, участвующие в его выполнении, и, самое главное, чтобы оценить насколько они должны быть изменены. Вы можете думать о реализации сценария использования как об обеспечении «как» для дополнения повествования сценария использования «что».

Реализация сценария использования может быть представлена следующими уровнями детализации:

	Элементы реализации определены: Легкий уровень детализации, который просто фиксирует элементы системы как новые, так и существующие, которые примут участие в сценарии использования. Такой уровень детализации подходит для небольших групп, работающих в тесном сотрудничестве и при разработке простых систем с известной архитектурой. Может потребоваться и более подробно описать, если ваша система является сложной или ваша команда большая или географически распределена.
	Обязанности определены: Чтобы обеспечить команде возможность обновлять затрагиваемые элементы системы параллельно или при разработке нескольких слайсов, разработчики должны понимать обязанности отдельных элементов. Обязанности обеспечивают общее определение того, что каждый элемент должен делать, где хранить и как отслеживать. Такой уровень детализации подходит для ситуаций, когда каждый слайс сценария использования затрагивает несколько элементов системы, или где слайсы будут разрабатываться несколькими разработчиками, работающими параллельно. Его следует также использовать, когда архитектура системы незрела и общие обязанности элементов системы до сих пор необходимо понять.
	Взаимодействия определены: Чтобы обеспечить полное, однозначное определение изменений, необходимых для каждого элемента системы, участвующих в сценарии использования, реализации сценариев использования должны включать детали всех интерфейсов и взаимодействия участвующих в выполнении сценария использования. Такой уровень детализации особенно полезен для тех сценариев использования, где проектирование системы является сложным. Он также может быть полезным, когда элементы системы должны быть разработаны разработчиками с небольшим или без знания архитектуры системы, при отсутствии доступа к опытным архитекторам и без компетенции рефакторинга или изменения архитектуры. Он также полезен при работе с неопытными разработчиками, которые все еще учатся своему делу.

Реализация варианта использования – это очень гибкий рабочий продукт, который команда может расширить добавлением дополнительной информации, когда она в ней нуждается. Если небольшая группа делает совместно анализ и проектирование, тогда простая и легкая реализация варианта использования будет достаточной. Если большая команда, которая не может иметь много совещательных сессий, занимается разработкой комплексной системы, то более подробная реализация поможет в общении и позволит убедиться, что все разработчики имеют всю информацию, которая им необходима для успешной поставки их элементов системы и реализации их слайсов сценариев использования.

Use-Case 2.0. Использование Сценария Использования 2.0

<<Содержание

Сценарий Использования 2.0 может использоваться во многих различных контекстах для создания многих различных видов систем. В этой главе мы рассмотрим использование сценариев использования для различных видов системы, различных видов требований и различных подходов разработки.

Сценарий Использования 2.0: применим для всех типов систем

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

Сценарий Использования 2.0: не только для приложений интенсивного использования

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

Все, что нужно, чтобы сценарии использования были целесообразными, — система должна взаимодействовать с внешним миром, независимо от того, являются ли пользователи людьми или другими системами. Их применимость гораздо шире, чем большинство людей думает.

Сценарий Использования 2.0: не только для разработки программного обеспечения

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

Сценарии использования используются для бизнес-моделирования, что часто называются бизнес сценариями использования. Они обеспечивают контекст для разработки вашей ИТ-системы, позволяя развитию бизнеса и ИТ разработке идти в идеальной синхронизации. Вы можете не только разрабатывать ИТ систему слайс за слайсом, но также вы можете развивать ваш бизнес по модели слайс за слайсом. Это очень мощный инструмент, который позволяет вам развивать ваш бизнес и его системы поддержки в тандеме друг с другом, позволяя обеспечить инкрементальное развитие бизнеса также, как и инкрементальная разработка систем.

В современном мире бизнес и поддерживаемые ИТ-системы могут и должны развиваться в синхронизации (одно не будет работать без другого). Через использование сценариев использования и слайсов сценария использования для определения границ и бизнеса, и ИТ можно закрыть разрыв между бизнесом и ИТ, позволяя им работать в качестве действительно сотрудничающих партнеров.

Сценарий Использования 2.0: обрабатывает все виды требований

Хотя сценарии использования являются одним из самых популярных методов для описания функциональности систем, они также используются для изучения их нефункциональных характеристик. Самый простой способ это сделать – зафиксировать их в рамках самих сценариев использования. Например, связать требования к производительности ко времени между конкретными шагами сценария использования или перечислить уровни ожидаемого обслуживания для сценария использования как часть его самого.

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

Сочетание таких сценариев использования инфраструктуры с другими методами, например, разделение проблем и аспектно-ориентированного программирования, позволяет решить эти общие требования без необходимости изменения реализации существующих функциональных сценариев использования.

Сценарий использования 2.0: применим для всех подходов разработки

Сценарий Использования 2.0 работает со всеми популярными подходами разработки программного обеспечения, в том числе:

• Итеративные подходы на основе журналов, такие как Scrum, EssUP и OpenUP
• На основе потока целых частей, такие как Kanban
• Подход все-в-одном, такие как традиционный водопад

В следующих 3 коротких разделах мы проиллюстрируем как Сценарий Использования 2.0 и, в частности, слайсы сценария использования могут помочь в каждом из походов. Эти разделы не являются самодостаточными как остальные части документа, поэтому предполагается, что читатель имеет базовое понимание обсуждаемого подхода. Мы рекомендуем вам прочитать только те разделы, с подходами которых вы знакомы.

Сценарий Использования 2.0 и итеративные подходы на основе журналов

Перед адаптацией любого подхода на основе журнала, вы должны понять, что будет идти в виде элементов в журнал. Существуют различные виды журналов, которые команды используют для управления их работой, включая журнал продукта, журнал релиза и журнал проекта. Независимо от используемой терминологии, все они следуют одним принципам. Журнал сам по себе представляет упорядоченный список всего, что может потребоваться, и является источником требований для внесения любых изменений. Основная концепция журнала проиллюстрирована на рисунке ниже.

Рисунок 1. Концепция журнала

При использовании Сценария Использования 2.0 слайс сценария использования является основным элементом журнала. Использование слайсов гарантирует, что элементы журнала правильно сформированы, т.к. они естественно независимы, значимы и проверяемы. Структурирование повествования сценария использования, которое определяет их, обеспечивает уверенность в том, что они могут быть оценены и по ним могут быть достигнуты договоренности, и механизм нарезки сценария использования позволяет нарезать их настолько малыми, насколько вам необходимо для поддержки работы вашей команды разработки.

Сценарий использования не размещается в упорядоченный список если не ясно, что он будет означать. Означает ли это, что это то, где будет появляться первый или последний слайс из сценария использования? Если вы хотите разместить сценарий использования в список перед его нарезкой, просто создайте фиктивный слайс, который представляет весь сценарий, и вставьте его в список.

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

Рисунок 2. Активности для итеративных подходов на основе журналов

Перед началом разработки готовится журнал; «Найти субъекты и сценарии использования» используется для создания первоначальной модели сценария использования и определения масштабов системы, «Разделить сценарии использования» используется для создания начального набора наиболее важных слайсов сценариев использования для заполнения журнала, и «Подготовить слайс сценария использования» используется для получения одного или нескольких слайсов, готовых для разработки в первой итерации.

После того, как журнал будет установлен и запущен, вы можете начать первую итерацию разработки. Каждая новая итерация начинается с некоторого планирования. Во время этого планирования может потребоваться использовать «Разделить сценарии использования» для дальнейшей нарезки слайсов выбранного сценария использования, чтобы убедиться, что они достаточно малы для того, чтобы их можно было выполнить в итерации. Затем команда разработчиков использует «Подготовить слайс сценария использования», «Анализировать слайс сценария использования», «Реализация программного обеспечения (по слайсам)», и «Тестирование системы (по слайсам)» для разработки идентифицированных слайсов и их добавления в систему.

Хоть разработка является постоянной, команда также использует «Изучать и адаптировать сценарии использования», «Разделить сценарии использования» и «Подготовить слайс сценария использования» для поддержки журнала, обработки изменений и обеспечения уверенности в том, что есть достаточно элементов журнала, готовых для следующей итерации. Команде может даже понадобиться использовать «Найти субъекты и сценарии использования» для обработки крупных изменений или поиска большего количества сценариев использования для команды. В Scrum команде рекомендуется тратить 5-10 процентов от их времени для поддержки их журнала. Это незначительные дополнительные расходы для команды, и Сценарий Использования 2.0 обеспечивает рабочие продукты и активности, необходимые для простого и эффективного выполнения этой деятельности.

В конце итерации команда должна продемонстрировать систему и отобразить результаты исполнения их итерации. Команда должна использовать «Тестирование системы (по слайсам)», чтобы понять, где они находятся, и «Изучать и адаптировать сценарии использования», чтобы задуматься о качестве и эффективности их слайсов и сценариев использования.

Сценарий использования 2.0 и поток целых частей

Поток целых частей является подходом, который избегает пакетной обработки требований, что наблюдается в итеративном и водопадном подходах. В подходе поток целых частей каждый элемент требования проходит через процесс разработки. Поток целых частей — это метод, который взят из бережливой разработки. На рисунке ниже показана небольшая команда в потоке целых частей, которая передает каждый элемент непосредственно от рабочей станции A к B и C.

Рисунок 3. Концепция потока целых частей

Для этого, чтобы работать эффективно, вы должны иметь небольшие, стандартного размера элементы, которые будут быстро проходить через систему. Для разработки программного обеспечения требования являются сырьем, а рабочее программное обеспечения является готовой продукцией. Сценарий использования будет слишком нестандартным и слишком большим, чтобы пройти через систему. Время на станциях A, B и C будет слишком непредсказуемым и элементы начнут застревать. Слайс сценария использования может быть выполнен в нужном размере и доработан под потребности команды. Рисунок ниже иллюстрирует поток целых частей для разработки программного обеспечения со слайсами сценариев использования.

Рисунок 4. Поток целых частей для разработки программного обеспечения со слайсами сценариев использования

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

Поток целых частей не означает, что люди делают только одну вещь и работа выполняется только на одной рабочей станции. Например, может быть больше людей, работающих в области разработки, чем есть в тестировании, и если элементы начинают застревать, то люди должны сделать все возможное, чтобы заставить элементы двигаться снова. Если нет слайса сценария использования, ожидающего тестирования, но есть слайсы, которые застряли в анализе, тестировщики могут предпринять некоторые инициативы и помочь выполнить подготовительную работу. Таким образом вы не ограничены одним человеком на каждой рабочей станции или даже только одним экземпляром каждой рабочей станции.

Доски Kanban — это технология для визуализации потока через производственную линию. Kanban — это знак, флаг или сигнал в пределах производственного процесса для запуска производства и поставки продукции как часть подходов «точно в срок» и бережливого производства. На Kanban доске Kanban карты используются для представления элементов в системе. Рисунок ниже показывает простую Kanban доску для команды разработки, где сначала каждый слайс анализируется, чтобы понять его воздействие, затем разрабатывается и выполняется модульное тестирование для программного обеспечения и, наконец, полученное программное обеспечение независимо тестируется до передачи его в использование.

Рисунок 5. Слайсы сценариев использования на Kanban доске

Лимиты работы показаны красным цветом. Читая слева направо, вы можете увидеть, что слайсы должны быть идентифицированы и определена область прежде, чем они перейдут команде. Здесь лимит выполняемой работы равен 5, и клиенты, владелец продукта или команда бизнес-требований, которые являются источником требований, пытаются все время держать 5 готовых к реализации слайсов сценариев использования.

Слайсы берутся из входной очереди в область подготовки, где проводится анализ влияния, истории уточняются и финализируются тестовые сценарии. Здесь лимит выполняемой работы равен 3 пунктам. Элементы, которые находятся в столбце «on-going», в текущее время обрабатываются. Элементы в столбце «Done» завершены и ждут их принятия разработчиком. Таким же образом, слайсы проходят через команду разработки и, после успешного прохождения независимого тестирования системы, переходят в эксплуатацию. Лимит выполняемой работы покрывает всю работу на станции, включая текущие и выполненные элементы. Лимит выполняемой работы на выходе или ограничение на количество элементов, которые будут выпущены, не устанавливается.

Важный момент о Kanban – не существует определенной Kanban доски или лимита выполняемой работы; структура доски зависит от вашей командной структуры и методов работы. Доску и лимиты выполняемой работы следует настраивать так, как вы адаптировали ваши практики. Дополнительным вспомогательным инструментом для такого рода работы по дизайну являются состояния для слайсов сценария использования. На рисунке ниже показано выравнивание между состояниями и Kanban доской, показанной на рисунке выше. Состояния являются очень мощными, т.к. они четко определяют в каком состоянии слайс должен быть, когда он будет передан в следующую часть цепи.

Рисунок 6. Выравнивание состояний слайсов сценариев использования к Канбан доске

Рисунок ниже показывает, где применяются различные активности Сценария Использования 2.0. Самое интересное здесь то, что за «Изучать и адаптировать сценарии использования» не несет ответственность какая-либо конкретная рабочая станция, а проводится в рамках регулярного контроля качества, выполняемого командой. Эта деятельность поможет команде настроить количество и типы рабочих станций, а также лимиты выполняемой работы.

Рисунок 7. Активности для подхода потока целых частей

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

Рисунок 8. Kanban доска команды, отражающая завершающие состояния

Сценарий Использования 2.0 и водопад

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

Когда вы адаптируете подход водопад, над сценариями использования постоянно не работают и их не обновляют до появления окончательной системы, т.к. они все за один раз определены на старте работ. Затем в идеальной синхронизации они переходят через другие этапы разработки, которые сосредоточиваются над одним видом деятельности в одно время. Типичная последовательность активностей для подхода водопад показана на рисунке ниже.

Рисунок 9. Активности для подхода водопад

Даже в условиях строжайшего водопада существуют изменения, происходящие в ходе разработки самого программного обеспечения. Вместо того, чтобы принять и поощрять изменения, проекты водопада пытаются контролировать изменения. Они будут время от времени применять «Изучать и адаптировать сценарии использования», когда появляется запрос на изменение, который не может быть отложен, и они будут готовить дополнительные слайсы сценария использования для обработки любых изменений, которые принимаются. Они вряд ли найдут какие-либо дальнейшие сценарии использования после этапа требований, т.к. это будет считаться слишком большим изменением границ.

Характер подхода водопад «одна активность в одно время» означает, что состав команды постоянно меняется с течением времени, и, таким образом, возможность использования личного общения, чтобы поделиться историями, является весьма ограниченной. Чтобы справиться с этим, вам нужно поднять уровень детализации рабочих продуктов, далеко выходя за пределы простых сущностей. Рисунок ниже показывает уровень детализации, который, как правило, используется в проектах водопада.

Рисунок 10. Уровни детализации для рабочих продуктов в подходе водопад

В рамках каждой из фаз разработки один или несколько рабочих продуктов достигают весьма высокого уровня детализации для того, чтобы обеспечить их полноту 1) и 2) ответить на любые вопросы, которые могут возникнуть на более поздних этапах. В фазе требований постоянно обрабатывается модель сценариев использования, чтобы убедиться, что были обнаружены все сценарии использования, все повествования сценариев использования полностью описаны и вспомогательная информация всесторонне определена. На этом этапе закладываются некоторые мысли для тестирования и формулируются тестовые идеи. Тестовые сценарии затем откладываются в сторону, пока не будет достигнут этап тестирования.

Сценарии использования и их вспомогательная информация передаются команде анализа и проектирования, которая будет конкретизировать реализацию сценария использования, сначала назначив ответственности элементов системы и затем определив все взаимодействия. Со временем начнется кодирование и будут реализовываться все сценарии использования и слайсы сценариев использования. В конце будут участвовать тестировщики, и будут определены в деталях все тестовые сценарии и начнется тестирование.

Последовательный характер этого подхода работы может вас заставить задуматься о том, что нет никакого смысла в слайсе сценария использования, и что просто обработки всего сценария использования будет достаточно. Это не так, т.к. мелкозернистый контроль, реализованный через слайсы сценариев использования, позволяет команде требований быть гораздо более конкретными о фактических границах системы, которая будет разработана. Даже в проектах водопада маловероятно, что вам нужны все истории из всех сценариев использования. Они также помогут вам обрабатывать любые изменения границ, которые вносятся в последнюю минуту и вызваны проблемами графика или качества.

Сценарий Использования 2.0 не только для одного типа команд

Другим важным аспектом Сценария использования 2.0 является его способность адаптироваться к существующим командным структурам и рабочим функциям, одновременно способствуя команде в устранении потерь и повышении эффективности. В этом случае Сценарий Использования 2.0 не предопределяет каких-либо конкретных ролей или структуру команды, но он определяет набор состояний для каждого из центральных элементов (сценарий использования и слайс сценария использования).

Как проиллюстрировано в разделе «Сценария Использования 2.0 и поток целый частей», состояния указывают, когда элементы находятся в состоянии покоя и могут быть переданы от одного человека или группы к другой. Это позволяет использовать практику командами всех форм и размеров, начиная с малых кросс функциональных групп с небольшой или отсутствующей передачей ответственности до больших сетей групп специалистов, где за каждое изменение состояния отвечает отдельный специалист. Отслеживание состояния и передачи элементов позволяет отслеживать поток работы через команду (или команды), а команды могут адаптировать их способы работы для постоянного улучшения их производительности.

Сценарий Использования 2.0: масштабирование под ваши потребности

Никогда предопределенные подходы не подойдут всем сразу, поэтому нам необходимо иметь возможность масштабировать наш Сценарий Использования 2.0 в ряде различных измерений:

1. Сценарии использования масштабируются для предоставления более подробных руководств для менее опытных специалистов (разработчиков, тестировщиков, аналитиков и т.д.) или для практиков, которые хотят или нуждаются в более подробных руководствах.
2. Они масштабируются, чтобы покрыть весь жизненный цикл, охватывающий не только анализ, проектирование, кодирование и тестирование, но также эксплуатацию и поддержку.
3. Они масштабируются для поддержки крупных и очень крупных систем, например, системы систем: корпоративные системы, производственные линии и многослойные системы. Такие системы являются сложными и обычно разрабатываются множеством команд, работающими параллельно, на различных локациях, возможно, для разных компаний, и повторно используя много старых систем или пакетных решений.

Независимо от сложности системы, которую вы разрабатываете, вы всегда начинаете с выявления наиболее важных сценариев использования и создания большой картины, отображающей, что должно быть построено. Затем вы можете адаптировать Сценарий Использований 2.0 для удовлетворения возникающих потребностей команды. На самом деле Сценарий Использования 2.0 настаивает на том, чтобы вы постоянно его оценивали и адаптировали для ликвидации потерь, увеличения пропускной способности и соответствия постоянно меняющимся требованиям команды.

Use-Case 2.0. Сценарий использования 2.0 – содержимое

<<Содержание

Сценарий использования 2.0 состоит из набора элементов, с которыми нужно работать, и набора мероприятий.

С чем работать

Предмет Сценария использования 2.0 – требования, системы разрабатываются для удовлетворения требований, и тесты используются для демонстрации, что система соответствует требованиям. В самом сердце Сценария использования 2.0 находятся сценарий использования, история и слайс сценария использования. Это фиксирует требования и направляет разработку системы. Рисунок 1 показывает, как эти понятия связаны друг с другом. Он также показывает, как изменения и дефекты влияют на использование Сценария использования 2.0.

Рисунок 1. Сценарий использования 2.0 – карта содержимого

Заинтересованными сторонами являются люди, группы или организации, которые затрагивают или затрагиваются программной системой. Требования – это то, что должна делать система для удовлетворения заинтересованных сторон. Важно понять, что требуется от программной системы, передать этого понимание заинтересованным сторонам и членам команды, и использовать его для направления разработки новой системы. В Сценарии использования 2.0 требования записываются как набор сценариев использования, которые позволяют управлять границами и рассматриваются как набор слайсов сценариев использования. Любые изменения, которые просят заинтересованные стороны, приводят к дополнению или изменению в наборе сценариев использования и слайсов сценариев использования.

Система – это система, которая будет разработана. Это, как правило, программная система, хотя Сценарий использования 2.0 также может использоваться в разработке нового бизнеса (где вы рассматриваете сам бизнес как систему) и систем комбинированного аппаратного и программного обеспечения (встроенных систем). Это система, которая реализует требования и является предметом модели сценариев использования. Качество и полнота системы проверяется путем набора тестов. Тесты также проверяют успешно ли реализован слайс сценария использования. Если во время тестирования обнаружены дефекты, их присутствие заблокирует завершение слайса сценария использования до тех пор, пока они не будут исправлены и система улучшена.

Рассказывая истории, мы устраняем разрыв между заинтересованными сторонами, сценариями использования и слайсами. Это метод, с помощью которого заинтересованные стороны получают их требования и изучают сценарии использования. Понимание историй также является механизмом для нахождения правильных слайсов сценариев использования для направления реализации системы.

Сценарии использования

Сценарий использования – это все пути использования системы для достижения конкретной цели для конкретного пользователя. Взятые вместе наборы всех сценариев использования дают нам все полезные способы использования системы.

Сценарий использования – это:

• Последовательность действий, которую система выполняет, которая приносит наблюдаемый, значимый результат для конкретного пользователя.
• Это конкретное поведение системы, которое участвует в сотрудничестве с пользователем, чтобы доставить что-то ценное для этого пользователя.
• Наименьшая единица активности, которая обеспечивает значимый результат пользователю.
• Контекст для ряда связанных требований.

Чтобы понять сценарий использования, мы рассказываем истории. Истории охватывают: как успешно достичь цели и как обрабатывать любые проблемы, возникающие на пути. Они помогают нам понять сценарий использования и реализовать его слайс за слайсом.

Рисунок 2. Жизненный цикл сценария использования

Как показано на Рисунке 2, сценарий использования проходит через несколько состояний, изменяясь от ее первоначальной идентификации до его завершения в системе. Состояния являются важным методом, указывающим на понимание и реализацию сценария использования, отображая:

1. Цель установлена: когда цель сценария использования была выяснена.
2. Структура истории понятна: когда понимание структуры повествования сценария использования достаточно для команды, чтобы начать работу по выявлению и реализации первого слайса сценария использования.
3. Простейшая история выполнена: когда система выполняет простейшую историю, которая позволяет пользователю достичь цель.
4. Достаточно историй выполнено: когда система выполняет достаточно историй для обеспечения полезного решения.
5. Все истории выполнены: когда система выполняет все истории, рассказываемые сценарием использования.

Это будет достигаться путем реализации сценария использования слайс за слайсом. Состояния предоставляют простой метод для оценки прогресса, который вы делаете в понимании и реализации сценария использования.

Слайс сценария использования

Сценарии использования охватывают многие связанные истории различной важности и приоритетности. Часто может быть слишком много историй для поставки в одном релизе и в целом слишком много для работы в один инкремент. Из-за этого нам нужен способ разделения сценария использования на более мелкие куски, которые 1) позволяют нам выбрать, какие части сценария использования поставить и когда, 2) предоставляют подходящий блок для разработки и тестирования командой разработчиков, и 3) позволяют нам иметь малые и с размером, который определяется единым методом, части работ, которые быстро проходят через поток разработки.

Слайс сценария использования является одной или более историй, выбранных из сценария использования в форме рабочего элемента, который имеет четкое значение для заказчика. Он действует как ячейка для всех работ, необходимых для завершения реализации выбранных историй. Как мы видели ранее, когда мы обсуждали, что слайсы сценариев использования – это больше, чем просто требования и тестовые сценарии, слайс сценария использования развивается для включения соответствующих слайсов в разработку, реализацию и тестирование.

Слайс сценария использования является наиболее важным элементом Сценария использования 2.0, т.к. он используется не только в помощь требованиям, но также направляет разработку системы для их выполнения.

Слайс сценария использования:

• Позволяет сценариям использования быть разбиты на меньшие, отдельно поставляемые блоки работы.
• Позволяет требованиям, которые содержатся в наборе сценариев использования, быть упорядоченными с соответствующим приоритетом и быть рассмотренными параллельно.
• Связать различные модели системы (требования, анализ, проектирования, реализация и тестирование), которые используются в разработке на основе сценариев использования.

Рисунок 3. Жизненный цикл слайса сценария использования

Как показано на Рисунке 3, слайс сценария использования претерпевает некоторые изменения состояний от его первоначальной идентификации до окончательной приемки. Состояния являются важным методом, указывающим на понимание, реализацию и тестирование слайса сценария использования, отображая:

1) Границы определены: когда границы слайса определены и выявлено количество покрываемых историй.

2) Подготовлен: когда слайс был подготовлен путем улучшения повествования и тестовых сценариев для четкого определения, что значит успешная реализация слайса.

3) Проанализирован: когда слайс проанализирован и понятно его воздействие на компоненты системы, и затрагиваемые части готовы для написания кода и тестирования разработчиком.

4) Реализован: когда программная система была усовершенствована реализацией слайса, и слайс готов к тестированию.

5) Проверен: и, наконец, когда слайс был проверен как завершенный и готов для включения в релиз.

Состояния обеспечивают простой способ оценки прогресса, которого вы делаете в понимании и реализации слайса сценария использования. Они также обозначают точки, когда слайс находится в состоянии покоя и может быть потенциально передан от одного лица или группы к другой. Для случайного наблюдателя, взглянувшего на состояния, это может выглядеть как процесс водопада: определение границ > подготовка > анализ > реализация > проверка. Однако есть существенная разница. В водопадном подходе все требования готовятся до начала анализа, и весь анализ завершается до начала реализации проекта, и вся реализация завершается до начала проверки. Здесь мы имеем дело с отдельным слайсом сценария использования. С использованием набора слайсов все действия могут происходить параллельно. Пока один слайс сценария использования проверяется, второй слайс реализуется, третий реализуется, а четвертый анализируется. В следующей главе мы рассмотрим это более детально, когда мы будем рассматривать использование Сценария использования 2.0 с различными подходами разработки.

Истории

Рассказывание историй является методом, с помощью которого мы исследуем сценарии использования с нашими заинтересованными лицами. Каждая история о ценности для пользователей и других заинтересованных сторон представляет собой поток через один из сценариев использования. Истории могут иметь функциональный или нефункциональный характер.

История описывается как часть повествования сценария использования, один или более потоков, специальные требования и один или несколько тестовых сценариев. Ключом к поиску эффективных историй — понять структуру повествования сценария использования. Сеть потоков можно рассматривать как карту, которая суммирует все рассказы, необходимые для описания сценария использования. Рисунок 4 иллюстрирует взаимосвязь между потоками повествования сценария использования и историй, которые они описывают.

Рисунок 4. Взаимосвязь между потоками и историями

Слева на рисунке показан основной поток, как линейная последовательность шагов, и альтернативные потоки, как отклонения от этого набора шагов. Альтернативные потоки всегда определяются как вариации на основные. В правой части диаграммы показаны некоторые из этих историй, покрываемые потоками. Каждая история проходит через один или более потоков, начиная со старта основного потока и заканчивая в конце основного потока сценария использования. Это гарантирует, что все истории имеют отношение к достижению одной и той же цели, являются полными и значимым и являются взаимодополняющими, поскольку все они опираются на простейшую историю, описанную в основном потоке. Для каждой истории будет один или несколько тестовых сценариев.

Существует два общих подхода к выявлению историй и созданию повествований сценария использования:

• Сверху вниз: Некоторым людям нравится использовать подход сверху вниз где они 1) определяют сценарий использования 2) набрасывают основной поток, и 3) применяют мозговой штурм для определения альтернативных потоков на основе базового потока. Такое структурирование повествования и позволяет им определить свои истории.
• Снизу вверх: Используя подход снизу вверх мы начинаем с мозгового штурма для некоторого набора историй, и затем группируем их по темам для определения наших сценариев использования. Набор историй изучается, чтобы помочь нам определить основные и некоторые из альтернативных потоков. Структура сценария использования в дальнейшем приводит нас к выявлению любых отсутствующих историй и дает возможность убедиться, что все истории были сформированы и дополняют друг друга.

Вы должны выбрать подход, который будет лучше работать с вашими заинтересованными лицами. Конечно, можно объединить эти два подхода и работать как сверху вниз, от ваших сценариев использования, так и снизу вверх, от любых предлагаемых новых историй.

Истории являются полезным инструментом осмысления, который помогает нам найти правильные слайсы сценария использования, а самое главное – правильные тестовые сценарии. Нам не нужно отслеживать состояние самих историй, т.к. выполнение тестовых сценариев показывает нам, насколько полна система, и прогресс сценариев использования и слайсов сценариев использования направляет разработку.

Дефекты и изменения

Пусть это не прямая часть Сценария использования 2.0, но важно понимать, как дефекты и изменения связаны со сценариями использования и слайсами.

Изменения, которые попросила заинтересованная сторона, анализируются на основе текущей модели сценариев использования, сценариев использования и слайсов сценария использования. Это позволяет быстро понять степень изменений. Например, добавление нового сценария использования системы является значительным изменением, т.к. он изменяет общие цели и задачи системы; тогда как изменение существующего сценария использования обычно гораздо меньше, особенно если это история, которая не разделена на слайсы и не подготовлена, проанализирована, реализована или проверена.

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

Рабочие продукты

Сценарии использования и слайсы сценария использования поддерживаются набором рабочих продуктов, которые команда использует, чтобы помочь их распространить, изучить и задокументировать. На Рисунке 5 показано пять рабочих продуктов Сценария использования 2.0 (синим) и их связь с требованиями, сценариями использования, слайсами сценария использования, историями, тестами и системами (желтым).

Рисунок 5. Рабочие продукты Сценария использования 2.0

Модель сценариев использования визуализирует требования как набор сценариев использования, обеспечивая построение общей картины системы. Модель определяет сценарии использования и обеспечивает контекст для разработки индивидуальных сценариев использования. Сценарии использования изучаются через рассказы историй. Каждый сценарий использования описан 1) повествованием сценария использования, что очерчивает его истории и 2) набор тестовых сценариев, которые завершают истории. Истории описываются как набор потоков. Они могут быть дополнены набором специальных требований, которые будут влиять на истории, помогут вам назначить правильную историю на слайс сценария использования для реализации и, самое главное, определить правильные тестовые сценарии.

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

Вы может быть озадачены отсутствием каких-либо явных рабочих продуктов для фиксации и документирования историй и слайсов сценариев использования. Они не нужны, т.к. они полностью документируются другими рабочими продуктами. При необходимости вы можете получить список историй, связанных со сценарием использования как дополнительный раздел в повествовании сценария использования, но это не является существенным.

Работа со сценариями использования и слайсами

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

На Рисунке 6 показаны сценарий использования и некоторые из его слайсов, зафиксированные на бумажных заметках.

Рисунок 6. Фиксация свойств сценария использования и его слайсов с помощью бумажных заметок

Отображенный сценарий использования является сценарием использования «7 Просмотр и покупка» для онлайн-покупок приложений. Слайсы 1 и 2 сценария использования основаны на индивидуальных историях, производных от основного потока: «Выбрать и купить 1 продукт» и «Выбрать и купить 100 продуктов». Слайс 3 основан на нескольких историях, покрывающих наличие различных систем поддержки, участвующих в сценарии использования. Эти истории охватывают целый ряд альтернативных потоков.

Основными свойствами сценария использования являются его имя, состояние и приоритет. В этом случае используется популярная схема приоритетов MoSCoW (Must, Should, Could, Would) — (Должен Быть, Стоит Иметь, Может Быть, Может не Быть). Сценарии использования должны также быть оценены. В этом случае используется простая схема оценки их относительного размера и сложности.

Основными свойствами слайса сценария использования являются 1) перечень его историй, 2) ссылки на сценарий использования и потоки, которые определяют истории, 3) ссылки на тесты и тестовые сценарии, которые будут использоваться для проверки его выполнения и 4) оценку работы, необходимой для имплементации и тестирования слайса. В этом примере истории используются для наименования слайса и ссылки на сценарий использования, скрытой в номере слайса, и на список потоков. Оценки были добавлены позднее после консультаций с командой. Это большие цифры в нижней правой части каждой бумажной заметки. В этом случае команда играет в покер планирования для создания относительных оценок с помощью баллов историй; 5 баллов историй для слайсов 7.1 и 7.2 и 13 баллов описаний для слайса 7.3, который, как команда считает, будет занимать более чем вдвое большее усилий в сравнении с другими слайсами. В качестве альтернативы могут использоваться идеальные дни, размеры футболки (XS, S, M, L, XL, XXL, XXXL) или любой другой популярный метод оценки.

Сценарий использования и слайс сценария использования также могут быть упорядочены так, чтобы сначала рассматривались наиболее важные из них. Рисунок 7 показывает, как эти бумажные заметки могут использоваться для создания простого журнала продукта на белой доске. Читая слева направо вы можете увидеть 1) общую картину, иллюстрируемую диаграммой сценариев использования, которая показывает границы полной системы и первый релиз, 2) сценарии использования, выбранные для первого выпуска, и некоторые из их слайсов, которые были определены, но пока еще не детализированы и не упорядочены, 3) упорядоченный список слайсов, готовых быть разработанными в релизе, и, наконец, 4) те слайсы, которые команда успешно реализовала и проверила.

Рисунок 7. Использование сценариев использования и слайсов для построения журнала продукта

Рисунок 7 включен только для демонстративных целей, существует много других способов для организации и работы с вашими требованиями. Например, многие команды беспокоятся о своих бумажных заметках, падающих с доски. Эти команды часто отслеживают состояние сценариев использования и их слайсов, используя простую электронную таблицу, включая рабочие листы, примеры которых показаны на Рисунке 8 и Рисунке 9.

Рисунок 8. Рабочий лист сценариев использования из простого инструмента отслеживания

Рисунок 9. Рабочий лист слайсов сценариев использования из простого инструмента отслеживания

Эти иллюстрации включены, чтобы помочь вам начать работу. Сценарий использования и слайс сценария использования имеют центральное значение для всего, что делает команда, поэтому используйте любые методы, чтобы сделать их ощутимыми и видимыми команде. Не стесняйтесь добавлять другие атрибуты, если вы в них нуждается, например, для записи исходного сценария использования или его владельца, или целевых слайсов сценария использования для определенного инкремента в рамках релиза.

Завершая рабочие продукты

Также как отслеживание сценариев использования и слайсов, вам нужно будет, по крайней мере, набросать и распространить вспомогательные рабочие продукты.

Все рабочие продукты определяются уровнем детализации. Первый уровень детализации определяется голыми основами, минимальным количеством информации, которая требуется для работы практики. Дополнительные уровни детализации помогут команде справиться с какими-либо особыми обстоятельствами, с которыми они могут столкнуться. Например, это позволяет небольшим, не разнесенным группам иметь очень легкое повествование сценария использования, определенных на простых индексных карточках, а крупные распределенные команды для более подробного повествования сценария использования могут иметь документы. Команды могут в дальнейшем наращивать повествования по мере необходимости для улучшения обмена информацией или тщательного определения важных или критических требований к безопасности. Команда решает, должна она или нет выйти за рамки простоты, добавляя более подробную информацию при столкновении с проблемами, с которыми простая форма не может справиться.

На рисунке 10 показаны уровни детализации, определенные для набора рабочих продуктов Сценария использования 2.0. Легкий уровень детализации отображается в верхней части таблицы. Количество детализации рабочего продукта увеличивается по мере спуска вниз по столбцу, уплотняя и расширяя содержимое.

Рисунок 10. Уровни детализации рабочих продуктов

Хорошая новость заключается в том, что вы всегда начинаете одинаково с простого. Команда может затем постоянно адаптировать уровень детализации в их повествованиях сценария использования для удовлетворения возникающих потребностей. Уровень детализации можно регулировать через сокращение ненужной работы; все, что за пределами простого, должно иметь четкие основания для существования или должно быть ликвидировано. Как сказал Эйнштейн (как приписывается), «Все должно делаться так просто, насколько возможно, но не проще».

Для получения дополнительной информации о рабочих продуктах и их уровней детализации см. Приложение 1: Рабочие продукты.

Что делать

Сценарий использования 2.0 разбивает работу на целый ряд основных мероприятий, которые позволят сценариям использования предоставлять реальную ценность для команды. Эти действия показаны на Рисунке 11, где они сгруппированы по деятельностям, которые используются для обнаружения, упорядочивания и проверки требований, а также для формирования, реализации и тестирования системы. Жирные шевроны указывают на активности, которые явно задаются в практике. Пунктирные шевроны являются содержимым для других видов деятельности, от которые зависит успех практики. Сценарий использования 2.0 не волнует, как выполняются эти действия, он просто нуждается в их выполнении.

Рисунок 11. Активности Сценария Использования 2.0

Рисунок 15 необходимо рассматривать слева направо, чтобы получить полное впечатление о порядке выполнения мероприятий. Сами действия будут много раз выполняться в ходе вашей работы. Даже, например, простое действие «Найти субъекты и сценарии использования» может потребоваться выполнять много раз, чтобы найти все сценарии использования, и может проводиться параллельно с или после других мероприятий. Например, пока продолжается активность «Найти субъекты и сценарии использования» вы можете также реализовывать некоторые из слайсов, найденных ранее сценариев.

Остальная часть этой главы представляет собой введение в каждый вид деятельности, следуя за слайсом сценария использования от его первоначальной идентификации в родительском сценарии использования до его окончательного тестирования и проверки. Следующая глава включает в себя краткое обсуждение того, как организовать мероприятия для поддержки различных подходов разработки, таких как Scrum, Kanban, Итерационный подход и Водопад.

Найти субъекты и сценарии использования

Во-первых, вам нужно найти субъекты и сценарии использования, которые помогут вам:

• Согласовать цели системы.
• Договориться о новом поведении системы.
• Ограничить релизы системы.
• Согласовать значение, которое система обеспечивает.
• Определить пути использования и тестирования системы.

Лучшим методом выполнить это – провести воркшоп моделирования сценариев использования с заинтересованными сторонами. Нет крайней нужды находить все сценарии использования системы, просто сосредоточьтесь на тех, которые могут представить заинтересованным сторонам ценность, которую они ищут. После того, как вы оцените и адаптируете текущие сценарии использования, в будущем будут найдены дополнительные субъекты и сценарии использования.

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

Повторяйте эту активности по мере необходимости для развития вашей модели и обеспечения возможности найти все недостающие субъекты или сценарии использования.

СОВЕТ: МОЗГОВОЙ ШТУРМ МОДЕЛИРОВАНИЯ ЗАПУСТИТ ВАШУ МОДЕЛЬ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ Формальный характер модели сценариев использования и его использование в унифицированном языке моделирования, могут стать препятствием для привлечения заинтересованных сторон к моделированию. Отличный способ преодолеть это – просто собрать заинтересованные стороны вместе, чтобы обсудить некоторых различных пользователей и их цели, используя бумажные заметки (вертикальные для пользователей и горизонтальные для целей). Это способствует дальнейшему объединению этих субъектов и сценариев использования, которые найдут заинтересованные стороны, что затем очень легко поддается количественной оценке, выделению и упорядочиванию.

Разделить сценарии использования

Далее, вам нужно создать свой первый слайс сценария использования. Вы делаете это для:

• Создания подходящего размера элементов для команды, над которыми она будет работать.
• Обеспечения возможности вписаться в сроки и бюджет.
• Доставить наибольшее значение для пользователей и других заинтересованных сторон.
• Продемонстрировать критический прогресс проекта или понимание потребностей.

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

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

Созданные слайсы должны быть упорядочены для поставки, чтобы быть уверенными, что команда разработчиков решает их в правильном порядке. Опять же, вы должны делать это с заинтересованными сторонами и другими членами команды, чтобы быть уверенными, что порядок определяет наименьшую часть системы, которую возможно использовать. Для этого лучше всего рассмотреть сочетание приоритета, значения, риска и необходимости.

Повторяйте эту активность всякий раз, когда требуются новые слайсы.

СОВЕТ: ВАМ НУЖЕН ТОЛЬКО ОСНОВНОЙ ПОТОК САМОГО ВАЖНОГО СЦЕНАРИЯ ИСПОЛЬЗОВАНИЯ ДЛЯ СОЗДАНИЯ ВАШЕГО ПЕРВОГО СЛАЙСА Многие люди думают, что им нужно изложить все сценарии использования, прежде чем они смогут начать создавать свои слайсы. Это приводит к подходу водопад, который задерживает создание ценного, работающего программного обеспечения. Один слайс от одного сценария использования достаточен, чтобы запустить разработку и тестирование системы командой. Первый слайс всегда должен быть основан на основном потоке. Для некоторых сложных систем этот слайс может даже не покрыть весь поток. Можно просто взять часть основного потока, упуская детализацию некоторых шагов и формируя заглушки для других, чтобы затрагивать наиболее важные проблемы в реализации сценария использования и узнать, может ли он быть реализован.

Подготовить слайс сценария использования

После выбора слайса для разработки потребуются дополнительные действия для:

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

Подготовка слайса сценария использования – это совместная деятельность, где вам нужна информация от заинтересованных сторон, разработчиков и тестировщиков для уточнения повествования сценариев использования и определения тестовых сценариев.

При подготовке слайсов сценария использования, вы должны сосредоточиться на потребности разработчиков и тестировщиков, которые будут их реализовать и проверять. Подумайте о том, как они будут получать доступ к информации, в которой они нуждаются. Они будут говорить с экспертами в предметной области для освещения историй, или они нуждаются, чтобы для них все было задокументировано? Вам также нужно сбалансировать работу между детализацией повествования сценария использования и детализацией тестовых сценариев. Чем более подробно вы опишете повествование сценария использования, тем легче будет создавать тестовые сценарии. С другой стороны, более легкое повествование сценария использования, вводит меньше дублирования и повторения между ним и тестовыми сценариями. Необходимо создавать повествование сценария использования и тестовые сценарии в одно и тоже время, чтобы авторы могли сбалансировать свои собственные и потребности их заинтересованных сторон. Может потребоваться автоматизация тестовых сценариев, но тут не будет никаких сомнений относительно того, что будет достигнуто при их успешной реализации.

Выполняйте эту активность по крайней мере один раз для каждого слайса. Повторяйте это действие всякий раз, когда к слайсу есть изменения.

СОВЕТ: ЕСЛИ СЛАЙС НЕ ИМЕЕТ ТЕСТОВЫЕ СЦЕНАРИЕВ, ТО ОН НЕ ПОДГОТОВЛЕН ДОЛЖНЫМ ОБРАЗОМ Когда вы готовите слайс сценария использования, не забудьте определить тестовые сценарии, которые будут использоваться для его проверки. Когда мы смотрим на тестовый сценарий, мы знаем, что действительно должно быть достигнуто. Тестовые сценарии обеспечивают разработчиков эмпирическим изложением того, что система должна делать. Они будут знать, что разработка слайса не завершена до тех пор, пока система успешно не проходит все тестовые сценарии.

Анализировать слайс сценария использования

Перед началом создания кода следует проанализировать слайс для:

• Понимания его воздействия на элементы системы, которые будут использоваться для его реализации.
• Определения ответственности затрагиваемых системных элементов.
• Определения взаимодействия элементов системы для выполнения сценария использования.

Когда команде предоставлен для реализации новый слайс, первое, что нужно сделать, это проработать то, как это будет влиять на систему. Сколько битов системы должно быть изменено и каким образом? Как много новых элементов необходимо и куда они вставляются?

Анализ целевых слайсов часто является предшественником к планированию задач разработки. Это позволяет команде планировать реализацию слайса как набор небольших изменений кода, а не один, большой, неделимый кусок работы. Кроме этого, сам слайс может использоваться как единица работы, и анализ слайса – это заключительный элемент, предстоящий для разработчика перед началом кодирования.

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

Выполняйте эту активность по крайней мере один раз для каждого слайса. Повторяйте эту активность всякий раз, когда к слайсу применяются изменения.

СОВЕТ: ХРАНИТЕ АНАЛИЗ ДОСТУПНЫМ И ЛЕГКИМ Самый простой способ анализа слайса сценария использования – это совместное с командой обсуждение его влияния на различные элементы системы. В ходе рассмотрения командой дизайна, она рисует его на белой доске, обычно в виде простых диаграмм последовательности или взаимодействия, которые затем могут быть зафиксированы как фотография или в инструменте моделирования, которые выберет команда.

Реализация программного обеспечения (по слайсам)

Вы теперь готовы к проектированию, кодированию, модульному тестированию и интеграции компонентов программного обеспечения, необходимых для реализации слайса сценария использования.

Программное обеспечение будет развиваться слайс за слайсом, различными членами команды, работающими параллельно над различными слайсами. Каждый слайс потребует внесения изменений в одной или более частей системы. Завершение реализации слайса как в результирующего куска программного обеспечения, потребует модульного тестирования и, затем, интеграции с остальной частью системы.

Тестирование системы (по слайсам)

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

Сценарий использования 2.0 работает с наиболее популярными практиками тестирования. Его можно считать формой разработки на основе тестов, т.к. он создает тестовые сценарии для каждого слайса перед тем, как он будет передан разработчикам для реализации.

Тестирование системы целиком

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

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

Изучать и адаптировать сценарии использования

Вам также нужно постоянно подстраивать и оценивать сценарии использования и слайсы сценария использования для:

• Обработки изменений.
• Отслеживания хода выполнения.
• Поддержки вашей работы в рамках срока и бюджета.
• Регулярного обновления модели сценариев использования.
• Настройки размера слайсов для увеличения пропускной способности.

Прогрессу проекта важно, чтобы вы постоянно работали с вашей моделью сценариев использования, сценариями использования и слайсами сценария использования. Изменения приоритетов, полученные уроки и запрашиваемые изменения. Все это может иметь влияние на сценарий использования и слайс сценария использования, которые уже были выполнены, а также на те, которые еще ждут своего прогресса. Часто эта деятельность приводит к открытию новых сценариев использования и оптимизации существующих сценариев использования и слайсов.

Вариации проектных запросов могут потребовать от вас дополнительной настройки использования Сценария использования 2.0 и регулирования размера слайсов или уровня детализации вашего повествования сценария использования, поддерживающих определения и тестовые сценарии. Важно постоянно проверять и адаптировать свои методы работы, а также сценарии использования и слайсы, с которыми вы работаете.

Выполняйте эту активность по мере необходимости для поддержки ваших сценариев использования и управления изменениями.

СОВЕТ: НЕ ЗАБУДЬТЕ ПОДДЕРЖИВАТЬ ВАШ ЖУРНАЛ СЛАЙСОВ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ Упорядочивая ваши слайсы и отслеживая их состояния (область определена, подготовлен, проанализирован, реализован, проверен), вы создаете журнал требований, которые осталось выполнить. Этот список должен постоянно контролироваться и корректироваться с учетом хода работ команды и пожелания заинтересованных сторон. По ходу реализации проекта следует контролировать и регулировать размер слайсов для ликвидации не нужных элементов и повышения эффективности работы команды.

USE-CASE 2.0. Базовые принципы

<<Содержание

В основе любого успешного применения сценариев использования находятся шесть основных принципов:

1. Сохранять их простыми, рассказывая истории
2. Понимать общую картину
3. Сосредотачивать внимание на значении
4. Строить систему слайсами
5. Поставлять систему инкрементами
6. Адаптировать под потребности команды

В этой главе мы рассмотрим эти принципы более подробно и будем использовать их для введения в концепцию моделирования сценариев использования и разработку на основе сценариев использования.

Принцип 1: Сохранять их простыми, рассказывая истории

Рассказ историй – это как инструмент выживания и развития культур. Это простейший и самый эффективный способ для передачи знаний от одного человека к другому. Это лучший способ для передачи информации о том, что должна делать система, и позволить каждому, кто работает над системой, сосредоточиться на одних и тех же целях.

Сценарии использования фиксируют цели системы. Чтобы понять сценарий использования, мы рассказываем истории. Истории показывают, как успешно достичь цели и как обрабатывать любые проблемы, которые могут возникнуть на пути. Сценарии использования позволяют определить и зафиксировать все разные, но связанные истории простым, но исчерпывающим способом. Это позволяет легко сохранить, передать и понять системные требования.

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

При использовании рассказов историй, как метода для передачи требований, важно убедиться, что истории фиксируются по пути, что делает их действенными и проверяемыми. Для завершения описания сценария использования каждое их повествование сопровождает набор тестовых сценариев. Тестовые сценарии являются наиболее важной частью описания сценария использования, даже более важными, чем его повествование. Это так, потому что они делают истории реальными, и их использование может недвусмысленно продемонстрировать, что система делает то, что она должна делать. Тестовые сценарии определяют, что значит успешная реализация сценария использования.

Принцип 2: Понимать общую картину

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

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

Рисунок 1. Диаграмма сценариев использования для простой телефонной системы

Диаграмма сценариев использования является представлением в модель сценариев использования. Модели сценариев использования принимают тот факт, что системы поддерживают много различных целей для многих различных заинтересованных сторон. В модели сценариев использования заинтересованные стороны, которые используют систему и участвуют в достижении целей, моделируются как субъекты, а пути, которые система будет использоваться для достижения этих целей, моделируются как сценарии использования. Таким образом модель сценариев использования обеспечивает контекст для требований системы, которые будут обнаружены, переданы и изучены. Она также обеспечивает легкодоступную общую картину всех элементов, которые система будет делать. В диаграмме сценариев использования (например, Рисунок 1) субъекты отображаются как спичечные человечки и сценарии использования как эллипсы. Стрелки указывают на инициатора взаимодействия (субъект или система), что позволяет четко видеть, кто начинает сценарий использования.

Модель сценариев использования представляет собой модель всех полезных способов использования системы. Это позволяет вам очень быстро установить границы системы – что включено и что нет – и дать команде всеобъемлющую картину того, что система будет делать. Модель позволяет делать это без погружения в детали требований или внутренности системы. Не имея большого опыта, очень легко разрабатывать модели сценариев использования даже для самых сложных систем, создание легкодоступной картины делает границы и цели системы видимыми для всех участников.

Принцип 3: Сосредотачивать внимание на значении

При попытке понять, как будет использоваться система, всегда важно сосредоточить внимание на значении, которое она будет предоставлять своим пользователям и другим заинтересованным сторонам. Значение создается только в случае, если система фактически используется; так что гораздо лучше сосредоточиться на том, как система будет использоваться, чем на длинных списках функций или возможностей, которая она будет предлагать.

Сценарии использования обеспечивают такой фокус путем сосредоточения внимания на том, как система будет использоваться для достижения конкретной цели для конкретного пользователя. Они покрывают много способов использования системы: те, которые успешно достигают цели, и те, которые обрабатывают любые проблемы, которые могут возникнуть. Чтобы сделать значение легко подсчитываемым, идентифицируемым и поставляемым, вам нужно структурировать повествования сценария использования. Чтобы держать элементы простыми, начните с простейшего способа достижения цели. Затем зафиксируйте любые альтернативные пути достижения цели, а также как обрабатывать любые проблемы, которые могут возникнуть при попытке достичь цель. Это позволит сделать прозрачными связи между способами использования системы. Это позволит идентифицировать и увидеть прогресс для наиболее ценных путей, а менее ценные могут быть добавлены позже, не нарушая или изменяя то, что было сделано раньше.

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

На Рисунке 2 показано повествование сценария использования, структурированное подобным образом. Самый простой способ достижения цели описывает основной поток. Другие представлены как альтернативные потоки. Таким образом вы создаете набор потоков, который структурирует и описывает истории, и помогает нам найти тестовые сценарии, которые дополняют их определение.

ОСНОВНОЙ ПОТОК	АЛЬТЕРНАТИВНЫЕ ПОТОКИ
1. Вставить карту	А1. Неправильная карта
2. Выполнить валидацию карты	А2. Нестандартный сумма
3. Выбор получения наличных денег	А3. Требуется квитанция
4. Выбор счета	А4. Недостаточно средств в банкомате
5. Подтверждение доступности средств	А5. Недостаточно средств на счету
6. Возврат карты	А6. Возможен перерасход
7. Выдача наличных	А7. Карта застряла
	А8. Карта забыта
	И т.д.

Рисунок 2. Структура рассказов сценариев использования

Рисунок 2 показывает повествовательную структуру для сценария использования Снять наличные для банкомата. Основной поток отображается как набор простых шагов, которые фиксируют взаимодействие между пользователями и системой. Альтернативные потоки идентифицируют любые другие способы использования системы для достижения цели, например, запрашивают нестандартную сумму, а также любые дополнительные возможности, которые могут предлагаться пользователю, например, выдача квитанции, и любые проблемы, которые могут возникнуть на пути к достижению цели, такие как Карта застряла.

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

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

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

Принцип 4: Строить систему слайсами

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

Рецепт довольно прост. Во-первых, определите наиболее полезную вещь, которую система должна делать и сосредоточьтесь на этом. Затем возьмите одна такую вещь и нарежьте на слайсы. Определите тестовые сценарии, которые представляют собой приемку этих фрагментов. Некоторые слайсы будут иметь вопросы, на которые нельзя ответить. Отложите их в сторону в данный момент. Выберите самый центральный фрагмент, который проходит через всю концепцию от начала до конца, или как можно ближе к этому. Оцените его как команда (оценки не должны быть «правильными», это просто оценки) и начните собирать его.

Это подход, принятый в сценариях использования 2.0, где сценарии использования нарезаны для предоставления подходящего размера рабочих элементов, а сама система развивалась слайс за слайсом.

Нарезка сценариев использования

Лучший способ найти правильный слайс – думать о историях и о том, как мы их фиксируем. Каждая история является хорошим кандидатом на слайс. Каждая история определяется частью повествования сценария использования и одного или нескольких сопровождающих тестовых сценариев. Тестовые сценарии являются наиболее важной частью описания слайса сценария использования, т.к. они делают историю реальной.

Применяя наш рецепт выше, сценарии использования определят полезные вещи, которые система будет делать. Выберите наиболее полезные сценарии использования, чтобы найти наиболее полезную вещь, которую делает система. Чтобы найти наиболее центральный слайс, необходимо отбросить все менее важные пути достижения цели и решения проблем. Вы можете сделать это, сосредоточив внимание на историю, описанную в основном потоке. Слайс, основанный на основном потоке, гарантированно проходит через всю концепцию от начала до конца, т.к. это будет наиболее простым путем для пользователя для достижения его цели.

Оцените слайс и начните формировать его. Из сценария использования можно брать дополнительные слайсы до тех пор, пока не будет достаточно слайсов, чтобы предоставить полезное решение для этого конкретного пользователя. Затем то же самое может быть сделано для других сценариев использования, вам необходимо собрать систему, которую можно использовать.

Слайсу сценария использования не нужно содержать весь поток и все его тестовые сценарии – первый слайс может быть просто основным потоком с одним тестовым сценарием. Для завершения потока и затрагивания всех тестовых сценариев в дальнейшем можно добавить дополнительные слайсы. Механизм нарезки является очень гибким, позволяет создать слайсы большие и малые так, как вам нужно направить вашу разработку.

Слайсы – это больше, чем просто требования и тестовые сценарии

Когда мы строим систему слайсами, не достаточно просто нарезать требования. Пусть даже сценарии использования традиционно использовались для понимания и фиксации требований, но они всегда были больше, чем это. Как показано на Рисунке 3, слайсы сценариев использования проходят больше, чем просто через требования, они также нарезают все другие аспекты системы и ее документации.

Рисунок 3. Слайс сценария использования больше, чем просто нарезка требований

В левой части Рисунка 3 вы можете увидеть слайс сценария использования, этот фрагмент взят из одного из сценариев использования, который показан в следующей колонке. Слайс затем продолжается через проектирование, где показаны вовлекаемые элементы дизайна, так и через реализацию, где вы можете увидеть, какие части кода фактически реализуют слайс. Наконец слайс прорезает активы тестирования, охватывающие не только тестовые сценарии, но также тестовые скрипты, которые используются для выполнения тестов, и полученные результаты тестирования.

Также как обеспечение трассировки от требований до кода и тестов, также образ слайсов помогает вам развить правильную систему. Когда вы приходите к реализации слайса, необходимо понимать влияние слайса на проектирование и реализацию системы. Нужны ли новые элементы системы? Может ли это быть реализованным просто внесением изменений в существующие элементы? Если влияние слишком велико, вы даже может решите не реализовывать слайс! Если у вас есть основной дизайн для системы, такой анализ можно сделать легко и быстро, что предоставляет отличный способ для понимания влияния добавления слайса в систему.

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

Слайсы сценария использования: Наиболее важная часть Сценария использования 2.0

Концепция слайса сценария использования является неотъемлемой частью Сценария использования 2.0 как и сам сценарий использования. Эти фрагменты позволяют дробить сценарии использования на соответствующего размера части работ команды разработчиков, готовые для реализации. Представьте себе, что вы являетесь частью небольшой группой, выпускающей работающее программное обеспечение каждые две недели. Весь сценарий использования, вероятно, является слишком большим, чтобы он мог быть завершенным в один двухнедельный период. Слайс сценария использования – это другой вопрос, потому что он может быть нарезан настолько тонко, насколько этого требует команда. Слайсы сценария использования также позволяют команде сосредоточиться на предоставлении значимой части, готовой к использованию системы как можно скорее, отбросив все ненужные требования на пути.

Принцип 5: Поставлять систему инкрементами

Большинство программных систем развиваются на основе многих генераций. Они не выпускаются за один раз; они строятся как серия релизов сборка за сборкой. Даже сами релизы часто не выпускаются за один раз, они развиваются как серия инкрементов. Каждый инкремент обеспечивает демонстрируемую или готовую к использованию версию системы. Каждый инкремент основывается на предыдущем, добавляя больше функциональных возможностей или улучшая качество предыдущего. Так должны выпускаться все системы.

Сценарии использования сами по себе также могут быть слишком большими, чтобы рассматривать их поставку сразу. Например, нам, возможно, не нужны все способы обеспечения местного звонка в самых первых инкрементах телефонной системы. Самых основных возможностей может быть достаточно, чтобы установиться и запуститься. Дополнительные или нишевые методы установки местного звонка, такие как обратный звонок или повторный набор последнего номера, могут быть добавлены в более поздних инкрементах. Нарезая сценарии использования, мы можем достичь мелкозернистого управления, необходимого для достижения максимальной значимости в каждом выпуске.

Рисунок 4 показывает инкрементальную разработка версии системы. Первый инкремент содержит только один слайс: первый слайс от сценария использования 1. Второй инкремент добавляет еще один слайс из сценария использования 1 и первый слайс от сценария использования 2. Для создания третьей и четвертой частей добавляются дополнительные слайсы. Четвертый инкремент считается завершенным и достаточно полезным для реализации.

Рисунок 4. Сценарии использования, слайсы сценариев использования, инкременты и релизы

Сценарии использования являются отличным инструментом для планирования релиза. Работа на уровне сценариев использования позволяет все требования-спутники соответствующих требований отложить до более поздней версии. Принимая решения на уровне сценариев использования, можно быстро набросать общую картину и использовать ее, чтобы сосредоточиться на областях системы, которые должны быть рассмотрены в следующем релизе.

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

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

Принцип 6: Адаптировать под потребности команды

К сожалению, нет «единого размера, который подходит всем» для решения проблем разработки программного обеспечения; различные команды и различные ситуации требуют разных стилей и разных уровней детализации. Независимо от того, какие методы и приемы вы выбираете, вы должны убедиться, что они являются достаточно гибкими для удовлетворения текущих потребностей команды.

Это относится к практикам, выбранных вами как для обмена требованиями и направления разработки программного обеспечения, так и любых других. Например, легковесные требования невероятно эффективны, когда существует тесное взаимодействие с пользователями, и команда разработчиков может получить личные объяснения требований и своевременные ответы на любые вопросы, которые возникают. Если такого рода сотрудничество не представляется возможным, т.к. пользователи не доступны, то требования потребуют больше подробностей и неизбежно станут более тяжеловесными. Есть много других обстоятельств, где команде могут потребоваться более детальные требования для входа в разработку. Однако важно не составлять список всех возможных обстоятельств, где легковесный подход не может быть подходящим, а понимать тот факт, что практики нужно масштабировать.

Сценарий использования 2.0 разработан с таким пониманием, и может быть настолько легким, насколько это вам необходимо. Малые, не разнесенные команды могут иметь очень легкие повествования сценария использования, которые фиксируют простые истории. Они могут быть написаны от руки на простых индексных карточках. Крупные распределенные команды могут иметь более подробные повествования сценариев использования, представленные в виде документов. Это решать команде нужно ли или нет выходить за рамки простого подхода, добавляя дополнения при возникновении проблем, с которыми простой подход не может справиться.