USE-CASE 3.0 Руководство по успешному использованию юзкейсов

• Авторы: Ивар Якобсон, Ян Спенс, Кейт де Мендонка
• Дата: Декабрь 2024
• Версия: 1.00
• Отказ от ответственности: © 2005-2024 Ivar Jacobson International SA. Все права защищены.
• Внимание: В данном документе рассматривается версия Use-Case 3.0. Для получения информации о более ранних версиях обратитесь к предыдущим изданиям.

О данном руководстве

В этом руководстве описано, как применять юзкейсы для сбора системных требований в гибкой и масштабируемой манере. Оно основано на отзывах и уроках, извлеченных с момента первоначальной публикации электронной книги Use-Case 2.0 в 2011 году. Наша цель - предоставить вам интегрированное семейство практик юзкейсов, которые помогут вам получить максимальную отдачу от ваших юзкейсов. Эти практики применимы как для небольших, совместно расположенных гибких команд, так и для крупных, распределенных команд, аутсорсинга и сложных разработок мультисистем.

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

Юзкейсы можно применять различными способами к системам всех типов и размеров: предприятиям, ИТ-системам, физическим системам или любым их комбинациям. Различные команды должны выбирать свой способ работы. Чтобы удовлетворить эту потребность, Use-Case 3.0 предоставляет семейство практик, из которых команды могут выбрать несколько элементов и скомпоновать их в соответствии со своими потребностями.

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

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

В этом руководстве также описано, как создавать пользовательские истории на основе юзкейсов - оно соединяет мощь юзкейсов с дополнительными преимуществами пользовательских историй. Use-Case 3.0 на 100% совместим с командами, которые уже используют пользовательские истории.

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

Предисловие

Руководство состоит из следующих основных глав:

1. Что такое Use-Case 3.0?
2. Основа Use-Case - обзор соглашения 2024 года, опубликованного Иваром Якобсоном и Алистером Кокберном.
3. Исследование принципов - введение в юзкейсы, основанное на принципах, которые служат основой для семейства практик.
4. Семейство практик Use-Case 3.0 - краткое описание того, когда и как применять практики, составляющие Use-Case 3.0.
5. Анатомия практик Use-Case 3.0 - описание ключевых концепций, действий, рабочих продуктов и правил, которые их связывают.

Если вы новичок в юзкейсах, то вам стоит прочитать главы “Что такое Use-Case 3.0?”, “Исследование принципов” и “Семейство практик Use-Case 3.0”, чтобы понять основные концепции. Затем вы можете погрузиться в “Анатомию практик Use-Case 3.0”, когда начнете применять практику.

Если вы знакомы с основами юзкейсов, то вы можете сразу перейти к главам “Семейство практик Use-Case 3.0” и “Анатомия практик Use-Case 3.0” после прочтения главы “Что такое Use-Case 3.0?”. Это поможет вам сравнить Use-Case 3.0 с вашим собственным опытом и понять, что изменилось.

Если вы ранее читали или применяли Use-Case 2.0, то вы узнаете структуру новых практик. Прочтите главу “Исследование принципов”, чтобы ознакомиться с обновлением, а затем следуйте приведенным выше советам для людей, уже знакомых с юзкейсами.

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

Что такое Use-Case 3.0?

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

Юзкейс - это все способы использования системы для достижения цели конкретного пользователя.

Use-Case 3.0 - это масштабируемое, гибкое семейство практик, которое использует юзкейсы для сбора набора требований и управления инкрементной разработкой системы для их выполнения.

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

• Легковесный
• Масштабируемый
• Адаптируемый
• Простой в использовании
• Представлен в виде семейства практик, помогающих внедрению и сосредоточению на решении ваших насущных проблем.

Юзкейсы проясняют, что система будет делать и, намеренно опуская, чего она делать не будет. Они обеспечивают эффективное предвидение, управление областью применения и инкрементную разработку систем любого типа и размера. Они использовались для управления разработкой программных систем с момента их первоначального представления Иваром Якобсоном на OOPSLA в 1987 году. За прошедшие годы они стали основой для многих различных методов и неотъемлемой частью Unified Modeling Language. Они используются во многих различных контекстах и средах, а также многими различными типами команд. Например, юзкейсы могут быть полезны как небольшим гибким командам разработчиков, создающим приложения, интенсивно работающие с пользователем, так и крупным проектам, создающим сложные системы взаимосвязанных систем, такие как корпоративные системы, линейки продуктов и системы в облаке.

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

Use-Case 3.0 существует как проверенный и четко определенный набор практик. Хотя термин Use-Case 3.0 предполагает новую версию юзкейсов, он относится не к обновлению Unified Modeling Language, а, скорее, к кумулятивным изменениям в том, как разработчики программного обеспечения и бизнес-аналитики применяют юзкейсы. Юзкейс по-прежнему остается юзкейсом, но способы их представления, рассмотрения и управления ими эволюционировали, чтобы стать более эффективными. Изменения не теоретические, а прагматические, основанные на почти 40-летнем опыте со всего мира и из всех областей разработки программного обеспечения.

Основа Use-Case

Успех юзкейсов был настолько широким, что термин “юзкейс” вошел в обиход. Например, онлайн-словарь Meriam Webster содержит следующее определение:

юзкейс:

применение, которому может быть найдено что-либо (например, предлагаемый продукт или услуга)

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

На самом деле, в наши дни редко какой новый продукт запускается без какой-либо ссылки на его юзкейсы:

РИСУНОК 1: ТЕРМИН “ЮЗКЕЙС” ТЕПЕРЬ ИСПОЛЬЗУЕТСЯ В ПОВСЕДНЕВНОМ ОБИХОДЕ

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

Чтобы исправить эту ситуацию, в 2024 году Ивар Якобсон и Алистер Кокберн опубликовали набор принципов и концепций, лежащих в основе всех успешных применений юзкейсов. Он получил название “Основа Use-Case”.

Основополагающие принципы

Девять основополагающих принципов были согласованы Иваром Якобсоном и Алистером Кокберном и опубликованы в документе “Основа Use-Case” в 2024 году:

1. Юзкейсы применимы к системам всех типов и размеров: предприятиям, ИТ-системам, физическим системам или любым их комбинациям.
2. Юзкейсы помогают понять общую картину: назначение системы и то, как она будет использоваться.
3. Юзкейсы сосредоточены на ценности: целях пользователей и наилучших способах их достижения.
4. Вовлечение заинтересованных сторон имеет важное значение: соберите все заинтересованные стороны вместе, чтобы определить назначение и область применения системы.
5. Юзкейс рассказывает всю историю, как историю, от начального события до реализации ценности, которую он предоставляет, или возможного сбоя, если он не может быть выполнен. Он включает в себя способы обработки любых проблем и альтернатив, которые могут возникнуть на этом пути.
6. Юзкейсы инициируют обсуждения: обсуждая возможные сценарии, вы и ваши соавторы будете думать об отсутствующих шагах и отсутствующих расширениях. Эти обсуждения помогут вам найти ситуации, которые часто упускаются из виду.
7. Приоритет удобочитаемости: цель состоит в том, чтобы донести общую картину до всех участников, генерируя комментарии, выявляя любые пробелы и получая их поддержку.
8. Объем деталей и используемый формат будут варьироваться в зависимости от ваших обстоятельств: вы можете начать с наброска последовательности событий и добавлять детали по мере необходимости.
9. Юзкейс может быть реализован поэтапно: разработайте и внедрите некоторые ключевые сценарии юзкейса на ранней стадии, чтобы получить ценность и обратную связь, добавляйте менее используемые или менее критичные сценарии с течением времени стратегически.

Ключевые концепции

В документе “Основа Use-Case” также определен набор концепций:

1. Система, представляющая интерес.
2. Действующее лицо (актор) с целью.
3. Набор сценариев (их будет несколько).
4. Юзкейс для сбора этих сценариев.
5. Основное действующее лицо, которое инициирует юзкейс.
6. Система может вызвать вспомогательное действующее лицо для поддержки выполнения юзкейса.

РИСУНОК 2: ЮЗКЕЙС

Юзкейс - это все способы использования системы для достижения цели конкретного пользователя:

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

Система, представляющая интерес - система, используемая для достижения цели.

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

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

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

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

Основной сценарий - нормальный, счастливый путь к ценности, часто называемый “основным сценарием успеха”, “базовым потоком” или “счастливым путем”.

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

РИСУНОК 3: ОБЗОР ОСНОВЫ USE-CASE

Это основополагающие концепции и принципы, лежащие в основе всех успешных применений юзкейсов.

Простой пример

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

При использовании юзкейсов мы не хотим иметь отдельное действующее лицо для каждого типа покупателя (гитарист, басист, певец, родитель, школа, менеджер и т. д.) и отдельный юзкейс для каждого продукта, который мы продаем (гитары, гобои, микрофоны, педали эффектов и т. д.), поскольку способ их взаимодействия с системой для просмотра и покупки продуктов будет одинаковым. Мы, вероятно, закончим чем-то вроде юзкейса, показанного на РИСУНКЕ 4.

РИСУНОК 4: ЮЗКЕЙС “ПРОСМОТР И ПОКУПКА”

Хотя этот юзкейс отражает наиболее ценную вещь, которую может делать наш интернет-магазин, его, вероятно, недостаточно, чтобы создать удобную систему. Могут потребоваться некоторые другие юзкейсы, такие как те, что выделены жирным шрифтом на РИСУНКЕ 5:

РИСУНОК 5: РАСШИРЕНИЕ НАШЕГО НАБОРА ЮЗКЕЙСОВ

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

Базовый сценарий

1. Шаг 1 - Юзкейс начинается, когда…
2. Шаг 2
3. Шаг 3

…

N. Шаг N

Юзкейс завершается.

Расширения

Ext1 - Что-то, что может пойти не так и что нужно обработать

Ext 2 - Что-то необязательное, что должно быть предоставлено

Ext 3 - Особый случай, который нужно обработать по-другому

…

Ext N

РИСУНОК 6: БАЗОВЫЙ СЦЕНАРИЙ И РАСШИРЕНИЯ

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

Рассмотрим следующие 3 сценария, которые описывают юзкейс для банкомата. В этом примере обычно есть две переменные: PIN-код и лимит суммы для снятия.

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

Ниже мы будем ссылаться на эти примеры сценариев.

Базовый сценарий - нормальный путь через юзкейс для достижения цели, часто называемый “счастливым путем”. Он описывается как простая последовательность шагов, каждый из которых включает в себя систему и/или одно из действующих лиц, делающих что-то. Эта последовательность традиционно называется “базовым потоком” или “основным сценарием успеха”. Базовый сценарий всегда описывает полный путь через юзкейс - от момента, когда юзкейс запускается действующим лицом, до конца юзкейса, когда это действующее лицо достигает своей цели (см. РИСУНОК 6).

Сценарий 1 в приведенном выше примере является базовым сценарием - когда юзкейс завершается тем, что пользователь достигает своей цели. Обратите внимание, что мы могли бы рассматривать Сценарий 1 как один конкретный экземпляр юзкейса - например, когда для доступа вводится правильный PIN-код 1234 для одного конкретного пользователя “Ivar”. Или мы могли бы рассматривать его как базовый сценарий, когда вводится любой правильный PIN-код, чтобы разрешить доступ авторизованному пользователю. В этой электронной книге мы рассматриваем оба этих случая как базовый сценарий; первый можно использовать для создания конкретного тестового сценария с тестовыми параметрами “Ivar” и “1234”; второй пример полезен в качестве общей иллюстрации “счастливого” поведения этого юзкейса, которое также можно использовать для определения тестовых случаев.

Расширения - представляют два разных типа путей: первый тип - это альтернативный путь через юзкейс, который отклоняется от базового сценария для выполнения одного или нескольких альтернативных шагов, а затем возвращается для завершения базового сценария, чтобы достичь цели юзкейса. Второй тип расширения представляет собой путь через юзкейс, который отклоняется от базового сценария из-за ошибки, которую необходимо обработать, и который затем приводит к тому, что пользователь не достигает своей цели, когда юзкейс завершается (РИСУНОК 6).

В Сценарии 2 юзкейс завершается тем, что пользователь не достигает своей цели. Сценарий 3 описывает альтернативный сценарий через юзкейс, когда пользователь все еще достигает своей цели.

Ключевым аспектом юзкейса является его структура: способ определения базового сценария и его расширений - это действует как карта того, как система будет использоваться. Базовый сценарий можно описать просто как маркированный список шагов и имен для расширений. Или его можно разработать, чтобы полностью описать, что должно произойти на каждом шаге или в каждом расширении. Его можно описать в тексте, как указано выше, или в какой-либо графической форме. РИСУНОК 7 представляет собой простой пример базового сценария, перечисленного для юзкейса “Просмотр и покупка”, и список имен, описывающих каждое из расширений.

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

Просмотр и покупка: Помогите покупателю найти наиболее подходящий продукт для удовлетворения его потребностей и помогите ему приобрести его.

Основное действующее лицо: Покупатель

Базовый сценарий

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

1. Просмотр продуктов
2. Выбор продуктов для покупки
3. Предоставление платежных реквизитов
4. Предоставление реквизитов доставки
5. Подтверждение покупки

Юзкейс завершается.

Расширения

Ext 1 - Поиск продуктов по ключевым словам

Ext 2 - Продукты не выбраны

Ext 3 - Неверные платежные реквизиты

Ext 4 - Платежная система недоступна

Ext 5 - Получение сохраненных платежных реквизитов и реквизитов доставки

Ext 6 Неверные реквизиты доставки

Ext 7 - Продукт отсутствует на складе

Ext 8 - Система управления запасами недоступна

Ext 9 - Нет подтверждения покупки

Ext 10 - Прекращение покупок без покупки

Ext 11 - Покупатель перестает отвечать

Ext 12 - Покупателю нужен совет эксперта

РИСУНОК 7: ОПИСАНИЕ ЮЗКЕЙСА “ПРОСМОТР И ПОКУПКА”

Сценарии, расширения и потоки

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

Use-Case 3.0 расширяет основу Use-Case

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

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

Что входит в Use-Case 3.0? В частности, Use-Case 3.0 Foundation добавляет:

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

Новые концепции определяются соответствующими практиками Use-Case 3.0, что гарантирует, что новые концепции и новые рабочие продукты описываются с точностью для этой практики, а также для обеспечения того, чтобы они применялись только тогда, когда выбрана соответствующая практика.

Давайте теперь более подробно рассмотрим дополнительный принцип и концепции, представленные в Use-Case 3.0.

Один дополнительный принцип

Принципы Use-Case 3.0 идентичны принципам “Основы Use-Case”, но с добавлением десятого принципа:

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

Use-Case 3.0 добавляет концепции к основе Use-Case

Use-Case 3.0 построен на основе Use-Case Foundation. Как упоминалось ранее, он добавляет ряд дополнительных концепций, которые позволяют описывать юзкейс с большей точностью. В этом разделе мы рассмотрим некоторые дополнительные ключевые концепции, лежащие в основе Use-Case 3.0:

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

РИСУНОК 8: ОСНОВОПОЛАГАЮЩИЕ ПРИНЦИПЫ И КЛЮЧЕВЫЕ КОНЦЕПЦИИ ДЛЯ USE-CASE 3.0 FOUNDATION

РИСУНОК 8 показывает, как Use-Case 3.0 основывается на “Основе Use-Case”, но добавляет важные дополнительные концепции. В Use-Case 3.0 мы используем ту же терминологию, что и в версии 1.1 “Основы Use-Case”: “базовый поток” переименован в “базовый сценарий”, а “альтернативный поток” переименован в “расширение”.

Теперь мы более подробно рассмотрим некоторые важные концепции Use-Case 3.0.

Модель юзкейсов

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

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

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

РИСУНОК 9 (ниже) показывает диаграмму юзкейсов для простой телефонной системы. Действующие лица показаны в виде фигурок, а юзкейсы — в виде эллипсов. Стрелки указывают инициатора взаимодействия (действующее лицо или систему), что позволяет четко видеть, кто запускает юзкейс.

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

РИСУНОК 9: ДИАГРАММА ЮЗКЕЙСОВ ДЛЯ ПРОСТОЙ ТЕЛЕФОННОЙ СИСТЕМЫ

Примечание: Юзкейсы в сравнении с функциями и возможностями - важно понимать, что юзкейсы описывают все способы использования системы пользователем; они не являются описаниями функций системы. Поскольку юзкейс привязан к сущности системы, он не подлежит традиционной функциональной декомпозиции. Если юзкейс разбивается на подчиненные юзкейсы, каждый подчиненный юзкейс является юзкейсом этой подчиненной системы (например, подсистемы) со своей собственной целью. Юзкейс - это не функция.

Срез юзкейса (Use-Case Slice)

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

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

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

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

Концепция среза юзкейса так же неотъемлема для Use-Case 3.0, как и сам юзкейс. Именно срезы позволяют юзкейсы разбивать на части и поставлять поэтапно. Представьте, что вы являетесь частью небольшой команды, выпускающей работающее программное обеспечение каждые две недели. Целый юзкейс во многих случаях слишком велик, чтобы быть выполненным командой разработчиков за один двухнедельный период. Срез юзкейса — это другое дело, потому что его можно нарезать настолько тонко, насколько этого требует команда. Срезы юзкейсов также позволяют команде сосредоточиться на предоставлении ценной, используемой системы, которую заинтересованная сторона в разработке (или пользователь) может оценить как можно скорее, отбрасывая все ненужные требования на этом пути.

Давайте рассмотрим пример нарезки юзкейса. Юзкейс «Просмотр и покупка», описанный на РИСУНКЕ 7, описывает базовый сценарий и двенадцать расширений. Вы увидите, что все эти расширения — это слишком много работы для реализации за один раз и, возможно, больше, чем вы когда-либо захотите реализовать. Даже базовый сценарий может быть слишком большим, чтобы его можно было решить за один раз. Именно здесь в игру вступает идея срезов юзкейсов.

РИСУНОК 10 показывает начальную нарезку юзкейса «Просмотр и покупка». Здесь было выделено шесть срезов. Считается, что их достаточно для обеспечения надежного, удобного взаимодействия с пользователем.

РИСУНОК 10: НАРЕЗКА ЮЗКЕЙСА “ПРОСМОТР И ПОКУПКА”

Что здесь следует отметить:

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

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

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

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

Рабочие элементы (Work Items)

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

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

Исследование принципов

В этом разделе мы более подробно рассмотрим основополагающие принципы Use-Case 3.0. У нас есть девять принципов из “Основы Use-Case”, а также добавленный десятый принцип для Use-Case 3.0.

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

“Юзкейсы применимы к системам всех типов и размеров: предприятиям, ИТ-системам, физическим системам или любым их комбинациям”.

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

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

• Бизнес-юзкейсы использовались в течение многих лет, чтобы помочь понять, что делает компания и как она это делает.

Юзкейсы можно использовать для понимания любого типа систем, включая:

• Организации

• Предприятия

• ИТ-системы

• Физические системы

• Инфраструктура

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

Эта универсальная применимость невероятно эффективна, поскольку:

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

2. Мы можем начать понимать использование и контекст нашего предлагаемого решения, прежде чем решим, какой тип системы мы должны построить.

Принцип 2: Начните с общей картины

“Юзкейсы помогают понять общую картину: назначение системы и то, как она будет использоваться”.

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

В нашем примере “Просмотр и покупка”, приведенном выше на РИСУНКЕ 4, мы начали с простой цели пользователя и юзкейса, исследующего все способы использования системы для достижения этой цели.

Каждый юзкейс представляет собой общую картину одного аспекта системы, и часто этого достаточно для начала работы. В примере “Просмотр и покупка”, если нет покупателей, приходящих просматривать и покупать, то наш интернет-магазин не имеет никакой ценности. Затем мы можем перейти к рассмотрению других пользователей и их целей (РИСУНОК 5), пока не создадим удобную систему, имеющую явную ценность для ее пользователей.

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

“Юзкейсы сосредоточены на ценности: целях пользователей и наилучших способах их достижения”.

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

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

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

РИСУНОК 11 показывает повествование юзкейса, структурированное таким образом. Самый простой способ достижения цели описывается базовым сценарием. Другие способы представлены в виде имен расширений. Таким образом, вы создаете набор сценариев, которые структурируют и описывают рабочие продукты (например, пользовательские истории) и помогают нам находить тестовые случаи, которые завершают их определение.

РИСУНОК 11: СТРУКТУРА ПОВЕСТВОВАНИЯ ЮЗКЕЙСА

Этот Рисунок 11 показывает структуру повествования для юзкейса «Снять наличные» для банкомата. Базовый сценарий показан в виде набора простых шагов, которые отражают взаимодействие между пользователями и системой. Расширения определяют любые другие способы использования системы для достижения цели, такие как запрос нестандартной суммы, любые дополнительные возможности, которые могут быть предложены пользователю, такие как выдача квитанции, и любые проблемы, которые могут возникнуть на пути к достижению цели, такие как застревание карты. Например, E2 представляет собой расширение «нестандартная сумма», в котором базовый сценарий будет выполняться до шага 4, где пользователь запросит нестандартную сумму, а затем базовый сценарий продолжит выполнение с шага 5 до конца юзкейса.

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

Такой маркированный план может быть достаточным для сбора рабочих продуктов и управления разработкой, или его, возможно, потребуется доработать, поскольку команда изучает детали того, что система должна делать. Самое главное — это аддитивная структура повествования юзкейса. Базовый сценарий необходим, если юзкейс когда-либо должен быть успешно завершен; его необходимо реализовать в первую очередь. Расширения могут (или не могут) быть необязательными; их можно добавить к базовому сценарию и при необходимости. Это позволяет вам действительно сосредоточиться на ценности, которую можно получить от системы. Вам больше не нужно выполнять весь юзкейс, но вы можете сосредоточиться на тех частях юзкейса, которые предлагают наибольшую ценность. Это также означает, что вам не нужна полная модель юзкейсов или даже полный юзкейс, прежде чем вы начнете работать над разработкой системы. Если вы определили наиболее важный юзкейс и поняли его базовый сценарий, то у вас уже есть что-то ценное, что вы могли бы добавить в свою систему.

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

Принцип 4: Вовлекайте заинтересованные стороны

“Вовлечение заинтересованных сторон имеет важное значение: соберите все заинтересованные стороны вместе, чтобы определить назначение и область применения системы”.

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

Было бы намного лучше, если бы все были на одной волне, и в идеале эта волна — юзкейс.

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

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

Принцип 5: Расскажите всю историю

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

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

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

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

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

Принцип 6: Инициируйте обсуждения

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

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

Мы уже обсуждали, как простой набросок юзкейса вызовет обсуждения о шагах в юзкейсе и охвате расширений (также известных как “альтернативные потоки”).

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

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

Как это не редкость на такого рода мероприятиях, технари сидели вместе за одним столом, а все бизнесмены сидели вместе за другим. Одним из вводных упражнений, которые мы сделали, было обрисовать в общих чертах базовый сценарий юзкейса «Перевод средств». Казалось бы, простое упражнение, но когда пришло время поделиться своими набросками, технари встали и прошлись по шагам своего базового сценария. К их и нашему удивлению, бизнесмены просто начали смеяться. Что могло быть такого смешного? Они только что представили шаги, задействованные в существующем автоматизированном процессе для основного банка. Ну, оказалось, что они были в неправильном порядке. «Знаете ли вы, сколько миллионов это стоило банку?» — спросил главный бизнес-спонсор.

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

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

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

Принцип 7: Приоритет удобочитаемости

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

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

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

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

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

Принцип 8: Достаточно и вовремя

“Объем деталей и используемый формат будут варьироваться в зависимости от ваших обстоятельств: вы можете начать с наброска последовательности событий и добавлять детали по мере необходимости”.

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

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

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

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

Принцип 9: Реализуйте поэтапно

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

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

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

РИСУНОК 12 показывает инкрементную разработку релиза системы. Первый инкремент содержит только один срез: первый срез из юзкейса 1. Второй инкремент включает еще один срез из юзкейса 1 и первый срез из юзкейса 2. Затем добавляются дополнительные срезы для создания третьего и четвертого инкрементов. Четвертый инкремент считается завершенным и достаточно полезным для выпуска.

РИСУНОК 12: ЮЗКЕЙСЫ, СРЕЗЫ ЮЗКЕЙСОВ, ИНКРЕМЕНТЫ И РЕЛИЗЫ

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

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

Принцип 10: Стройте систему по частям

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

Этот десятый принцип был добавлен к исходным девяти принципам “Основы Use-Case”. Use-Case 3.0 добавляет концепцию нарезки юзкейса как механизм разбиения юзкейса на более мелкие поставляемые и проверяемые компоненты.

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

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

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

Семейство практик Use-Case 3.0

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

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

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

Практики Use-Case 3.0, описанные здесь, следует рассматривать как набор строительных блоков. Каждая практика полезна сама по себе и может применяться для удовлетворения конкретной потребности, или их можно комбинировать вместе в различных сочетаниях - в соответствии со сложностью задачи моделирования. Семейство практик Use-Case 3.0, описанное в этой электронной книге, включает:

1. Практика Use-Case 3.0 Foundation - определяет принципы и концепции, описанные в “Основе Use-Case”, включая один дополнительный десятый принцип и одну концепцию для описания среза юзкейса.

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

3. Практика Use-Case Authoring - юзкейс, описанный более подробно и с использованием более формальной структуры для фиксации повествования юзкейса и любой вспомогательной информации.

4. Практика Use-Case Light Modeling - создание модели юзкейсов, которая описывается с базовым уровнем детализации (т. е. именование системы, действующих лиц, юзкейсов и определение взаимосвязи между действующими лицами и юзкейсами).

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

Добавление этих практик-“строительных блоков” в Use-Case 3.0 является одним из существенных улучшений, которые мы внесли по сравнению с Use-Case 2.0.

Чтобы понять, как можно использовать эти строительные блоки, представьте, что мы начинаем новое предприятие. Сначала мы можем захотеть набросать простую модель юзкейсов, чтобы определить, какие исходные юзкейсы должны быть выполнены, и согласовать “общую картину” нового решения. Мы могли бы выбрать практику Use-Case Light Modeling для выполнения этой работы. Теперь у нас есть названия некоторых юзкейсов и действующих лиц, но не обязательно всех из них.

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

1 - Практика Use-Case 3.0 Foundation

Основополагающие концепции и принципы лежат в основе всех успешных применений Use-Case 3.0. Use-Case 3.0 Foundation расширяет “Основу Use-Case”, добавляя ключевые концепции Use-Case 3.0 среза юзкейса и уточняя состояния альфы юзкейса, добавляя при этом дополнительный принцип «стройте систему по частям».

Практика Use-Case 3.0 Foundation также добавляет концепцию «Рабочий элемент» — дополнение, которое позволяет комбинировать практики Use-Case 3.0 с другими популярными практиками, такими как пользовательские истории, Scrum, Kanban, интеграция с более крупными гибкими фреймворками, такими как SAFe®, Scrum@Scale, Nexus, или с более традиционными подходами к планированию, основанными на задачах (например, проекты, управляемые водопадом).

РИСУНОК 13: ПРИНЦИПЫ И КОНЦЕПЦИИ, ОПРЕДЕЛЕННЫЕ ПРАКТИКОЙ USE-CASE 3.0 FOUNDATION

Обратите внимание, что эта базовая практика не является конкретной практикой — вы не будете использовать ее саму по себе. Она описана здесь только для полноты. Все практики Use-Case 3.0 построены на основе этой базовой практики — все они являются расширениями этой практики.

2 - Практика Use-Case Storytelling

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

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

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

Или в сочетании с практикой моделирования юзкейсов (описанной ниже):

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

Примечание: Use-Case Storytelling не включает в себя моделирование юзкейсов. Если эта практика используется отдельно, команда разработчиков предлагает юзкейс, на котором нужно сосредоточиться, как часть действия «Описать и нарезать юзкейс».

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

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

В таблице ниже показан конечный автомат для практики Use-Case Storytelling. В ней показано, как каждое действие будет изменять состояние альфы юзкейса или альфы среза юзкейса. В таблице также показано, как эта практика создает рабочие продукты с легким (существенным) уровнем детализации по сравнению с расширенными уровнями детализации, создаваемыми практикой Use-Case Authoring (описанной позже). В действии «Подготовить юзкейс» тестовый сценарий выбирается командой, чтобы представить один экземпляр юзкейса. Команда определит переменные, которые определяют вводимые пользователем данные или ответы системы для этого конкретного сценария, — чтобы проверить поведение системы после реализации среза.

РИСУНОК 14: ДЕЙСТВИЯ И РАБОЧИЕ ПРОДУКТЫ, ОПРЕДЕЛЕННЫЕ ПРАКТИКОЙ USE-CASE STORYTELLING

3 - Практика Use-Case Light Modeling

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

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

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

В таблице ниже показан конечный автомат для практики Use-Case Light Modeling. В ней показано, как каждое действие будет изменять состояние альфы юзкейса или альфы среза юзкейса. В таблице также показано, какой рабочий продукт создается или обновляется действием.

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

Практика Use-Case Light Modeling не требует создания каких-либо формальных повествований юзкейсов; каждый юзкейс можно использовать для обеспечения большего контекста для определения ваших пользовательских историй или функций. Команда разработчиков может провести мозговой штурм со своими заинтересованными сторонами, чтобы определить, какая последовательность шагов необходима для достижения цели юзкейса, а также любые условия сбоя или альтернативные способы достижения цели. Эти шаги затем можно использовать для определения серии потенциальных пользовательских историй. Затем команда разработчиков может обсудить с заинтересованными сторонами, как сгруппировать эти пользовательские истории в согласованные срезы юзкейсов, и таким образом определить и точно определить, что должно быть протестировано и доставлено каждым релизом или каждым инкрементом.

Рассмотрите возможность использования практики Use-Case Light Modeling в сочетании с практикой Use-Case Storytelling в качестве варианта по умолчанию в Use-Case 3.0. Практика Use-Case Light Modeling описывает «общую картину» вашей системы в виде модели юзкейсов; практика Use-Case Storytelling описывает каждый юзкейс в вашей модели в структурированном, но легковесном формате.

РИСУНОК 15: ДЕЙСТВИЯ USE-CASE LIGHT MODELING И РАБОЧИЕ ПРОДУКТЫ

4 - Практика Use-Case Authoring

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

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

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

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

Необязательные уровни детализации для рабочих продуктов показаны в левом нижнем углу РИСУНКА 16 в виде серых трапеций с пунктирными линиями вокруг полей; обязательные уровни детализации показаны в виде белой трапеции со сплошными линиями границ. Выберите правильный уровень детализации, чтобы удовлетворить требования вашего проекта или контракта.

РИСУНОК 16: ДЕЙСТВИЯ USE-CASE AUTHORING И РАБОЧИЕ ПРОДУКТЫ

Используйте эту практику, когда:

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

Эту практику, конечно, можно использовать для добавления деталей к вашим юзкейсам при начале работы с практикой Use-Case Storytelling.

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

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

5 - Практика Use-Case Structured Modeling

Развивайте свою модель юзкейсов, чтобы полностью определить область охвата вашей предполагаемой системы и отразить ее эволюцию с течением времени. Эта практика расширяет практику Use-Case Light Modeling. Ее можно использовать для добавления большей строгости и полноты в вашу модель юзкейсов, если эта практика используется вместо практики Use-Case Storytelling.

Используйте эту практику, когда:

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

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

Расширение обычно используется при расширении существующего юзкейса, чтобы позволить другому юзкейсу получить доступ к событиям, происходящим при выполнении расширяемого юзкейса. Возьмем, к примеру, юзкейс входа/выхода из системы. Если мы рассмотрим нашу модель юзкейсов «Просмотр и покупка» из РИСУНКА 5, то после входа в систему вы можете расширить этот юзкейс с помощью юзкейсов «Просмотр и покупка», «Ведение инвентаризации», «Выполнение заказов» и «Отслеживание заказов». Вы должны определить точку расширения в расширяемом юзкейсе (юзкейс входа/выхода из системы в этом примере), которая используется расширяющим юзкейсом (например, «Просмотр и покупка») для добавления своего поведения. Расширение можно использовать для описания различного поведения системы — например, для представления различных вариантов, предлагаемых клиентам, области охвата различных релизов или различных версий одной и той же системы, предлагаемых клиентам по разным ценам. Расширение также можно использовать для представления сложной обработки ошибок или обработки исключений, когда вы не хотите, чтобы это поведение заслоняло понятность расширяемого юзкейса.

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

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

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

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

РИСУНОК 17: ДЕЙСТВИЯ USE-CASE STRUCTURED MODELING И РАБОЧИЕ ПРОДУКТЫ

Пример композиции практик

Каждую практику Use-Case 3.0 можно использовать индивидуально. Но, как упоминалось ранее, их также можно рассматривать как «строительные блоки» — их можно комбинировать вместе, чтобы получить более мощные практики.

Мы уже определили одну составную практику: практика Use-Case Storytelling + практика Use-Case Light Modeling. Эта составная практика создает четыре рабочих продукта: модель юзкейсов, которая создается действиями Use-Case Light Modeling; остальные три рабочих продукта (повествование юзкейса, вспомогательная информация, тестовые случаи) создаются действиями, определенными практикой Use-Case Storytelling.

Используйте эту комбинацию двух практик, когда:

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

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

РИСУНОК 18: ДЕЙСТВИЯ И РАБОЧИЕ ПРОДУКТЫ, КОГДА ВЫ КОМБИНИРУЕТЕ ПРАКТИКУ USE-CASE LIGHT MODELING И ПРАКТИКУ USE-CASE STORYTELLING

Еще один пример композиции практик Use-Case

Практики Use-Case 3.0 можно комбинировать вместе. Если практика Use-Case Structured Modeling и практика Use-Case Authoring объединены вместе, на диаграмме ниже показан полный набор рабочих продуктов, которые будут определены.

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

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

РИСУНОК 19: ДЕЙСТВИЯ И РАБОЧИЕ ПРОДУКТЫ ДЛЯ КОМПОЗИЦИИ ПРАКТИКИ USE-CASE STRUCTURED MODELING И USE-CASE AUTHORING.

Анатомия практик Use-Case 3.0

Use-Case 3.0 использует язык Essence

Каждая практика в Use-Case 3.0 описывается:

• С чем работать (т. е. юзкейс и срезы юзкейсов)
• Что делать
• Что производить

Ключевым элементом является С чем работать, что в Essence называется альфами. В Use-Case 3.0 альфами являются юзкейс, срез юзкейса и рабочий элемент. Все альфы имеют состояния, и в течение срока службы альфа переходит из состояния в состояние. Альфы также могут иметь подальфы — простое агрегирование, например, юзкейс является подальфой требований, срез юзкейса является подальфой юзкейса, рабочий элемент является подальфой среза юзкейса. В Use-Case 3.0 состояния альфы рабочего элемента определяются практикой разработки, выбранной командой: например, состояния, которые описывают, как продвигается рабочий элемент пользовательской истории или рабочий элемент задачи проекта.

Что делать в Essence называется действиями. Действия продвигают альфы по состояниям и работают над рабочими продуктами.

Что производить в Essence называется рабочими продуктами. Рабочие продукты создаются, описываются или производятся и обновляются действиями.

Откуда берутся эти концепции альф, действий, рабочих продуктов и т. д.? Use-Case 3.0 определен с использованием языка OMG Essence, который является предметно-ориентированным языком для определения практик и методов. Essence использует простой, наглядный синтаксис, который прост в использовании. На рисунке ниже показана карта концепций для языка Essence, а также определены четыре элемента Essence, на которые есть ссылки в этом документе. Вам не нужно понимать язык Essence, чтобы использовать Use-Case 3.0, но может быть полезно знать, почему каждая практика структурирована с использованием четырех стандартных элементов Essence, описанных выше.

РИСУНОК 20: КЛЮЧЕВЫЕ КОНЦЕПЦИИ ЯЗЫКА ESSENCE.

РИСУНОК 21 показывает альфы, определенные в Use-Case 3.0, и то, как они связаны друг с другом. Он также показывает другие альфы, определенные вне Use-Case 3.0, но имеющие важное значение, описанные здесь:

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

Система — это система, которая должна быть построена, или система, которая уже существует. Это может быть программная система, хотя Use-Case 3.0 также можно использовать при разработке комбинированных аппаратных и программных киберфизических систем или новых предприятий (где вы рассматриваете сам бизнес как систему). Именно система реализует требования и является предметом модели юзкейсов. Качество и полнота системы проверяются набором тестов. Тесты также проверяют, был ли успешным срез юзкейса. Если во время тестирования обнаруживаются дефекты, то их наличие не позволит завершить срез юзкейса до тех пор, пока они не будут исправлены и система не будет улучшена.

РИСУНОК 21: КАРТА АЛЬФ USE-CASE 3.0

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

Альфы

Субъектами Use-Case 3.0 являются требования, система, которая должна быть оценена или разработана для удовлетворения требований, и тесты, используемые для демонстрации того, что система соответствует этим требованиям. В основе Use-Case 3.0 лежат юзкейс и срез юзкейса. Они фиксируют требования к существующей системе и к запрошенным изменениям в этой системе. Юзкейсы и срезы юзкейсов также управляют разработкой системы.

Альфа юзкейса

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

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

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

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

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

РИСУНОК 22: ЖИЗНЕННЫЙ ЦИКЛ ЮЗКЕЙСА

Альфа среза юзкейса

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

Важно помнить о срезах юзкейсов следующее:

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

Простой рецепт успеха

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

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

Нарезка юзкейсов

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

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

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

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

Срезы юзкейсов являются хорошими элементами для управления областью применения и приоритетами. Например, было бы легко применить схему расстановки приоритетов, такую как MoSCoW (Must, Should, Could, Won’t — должен, следует, мог бы, не будет), к срезам, определенным выше.

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

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

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

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

Срезы — это больше, чем просто требования и тестовые случаи

Когда мы строим систему по частям, недостаточно просто нарезать требования. Хотя юзкейсы традиционно использовались, чтобы помочь понять и зафиксировать требования, они всегда были чем-то большим, чем это. Как показано на РИСУНКЕ 23, срез юзкейса будет проходить через нечто большее, чем просто требования и тесты; он также проходит через проектирование и реализацию.

РИСУНОК 23: СРЕЗ ЮЗКЕЙСА — ЭТО БОЛЬШЕ, ЧЕМ ПРОСТО СРЕЗ ЮЗКЕЙСА

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

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

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

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

1. Определен: срез был определен, и объем сценариев и других требований, которые он охватывает, известен.
2. Уточнен: объем среза был уточнен путем определения сценариев юзкейса и способов их проверки. Это делается путем разработки сценариев и определения набора тестовых случаев, чтобы четко определить, что означает успешная реализация среза. Была сделана оценка высокого уровня усилий, необходимых для подготовки, реализации и тестирования среза.
3. Подготовлен: рабочие элементы, необходимые для реализации среза, были определены количественно и добавлены в бэклог команды и/или планы.
4. Реализован: система была расширена для реализации среза, и срез готов к тестированию.
5. Проверен: срез был проверен как выполненный и готов к выпуску для пользователя в системе.

РИСУНОК 24: ЖИЗНЕННЫЙ ЦИКЛ СРЕЗА ЮЗКЕЙСА

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

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

Зачем нужны юзкейсы, срезы юзкейсов и сценарии?

В документе The Use-Case Foundation дано следующее определение: «Юзкейс — это все способы использования системы для достижения цели конкретного пользователя».

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

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

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

РИСУНОК 25: СУЩЕСТВУЕТ МНОГО ПУТЕЙ ПРОХОЖДЕНИЯ ЮЗКЕЙСА

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

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

РИСУНОК 26: НАРЕЗКА ЮЗКЕЙСА

РИСУНОК 26 иллюстрирует один из способов нарезки юзкейса, при котором первый срез используется для представления базового сценария, второй срез завершает базовый сценарий и расширение Ext1, третий срез обрабатывает другие расширения. Четвертый срез обрабатывает два ошибочных условия, с которыми может столкнуться пользователь при попытке достичь своей цели.

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

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

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

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

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

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

Хотя дефекты и изменения не являются непосредственной частью Use-Case 3.0, важно понимать, как они связаны с юзкейсами и срезами юзкейсов.

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

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

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

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

РИСУНОК 27: РАБОЧИЕ ПРОДУКТЫ USE-CASE 3.0

РИСУНОК 27 показывает полный набор рабочих продуктов, определенных семейством практик Use-Case 3.0 (каждый рабочий продукт отображается с серыми границами), и их отношение к:

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

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

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

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

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

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

Работа с юзкейсами и срезами юзкейсов

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

РИСУНОК 28: ФИКСАЦИЯ СВОЙСТВ ЮЗКЕЙСА И ЕГО СРЕЗОВ С ПОМОЩЬЮ СТИКЕРОВ

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

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

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

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

РИСУНОК 29: ИСПОЛЬЗОВАНИЕ ЮЗКЕЙСОВ И СРЕЗОВ ЮЗКЕЙСОВ ДЛЯ СОЗДАНИЯ БЭКЛОГА

РИСУНОК 29 включен только в иллюстративных целях, существует много других способов организации и работы с вашими требованиями. Например, многие команды беспокоятся о том, что их стикеры упадут с доски. Эти команды часто отслеживают состояние своих юзкейсов и срезов юзкейсов, используя простую электронную таблицу, включающую рабочие листы, подобные показанным на РИСУНКЕ 30 и РИСУНКЕ 31 ниже.

РИСУНОК 30: ПРИМЕР — РАБОЧИЙ ЛИСТ ДЛЯ ОТСЛЕЖИВАНИЯ ЮЗКЕЙСОВ

РИСУНОК 31: ПРИМЕР — РАБОЧИЙ ЛИСТ ДЛЯ ОТСЛЕЖИВАНИЯ СРЕЗОВ ЮЗКЕЙСОВ

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

Завершение рабочих продуктов

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

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

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

РИСУНОК 32 показывает уровни детализации, определенные для полного набора рабочих продуктов Use-Case 3.0. Самый легкий уровень детализации показан в верхней части таблицы. Объем деталей в рабочем продукте увеличивается по мере того, как вы продвигаетесь вниз по столбцам, улучшая и расширяя содержимое.

РИСУНОК 32: УРОВНИ ДЕТАЛИЗАЦИИ РАБОЧИХ ПРОДУКТОВ

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

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

Действия

Use-Case 3.0 разбивает работу на ряд существенных действий, которые должна выполнить команда. Что делать представляют действия Essence в языке Essence. Эти действия показаны на РИСУНКЕ 33, где они сгруппированы в два набора: 1) те действия, которые используются для обнаружения, упорядочивания и проверки требований, и 2) те действия, которые используются для формирования, реализации и тестирования системы. Сплошные шевроны указывают на действия, которые явно определены Use-Case 3.0. Пунктирные шевроны являются заполнителями для других действий, от которых зависит успех практики. Use-Case 3.0 не определяет, как эти действия выполняются, ему просто нужно, чтобы они были выполнены.

РИСУНОК 33: ДЕЙСТВИЯ В USE-CASE 3.0

Прочитайте РИСУНОК 33 слева направо, чтобы получить представление о порядке, в котором действия выполняются в первую очередь. Сами действия будут выполняться много раз в ходе вашей работы. Даже простое действие, такое как «Найти действующих лиц и юзкейсы», может потребоваться выполнить много раз, чтобы найти все юзкейсы, и оно может выполняться параллельно с другими действиями или после них. Например, продолжая «Находить действующих лиц и юзкейсы», вы также можете реализовывать некоторые из срезов из тех юзкейсов, которые были найдены ранее.

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

Найти действующих лиц и юзкейсы

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

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

СОВЕТ: ПРОВОДИТЕ МОЗГОВОЙ ШТУРМ, ЧТОБЫ БЫСТРО ПРИСТУПИТЬ К СОЗДАНИЮ ВАШЕЙ МОДЕЛИ ЮЗКЕЙСОВ

Формальный характер модели юзкейсов и использование ею унифицированного языка моделирования (UML) могут стать препятствием для вовлечения пользователей и других заинтересованных сторон в процесс моделирования.

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

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

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

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

Описать и нарезать юзкейс

Далее вам нужно развить свое понимание юзкейса и создать свои первые срезы юзкейсов. Команда разработчиков сделает это, чтобы:

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

СОВЕТ: ВАМ НУЖЕН ТОЛЬКО БАЗОВЫЙ СЦЕНАРИЙ НАИБОЛЕЕ ВАЖНОГО ЮЗКЕЙСА, ЧТОБЫ СОЗДАТЬ СВОЙ ПЕРВЫЙ СРЕЗ

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

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

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

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

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

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

Повторяйте это действие всякий раз, когда необходимы новые срезы.

Подготовить срез юзкейса

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

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

СОВЕТ: ЕСЛИ У СРЕЗА НЕТ ТЕСТОВЫХ СЛУЧАЕВ, ЗНАЧИТ, ОН НЕ БЫЛ ДОЛЖНЫМ ОБРАЗОМ ПОДГОТОВЛЕН

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

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

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

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

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

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

СОВЕТ: ДЛЯ AGILE-КОМАНД РАЗБЕЙТЕ СРЕЗ НА НАБОР НЕБОЛЬШИХ, ДЕЙСТВЕННЫХ ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ

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

Хорошая новость заключается в том, что срезы юзкейсов можно легко разбить на набор пользовательских историй — например, каждый шаг может быть представлен как пользовательская история. Например, Шаг 1: Как клиент я хочу снять стандартную сумму наличных, чтобы я мог пойти за покупками, Шаг 2: Как банк я хочу проверить, что средства доступны, чтобы клиент не превысил лимит. Та же логика может быть применена к каждому расширению; например, Альт 1: Как банк я хочу предложить клиентам с хорошей репутацией овердрафт, если у них недостаточно средств для выполнения запрошенного снятия средств, чтобы они были довольны нашим сервисом.

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

Реализовать срез

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

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

Протестировать срез

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

Use-Case 3.0 работает с большинством популярных методов тестирования. Его можно рассматривать как форму разработки через тестирование, поскольку он создает тестовые случаи для каждого среза до того, как срез передается разработчикам для реализации.

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

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

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

Инспектировать и адаптировать юзкейсы

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

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

СОВЕТ: НЕ ЗАБЫВАЙТЕ ПОДДЕРЖИВАТЬ СВОЙ БЭКЛОГ СРЕЗОВ ЮЗКЕЙСОВ

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

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

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

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

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

Использование Use-Case 3.0

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

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

Use-Case 3.0: Применимо для всех типов систем

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

Use-Case 3.0: Это не только для приложений с интенсивным использованием пользователем

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

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

Use-Case 3.0: Это не только для разработки программного обеспечения

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

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

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

Нефункциональные требования

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

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

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

Use-Case 3.0: Применимо для всех жизненных циклов разработки

Use-Case 3.0 работает со всеми популярными жизненными циклами разработки программного обеспечения, включая:

1. Итеративные, управляемые бэклогом подходы, такие как Scrum, EssUP и openUP, и их масштабируемые эквиваленты, такие как SAFe, Scrum@Scale, LeSS и Nexus.
2. Жизненные циклы, основанные на однопоточном потоке, такие как Kanban
3. Жизненные циклы «все за один раз», такие как водопад.

В следующих 3 коротких разделах мы проиллюстрируем, как Use-Case 3.0 и, в частности, срезы юзкейсов могут помочь с каждым из них. Эти разделы не так автономны, как остальная часть документа, и предполагают, что читатель имеет базовое представление об обсуждаемом подходе. Мы рекомендуем вам читать только разделы, относящиеся к подходам, с которыми вы знакомы.

Пользовательские истории как рабочие элементы

Многие команды разработчиков используют пользовательские истории в приоритезированном бэклоге в качестве рабочих элементов, которыми они руководствуются в своей работе. Вот пример, который демонстрирует, как пользовательские истории могут быть легко получены из среза юзкейса. В этом примере мы будем ссылаться на первый срез юзкейса из юзкейса, показанного на РИСУНКЕ 34.

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

При желании мы могли бы расположить истории в виде карты историй, чтобы проиллюстрировать взаимосвязь между каждым шагом в повествовании юзкейса и историей (или историями), которые будут реализовывать этот шаг. Шаги базового сценария можно было бы расположить слева направо, чтобы создать основу для карты историй; истории можно было бы расположить под соответствующим шагом. РИСУНОК 34 показывает результаты первоначального мозгового штурма, представленные в виде карты историй.

РИСУНОК 34: МОЗГОВОЙ ШТУРМ ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ ДЛЯ СРЕЗА

Есть несколько интересных моментов, которые следует отметить в этом наборе пользовательских историй:

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

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

Use-Case 3.0 и итерации, управляемые бэклогом

Прежде чем принимать какой-либо подход, основанный на бэклоге, вы должны понять, какие элементы будут входить в бэклог. Существуют различные формы бэклогов, которые команды используют для управления своей работой, включая бэклоги продуктов, бэклоги релизов, бэклоги команд и бэклоги проектов. Независимо от используемой терминологии, все они следуют одним и тем же принципам. Сам бэклог представляет собой упорядоченный список всего, что может потребоваться, и является единственным источником требований для любых изменений, которые необходимо внести. Основная концепция бэклога проиллюстрирована на РИСУНКЕ 35.

РИСУНОК 35: БАЗОВЫЙ БЭКЛОГ

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

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

Когда вы применяете подход, основанный на бэклоге, важно понимать, что бэклог не создается и не заполняется заранее, а постоянно прорабатывается и уточняется, что часто называют уточнением или ведением бэклога. Типичная последовательность действий для итеративного подхода, основанного на бэклоге, показана на РИСУНКЕ 36.

РИСУНОК 36: ДЕЙСТВИЯ USE-CASE 3.0 ДЛЯ ИТЕРАТИВНЫХ ПОДХОДОВ К РАЗРАБОТКЕ

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

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

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

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

Дополнение бэклога историй юзкейсами и срезами юзкейсов

Как обсуждалось в этом документе, в первую очередь в разделах «Основы юзкейсов» и «Подготовка среза юзкейса», срезы юзкейсов обычно включают в себя множество шагов и изменений во многих различных частях системы и требуют разбиения на серию более мелких рабочих элементов для включения в планы команды или бэклог историй. Команды могут создавать пользовательские истории, чтобы описать эти изменения. Таким образом, Use-Case 3.0 на 100% совместим с командами, которые уже используют пользовательские истории.

Например:

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

Use-Case 3.0 и однопоточная разработка

Однопоточная разработка — это подход, который позволяет избежать группирования требований, наблюдаемого в итеративных и водопадных подходах. В однопоточном подходе каждый элемент требований проходит через процесс разработки. Однопоточная разработка — это метод, заимствованный из бережливого производства. РИСУНОК 37: БАЗОВАЯ ОДНОПОТОЧНАЯ РАЗРАБОТКА показывает небольшую команду, участвующую в однопоточной разработке, передающую каждый элемент непосредственно с рабочего места А на В и на С.

РИСУНОК 37: БАЗОВАЯ ОДНОПОТОЧНАЯ РАЗРАБОТКА

Чтобы это работало эффективно, вам нужны небольшие, единообразные по размеру элементы, которые будут быстро проходить через систему. Для разработки программного обеспечения требования являются сырьем, а работающее программное обеспечение — готовой продукцией. Юзкейсы были бы слишком нерегулярными по размеру и слишком большими, чтобы проходить через систему. Время на станциях A, B и C было бы слишком непредсказуемым, и все начало бы застревать. Однако срезы юзкейсов можно подобрать по размеру и настроить в соответствии с потребностями команды. РИСУНОК 38 иллюстрирует однопоточную разработку для разработки системы с использованием срезов юзкейсов. Обратите внимание, что в Use-Case 3.0 вы можете использовать срезы юзкейсов в качестве рабочих элементов, но если команда разработчиков хочет вместо этого использовать пользовательские истории или задачи, то каждый срез можно разбить на одну или несколько пользовательских историй (или задач) этой командой.

РИСУНОК 38: ОДНОПОТОЧНАЯ РАЗРАБОТКА ДЛЯ РАЗРАБОТКИ СИСТЕМЫ С ИСПОЛЬЗОВАНИЕМ СРЕЗОВ ЮЗКЕЙСОВ

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

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

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

РИСУНОК 39: СРЕЗЫ ЮЗКЕЙСОВ НА ДОСКЕ KANBAN

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

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

Важно отметить, что Kanban не имеет определенной доски Kanban или набора ограничений незавершенного производства; структура доски зависит от структуры вашей команды и методов работы. Вы должны настраивать доску и ограничения незавершенного производства по мере настройки своих методов. Состояния Alpha для срезов юзкейсов являются отличным подспорьем для такого рода организации работы. РИСУНОК 40 показывает согласование между состояниями и доской Kanban, показанной на РИСУНКЕ 39. Состояния очень эффективны, поскольку они четко определяют, в каком состоянии должен находиться срез, когда его нужно передать следующей части цепочки.

РИСУНОК 40: СОГЛАСОВАНИЕ СОСТОЯНИЙ СРЕЗА ЮЗКЕЙСА С KANBAN

РИСУНОК 41 показывает, где применяются различные действия Use-Case 3.0. Интересно, что «Инспектировать и адаптировать юзкейсы» не является обязанностью какого-либо конкретного рабочего места, а выполняется как часть регулярного контроля качества, выполняемого командой. Это действие поможет команде настроить количество и тип имеющихся у них рабочих мест, а также их ограничения незавершенного производства.

РИСУНОК 41: ДЕЙСТВИЯ USE-CASE 3.0 ДЛЯ ОДНОПОТОЧНОЙ РАЗРАБОТКИ

Например, в результате анализа эффективности команды вы можете решить упразднить рабочее место подготовки и увеличить ограничения незавершенного производства для разработки и системного тестирования. Опять же, вы используете состояния среза юзкейса, чтобы определить, что означает для каждого рабочего места завершение своей работы, что приводит к появлению доски Kanban, показанной на РИСУНКЕ 42.

РИСУНОК 42: ПЕРЕСМОТРЕННАЯ ДОСКА KANBAN КОМАНДЫ, ПОКАЗЫВАЮЩАЯ СОСТОЯНИЯ ЗАВЕРШЕНИЯ

Use-Case 3.0 и водопад

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

Когда вы применяете водопадный подход, юзкейсы не прорабатываются и не уточняются постоянно, чтобы обеспечить появление конечной системы, а определяются все сразу в начале работы. Затем они идеально синхронно проходят через другие этапы разработки, каждый из которых фокусируется на одном типе деятельности за раз. Типичная последовательность действий для водопадного подхода показана на РИСУНКЕ 43.

РИСУНОК 43: ДЕЙСТВИЯ USE-CASE 3.0 ДЛЯ ВОДОПАДНЫХ ПОДХОДОВ

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

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

РИСУНОК 44: УРОВНИ ДЕТАЛИЗАЦИИ РАБОЧИХ ПРОДУКТОВ ПРИ ИСПОЛЬЗОВАНИИ ВОДОПАДНОГО ПОДХОДА

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

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

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

Задачи как рабочие элементы

Если команда применяет более ориентированный на задачи подход (например, используя проект для выполнения работы), то вы можете получить что-то вроде этого:

• Задача 1 - Спроектировать экран
• Задача 2 - Реализовать интерфейс управления запасами
• Задача 3 - Реализовать интерфейс платежной системы
• Задача 4 - Настроить промежуточное ПО
• Задача 5 - Написать код и провести модульное тестирование - ИП
• Задача 6 - Написать код и провести модульное тестирование - бизнес-объекты
• Задача 7 - Интеграционное тестирование
• Задача 8 - Системное тестирование

Use-Case 3.0 — это не только для одного типа команды

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

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

Use-Case 3.0: Масштабирование в соответствии с вашими потребностями — масштабирование внутрь, в стороны и вверх

Ни один предопределенный подход не подходит всем, поэтому нам нужно иметь возможность масштабировать наше использование Use-Case 3.0 в нескольких различных измерениях:

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

Независимо от сложности разрабатываемой вами системы, вы всегда начинаете одинаково, определяя наиболее важные юзкейсы и создавая общую картину, обобщающую то, что необходимо построить. Затем вы можете адаптировать Use-Case 3.0 в соответствии с возникающими потребностями команды. Фактически, Use-Case 3.0 настаивает на том, чтобы вы постоянно проверяли и адаптировали его использование, чтобы устранить потери, увеличить пропускную способность и идти в ногу с постоянно меняющимися требованиями команды.

Заключение

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

Use-Case 3.0:

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

Use-Case 3.0 на 100% совместим с командами, которые уже используют пользовательские истории.

Use-Case 3.0 бесплатен и предлагается общественности в этом руководстве и в виде набора вспомогательных практик Essence, доступных на сайте www.ivarjacobson.com. Он предлагается в виде отдельного набора карточек или как часть среды Essence Workbench.

Это первая из многих публикаций по Use-Case 3.0, вы можете ожидать появления множества других статей, официальных документов и блогов по этой теме, опубликованных на сайте www.ivarjacobson.com.

Приложение 1: Взаимосвязь между практиками Use-Case 3.0

Мы использовали язык Essence для определения и описания всех практик Use-Case 3.0. РИСУНОК 45 ниже показывает, как каждая практика связана с другими практиками в Use-Case 3.0. Каждая пунктирная стрелка на рисунке обозначает расширение¹.

Все практики Use-Case 3.0 являются расширением практики Use-Case 3.0 Foundation: т.е. все эти практики наследуют концепции и принципы, определенные в Use-Case 3.0 Foundation, и они также наследуют общее определение альфы Essence для «юзкейса» и альфы Essence для «среза юзкейса».

Use-Case 3.0 Foundation не определяет никаких действий (т.е. что делать); он был создан как отдельная практика просто для того, чтобы ограничить количество концепций и элементов, которые необходимо определить в других практиках Use-Case 3.0.

РИСУНОК 45: СЕМЕЙСТВО ПРАКТИК USE-CASE 3.0

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

¹ Расширение относится к модификации или настройке элемента в соответствии с новым контекстом. Например, рабочий продукт, определенный в практике P1, может быть изменен в контексте более широкой практики P2, которая использует P1 в качестве компонента. Механизм расширения в Essence позволяет изменять или настраивать элементы и имеет две ключевые особенности:

1) Расширение является «аспектным» в том смысле, что модифицируемый элемент не знает о модификации.

2) Расширение является неразрушающим в том смысле, что исходный элемент все еще существует и доступен.

(Из Essence - Kernel and Language for Software Engineering Methods Version 1.2).

Например:

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

Приложение 2: Рабочие продукты

В этом приложении представлены определения и дополнительная информация о рабочих продуктах, используемых Use-Case 3.0. Рассматриваются следующие рабочие продукты:

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

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

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

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

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

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

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

Заметки: Базовый уровень детализации, который указывает, что включено, - это просто набросок наиболее очевидных терминов и областей, которые необходимо рассмотреть.

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

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

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

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

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

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

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

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

Тестовый случай

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

Тестовые случаи:

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

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

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

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

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

Необходимо добавить больше деталей, если тестовый случай должен быть исполняемым.

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

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

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

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

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

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

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

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

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

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

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

Модель юзкейсов

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

Модель юзкейсов:

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

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

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

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

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

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

Этот уровень детализации полезен при моделировании совершенно новых систем или новых поколений существующих систем. На этом уровне детализации определены и смоделированы все действующие лица и юзкейсы систем.

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

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

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

Повествование юзкейса

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

Повествования юзкейсов:

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

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

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

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

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

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

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

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

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

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

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

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

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

Глоссарий терминов

АКТРОР - Действующее лицо: Действующее лицо определяет роль, которую пользователь может играть при взаимодействии с системой. Пользователем может быть как человек, так и другая система. Действующие лица имеют имя и краткое описание, и они связаны с юзкейсами, с которыми они взаимодействуют.

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

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

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

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

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

Требования: То, что система должна делать, чтобы удовлетворить заинтересованные стороны.

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

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

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

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

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

Системный элемент: Член набора элементов, составляющих систему (ISO/IEC 15288:2008).

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

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

Юзкейс: Юзкейс — это все способы использования системы для достижения определенной цели для конкретного пользователя.

Use-Case 3.0: Масштабируемый набор гибких методов, использующих юзкейсы для фиксации набора требований и управления инкрементной разработкой системы для их выполнения.

Диаграмма юзкейсов: Диаграмма, показывающая ряд действующих лиц и юзкейсов, а также их взаимосвязи.

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

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

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

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

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

Благодарности

Общие

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

Люди

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

Библиография

Объектно-ориентированная разработка программного обеспечения в промышленной среде Ивар Якобсон Первая опубликованная статья, описывающая юзкейсы.

• Издатель: В трудах конференции по объектно-ориентированным системам программирования, языкам и приложениям - OOPSLA 87 (1987)

Объектно-ориентированная разработка программного обеспечения: подход, управляемый юзкейсами Ивар Якобсон, Магнус Кристерсон, Патрик Йонссон, Гуннар Овергаард. Оригинальная книга, которая представила юзкейсы миру.

• Издатель: Addison-Wesley Professional; исправленное издание (10 июля 1992 г.)
• ISBN-10: 0201544350
• ISBN-13: 978-0201544350

Преимущество объекта: реинжиниринг бизнес-процессов с помощью объектной технологии Ивар Якобсон, Мария Эрикссон, Агнета Якобсон Полное руководство по использованию юзкейсов для реинжиниринга бизнес-процессов.

• Издатель: Addison-Wesley Professional (30 сентября 1994 г.)
• ISBN-10: 0201422891
• ISBN-13: 978-0201422894

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

• Издатель: Addison-Wesley Professional (1 июня 1997 г.)
• ISBN-10: 0201924765
• ISBN-13: 978-0201924763

Моделирование юзкейсов Курт Биттнер и Ян Спенс Руководство по созданию моделей юзкейсов и написанию юзкейсов.

• Издатель: Addison-Wesley Professional; 1-е издание (30 августа 2002 г.)
• ISBN-10: 0201709139
• ISBN-13: 978-0201709131

Аспектно-ориентированная разработка программного обеспечения с использованием юзкейсов Ивар Якобсон и Пан-Вэй Нг Книга, которая познакомила мир со срезами юзкейсов.

• Издатель: Addison-Wesley Professional; 1-е издание (9 января 2005 г.)
• ISBN-10: 0321268881
• ISBN-13: 978-0321268884

Юзкейсы являются существенными Ивар Якобсон и Алистер Кокберн Статья, написанная в соавторстве, которая положила начало новой волне интереса к юзкейсам

• ACM Queue, 11 ноября 2023 г. Том 21, выпуск 5.

Основы юзкейсов Ивар Якобсон и Алистер Кокберн Краткая статья, опубликованная в 2024 году, в которой определяется общая основа, лежащая между двумя наиболее широко практикуемыми способами работы с юзкейсами. Версия 1.1

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

• Издатель: Humans and Technology Press; 1-е издание (май 2024 г.)
• ISBN 978-1-7375197-6-8

Essence - ядро и язык для методов разработки программного обеспечения - версия 1.2

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

• Object Management Group
• https://www.omg.org/spec/Essence/

Об авторах

Ивар Якобсон

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

Ян Спенс

Будучи техническим директором Ivar Jacobson International, Ян Спенс специализировался на гибком применении унифицированного процесса. Он является сертифицированным специалистом по RUP, скрам-мастером, членом SAFe и опытным коучем, который работал с сотнями проектов по внедрению итеративных и гибких методов. Он имеет более чем 30-летний опыт работы в индустрии программного обеспечения, охватывающий полный жизненный цикл разработки, включая сбор требований, архитектуру, анализ, проектирование, реализацию и управление проектами. Его специализация - итеративное управление проектами, гибкая командная работа и управление требованиями с использованием юзкейсов. В роли технического директора Ян внес вклад в техническое руководство Ivar Jacobson International, и он продолжает работать с техническим отделом компании над определением следующего поколения интеллектуальных, активных методов разработки программного обеспечения. Он был руководителем проекта и архитектором процесса разработки унифицированного процесса Essential и содержащихся в нем практик. Когда он не занимается исследованиями, сбором и определением практик, он проводит время, помогая компаниям в создании и выполнении программ изменений для улучшения их возможностей разработки программного обеспечения. Он является соавтором книг Addison Wesley «Моделирование юзкейсов» и «Управление итеративными проектами разработки программного обеспечения».

Кейт де Мендонка

Доктор Кейт де Мендонка - главный консультант в Ivar Jacobson International. Будучи главным техническим архитектором и главным техническим специалистом в Symbian Ltd, он работал с инженерами-программистами в Великобритании, Индии и Китае над разработкой операционной системы для первой волны смартфонов используемой Nokia, Sony Ericsson, Fujitsu и многими другими производителями телефонов. Он вернулся в Великобританию, чтобы присоединиться к Ivar Jacobson International в 2015 году. Кейт помог многим средним и крупным предприятиям повысить производительность и стать более инновационными, внедрив методы бережливой и гибкой разработки на уровне команды и предприятия.

Ivar Jacobson International

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

www.ivarjacobson.com

Швейцария +41 (0) 79 330 16 57

Великобритания +44 (0) 20 3934 0278

Швеция +46 (0) 8 515 10 174