Моя команда использует scrum и TFS для управления новым программным проектом. Некоторые члены команды хотят решить проблему довольно необычным способом. Мне нужно знать, сталкивался ли кто-нибудь с чем-то подобным. (Отчасти это вопрос о разборках / проектах и отчасти TFS, потому что, если TFS сделает один подход намного проще, чем другой, это повлияет на решение.)
Существуют части этой программной системы, которые еще не были определены каким-либо образом - не через пользовательские истории, критерии приемки, тесты или что-либо еще. В некоторой степени это «угловые случаи» или случаи обработки ошибок. Тем не менее, программное обеспечение уже ведет себя определенным образом, когда встречаются эти случаи. (Это может быть вызвано отображением общего сообщения об ошибке или переходом по общему пути к некоторому разрешению.) Такая ситуация существует, поскольку программное обеспечение разработано так, чтобы быть устойчивым к ошибкам.
Члены команды хотят определить и тем самым заблокировать неуказанное поведение, чтобы оно не изменилось. Если оно меняется - и, в частности, если оно меняется в худшую сторону (например, сбой вместо отображения общего сообщения об ошибке), они хотят это уловить.
Но они предлагают сделать это, написав тесты или критерии приемки, которые соответствуют тому, что система уже делает в угловых случаях. Моя позиция заключается в том, что любое неуказанное в настоящее время поведение, которое мы хотим сохранить стабильным, должно сначала определяться с помощью новых пользовательских историй, а не с помощью критериев принятия или тестов. Как правильно использовать scrum / TFS для документирования и блокирования пока еще не определенного поведения в существующем программном обеспечении (желательно с минимальными усилиями)?