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

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

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 »

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

USE-CASE 2.0. Что такое сценарий использования 2.0?

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

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

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

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

  • Легковесный
  • Масштабируемый
  • Универсальный
  • Простой в использовании

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

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

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

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

USE-CASE 2.0. Об этом руководстве

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

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

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

Как читать это руководство

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

  • Что такое сценарий использования 2.0? – одна страница введения в практику.
  • Базовые принципы – введение в сценарии использования, основанное вокруг 6-ти принципов, которые выступают в качестве основы для практики.
  • Сценарий использования 2.0 – содержимое – практика, представленная как набор ключевых концепций, деятельностей, рабочих продуктов и правил, которые связывают их вместе.
  • Использование сценариев использования 2.0 – резюме, когда и как применять практику.

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

Если вы новичок в теме сценариев использования, то вы можете прочитать главы «Что такое сценарий использования 2.0?», «Базовые принципы» и «Использование сценариев использования 2.0», чтобы понять основные концепции. Затем вы можете погрузиться в «Сценарий использования 2. 0 – содержимое» для понимания, как и когда вы начинаете применять практику.

Если вы знакомы с основами сценариев использования, то вы можете нырять прямо в главы «Сценарий использования 2. 0 – содержимое» и «Использование сценариев использования 2.0» после прочтения главы «Что такое сценарий использования 2.0?». Это поможет вам сравнить сценарий использования 2.0 с вашим собственным опытом и понять, что изменилось.

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

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

Как установить порог качества для развертывания релиза в TFS и VSTS

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

Возможности TFS/VSTS Release Management позволяют обеспечить «врата качества» не только на основе утверждения от какого-то участника команды разработки, когда он в ручном режиме «дает добро» на развертывание релиза на необходимом стенде, но и на основе привязки к запросам по рабочим элементам. Это позволяет обеспечить следующие правила проверки для развертывания на стенде:

  1. Не превысили ли мы порог количества высоко приоритетных или важных ошибок на релиз или продукт.
  2. Все ли требования для данного релиза покрыты тестами.
  3. Все ли тесты для релиза закрыты после проверки.
  4. И т.д.

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

  • Предварительно необходимо подготовить запрос по рабочим элементам, который отберет необходимые ошибки:

  • Далее перейти на страницу редактирования релиза:

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

  • Выбрать в разделе Gates пункт Query Work Items

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

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

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

  • При просмотре журнала развертывания можно увидеть примерно следующий результат:

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

Posted in Microsoft, Release Management FAQ, Team Foundation Server FAQ | Отмечено: , , , , | Leave a Comment »

Динамическая обработка событий TFS/VSTS на основе скриптового выполнения С# кода и REST API

Posted by Shamrai Alexander на Март 30, 2018

Подготовка различных синхронизационных «мостиков» между системами или обработка событий для отдельной системы и выполнение в ней изменений заставляет создавать отдельные модули (веб-сервисы, исполняемые модули и т.д.). Это в свою очередь включает необходимость прохождения циклов тестирования, остановки сервисов, развертывания при их изменении в дальнейшем и т.д. Конечно можно идти через использование скриптовых языков, например, Perl для IBM Rational или PowerShell для TFS/VSTS для выполнения каких-либо действий. Но в данном случае необходимо расширять свои знания на необходимые области, что требует дополнительных усилий и времени. Поэтому можно также воспользоваться возможностью написать скрипт на основе языка, который используется для создания интеграционного механизма. Например, можно рассмотреть .Net C#. Для данного языка существует nugget пакет, который позволяет запускать код .Net C# в виде скриптов, которые можно формировать динамически. При этом можно использовать не только стандартные (системные) наборы библиотек, а также можно подключать собственные или внешние библиотеки.

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

  • Для решения необходимо применить пакет для выполнения C# скриптов Scripting API Samples.
  • Также необходим пакет для взаимодействия с TFS/VSTS (в этом случае через REST API) Microsoft.TeamFoundationServer.Client.
  • Далее необходимо подготовить скрипт, который будет проверять: событие, которое пришло, удовлетворяет ли нашим критериям. Пример скрипта:

    «bool CheckConditionUpdated(WorkItemEvent.WorkItemEventUpdated InputWorkItem)

    {

    if (InputWorkItem == null) return false;

    if (InputWorkItem.resource.fields.ContainsKey(«»System.History»») && InputWorkItem.resource.fields[«»System.History»»].newValue == «»Changes from script»») return false;

    if (InputWorkItem.resource.revision.fields[«»System.WorkItemType»»] == «»Bug»») return true;

    return false;

    }

    CheckConditionUpdated(InputWorkItem)»;

    Смысл простой: проверяем переданный параметр с событием на наличие информации; проверяем, что событие, которые пришло, не является следствием изменения рабочего элемента самим сервисом; проверяем, что тип рабочего элемента – Bug. Скрипт возвращает true или false.

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

    var ScrOpt = ScriptOptions.Default.AddReferences(

    Assembly.GetAssembly(typeof(WorkItemEvent.WorkItemEventUpdated))

    ).AddImports(«System», «TFTypesLib»);

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

    _result = CSharpScript.RunAsync<bool>(_src, ScrOpt, new ScriptWiUpdatedHost { InputWorkItem = pInputWorkItem }).Result.ReturnValue;

  • Далее формируем скрипт для обработки события:

    «bool ProcessEvent(WorkItemEvent.WorkItemEventUpdated InputWorkItem)

    {

    if (InputWorkItem == null) return false;

    JsonPatchDocument PatchDocument = new JsonPatchDocument();

    PatchDocument.Add(

            new JsonPatchOperation()

    {

    Operation = Operation.Add,

    Path = «»/fields/System.History»»,

    Value = «»Changes from script»»

    }

    );

    VssCredentials Cred = new VssCredentials(true);

    WorkItemTrackingHttpClient WIClient = new WorkItemTrackingHttpClient(new Uri(«»http://tfs-srv:8080/tfs/DefaultCollection»&#187;), Cred);

    WorkItem result = WIClient.UpdateWorkItemAsync(PatchDocument, InputWorkItem.resource.revision.id).Result;

    return true;

    }

    ProcessEvent(InputWorkItem);»

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

    var ScrOpt = ScriptOptions.Default.AddReferences(

    Assembly.GetAssembly(typeof(WorkItemTrackingHttpClient)),

    Assembly.GetAssembly(typeof(JsonPatchDocument)),

    Assembly.GetAssembly(typeof(VssCredentials)),

    Assembly.GetAssembly(typeof(WorkItemEvent.WorkItemEventUpdated)),

    Assembly.GetAssembly(typeof(Uri))

    ).AddImports(


    «Microsoft.TeamFoundation.WorkItemTracking.WebApi»,


    «Microsoft.TeamFoundation.WorkItemTracking.WebApi.Models»,


    «Microsoft.VisualStudio.Services.WebApi.Patch.Json»,


    «Microsoft.VisualStudio.Services.WebApi.Patch»,


    «Microsoft.VisualStudio.Services.Common»,


    «System»,


    «TFTypesLib»

    );

Пример результат выполнения скрипта в журнале рабочего элемента:

Полный пример можно посмотреть здесь: https://github.com/ashamrai/tfevents/tree/master/TFSServicesMVCRoslyn

Posted in Microsoft, Team Foundation Server, Visual Studio, visual studio team services | Отмечено: , , , , , , | Leave a Comment »

Использование решения на основе веб-приложения ASP .Net Core для обработки веб-хуков TFS и VSTS

Posted by Shamrai Alexander на Март 1, 2018

Данная публикация является развитием предыдущей статьи и базовые элементы берутся из нее: Создание WCF сервиса для обработки событий из Team Foundation Server или Team Services.

Если говорить о различиях создания сервиса обработки на основе ASP .Net Core и WCF, то как можно выделить следующее:

  • WCF сервис не умеет разбирать списки в приходящих json. Для того, чтобы «научить» его делать это, необходимо использовать Newtonsoft.Json и дополнительный код в классах, что незначительно повышает трудоемкость поддержки. Веб-Api на основе ASP .Net Core в свою очередь не требует никакой дополнительной доработки для разбора json в теле запроса, только лишь необходимо правильно составить класс, структуру которого можно подсмотреть при тестировании запроса:

Рисунок 1. Отображение структуры json при тестировании запроса

Таблица 1. Реализация класса для обработки json

Реализация WCF и Newtonsoft.Json Реализация ASP .Net Core
public class WorkItemEventCore
{

[JsonProperty(«subscriptionId»)]
public string subscriptionId;
[JsonProperty(«notificationId»)]
public int notificationId;
[JsonProperty(«id»)]
public string id;
[JsonProperty(«eventType»)]
public string eventType;
[JsonProperty(«publisherId»)]
public string publisherId;
[JsonProperty(«message»)]
public MessageClass message;
[JsonProperty(«detailedMessage»)]
public DetailedMessageClass detailedMessage;
[JsonProperty(«resourceVersion»)]
public string resourceVersion;
[JsonProperty(«resourceContainers»)]
public Dictionary<string, ResourceContainerClass> resourceContainers;
[JsonProperty(«createdDate»)]
public string createdDate;

}

public class WorkItemEventCore
{
public string subscriptionId;

public int notificationId;

public string id;

public string eventType;

public string publisherId;

public MessageClass message;
public DetailedMessageClass detailedMessage;

public string resourceVersion;

public Dictionary<string, ResourceContainerClass> resourceContainers;

public string createdDate;

}

  • WCF решение можно размещать и на веб-сервере, и как отдельно стоящий сервис. Веб-приложение ASP .Net Core в свою очередь может также работать через веб-сервер, как сервис, но и дополнительно решение может являться мульти платформенным.

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

  • Создать веб-приложение ASP.Net Core

Рисунок 2. Создание веб-приложения

  • Выбрать шаблон проекта Веб-API

Рисунок 3. Выбор решения веб-api

namespace TFSServices.Controllers

{

[Produces(«application/json»)]

[Route(«api/TS/workitems/created»)]
public class TeamServicesWICreatedController : Controller

{
// POST: api/TS/workitems/created

[HttpPost]
public void Post([FromBody]TSEvents.WorkItemEvent.WorkItemEventCreated value)

{

}

}

[Produces(«application/json»)]

[Route(«api/TS/workitems/updated»)]


public class TeamServicesWIUpdatedController : Controller

{
// POST: api/TS/workitems/updated

[HttpPost]
public void Post([FromBody]TSEvents.WorkItemEvent.WorkItemEventUpdated value)

{

}

}

}

  • Далее тестируем запрос, при этом указываем относительный адрес, который присутствует при определении контроллера ([Route(«api/TS/workitems/updated»)]), и получаем следующий результат:

Рисунок 4. Указание необходимого адреса и тестирование решение

Рисунок 5. Отладка решения

Пример решения данной статьи находится здесь: https://github.com/ashamrai/tfevents

Posted in Microsoft, Team Foundation Server, Visual Studio, visual studio team services | Отмечено: , , , | Leave a Comment »

Дополнительная настройка стандартных RDL отчетов Team Foundation Server

Posted by Shamrai Alexander на Февраль 23, 2018

Отчеты на основе SQL Server Reporting Services, которые поставляются «из коробки» в TFS, предоставляют достаточно информации для понимания ситуации с качеством и текущими требованиями в работе. Весь список отчетов можно посмотреть здесь: https://docs.microsoft.com/en-us/vsts/report/sql-reports/reporting-services-reports. Команде конечно может хватать оперативных отчетов, которые предоставляет TFS (VSTS) на основе отчетов от запросов по рабочим элементам, цифровым панелям и т.д.: https://docs.microsoft.com/en-us/vsts/report/dashboards/overview. Но, если же нет желания предоставлять доступ к проектам и исходному коду внешним пользователям, а на это может быть достаточно причин, то можно воспользоваться отчетам SQL Server Reporting Services и Power BI. В рамках данной статьи мы рассмотрим, как можно дополнительно настроить один из стандартных отчетов SQL Server Reporting Services.

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

  • Включена ли отчетность SQL Server Reporting Services. Если нет, то ее можно подключить этими шагами: https://docs.microsoft.com/en-us/vsts/report/admin/add-reports-to-a-team-project
  • Есть ли отчеты для выбранного проекта. Если нет, то можно подключить следующими шагами: https://ashamray.wordpress.com/2018/02/16/create_tfs_default_reports/
  • Выбрать отчет для дополнительной настройки. В нашем случае отчет «Обзор требований» из проекта на основе шаблона CMMI, который дает полную информацию о состоянии реализации требований и их тестирования.

Рисунок 1. Пример отчета

  • Выбрать инструмент для реализации изменений. Тут будем использовать SQL Server Report Builder.
  • Открыть отчет через выбранный инструмент:

Рисунок 2. Открытие отчета

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

Рисунок 3. Настройка параметра отчета

Параметры, которые имеет смысл настраивать:

  • IncludeTasks – отображать ли дочерние задачи в отчете. По умолчанию отображаются только требования без какой-либо декомпозиции. Если необходимо отображать задачи, то в значении по умолчанию устанавливаем =1.

Рисунок 4. Включение дочерних задач

Рисунок 5. Пример работы отчета

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

Рисунок 6. Добавление функции в общую структуру работ

Рисунок 7. Пример работы отчета

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

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

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

Рисунок 8. Изменение запроса

Рисунок 9. Пример запроса

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

Для того, чтобы включить в запрос новые задачи, необходимо закомментировать строки, которые отбрасывают эти задачи при построении иерархии данных. Это строка 98 в запросе:

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

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

Рисунок 11. Поля запроса

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

Рисунок 12. Создание нового набора данных

В конструкторе запроса необходимо выбрать представление CurrentWorkItemView и найти необходимое поле (Microsoft_VSTS_Common_Priority). Как правило, названия колонок для полей, которые подвергаются отчетности, именуются также как свойство Reference Name с заменой точек на подчеркивания.

Рисунок 13. Поле Важность

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

  • Добавить дополнительную колонку в таблицу Rollups (строка 227)

Рисунок 14. Новая колонка для отбора приоритета

  • Добавить извлечение поля приоритета (строка 259):

Рисунок 15. Получение приоритета из представления

  • Добавить столбец при обработке собственных значений (строка 390):

Рисунок 16. Добавление приоритета для собственных значений

  • Добавить колонку при создании результирующего набора данных (строка 431):

Рисунок 17. Добавление приоритета в результирующие данные

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

Рисунок 18. Добавление нового столбца таблицу отчета

Рисунок 19. Назначение в столбец поля приоритета

Кроме этого можно поправить форматирование, чтоб поле приоритета не выстраивалось в виде дерева.

Рисунок 20. Вызов свойства поля

Рисунок 21. Исправление отступа

Сохраняем изменения и в результате получим следующий вид:

Рисунок 22. Рабочий отчет

Posted in Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , | Leave a Comment »

Как создать отчеты по умолчанию в Reporting Services для проекта Team Foundation Server

Posted by Shamrai Alexander на Февраль 16, 2018

<< Перейти в раздел «Team Foundation Server Admin FAQ»

По умолчанию, когда проект создается в TFS из веб-интерфейса, отчеты на основе Reporting Services не создаются. Однако отчеты дают неплохие возможности для подключения внешних заинтересованных лиц, включая возможность экспорта отчетов и подписки на отчеты, без необходимости обеспечения непосредственного доступа к проектам. Для того, чтобы «вернуть» набор отчетов по умолчанию, необходимо воспользоваться командой TfsConfig addProjectReports с параметрами:

/collection:’url к колекции проектов’

/teamProject:’имя проекат’

/template:’Шаблон для отчетов: CMMI, Agile или Scrum’

Пример выполнения команды:

Детальная информация о команде: AddProjectReports

Posted in Admin FAQ, Microsoft, Team Foundation Server, Team Foundation Server FAQ, Visual Studio | Отмечено: , , | Leave a Comment »

Создание WCF сервиса для обработки событий из Team Foundation Server или Team Services

Posted by Shamrai Alexander на Январь 24, 2018

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

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

В этой статье мы рассмотрим возможность создания wcf сервиса, который будет в состоянии «слушать» сообщения, которые приходят из TFS или VSTS.

Пример, как создать wcf сервис, который способен принимать входящие сообщения через метод POST, можно посмотреть здесь: https://www.codeproject.com/Articles/275279/Developing-WCF-Restful-Services-with-GET-and-POST.

Основные моменты, которые стоит отметить при создании сервиса:

  • В файле определения сервиса «имя_сервиса.svc» добавить атрибут:

Factory=»System.ServiceModel.Activation.WebServiceHostFactory»

  • Для метода, который будет в дальнейшем использовать для приема сообщений от TFS/VSTS указать атрибуты, которые будут укажут, что метод POST и работать он будет в json формате.

[OperationContract]

[WebInvoke(Method = «POST», RequestFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare)]

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

void WorkItemChangedEvent(Stream EventData);

Для конвертирования некоторой базовой информации можно использовать следующий пример класса:

public class WorkItemEventCore

{

[JsonProperty(«subscriptionId«)]

public string subscriptionId;

[JsonProperty(«notificationId«)]

public int notificationId;

[JsonProperty(«id«)]

public string id;

[JsonProperty(«eventType«)]

public string eventType;

[JsonProperty(«publisherId«)]

public string publisherId;

[JsonProperty(«message«)]

public MessageClass message;

[JsonProperty(«resourceVersion«)]

public string resourceVersion;

[JsonProperty(«createdDate«)]

public string createdDate;

}

Данный класс используется в методе при десериализации строки в экземпляр с помощью библиотек Newtonsoft.Json:

StreamReader _reader = new StreamReader(pEventData, Encoding.UTF8);

string _eventStr = _reader.ReadToEnd();

WorkItemEventCore _wieventcorre = JsonConvert.DeserializeObject<WorkItemEventCore>(_eventStr);

После развертывания решения на IIS можно выполнить тестирование метода. В моем случае создается подписка на VSTS на создание рабочего элемента:

Указывается адрес, на который отсылать сообщения, включая сервис и метод:

И после нажатия кнопки Test, можно получить информацию об успешности исполнения и пример отправленной нотификации:

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

Пример решения данной статьи находится здесь: https://github.com/ashamrai/tfevents

Posted in Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , , | Leave a Comment »

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