Одушевленные системы и неодушевленные пользователи
#мысливслух #кейс #agile

Субботний опрос я затеяла, чтобы обратить внимание на пару моментов в работе с пользовательскими историями. Как и обещала делюсь мыслями.

📍Я предложила для уже сформулированного свойства решения определить, кто в нем может быть заинтересован и для чего. Получилось, что к следствию нужно придумать причины. На практике это случается, хотя по сути не выглядит нормальным порядком вещей. Обычно именно в таких случаях получаются формулировки с одушевлением систем «Я, как Система хочу, чтобы пользователь указывал логин и пароль, чтобы правильно логировать действия пользователя» или формулировки, где пользователю присваивается неестественное поведение «Я, как пользователь хочу войти в Систему, чтобы быстрее перейти к бронированию». Если человек действительно хочет скорее перейти к бронированию, то ввод логина и пароля будет восприниматься как помеха, а не как ожидаемая функция.

📍Как любые другие нефункциональные требования, требования к авторизации относятся к системе в целом. При реализации большинства историй будет важно учесть, что заявленный «кто» должен быть авторизованным пользователем. Получается, что общие характеристики системы так или иначе должны учитываться в критериях приемки любой истории или любая история должна наследоваться от нефункциональной...Может получиться громоздкая и неочевидная структура.
Прежде чем формулировать нефункциональное требование в формате истории я бы посоветовала подумать как эта история будет использоваться командой? Формат отдельной истории для требования к авторизации полезен, только если действительно нужен вашей команде как элемент бэклога. Иначе такое требование лучше не маскировать под историю, а фиксировать вместе с другими нефункциональными требованиями короткой фразой. Например, «Доступ к функциям должен предоставляться на основании ролей пользователей и схемы разграничения прав доступа между ними». Будет достаточно сослаться на это требование из других историй и задач, где необходимо.

Возвращаясь к субботнему опросу скажу так… На мой взгляд, лучше всего показывают контекст требования истории вида «Я, как пользователь хочу иметь Личный кабинет, чтобы хранить данные для автоматического заполнения полей при бронировании» и «Я, как специалист по кибербезопасности хочу знать, кто имеет доступ к бронированию и перс.данным». При этом с точки зрения планирования разработки эти истории слишком крупные и их придется разбивать на более конкретные. Так что подумайте как такой формат будет работать именно в вашей команде?