Конечно, требование должно быть полезным, должно приносить какую-то ценность нашей системе в целом.
История должна быть оцениваемой, то есть измеримой как в количестве, так и в качестве, или и в том, и в другом.
Она должна быть очень компактной, явно это не пользовательская история длинной в спринт или больше. История должна быть относительно маленькой, чтобы поместиться в спринт, и чтобы она не занимала все время разработчика.
История должна быть тестируемой.
Что делать потом с пользовательскими историями?
С этим уже работают непосредственно разработчики. Они переносят истории на канбан-доску, где набирают задачи в спринт по объему и по приоритетам.
Чтобы историями было удобно управлять, администратор должен регламентировать работу с пользовательскими историями. Это значит, что вы должны прописать следующие три совершенно фундаментальные важные вещи, а все остальное на ваше усмотрение:
Первое – форма пользовательской истории. Эта форма будет в каком-то документе, в Trello или в другом формате.
Второе – легенда, то есть как расставляется приоритет, как определяется размер, в каких единицах и так далее. Это очень важная вещь.
Третье – должно быть описано, каким образом заполняется пользовательская история и как она поступает в разработку. Допустим, от заказчика приходит запрос на изменение от администратора. Ему отправляется форма пользовательской истории, заказчик заполняет её, и пользовательская история возвращается к администратору. Администратор проверяет её на наличие всех необходимых данных и отправляет разработчику с запросом на обратную связь – принимает ли он эту пользовательскую историю или нет. Если разработчик не принимает историю, он должен предоставить четкие комментарии. Администратор, в свою очередь, должен отправить эти комментарии заказчику.
Совершенно точно должна быть указана роль пользователя.
Для администратора это важно, так как вы будете знать, к кому обратиться за уточнениями, и кто будет работать с приемкой результата. Для разработчика важно понимать, кто будет выполнять определенные задачи в этой системе. От роли пользователя может зависеть упрощенная система реализации требований; разработчики могут предложить альтернативные варианты, такие как список ограничений для разных уровней пользователей.
Например, если линейный специалист работает в системе и формирует запрос на изменение, которое откроет ему доступ к данным других филиалов, то разработчики могут увидеть, что у его роли есть ограничение на получение информации о других филиалах, и они не смогут принять эту пользовательскую историю, хотя запрос был верным. То есть в этом случае вопрос должен быть решен на более высоком уровне – на уровне руководства – чтобы определить, открываем ли мы информацию линейным специалистам или нет.
Желательно