Мы пытаемся внедрить некоторые гибкие/бережливые методы в нашей разработке программного обеспечения, и одна вещь, которую я прочитал, - это не поддерживать длинный «список пожеланий», а поддерживать продукт отставание как можно короче с подробными примечаниями только о вещах, расположенных в верхней части списка. Я могу ясно понять причины этого.Гибкая разработка и «список пожеланий»
Однако часто у нас будет случай, когда клиент тестера обнаруживает непонятную проблему или кромку. Обычно мы проводим какое-то исследование, чтобы найти точный источник проблемы, чтобы мы знали, насколько это серьезно (например, может ли это повлиять на другие случаи?) И часто рассматривают, как мы будем его решать и/или какие обходные пути доступны. В некоторых случаях мы не сталкиваемся с фактическим исправлением, потому что считаем, что в то время стоимость/выгода не стоит того, но я все же хочу записать результаты наших исследований, чтобы, если проблема повторится в будущем, легко понять его и увидеть, какие обходные пути мы использовали, и потому что мы можем решить, что стоит его исправить.
На данный момент мы создаем билет на джару со специальной категорией «список желаний» для чего-то подобного. Есть ли более гибкий подход, который мы должны использовать?
Просто положите его на отставание и установите состояние «не исправлять или отклонять» с комментарием, объясняющим, почему. Вы всегда можете вернуть его обратно на задний план, повторно открыв билет. Это дает понять, что в ближайшее время он не подходит для оценки. – jessehouwing