Заметки консультанта

Шамрай Александр Владимирович

Archive for 23.05.2018

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

Posted by Shamrai Alexander на Май 23, 2018

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Истории

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СОВЕТ: ХРАНИТЕ АНАЛИЗ ДОСТУПНЫМ И ЛЕГКИМ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СОВЕТ: НЕ ЗАБУДЬТЕ ПОДДЕРЖИВАТЬ ВАШ ЖУРНАЛ СЛАЙСОВ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ

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

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

Posted in Стандарты и методологии, Управление требованиями | Отмечено: , , | Leave a Comment »

 
%d такие блоггеры, как: