Заказчик требует ТЗ по ГОСТ 34, а команда работает по Scrum с user stories
Корпоративный заказчик принимает работу по формальному комплекту документов: ТЗ и ЧТЗ по ГОСТ 34, программа и методика испытаний. Внутри команда работает спринтами: бэклог из user stories с критериями приёмки, груминги, демо каждые две недели.
Как выстроить работу с требованиями, чтобы не сорвать ни приёмку, ни разработку?
- Заменить ГОСТ-документы на Confluence-страницы с требованиями и убедить заказчика, что для приёмки достаточно ссылок на актуальные статьи
- Держать оба контура: ТЗ/ЧТЗ как согласованный с заказчиком контур обязательств, user stories как единицу работы спринта, связав их трассировкой «пункт ТЗ → история → тест-кейс ПМИ»
- Вести разработку по user stories, а ТЗ по ГОСТ написать в конце проекта на основе реализованной системы — так документ точно совпадёт с фактом, и не придётся тратить время на согласование правок по ходу проекта
- Отказаться от user stories и вести разработку прямо по разделам ТЗ: два параллельных описания требований всегда рассинхронизируются