Какова цель предложения «так» в определении пользовательской истории?

Пользовательская история может быть определена в предложении как:

As a <type of user> I want <some goal> so that <some reason>

Просто Google для «формулы пользовательской истории» и первые ссылки предлагают эту формулу.

У меня вопрос, какова цель этого пункта? Это для менеджеров? Возможно ли, чтобы руководители проектов и заинтересованные стороны могли лучше понять приоритет этого вопроса? Почему это там?

Примечание: я работал с as a <type of user> I want <some goal>формулой, и она работает просто хорошо. Я не заметил никаких проблем в моей работе, реализовав этот формат, который является более кратким.

Цель состоит в том, чтобы избежать ненужной работы, заставляя пользователя / клиента предоставлять солидную, ощутимую деловую выгоду в качестве причины существования этой функции.

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

Однако, как правило, легко определить эти функции, потому что люди, предлагающие их, как правило, будут испытывать трудности с предоставлением убедительной деловой причины для них.

Существует методика, называемая Popping The Why Stack , где вы берете часть «так что» и спрашиваете «Почему?», Затем вы берете этот ответ и спрашиваете «Почему?» опять рекурсивно. Если после (скажем) трех-пяти «почему» вы не пришли ни к «потому что это принесет нам деньги», ни «потому что это сэкономит нам деньги» (желательно с точным описанием того, как именно произойдет), тогда эта функция не стоит реализовывать.

Некоторые люди считают это настолько важным, что фактически ставят его на первое место в шаблоне истории:

Чтобы [...]

Как [...]

Я бы хотел [...]

Вот замечательный пример из выступления некоторых людей из Thoughtworks: один из их клиентов хотел, чтобы печатные отчеты были отформатированы очень своеобразно. Когда консультант спросил «Почему», они ответили, что таким образом их легче ввести обратно. Поэтому вместо реализации функции форматирования отчетов они просто передали отчеты по сети. Без пункта «так, что» они все равно будут печатать эти документы в одном отделе, отправлять их по почте в другой отдел и печатать их обратно.

«Так, что» обеспечивает причину для цели.

Например, цель может состоять в том, чтобы отобразить показатели продаж за последний месяц. Вы можете работать с этим, но одна из причин, по которой вам нужно знать, почему вы хотите отображать их, чтобы вы могли выполнить более глубокие требования. Что они хотят делать с показателями продаж или перспективами? Знание этой информации даст вам более глубокое понимание приложения и больше шансов на разработку пользовательского интерфейса, который позволит клиенту делать то, что он хочет.

Другая причина использования - расставить приоритеты в истории. Если у вас есть две истории:

Я хочу показать показатели продаж за прошлый месяц.
Я хочу отобразить список перспектив.

но есть только ресурсы, чтобы сделать один - какой вы делаете? Без причины, о которой вы только догадались бы, и вы не могли бы доставить правильную вовремя. Хотя это менее важно, так как клиент должен сказать вам, что делать в первую очередь, но иногда это не так.

В дополнение к сказанному, обоснование требований позволяет судить об обоснованности требований. Пользователь может хотеть вещи по неправильной причине. Наличие «так, что» проясняет причину, следовательно, позволяет аналитику проверить, что запрос наилучшим образом удовлетворяется таким способом.

Пример:

ИИ хочет иметь возможность выбирать сотрудников из списка всех сотрудников компании

BI хочет иметь возможность выбирать сотрудников из списка всех сотрудников компании, чтобы я мог удалить тех, кто покинул компанию 5 лет назад.

(B) не имеет смысла даже в организации среднего уровня, но вы можете проверить требования пользователя и предложить клиенту другой способ выполнить требование.