Agile: технические требования и User Story: как оформить задачу рефакторинга?

Question

[Александр]

Используем в команде TFS 2015 хотим перейти с процесса Scrum на Agile и возник вопрос, как быть с внутренними задачами разработки, типа рефакторинга кода, изменение технологии развёртывания, и т.п. User Story подразумевают формирование требований в отношении функционала, адресованного конечному пользователю продукта, и история вида "Как разработчик Я должен провести рефакторинг кода для того чтобы облегчить разработку новых фич" считаются плохими историями.
Нужно запланировать или учесть уже исполняемую работу в системе, но не понятно, как её правильно оформить, как быть и что делать?

Answer 1

[Андрей Плетенев]

Не знаю, что ты имеешь в виду под переходом cо Scrum на Agile, посколько Scrum - это управленческий framework в рамках Agile подхода.
По существу вопроса: Все, что в перспективе экономит время разработчиков (рефакторинг, оптимизация, документирование кода, настройка инфраструктуры и т.п.) - это технические истории. Их тоже необходимо включать в бэклог и спринты.
Вот некоторые из способов, как это делать:
a) Сделать из них обычные истории, найдя преимущества для заказчика
b) "Продать" их ожидаемый результат продакт овнеру, как повышение фокус-фактора
с) Дополнять ими спринты, в которых идет опережение срока
d) Договориться о том, что максимальное количество незакрытых технических историй должно быть фиксированным и верхние по приоритету - всегда попадают в спринт наряду с обычными историями.