Системные User Stories
| October 3, 2011 | Posted by admin under Практики, Статьи |
Terry Bunio, a Principal Consultant at Protegra
http://bornagainagilist.wordpress.com/2011/03/06/a-system-user-story-holy-war-on-a-saturday-night/
Я отстаиваю концепцию системных User Stories. Есть мнение, что только User Stories должны использоваться как мера прогресса проекта.И я согласен с этим на 100 процентов.Я не предлагаю использовать системные User Stories для управления проектом и для измерения прогресса. Я предлагаю использовать их для валидации дизайна и для проверки полноты User Stories.По сути системные User Stories не отменяют User Stories. Они являются дополнительной активностью и также поставляются заказчику. Я считаю их бесценной легковесной моделью, которая документирует поведение системы. Я вижу большой разрыв между User Stories, Тест Case-ами и кодом. Не хватает определения системы (документа вроде System Definition ).Это место может занять легковесная модель, которая даст уверенность в полноте и связности решения.
По моему определению, системные User Stories определяют, как компоненты системы взаимодействуют друг с другом на высоком уровне.Они привлекают меня тем, что позволяют решить следующие три задачи:
- Изучить поведение системы, чтобы быть уверенным в полноте и детализации дизайна.
- Создать легковесную модель, которая описывает поведение системы, для коммуникаций внутри команды.
- Подтвердить, что для системы созданы подходящие User Stories и тесты.
Меня всегда беспокоил тот факт, что, при отсутствии легковесной модели, переработка User Stories на поздних итерациях затрагивает системную архитектуру и дизайн. С помощью системных User Stories (легковесная модель) мы можем валидировать традиционные User Stories . Кроме того, они позволяют найти области, которые не были описаны в традиционных User Stories . Я думаю, системные User Stories имеют большое значение для сложных систем. Сейчас я работаю над очень сложной системой. Я уверен, что системные User Stories существенно помогли убедиться в полноте и корректности дизайна. Поскольку это проект R&D системы, то роль Product Owner легла на проектную команду.Системные User Stories помогли прояснить эту концепцию.
Каков должен быть формат системных User Stories ?
По моему опыту системная User Story должна занимать не больше двух-трех страниц. При большем объеме вы залезаете в детали, а не подтверждаете целостность и согласованность дизайна. Фактически вы делаете определение требований.
Мне также нравится формат User Story. Он достаточно полный и краткий. Вот какой формат я использовал:
Как [Domain Specific Language Компонент] я буду [выполнять Domain Specific Language Действие ] если [произойдет Событие] используя [Domain Specific Language Компоненты или Системные Компоненты]
Под Domain Specific Language Компонентами и Действиями подразумеваются реальные DSL Компоненты и Действия или абстракции высокоуровневых компонентов системы. Определенно они не должны быть низкоуровневыми.Я разбил эти системные User Stories по основным фичам (features) для удобства категоризации и организации.
Я переименовал системные User Stories в Системную Грамматику (System Grammar). Я хотел показать, что эти правила являются грамматикой, которую использует система, чтобы построить свой язык функциональности.
Системная Грамматика. Думаю, для нее есть место.
-
Александр Пантелеев
-
anray
