В поисках мудрости, связанной с вариантами использования, на просторах интернета наткнулась на вот такой вопрос (из списка для собеседования на должность аналитика):

Как долго может длиться экземпляр варианта использования до достижения своей цели? В оригинале - "How long (time/calendar) may an instantiated use case run before it could complete its goal?"

Первое, что пришло в голову - "столько, сколько нужно", но хорошего аргументированного ответа я придумать не смогла. Как бы Вы ответили на этот вопрос?

Смотри книгу Коберна "Современные методы описания функциональных требований". Там все написано.

Если коротко, то для юзкейса уровня целей пользователя - до 10 минут.

А я вот не согласна с Коберном (если он такое утверждает). Не могу придумать конкретного примера, но внутреннее ощущение, что более длительные варианты использования имеют право на существование присутствует.
Внутренний конфликт даже заставил бросить все и полезть в эту книжку, но пока там ничего подобного не нашла... SALar, можете уточнить, куда смотреть?

Я думаю тут следует понять на каком уровне смотреть. Но в любом слкучае Salar прав. Если почитать того же Крэга Лармана, то он говорит:
что ВИ следует выделять
 - это элементарный бизнес-процесс (или задача)
 - это то, что одобрит руководство
 - это нечто достаточно компактное по времени

Наверное, точных границ нет, но это скорее всего минуты или несколько десятков минут максимум

Добрый день.

 

В поисках мудрости ...

можно было бы и весь тест приложить.
Ну да ладно держите - вот он - во вложении .

Наверно имелось ввиду следующее:

См. раздел 5.5 (книги), rдe вопрос обсуждается подробно.

• Удостоверьтесь, что для варианта использования указан правильный уровень
  цели: обобщенный, пользователя или подфункции.
   
• Периодически проверяйте, знаете ли вы, где "уровень моря" для ваших целей и
  насколько ниже (или выше) уровня моря находятся... Напомним тесты... :

 Цели добивается одно лицо в одном месте в одно время
(2- 20 мин).
 - Действующее лицо может уйти удовлетворенным, как только цель
будет достигнута.
-  Добившись многих целей, действующее лицо (если работает по
найму) может попросить повышения.

Спасибо за ответы
Посмотрела Корбена, к вопросу действительно лучше подходить учитывая уровни. В глоссарии есть практически готовый вариант ответа (термин "уровень"):

Вариант использования обобщенного уровня требует для выполнения несколько сеансов уровня цели пользователя, возможно, недели, месяцы или годы.
…
Вариант использования уровня цели пользователя описывает достижение основным действующим лицом определенной и непосредственной цели. Он обычно выполняется одним основным действующим лицом за один сеанс продолжительностью от 2 до 20 мин (или меньше, если основным действующим лицом является компьютер). Далее основное действующее лицо может продолжить работу с друrими целями.

Отмечу слово "обычно" в приведенной цитате. Это - важно. Потому что ВИ уровня пользователя - это сеанс работы пользователя с системой для достижения некоторой цели. И я встречал кейсы, когда такая работа длиться дольше, до нескольких часов, за которые пользователь реально достигает одну цель (и так каждый день). Обычно это происходит по побочным веткам процесса и связано с некоторым перебором вариантов "вручную". Если интересно, могу написать подробнее.

maksiq, да, интересно. Напишите подробней, пожалуйста!

Первый пример - автоматизация склада, формирование сменного задания складу, выполняется ежедневно с жесткими временными рамками (начинают в 16, надо успеть до 19). Основная ветка - тупая, система выбирает все заказы (назовем это так) с завтрашней датой отгрузки, контролирует, что для всех регулярных адресатов заказы уже созданы, проверяет ограничения и формирует это самое задание по некоторому алгоритму. Человек практически жмет большую кнопку, смотрит интегральные результаты и все, процесс на несколько минут. По этому сценарию идут 2/3 дней. А остальные - по побочным ветвям: если каких-то заказов нет, то репер - формировать из того что есть, или ждать. Если ограничения (их много, они разные) не удовлетворяются, то дальше начинается работа оператора, он смотрит на задание под разными разрезами и уменьшает его, или может принять решение о формировании с превышением (склад может поднатужится и сделать на 30% больше, но не ежедневно, а вот в машину лишний объем - не влезет, но можно поменять). А если почему-то отгрузка на день оказалась маленькой, он смотрит заказы на послезавтра и может запустить их. В общем-то, описание этого в виде ВИ - относительно муторное, потому что очень много ветвлений, но надо же на что-то опираться при проектировании интерфейса. Поэтому несколько кейсов мы прописали, как частых, так и экзотических. При этом, хотя человек в этом процессе взаимодействует не только с системой, но и с телефоном, это непрерывный кусок работы, на выходе которого должен быть вполне осязаемый результат. Это - один кейс.

Другой кейс. Девочки сидят на загрузке Каталогов от поставщиков. Квант работы - загрузка Каталога на следующий сезон от одного поставщика. Это Excel/Word файл условно структурированного формата, часто на несколько тысяч артикулов. "Условно" означает, что жесткой структуры нет. Конечная цель - товары и модели с необходимой атрибутикой должны появиться в Каталоге и правильно лечь по веткам, создав, где надо новые, а также - заполнив вспомогательные справочники (по необходимости). В зависимости от числа товаров, качества исходного материала и объема новых дополнительных справочников, задача занимает от некоторого количества минут на универсальной форме загрузки, до нескольких часов с последовательным преобразованием информации. Основное для нас было продумать удобную навигацию по интерфейсам и полуавтоматические кейсы заполнения справочников. А для этого - понять ход работы на типичных ветках.

Третий кейс. Бухгалтера, выверка отчетности. Тоже мутная задача. Смотришь, как он это делает в существующей системе, описываешь нитки ВИ (а то забудешь), потом - проектируешь новый интерфейс (или доработки), спрямляя проблемные места. Опять-таки, у него квант работы - отчет (или некоторая часть), выверяемая за "разумное" время - типа, полдня.

Как-то так.

Вопрос такой - реально ли такой большой ВИ описать с помощью user story? Или это просто нецелесообразно и нечетабельно?

Нечитабельно*

... Поэтому несколько кейсов мы прописали, как частых, так и экзотических. При этом, хотя человек в этом процессе взаимодействует не только с системой, но и с телефоном, это непрерывный кусок работы, на выходе которого должен быть вполне осязаемый результат. Это - один кейс.

Это один сценарий уровня уровня воздушного змея. И это несколько сценариев уровня моря.

Другой кейс. Девочки сидят на загрузке Каталогов от поставщиков. Квант работы - загрузка Каталога на следующий сезон от одного поставщика. Это Excel/Word файл условно структурированного формата, часто на несколько тысяч артикулов. "Условно" означает, что жесткой структуры нет. Конечная цель - товары и модели с необходимой атрибутикой должны появиться в Каталоге и правильно лечь по веткам, создав, где надо новые, а также - заполнив вспомогательные справочники (по необходимости). В зависимости от числа товаров, качества исходного материала и объема новых дополнительных справочников, задача занимает от некоторого количества минут на универсальной форме загрузки, до нескольких часов с последовательным преобразованием информации. Основное для нас было продумать удобную навигацию по интерфейсам и полуавтоматические кейсы заполнения справочников. А для этого - понять ход работы на типичных ветках.

Квант работы - это загрузка одной записи от одного поставщика. Это уровень пользователя (моря). 0.1 - 10 минут.
Загрузка каталога от поставщика - это обобщенный сценарий (уровня змея). Он действительно несколько дольше.

Третий кейс. Бухгалтера, выверка отчетности. Тоже мутная задача. Смотришь, как он это делает в существующей системе, описываешь нитки ВИ (а то забудешь), потом - проектируешь новый интерфейс (или доработки), спрямляя проблемные места. Опять-таки, у него квант работы - отчет (или некоторая часть), выверяемая за "разумное" время - типа, полдня.

Квант работы - это выверка одной записи. Это уровень пользователя (моря). 0.1 - 10 минут.
Проверка всего отчета  - это обобщенный сценарий (уровня змея). Он действительно несколько дольше.


Таким образом во всех трех случаях вы рассмотрели обобщенные сценарии. И показали, что во всех трех случаях ВИ уровня пользователя длится менее 10 минут.

Что и требовалось показать.

Один из источников предлагал критерий WAVE для определения ВИ

What
Actor
Value 
Entire

Вот в Entire  и скрыта продолжительность. Еще одна метафора на тему длительности  и целостности ВИ - "сделав это, я могу выпить чашечку кофе".

В поисках мудрости, связанной с вариантами использования, на просторах интернета наткнулась на вот такой вопрос (из списка для собеседования на должность аналитика):

Как долго может длиться экземпляр варианта использования до достижения своей цели? В оригинале - "How long (time/calendar) may an instantiated use case run before it could complete its goal?"

Отвечу так, как отвечают аналитики: в зависимости от того, как мы собираемся это применять.

SALar Вы неверно представляете кванты работы во всех трех сценариях. Потому что это компьютер при примитивном программировании крутит цикл по записям. Человек работает со всем заданием/каталогом/отчетом целиком. Потому что там взаимозависимые вещи и интегральные ограничения (в первом случае), а во втором и в третьем - идет настройка некоторых описателей или выбор класса строк, убеждаются что с ними хорошо, отбрасывают, разбираются с оставшимися. Да и компьютер при программировании в терминах коллекций, а не циклов - работает так же, по классам ситуаций. Естественно, в посте я писал по диагонали, без подробностей и шагов - которые интересны только в контексте конкретного бизнес-процесса. Но кванты работы с точки зрения человека и бизнес-области - именно такие, как я написал. Конечно, формлаьно можно придумать за человека жесткий алгоритм, по которому он якобы работает, но реально он работает не так, а параллельно и сложно. Тут, кстати, полная аналогия с процессом проектирования: есть умозрительная методика последовательных шагов и есть реальная жизнь со свободными переключениями. ПО должно поддерживать реальную жизнь.