Экстремальное программирование (XP) ввело практику выражения требований в форме пользовательских историй. Пользовательская история – это краткое описание функциональности, рассказанное с точки зрения пользователя, представляющее ценность для него самого, либо для заказчика программного обеспечения, и обычно имеет форму шаблона, состоящего из трех частей.
С другой стороны, сценарий использования (юзкейс) – это обобщенное описание набора взаимодействий между системой и одним или несколькими участниками, где участник – это либо пользователь, либо другая система. Варианты использования могут быть написаны в виде неструктурированного текста или соответствовать структурированному шаблону.
Требования обычно представляют собой список типа «Система должна...», например:
Система должна позволять компании оплачивать размещение вакансии с помощью кредитной карты.
Система должна принимать карты Visa, MasterCard и American Express.
Система должна снимать деньги с кредитной карты до размещения вакансии на сайте.
Система должна выдавать пользователю уникальный номер подтверждения.
Пользовательские истории обычно являются лучшим выбором для команд, использующих Scrum, поскольку они обладают рядом преимуществ по сравнению с юзкейсами, требованиями и другими вариантами.
Преимущества пользовательских историй
Пользовательские истории обладают подобными характеристиками, что юзкейсы или традиционные требования, но именно то, чем они отличаются, дает пользовательским историям в agile так много преимуществ.
Преимущество 1: Пользовательские истории нуждаются в диалогах
Возможно, самым важным преимуществом пользовательских историй в agile-разработке продукта является то, что в отличие от требований или юзкейсов, они не предназначены для того, чтобы существовать изолированно. Вместо этого, каждая история пользователя - это место для последующего диалога с командой разработчиков.
Текст высокого уровня, хранящийся на индексной карточке, в задаче Jira, в ячейке электронной таблицы или на стикере, может представлять собой самое видимое отображение истории пользователя, но это не имеет первостепенного значения. Наиболее важной частью любой пользовательской истории является то, что общее понимание того, что необходимо, вырабатывается в будущем диалоге.
Преимущество 2: Пользовательские истории вербальны, поэтому более точны
Пользовательские истории ориентированы на устное общение, поэтому они более точны. Зачастую изложенное бывает весьма неточным, и нет никакой гарантии, что заказчик и разработчик будут интерпретировать утверждение одинаково.
Мы поступаем так, как будто написанные слова точны, но зачастую это не так. Например, недавно за обедом я прочитал в меню следующее: "Блюдо подается на выбор с супом или салатом и хлебом".
Это предложение не должно было стать сложным для понимания, но так и получилось. Что из этого по логике я могу выбрать?
Суп или (салат и хлеб)
(Суп или салат) и хлеб
Сравните слова, написанные в меню, со сказанным официанткой: «Вы хотите суп или салат?». Еще лучше то, что она устранила всю двусмысленность, поставив на стол корзинку с хлебом, прежде чем принять мой заказ.
Преимущество 3: Пользовательские истории относительно легко оценивать и расставлять приоритеты
Третье преимущество написания пользовательских историй заключается в том, что они получают оценку, которая позволяет более эффективно расставлять приоритеты и планировать. Для каждой истории пользователя можно просчитать усилия, необходимые при ее разработке; юзкейсы, с другой стороны, обычно слишком велики, чтобы составить по ним практически применимый в дальнейшем анализ.
В то же время, если учесть тысячи или десятки тысяч утверждений в спецификации требований к программному обеспечению (и взаимосвязи между ними) для типичного продукта, легко понять, насколько сложно определить их приоритетность.
Если требования нельзя расставить по порядку в виде обычных высоких, средних и низких приоритетов, они непригодны для высокоитеративного и инкрементального процесса разработки, при котором рабочее программное обеспечение будет поставляться каждые две-четыре недели.
Преимущество 4: Пользовательские истории побуждают команду отложить детали
Четвертое преимущество заключается в том, что пользовательские истории побуждают команду отложить сбор деталей.
Первоначальная история эпик-уровня («Рекрутер может разместить новую вакансию») может быть написана, оценена и помещена в бэклог продукта. Позже ее можно заменить несколькими более подробными историями меньшего размера с конкретными условиями удовлетворенности (критериями приемки), когда эти детали станут важными.
Эта техника делает пользовательские истории идеальными для проектов с временными ограничениями. Команда может очень быстро написать несколько десятков пользовательских историй, чтобы получить общее представление о системе. Затем они могут погрузиться в детали по нескольким из них и начать кодирование гораздо быстрее, чем команда, которая считает необходимым полностью завершить спецификацию функциональных требований.
Преимущество 5: Пользовательские истории дают общее понимание продукта
Пятое преимущество чуть менее заметно. Списки требований, которые может составить бизнес-аналитик, не дают читателю такого общего понимания продукта, как пользовательские истории.
Очень трудно читать список требований, по ходу не прокручивая в голове решения.
Например, рассмотрим следующие требования, позаимствованные из книги Алана Купера (Alan Cooper) «Психбольница в руках пациентов: почему высокотехнологичная продукция сводит нас с ума и как вернуть рассудок» (The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How To Restore The Sanity).
Изделие должно иметь двигатель, работающий на бензине.
Изделие должно иметь четыре колеса.
На каждом колесе должна быть установлена резиновая шина.
Изделие должно иметь руль.
Изделие должно иметь металлический кузов.
В этот момент, я полагаю, в вашей голове уже крутятся образы автомобилей. Конечно, автомобиль удовлетворяет всем перечисленным выше требованиям. Можно мысленно вообразить ярко-красный кабриолет, я же представляю себе синий пикап. Вероятно, различия между вашим кабриолетом и моим пикапом описаны в дополнительных требованиях.
Но предположим, что вместо написания спецификации требований в стиле IEEE 830 [рекомендуемая методика составления спецификаций требований к ПО], истории были написаны с точки зрения пользователя.
Как домовладелец, мне нужно что-то, позволяющее легко и быстро подстригать газон.
Как домовладелец, я хочу иметь возможность косить газон сидя, а не стоя.
Рассматривая цели, мы получаем совершенно иной взгляд на продукт: покупатель на самом деле хочет газонокосилку, а не автомобиль!
Истории описывают цели пользователя. Сосредоточившись на них в отношении нового продукта, а не на списке его атрибутов, мы можем разработать лучшее решение для удовлетворения потребностей клиента.
Преимущество 6: Пользовательские истории подскажут стоимость
Последнее преимущество пользовательских историй по сравнению со спецификациями требований заключается в том, что стоимость каждого требования не видна до тех пор, пока все они не будут написаны полностью.
Типичный сценарий таков: один или несколько аналитиков тратят два или три месяца (часто больше) на написание объемного документа с требованиями. Затем этот документ передается программистам, которые сообщают аналитикам (которые направляют информацию заказчику), что весь проект займет 24 месяца, а не шесть месяцев, на которые они рассчитывали.
В этом случае время было потрачено впустую на написание трех четвертей документа, разработать который до конца команда не успеет, и еще больше времени будет потрачено впустую, пока разработчики, аналитики и заказчик будут спорить о том, какую функциональность можно разработать в срок.
В хорошей практике пользовательских историй с каждой историей связана ее оценка. Потребитель/владелец продукта знает скорость работы команды и относительную стоимость каждой истории, и сможет быстро решить, можно ли получить желаемый продукт за то время, которым он располагает.
Кент Бек (Kent Beck) однажды сказал мне, что данное различие схоже с процедурой выбора свадебных подарков. Когда вы оформляете свой список, то не просматриваете стоимость каждого предмета. Просто составляете список желаний, в который заносите все, что хотите.
Списки желаний без учета стоимости могут быть выполнены на свадьбе, но они не работают при разработке продукта. Когда клиент (потребитель), владелец продукта или стейкхолдер помещают элемент в список желаний своего проекта, им необходимо знать его стоимость.
Через несколько дней состоится открытое занятие, которое рекомендуем посетить бизнес-аналитикам и системным аналитикам, которые занимаются сбором и проработкой требований и проектированием целевых ИТ-решений. На этом вебинаре мы:
обсудим актуальные проблемы в области работы с НФТ;
сформируем базовую структуру подходов и методов в области работы с НФТ;
получим представление о том, где можно взять шаблоны для формулировок требований и какие источники в отрытом доступе стоит посмотреть при изучении данной темы.
В результате вебинара структурируем представление об НФТ и получим список источников для дальнейшего более глубокого изучения.
Записаться можно на странице курса «Системный аналитик. Advanced».