Вы здесь: Home > Правила XP > User Story
Что здесь происходит
Правила XP
   Соглашение о кодировании
   Коллективное владение кодом
   Конституция разработки ПО
   CRC Сессия
   Заказчик
   Выбирайте самое простое решение
   Функциональные тесты
   Частая интеграция
   Планирование Итерации
   Итерации
   Меняйтесь задачами
   Оставляйте оптимизацию на потом
   Парное программирование
   Безжалостно Рефакторить!
   План Релиза
   Частые Релизы
   Пробное решение
   Собрание стоя
   Метафора Системы
   Unit Test-ы
   User Story
   Скорость проекта
   Когда обнаружена ошибка
   Вам это не понадобится
Статьи по XP
Книги по XP
Ссылки по XP
Обсудить
Написать нам

User Story

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

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

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

User Stories используются в XP вместо традиционных требований. Главное отличие User Story от требований (requirements) - уровень детализации. User Story содержит минимум информации, необходимой для обоснованной оценки того, сколько времени надо на ее реализацию.

Типичная User Story занимает 1-3 недели идеального времени. История требующая менее 1 недели слишком детализирована. История требующая более 3 недель может быть разбита на части - отдельные истории.

Наш опыт.

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