TL; DR
Scrum не требует использования пользовательских историй; они просто полезная гибкая практика. Хотя владелец продукта может использовать технические спецификации вместо пользовательских историй для создания журнала невыполненных работ по продукту, большинство других проблем вашего процесса связаны с неспособностью использовать эффективные методы Scrum и Agile.
Различные проблемы с вашим процессом
Ваш Скрам, кажется, сломан различными способами, включая:
- В ваших спецификациях отсутствует четкая точка зрения или ценностное предложение.
- Ваши позиции в бэклоге не привязаны к целям спринта.
- Ваш процесс устранения отставания либо полностью отсутствует, либо не может создать всплески истории для журнала невыполненных работ.
- В процессе планирования Sprint не выполняется адекватная декомпозиция элементов журнала невыполненных работ продуктов в элементы журнала незавершенного производства.
- Ваша команда неправильно учитывает неопределенность в отношении элементов невыполненных работ в своих оценках планирования спринта.
- Ваша команда не соблюдает основы тайм-бокса или целостности спринта.
Хотя Scrum не всегда подходит для каждого проекта, в этом случае было бы точнее сказать, что Scrum не работает, потому что команда на самом деле не делает Scrum. Ваш вопрос о пользовательских историях - это лишь малая часть общих проблем, с которыми сталкивается ваша команда.
Почему проворные программисты принимают истории пользователей
Технические спецификации - принципиально сломанный способ сообщить о требованиях. Требования, которые не привязаны с точки зрения, не дают никаких полезных рекомендаций для разработчиков. Используя ваши опубликованные примеры:
- Переписать объектный кеш. Почему? Какова цель? Кто получает выгоду? Кто может дать разъяснения по поводу задачи? Если это связано с нефункциональным требованием, к какой цели проекта это относится?
- Внедрить систему ведения журнала. Почему? Кто будет читать журналы? Какую информацию должны содержать журналы? Как вы узнаете, полезны ли формат журнала или данные журнала?
С точки зрения разработчика, неспособность ответить на подобные вопросы приводит именно к тем проблемам процессов, которые вы описываете. Это то, что делают пользовательские истории: они предоставляют крайне необходимый контекст и выступают в качестве заполнителей для дополнительных бесед с заинтересованными сторонами или конечными пользователями о конкретных функциях.
Вы не должны использовать пользовательские истории, потому что вы думаете, что это базовое требование, или потому что это широко распространенная гибкая практика. Вместо этого вам следует поработать над их созданием и эффективным использованием, поскольку это облегчает программирование и делает программирование более увлекательным. Конечно, ваш пробег может отличаться.