Процессная практика: Управление историями (Story Mapping)

Пользовательские истории (англ. User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований (вместе с приёмочными испытаниями). Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке. Это гарантирует, что она не станет слишком большой. В Экстремальном программировании пользовательские истории пишутся пользователями (заказчиками) системы. В методологии SCRUM — пишутся либо одобряются ролью владельца продукта (англ. Product Owner). Для заказчиков (пользователей) пользовательские истории являются основным инструментом влияния на разработку программного обеспечения.

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

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

Преимущества

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

Недостатки

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