Сэд стори(0((
передерни на ее фотку
Излечился
Был один шапочный знакомый. Так, изредка пересекались, в основном на тусовках.
Представлял из себя внешне эдакого чуть оплывшего мачо. Ему бы в спортзале полгода позаниматься, получился бы красавчик. Однако, его мнение о себе, как о гениальном филологе и поэте, времени для спорта не оставляло.
Его появление на играх (преферанс и настолки), обычно воспринимали без энтузиазма. Ибо ходил он туда не столько для игры, но чтобы поплакаться. Выбирал очередную жертву и начинал ныть о неразделённой любви.
С этим у него была реальная проблема. Влюблялся он моментально, горячо, «на всю жизнь». Пел дифирамбы, парил на крыльях, светился от счастья.
Через неделю избранница от него сбегала. Не выдержав слащавого романтизьма, непрестанного внимания, розовых соплей.
У поэта начиналась депрессия. Его ломало полгода-год, он всем обещал покончить с собой, выпив йаду или утопившись, или прыгнув с высотки, каждый день придумывал новый способ осчастливить мир своим уходом, писал об этом 100500й стих, потом переписывал его, потому что нет надрыва и драматизма в последнем произведении, должным запечатлеть в веках великого мертвого поэта. Тошнил своими писульками в реале и на форумах. Непризнанный гений, в общем. Живущий в свои 30+ на зарплату родителей.
После отходняка от очередной послеамурной депрессии, он решил что-то менять. Раз не везёт с женщинами, решил он, надо сменить ориентацию, влюбиться в мужчину, (женщинам нет веры), и жизнь наладится.
Как человек, верный своим принципам, рассказывать все и всем, он выложил родителям свое решение. Все остальные к тому времени уже знали о его предстоящей трансформации.
Батя, долго терпевший причуды сына, не сдержался. Дал в глаз, рубль на транспорт и пинком выгнал за дверь со словами «тут тебе не гей-клуб, катись на*ер к своим пид*расам».
Гений несколько месяцев скитался по квартирам своих знакомых. Иногда его подкармливала мать, но со временем ночлег стал проблемой, все меньше знакомых перестали его пускать к себе. Похудел заодно.
Назрела необходимость что-то решать. Возлюбленный все никак не находился, лишения и жизнь впроголодь не оставили сил и времени на такую блажь.
Пришлось ему устроиться на работу. Что умеет филолог? Правильно, ничего. Пошел курьером, заодно приторговывал на рынке в выходные.
Прошел год. Гений заматерел внешне, от былой оплылости не осталось и следа. Жизнь в общаге, в одной комнате с семью приезжими из глубинки работягами, превратила его былую пафосную речь в русско-матерный суржик. Подрабатывал немного на стройке.
Ныть перестал совсем. Очень изредка, появляясь на преферансе, вынимал из рюкзака 2-3 двухлитровых фляги пива, и со словами «снимай, мля, прикуп», лихо раскидывал карты по рукам, комментируя ход игры отборной барковщиной.
Еще через год он женился. По залету. Сменив за этот год кучу любовниц, толпами падавших на брутального, подтянутого мачо, с хищным и хололным блеском в глазах.
Да, с батей он помирился. Что было дальше, не знаю, человек с головой ушел в семейную жизнь.
Основы пользовательских историй. Часть 1. Введение
Перевод: Александр Якима (www.enter-agile.com)
Независимый консультант, agile-тренер. В IT-индустрии с 2002 года. Работал менеджером проектов, программ, а также присейл-менеджером в аутсорсинговых компаниях и директором по разработке в стартапах Силиконовой долины. В 2007-2008 сотрудничал с тренинг-центром Luxoft.
Аннотация:
В этой статье мы предлагаем обзор происхождения и приложений пользовательских историй, являющихся ключевым механизмом в гибких методах разработки и служащих проводником требований заказчика сквозь поток ценностей. В свою очередь, пользовательские истории являются критическим элементом в статьях «Бережливая и масштабируемая информационная модель требований для гибких компаний» и «Общая картина гибкости компании», обе статьи можно найти в блоге. Текущая же статья извлечена из будущей книги «Гибкие требования: бережливые практики управления требованиями для команд, программ и предприятий», издание которой запланировано на 2010 год. Отдельная благодарность Дженнифер Фосетт (Jennifer Fawcett) и Дону Видригу (Don Widrig) за их вклад в работу над книгой.
О терминологии (примечания автора перевода):
Центральным объектом статьи, как читатель уже мог догадаться, является пользовательская история, в оригинале звучащая как user story. Существует несколько различных, в том числе и довольно экстравагантных переводов этого термина (напр., «пожелание»). Однако при переводе я решил пользоваться исключительно практическими мотивами, именно поэтому мы используем термин «пользовательская история» в несколько официальном ключе и для непосредственных выкладок — «стори». Дело в том, что именно этот термин преобладает в быту большинства гибких команд при работе с англоязычными заказчиками и поэтому вполне оправдан.
Основы пользовательских историй
Они были на великом пиру языков, но довольствовались крохами.
— паж Моль к Костарду, «Напрасный труд любви», Уильям Шекспир
Введение
В гибкой разработке пользовательская история — это легковесная и более живая замена традиционным средствам описания требований: функциональных спецификаций, описаний сценариев использования (use cases) и т. д. На самом деле можно даже утверждать, что пользовательская история (стори) является наиболее весомым артифактом в гибкой разработке, поскольку представляет собой контейнер, служащий переносу потока ценностей к пользователю, а суть гибкой разработки как раз и состоит в быстрой доставке ценного результата.
Стори служит также метафорой всему нашему подходу, базирующемуся на инкрементальной доставке ценностей, а именно:
Определить полезную стори — реализовать и оттестировать в рамках короткой итерации — продемонстрировать и/или доставить ее пользователю — получить фидбек — усвоить информацию — повторить в цикле!
Я уже вкратце приводил обсуждение пользовательских историй в контексте моих более широких статей: «Бережливая и масштабируемая информационная модель требований для гибких компаний» и «Общая картина гибкости компании»(1), в которых наряду с темами, эпосами и фичами, стори являются первостепенными артефактами требований, используемых гибкими командами.
В этой статье мы более подробно опишем пользовательские истории, так как именно здесь мы раскроем одну из ключевых гибких практик, которая дает возможность направлять наше решение непосредственно на потребности пользователя и в то же время удостовериться в качестве продукта.
Пользовательские истории: обзор
В вышеупомянутых статьях и связанных с ними публикациях в блоге я подчеркивал существенность вклада Скрам-модели в гибкие практики для компаний, отмечая, к примеру, само определение роли продакт оунера (product owner), являющейся неотьемлимой по отношению к работе с требованиями. Но самим изобретением пользовательской истории мы обязаны XP и именно сторонники XP и разработали всю широту и глубину этого артефакта. Хотя это значительно менее значимое «методологическое распутье», чем это может показаться, так как пользовательские истории сейчас обычно входят в рамки Скрам-курсов как средство построения бэклога и определения состава Спринта. Наверняка мы должны благодарить Майка Кона (Mike Cohn) за большую часть этой интеграции, так как он обстоятельно проработал пользовательские истории в своей книге User Stories Applied [см. Cohn 2004], и был очень активным в сообществе Scrum Alliance.
Для наших целей мы определим пользовательскую историю так:
Пользовательская история — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
В XP стори обычно пишутся заказчиком, непосредственно интегрируя таким образом заказчика в процесс разработки. В Скраме продакт оунер часто создает стори, учитывая информацию от заказчика, стейкхолдеров и команды. Однако, на самом деле любой член команды, обладающий достаточными знаниями в бизнес-области, может создавать пользовательские истории, но в конечном итоге продакт оунер решает вопрос о принятии и выставлении приоритетов потенциальных стори в бэклоге продукта.
Пользовательские истории являются средством определения поведения системы так, чтобы это было понятно и разработчикам и пользователям. Стори концентрируют работу на ценности, определенной пользователем, нежели на структурном разбиении на задачи, как это принято делать в силу традиции. Они предоставляют легковесный и эффективный подход к управлению требованиями в системе.
Пользовательская история фиксирует короткую формулировку функции на карточке или, возможно, с помощью онлайн-средства.
Подробности поведения системы не фигурируют в этой короткой формулировке, а оставляются на потом и разрабатываются посредством диалога и критерия приемки командой и продакт оунером.
Пользовательские истории помогают преодолевать разрыв между разработчиками и пользователями
В гибкой разработке разработчик должен уметь общаться на языке пользователя, а не пользователь – говорить техническим языком. Эффективное коммуницирование является ключем ко всему и поэтому нам просто необходим общий язык. Стори как раз предоставляет общий язык для достижения понимания между пользователем и технической командой.
Билл Вейк (Bill Wake), один из создателей XP, описывает это следующим образом(2):
Пиджин (pidgin) — упрощенный язык, обычно используемый в торговле, позволяет людям, которые не могут общаться на своем родном языке, тем не менее работать вместе. Пользовательские истории действуют подобным образом. Мы не ждем от заказчика или пользователей точно такого же видения системы, как у разработчиков; стори действуют как пиджин, где обе стороны всегда могут договориться, чтобы эффективно вместе работать.
В случае с пользовательскими историями нам не нужно понимать язык друг друга на уровне мастерства, необходимого для написания сонетов; нам просто нужно в достаточной мере понимать друг друга, чтобы знать, когда мы достигли соответствующего соглашения!
Пользовательские истории — это не требования
Несмотря на то, что стори играют в огромной степени роль, ранее принадлежавшую спецификациям требований (SRS), сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов:
Литература
Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
Скиньте сэд стори
25 Jan 2016 в 12:10
25 Jan 2016 в 12:10 #1
Рили просто скиньте сэд стори если знаете такую
З.Ы люблю почитать разные стори
25 Jan 2016 в 12:12 #2
я влюбился в 1 телку. офк духу не хватало заговорить. и каждый день я наблюдал как она гуляет с другими парнями
сад же
25 Jan 2016 в 12:15 #3
25 Jan 2016 в 12:17 #4
ну у тебя она тебя знает. а моя о моем существовании не подозревает
каждую ночь я представляю как ее спасаю или еще что то хахахха рофл
25 Jan 2016 в 12:19 #5
Что такое сэд история?
25 Jan 2016 в 12:21 #6
Чёто с этого коммента в голос
25 Jan 2016 в 12:23 #7
Агенты Габена не дают мне апать ммр((( T_T
25 Jan 2016 в 12:24 #8
пасты про говно считаются сед стори?
25 Jan 2016 в 12:26 #9
говно и лифт? мм, топовая же
25 Jan 2016 в 12:28 #10
про говно и лифт годная офк
но есть и другие
25 Jan 2016 в 13:44 #11
Грустная история из жизни
25 Jan 2016 в 13:45 #12
25 Jan 2016 в 13:46 #13
25 Jan 2016 в 13:47 #14
25 Jan 2016 в 13:52 #15
Я ждал кароч в военкоме 5 часов пока дадут мне моё личное дело, а они его всунули в личное дело другого чувака.
Вот это сэд стори.
25 Jan 2016 в 13:57 #16
У меня 3к ММР.
Пойдет такая сэд стори?
25 Jan 2016 в 14:03 #17
25 Jan 2016 в 14:07 #18
кот как то нассал на монитор
25 Jan 2016 в 14:28 #19
В школьном лагере нассал соседу в кровать. Потом плакал, он.
25 Jan 2016 в 14:31 #20
25 Jan 2016 в 14:32 #21
Вот тебе топовая сэд стори: у нас сегодня было 5 пар
25 Jan 2016 в 14:38 #22
у меня 3700 ммр а на самом деле я 6000 как минимум
25 Jan 2016 в 15:20 #23
Заходишь в любой паблик Вконтакте с этими историями и читаешь там бабское нытьё ( там в основном одни девушки ).
Д — Дарксторы: как работает доставка еды
Чтобы не отставать от современности и не упустить новые слова, подписывайтесь на подкаст в Apple Podcasts, «Яндекс.Музыке» и на Castbox. Ставьте оценки и делитесь в комментариях словами, без которых, как вам кажется, невозможно представить коммуникацию в XXI веке.
Что такое дарксторы?
Даркстор — это специальный склад с продуктами, в которых собирают онлайн-заказы для доставки еды. Они отличаются особой системой, которая непохожа на обычную систему супермаркетов: товары находятся в специальных отсеках, чтобы сборщикам было удобно собирать заказы. То, как расположены продукты, зависит от того, насколько часто эти продукты заказывают и насколько товары тяжелые.
Зачем они нужны?
Дарксторы происходят от такназываемых «темных кухонь» или dark kitchen, которые появились в Великобритании и работали по принципу «закажи и забери». В таких кухнях не было мест для посадки гостей, но в них готовили еду на вынос.
Дарксторы нужны для того, чтобы сервисы доставки работали быстрее: если в районе есть несколько дарксторов, покупатели будут получать свои заказы намного быстрее.
Почему формат дарксторов так популярен?
К тому же, онлайн-магазины сегодня вполне могут составить конкуренцию офлайн-маркетам, поэтому многие не видят смысла превращать дарксторы в обычные супермаркеты.
Сервис «Яндекс.Лавка» стал первым даркстором, у которого не было офлайн-магазинов: компания создала сеть складов, в которых находилась продукция и курьеры развозили заказы по районам.
Больше о достоинствах и недостатках ассертивности читайте в материалах РБК Тренды:
Гайд по User Stories для Junior BA / PO / PM
Статья будет полезная Junior-специалистам, которые так или иначе работают с документацией на проекте. В статье рассматриваются как сами пользовательские истории, так и критерии, по которым можно написать хорошую историю. Из статьи читатель сможет подчерпнуть и как писать истории, и как правильно дополнить их деталями, и какие детали важны, и как не перегрузить историю.
Содержание:
Вводная информация о User Stories
Что такое User Stories
Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner. Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта.
Дать емкое определение этому приёму сложно. Его внешняя простота заставляет сводить его описание к внешним характеристикам. Поэтому я, как автор, хотел бы дать читателю несколько определений.
В качестве первого ответа приведем «официальное» определение из книги М. Кона «Пользовательские истории: гибкая методология разработки ПО».
Пользовательские истории — это краткое описание функциональности, детали которой должны уточняться в ходе устных обсуждений между заинтересованными лицами проекта.
Такое определение не помогает разобраться в сути приема и его распространенности среди пользователей. Неужели главное — это записи или то, что детали должны уточняться? Думаю, нет. Поэтому я не бросил копания и начал смотреть другие источники. Множество сайтов предлагает такое определение:
Этот ответ тоже не удовлетворил моё любопытство. Такое определение ставит во главу угла формат. Ведь User Story может существовать и без какой-то части (As a user, I want to save data) и быть написанной без обсуждения интровертным продакт-овнером. Но самое главное — об этом будет ниже — User Story может быть написана по совершенно иному формату!
Пройдя круг обсуждений с ментором, прочитав и посмотрев много статей и видео, я понял, что главное в пользовательской истории — это ценность, которую пользователь получит от функции. Поэтому я попытался сгенерировать определение:
Очень важно отметить, что история и ее ценность может быть направлена не только на какую-то группу пользователей. Она может быть направлена на команду разработки (обновить компонент, добавить компонент, переделать код. ), Product Owner или представителей бизнеса.
Далее в статье я использую однострочные примеры пользовательских историй: «Как Х, я хочу Y, чтобы Z«. Тем не менее, многие аналитики использую другой подход, который считается даже более каноничным.
Так, истории пишутся в три строки:
Job Stories
В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности.
Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.
«Тело» JS делится на три части:
Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение.
Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции.
Expected Outcome: описывает, что получит юзер после использования функции.
Job Stories могут писаться по двум форматам:
В одну строку:
When X I want to Y so I can Z» или «When X, actor is Y so that Z.
В три строки:
When X
I want to Y
So I can Z.
When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.
Вопросы, которые следует задавать во время написания стори
Решает ли это настоящую проблему юзера?
Есть ли у такого решения какие-либо side effects? Влияет ли это на продукт в целом?
Какие последствия от такого решения?
А при работе с другими стейкхолдерами и выяснении первопричин нужды у них аналитик может использовать знаменитый приём «5 почему?».
Пример работы техники «5 почему».
Три С в User Story
Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют «the 3 C’s of User Stories».
Card — по задумке автора метода истории пишутся на физических карточках. В реальности они пишутся в Jira и Confluence, поэтому мы не так ограничены в детальности.
Conversation — каждая стори — это множество митингов вокруг нее, которые и направлены на понимание деталей.
Confirmation — перед началом работы клиент дает согласие на данное решение, а команда полностью уверена в выполнимости решения.
User Personas
Этот метод представляет собой детализированное описание пользователя продукта. Описание пользователя должно быть конкретным и детальным, ведь по его описанию члены команды должны понять, что это целевая аудитория приложения, которое они делают.
Создавая четкого и детального персонажа, аналитик требований или Product Owner уменьшает вероятность того, что нужды пользователя будут забыты или заменены на нужды тех членов проектной команды, которые ставят себя на место пользователей.
Карточка персонажа не обязана быть полностью правильной, но она обязана содержать максимальное количество деталей.
Наиболее важными деталями персонажа являются его имя, место работы (роль в системе), место проживания. Причём имя и роль в будущем могут использоваться и при написании историй:
Как Георгий, я хочу печатать документы, чтобы я мог работать над ними вне компьютера.
Стоит также отразить маркетинговые характеристики персонажа такие как предпочитаемые бренды, блюда, увлечения и хобби. Эти характеристики важны не только, чтобы знать для кого мы создаем ПО, но и как его рекламировать и продавать. Описание должно также раскрывать и характер персонажа. Он веселый или чаще хмурится? Он делится информацией в соцсетях или вовсе не ведет их?
В описании следует отразить и задачи, которые наиболее важны для персонажа в его работе с системой. Это поможет всей команде увидеть нужды персонажа и поможет создать стимул для покупки премиум-версии или подписки.
Не стоит забывать и об еще одной важной детали. Персонажи не могут «гулять» из продукта в продукт, но человек, который создаёт их описание, может обращаться к давно созданным образам как за вдохновением, так и за шаблоном описания.
Создав одного персонажа, можно отдохнуть и насладиться проделанной работой. Однако не стоит останавливаться, так как именно набор персонажей (от 3 до 10) поможет в будущем выстроить систему, которая поможет приоритизировать истории, благодаря пониманию того, что нужно тому или другому персонажу. А если что-то нужно двум из трех персонажей, то следует бросить все силы на эту функцию.
Что же в сухой практике использования User Personas?
Отрицательный персонаж
Не все персонажи должны создаваться, чтобы показать пользователей системы. Задача некоторых указать, кому в приложении нет места.
Создавая любое приложение для такси, мы вспомним, что в процессе заказа традиционно есть 3 участника: клиент, водитель, оператор. Скорее всего, задачей нашего приложения будет автоматизация работы оператора так, чтобы клиент мог связаться с водителем напрямую. В таком случае самому оператору в системе не будет места.
Ключевой персонаж
Ключевыми персонажами являются те, для кого и будет проводиться проектирование решения. Такой персонаж олицетворяет группу пользователей, которая будет либо чаще всего пользоваться приложением, либо имеет какие-то особенности, из-за которых им следует пользоваться приложением иначе. Такие персонажи заслуживают отдельных интерфейсов в системе.
Давайте вернемся к приложению для саппорта. В нем оба персонажа, которые всё-таки будут пользоваться системой, будут ключевыми. Так, тому, кто будет устранять жалобы, нужен интерфейс, который показывает жалобы и помогает выстроить маршрут. В тоже время клиенту, скорее всего, нужно посмотреть все его жалобы и оставить новую.
INVEST
По критериям INVEST мы можем судить, хорошо ли написана User Story и можно ли над ней работать.
I — Independent — Независимый
Следует избегать зависимости между историями, так как иногда это приводит к проблемам во время имплементации. (пример: задача А не может быть реализована без задачи Б, однако задача А — очень важна, а Б лишь желательно иметь в готовом продукте).
На практике это стремление не всегда достижимо. Например, в случае зависимости нескольких историй друг от друга, следует искать другой способ разбить их.
Мы хотим добавить в наш продукт поддержку банковских карт MasterCard, Visa и третьей системы. Тогда проще всего разделить эту стори на три. В первой, самой большой, разработчик должен добавить поддержку банковских карт в целом и какую-то из списка. А остальные две могут пойти в другую стори, которая зависит от первой.
N — Negotiable — Обсуждаемый
После написания черновика истории следует обсудить ее со стейкхолдерами и, возможно, внести изменения, исправить ошибки. В ходе обсуждения команда ещё не говорит о том, как данная история будет реализована, а обсуждается лишь то, как будет удовлетворяться нужда пользователя.
V — Valuable — Ценный
Каждая User Story должна нести пользу как пользователю, так и продукту, а описание должно создаваться так, чтобы ценность была наиболее очевидна. Так команда разработки будет понимать, зачем это нужно реализовывать.
Если ценность историй, которые несут новый функционал или улучшают старый, очевидна, то с теми, которые завязаны на технической стороне продукта, не все так очевидно. Но и истории, в рамках которой команда избавляется от легаси-кода, делает рефакторинг или переносит старый функционал на новую инфраструктуру (например, в новую базу данных) несут ценность для как для продукта, так и для пользователя. Скорее всего, пользователь ощутит их благодаря улучшению отзывчивости или скорости работы системы. Это следует отразить в описании такой задачи.
E — Estimable — Оцениваемый
История должна быть настолько ясно написана, чтобы у разработчика было достаточно понимания ведь без него он сможет выдать оценку, близкую к правде. Есть три причины, почему dev не может выдать оценку:
история слишком большая;
в описании недостаточно данных;
разработчику нужно больше опыта.
Однако подробнее об оценках поговорим в отделе “Оценка историй”.
S — Small — Компактный
Этот пункт говорит не о самом описании под историей, а о ее размере, времени на реализацию. На многих проектах команды устанавливают рамки, в которые должна уместиться история. Так, часто можно услышать о правиле, согласно которому история должна укладываться в рабочий день. Однако на других же пользовательской историей может считаться функция, на реализацию которой нужно несколько месяцев времени разработчика.
T — Testable — Тестируемый
Суть этого пункта не только в том, что команда тестировщиков должна понимать, что проверять, но и в том, что пользовательская история должна обладать чем-то, что можно посмотреть, запустить.
Однако не стоит забывать, что стоит писать истории так, чтобы QA-команда могла понять, какие кейсы и сценарии ей тестировать. Для создания этого понимания аналитику требований следует пользоваться критериями приемки и описанием сценариев по Gherkin. Подробнее об этих приемах можно прочитать в разделе “Как добавить деталей к истории”.
Как добавить деталей к истории?
Очень важно понимать, что когда работа над «телом» стори закончена, начинается работа над деталями, которые и помогут команде понять, что надо реализовать. Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin.
Acceptance Criteria
Что такое АС
Элемент User Stories, который дополняет их так, что команда начинает видеть историю в деталях. Этот инструмент помогает понять, что должно быть сделано, чтобы удовлетворить потребность бизнеса.
АС помогают увидеть фичу с точки зрения конечного пользователя, установить границы фичи и создать понимание того, что должно быть сделано и что будет проверяться.
Их надо понимать максимально буквально, потому что это те критерии по которым мы понимаем, выполнена история или нет.
Для чего нужны
Показывают фичу с точки зрения конечного юзера.
Для понимания задач бизнеса.
Достижения консенсуса с бизнесом относительно какой-то стори.
Служат базой для тестов.
Помогают эстимировать стори.
Правила написания
Мы пишем их не в форме should, а в настоящем времени (суть в том, что человек читает и видит, какими «способностями» обладает юзер или система).
Должны быть измеримы.
Пишутся ДО работы над задачей.
Включают функциональные и нефункциональные критерии.
Пользователь может выбрать цвет. Пример: есть дропдаун с цветами.
Не слишком узкие (привязаны к одному юз-кейсу-примеру) и не слишком широкие (понятно где сделано и как работает).
Не содержат технического арго.
Что делать, когда надо выбрать одно из нескольких решений?
Тогда на помощь приходит Evaluation Criteria. Используются, чтобы оценить ценность нескольких решений и выбрать нужное.
Компания хочет пообедать в итальянском веганском ресторане, где играет живая испанская гитара. Тогда ресторан, который подойдёт, должен соответствовать трем критериям:
1. Ресторан должен быть итальянским.
2. Ресторан должен быть должен подавать вегетарианские блюда.
3. В ресторане играет живая испанская гитара.
Gherkin
Scenario: Dr Bill posts to his own blog.
GIVEN I am logged in as Dr Bill
WHEN I try to post to my blog
THEN I should see «Your article was published»
Базовый синтаксис Gherkin
1) Пишется сценарий-скелет.
Scenario Outline: Dr Bill posts to his own blog.
Given I Have published
When I try to post a new blog
Then I should see
2) Создается таблица с примерами.
В данном примере мы должны показать связь между количеством постов в блоге и тем, какое сообщение увидит пользователь.Например:
