Возник следующий вопрос. В общем и целом формат написания user stories прост и понятен (как [роль (например, пользователь / администратор) ], я могу [действие / feature], чтобы [цель] + метаданные: приемочные тесты, оценка, приоритет и др.).

Но интересует, есть ли в открытом доступе практический пример того, как же писать эти истории, если при мелкой детализации (когда прям совсем по invest) их может быть 100-200 или больше? И в чем плюсы и минусы user stories по сравнению с use cases?

Читал об этом в книге Майкла Кона User Stories Applied, но хотелось бы обсудить это в привязке к конкретному кейсу и услышать мнение и гуру agile, и приверженцев rup — чего-то околоводопадного =))

Есть ли тут такие эксперты? И есть ли кто-то, кто бы мог провести мастер-класс / семинар на эту тему? Если кто-то мог бы, то я бы взял все организационные моменты на себя (возможности есть) и активно поучаствовал бы в проработке кейса.

Семинар можно сделать, но по-моему кто-то уже читал доклад об этом из Сообщества Агиле Россия.

Говорить о US vs UC вне контекста конкретного проекта достаточно сложно. Это примерно то же самое, что и спрашивать какой автомобиль лучше (вообще). Если бы вопрос был поставлен несколько иначе - какую технику для описания требований лучше использовать в такой-то ситуации - думаю это бы облегчило задачу отвечающих.

Говорить о US vs UC вне контекста конкретного проекта достаточно сложно. Это примерно то же самое, что и спрашивать какой автомобиль лучше (вообще). Если бы вопрос был поставлен несколько иначе - какую технику для описания требований лучше использовать в такой-то ситуации - думаю это бы облегчило задачу отвечающих.

Юрий, какую же технику сбора требований оптимально использовать при написании ТЗ, например, на небольшую Систему. Пример: Система учёта оборудования какой-нибудь крупной компании. Допустим, что Система реализует выполнение 3-5 бизнес-задач.

Я такую делал - обслуживание торговых аппаратов (с кофе, чипсами и тп) и хранение запчастей для них. Доменной модели и одной встречи часа на 2 в середине проекта вполне хватило, весь проект занял полтора месяца (учитывая, что разработчик из меня не ах). Правда, заказчик был дружественный..

Юра, ilyap1 как раз и предлагает это разобрать на нескольких кейсах.

http://jamesshore.com/Presentations/Beyond%20Story%20Cards.html здесь тоже имеется довольно интересный материал по теме

Юрий, какую же технику сбора требований оптимально использовать при написании ТЗ, например, на небольшую Систему. Пример: Система учёта оборудования какой-нибудь крупной компании. Допустим, что Система реализует выполнение 3-5 бизнес-задач.

Для такой системы я бы не стал писать явного ТЗ - а просто более четко сформулировал критерии выбора системы из готовых в виде 10 буллетов, т.к. это в чистом виде CMDB :-), потом читал бы документацию на системы и пробовал их использовать. Второй момент - давайте определимся что понимаем под "бизнес-задачами". В качестве бизнес-задачи вполне можно считать что-то типа "формировать отчетность по GAAP" ... вполне себе бизнес-задача, однако под ней столько всего может быть .... А реально - еще нужно учитывать формальные требования к ТЗ. Даже для такой простой задачи, гос.заказчик может попросить все оформить по ГОСТ. В другом случае мы можем работать менее формально - используя то что удобно нам ... хоть UC, хоть US, хоть что угодно.

Юра, ilyap1 как раз и предлагает это разобрать на нескольких кейсах.

Видимо Илья пользовался google и не нашел кейсов в открытом доступе .... :-) Не заниматься же созданием кейсов.

Коллеги, кто-нибудь когда-нибудь писал методологию по формулированию User Story? Поделитесь, пожалуйста, опытом.