Запись пользовательских историй для внутренних технических [закрытых] задач

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

Тем не менее, рекомендуемый шаблон для пользовательских историй на самом деле Как <роль>, я хочу <действие>, чтобы <преимущества> . Я не хочу быть разборчивым, но, если вы решите использовать истории, я настоятельно рекомендую использовать их как есть, без снятия какой-либо части. Во-первых, использование роли действительно помогает (один и тот же пользователь / человек может иметь несколько ролей) для открытия историй. Тогда определение преимуществ действительно важно, чтобы раскрыть ценность истории для бизнеса и правильно расставить приоритеты. Что касается ценности, вы должны думать о ней как о конечном пользователе / ​​покупателе (« наденьте очки покупателя » - Мэри Поппендик). На самом деле не всегда так просто выразить преимущества, но некоторые инструменты могут помочь, и я предпочитаю 5 почему (который используется для анализа первопричин).

В вашем случае это может привести к примерно следующему: ИТ-отдел Я хочу, чтобы база данных была обновлена, чтобы пользователи могли пользоваться новейшими функциями приложения и [делать свою работу лучше | иметь лучший пользовательский опыт] (хотя и не очень удовлетворительно, используйте 5 «почему»).

Но лично я не находите, что пользовательские истории являются лучшим средством для решения технических задач, даже если очевидно возможно их использовать и если у них есть свои сильные стороны. Теоретически рассказы отражают суть, а не детали, и должны поддержать обсуждение. Возможно, я ошибаюсь, но я не считаю, что технические задачи предлагают много места для обсуждения и творчества. Итак, в зависимости от того, кто их прочитает и что они должны передать, я могу их использовать или нет. Другой вариант - смешать истории с другим формализмом для ваших PBI. Как я уже сказал, дело не в том, чтобы использовать истории,

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

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

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

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

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

OTOH , если проект более сложный, это может стать «тегом», например, заметкой, которая должна быть прикреплена ко многим историям. Это означает, что вы должны включить это как «вспомогательную историю» во все истории, которые изменяют базу данных. Как видите, эти «истории, охватывающие весь проект» довольно сложно отследить с помощью гибких методов.