пользовательская история

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

Каждый человек в команде судит о пользовательской истории по-своему.

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

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

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

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

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

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

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

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

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме пользовательская история:

  1. Чем отличается история экономического анализа от истории систем политической экономии и от истории экономической мысли?
  2. 2.4.2. Монетизация пользовательской активности в сетях третьего поколения
  3. Метки: пользовательский контент, типы блогов, видео
  4. Метки: СМИ, пользовательский контент
  5. Метки: реклама, пользовательский контент
  6. Часть 11/25. Как продвигать сайт — внешняя и пользовательская оптимизация
  7. Метки: блоговедение, пользовательский контент, что такое блог
  8. Метки: темы блога, внимание, пользовательский контент
  9. Метки: пользовательский контент, приманки, интервью с блоггерами
  10. Метки: темы блога, внимание, пользовательский контент, web 2.0, репутация
  11. Метки: автор блога, пользовательский контент, задачи, вирусный маркетинг, приманки
  12. Раздел 1.Фьючерская биржа, ее история, организация и регулирование Глава I.Товарные биржи: история и роль в современной экономике