Читать книгу Молекулярное управление: периодическая система проектных элементов. Свод инструментов проектного управления для создания гибридного подхода на предприятиях онлайн

Она должна быть очень компактной, явно это не пользовательская история длинной в спринт или больше. История должна быть относительно маленькой, чтобы поместиться в спринт, и чтобы она не занимала все время разработчика.

История должна быть тестируемой.

Что делать потом с пользовательскими историями?

С этим уже работают непосредственно разработчики. Они переносят истории на канбан-доску, где набирают задачи в спринт по объему и по приоритетам.

Чтобы историями было удобно управлять, администратор должен регламентировать работу с пользовательскими историями. Это значит, что вы должны прописать следующие три совершенно фундаментальные важные вещи, а все остальное на ваше усмотрение:

форма пользовательской истории

легенда

каким образом заполняется пользовательская история и как она поступает в разработку

Совершенно точно должна быть указана роль пользователя.

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

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

Желательно проверять, чтобы были указаны возможность и желание, не просто история «Я хочу», а «Я хочу, чтобы у меня была возможность». Такая формулировка помогает более точно и конкретно обозначить требования.

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