Comments 15
Что означает «TBD»?
To Be Done очевидно
И вовсе не очевидно. Гугл считает, что "TBD" это "to be determined". А вообще, это минус автору за использование аббревиатур без расшифровки.
Поддерживаю. Первый раз встретился с аббревиатурой ''TBD'' в книге Карла Вигерса и Джона Битти "Разработка требований к программному обеспечению", в которой она расшифровывается как «To Be Determined» и служит меткой в системе управления требованиями с помощью которой можно сначала пометить требования, в которых при первичной формализации возникли вопросы и непонимания, требующие дополнительных размышлений, поиска, сбора и анализа информации и. соответственного, последующей выработки решения, а затем быстро отобрать такие требования из списка, чтобы вернуться к работе над ними.
Спасибо всем за внимательность! Расшифровку добавили в текст. В нашем случае имелось в виду «To be determined», но все варианты могут быть применимы.
to be determined
To be discussed
Думаю. что то из этого: To be determined, or "to be decided" or "to be declared".
To be discussed
To be defined
Принято к сведению) Добротная статья
Мне кажется, что user story читабельнее, если отрицательные сценарии указывать отдельно
Пример: «
Основной сценарий
...
При заполнении всех полей в соответствии с правилами валидации, указанными в таблице 1, после нажатия кнопки “Создать” открывается окно создания заказа».
....
Алтернативные сценарии
Про ошибке валидации (ссылка на таблицу 1) появляется сообщение об ошибке. Возможный текст:…
Как клиент магазина бытовой техники, я хочу зарегистрироваться на сайте магазина, чтобы оформить он-лайн заказ.
Это то, как не надо писать юзер стори. Почти все в этой шаблонной формулировке сущее вранье. Пользователь не хочет регистрироваться на сайте магазина, чтобы оформить заказ.
Пользователь хочет оформить заказ и, как правило, вынужден для этого проходить процесс регистрации. Не он хочет этого, этого хочет магазин. Для того чтобы выслать товар клиенту, владелец магазина хочет получить от клиента адресные данные и данные по оплате. (Для этого регистрация кстати не нужна). А регистрация нужна для того, чтобы хранить адресные данные и данные по оплате для последующих заказов. Либо же там есть какие-то удобные функции (типа истории заказов) которые привязаны к учетной записи. И эти случаи все нужно четко разграничить. Тогда у нас получатся разные истории: я новый клиент и хочу быстро оформить заказ, я постоянный клиент и при оформлении заказа не хочу каждый раз вводить одни и те же данные.
Юзер стори не содержит деталей реализации. Одна из функций юзер стори это, грубо говоря, прояснить в голове заказчика, а как же у него бизнес работает и как он взаимодействует с пользователем, зачем и почему, а также инициировать процесс осмысления и обсуждения.
Я понимаю, что это "всего лишь пример, и вообще не про это, а про именование", но из таких неверных примеров потом мы имеем тонны шаблонно написаных юзер стори от которых ни тепло ни холодно. Кстати и именование я бы сделал исходя из пользователя, а не функции. "новый клиент", "постоянный клиент". А для различения лучше написать отличительную особенность этой истории вместо цифр и аббревиатур, которые не несут в себе никакой полезной информации, кроме того что по цифрам можно сортировать в экселе. Для группировки по тематической области лучше потом уже к карточке "тег" прикрепить.
Полагаю, что автор статьи попал в типичную ловушку, когда на проекте в качестве формата описания пользовательских требований (и их разбивки до функциональных) выбран User Story. И в такой области, как ритейл/eCommerce (в примере выше), это приводит к формализму и натягиванию смысла на шаблон, поскольку функции и так в целом понятны: мол, разве кому-то не ясно, что именно система должна позволять сделать пользователю в процессе покупки и оформления заказа?
На всякий случай уточню свою мысль. Я не призываю забивать на формулировки, используемые в текста самой юзерстори! Но просто в некоторых предметных областях важность такой информации резко снижается и вся ценность оказывается сосредоточена именно в "критериях приёмки", на что, как я понял, и делает акцент автор.
User story на отлично: что учесть, чтобы написать хорошие требования к ПО