А как хранятся требования к продукту, если ТЗ суть зло и заводить задачи скучно? Вот начинаем мы делать фичу №73 через год, а она, вроде, косвенно начинает влиять на фичу №14 сделанную где-то на старте. Как это разрулить без чётко прописанного требования? Собрались обсуждать и сообразить как эти фичи должны работать вместе, но вот помнят все первую фичу по разному, ибо её потом ещё патчили пару раз и дорабатывали... как тут быть?
Не подумайте, вопрос не из разряда докопаться, правда интересно как при таком быстром и легком старте решаются такие вот проблемы потом.
Тесты могут лишь показать что уже сломалось, после разработки фичи. Но они не могут подсказать что сломается когда мы сделаем фичу такую-то.
Грубый пример - есть некоторая сущность, которая заполняется из четырёх разных мест. Вот такой у нас сложный продукт, когда под разным соусом разные пользователи видят почти одно. Делаем некоторую фичу, расширяя нашу модель(и) данных. Три формы обновили под эти данные, а четвёртую - не вспомнили. Т.к. речь только о расширении данных, то тесты скорее всего не упадут... и четвертую забытую форму мы найдём спустя какое-то время.
В классическом подходе подразумевается, что у нас остается некая документация, которая как-то сводит вещи воедино. Что-то вроде описания "модель данных Х используется для .... форм для заполнения 4. Вот список кому где и как они доступны:..."
Правильно ли я понимаю, что в вашем подходе никто и не будет браться фичу реализовывать сразу, сначала нужно код посмотреть, понять что как на что повлияет, потыкать интерфейс, и потом уже планируется разработка?
Грубо говоря, тратим время не на описание того, что только что сделали, а на обновление сведений в тот момент, когда они реально требуются?