Qual è la terminologia standard per lo scenario della scogliera iterativa agile?

Il termine ingorgo sembra appropriato. Ricorda che l'ho appena inventato, non è un termine ampiamente accettato per la situazione che descrivi.

Continui ad aggiungere correzioni rapide e sporche legate allo scenario fino a raggiungere uno stato che non consente un'altra correzione rapida senza rompere qualcos'altro. Quindi non c'è più la possibilità di fare una mossa semplicemente modificando qualcosa, devi separare tutto e ricominciare da capo.

Io chiamo la metodologia che porta a questa situazione "correndo verso l'uscita". Nessuna analisi viene eseguita, nulla viene modellato, i problemi vengono affrontati ad hoc, uno alla volta, finché non smettono di entrare. Se non smettono di entrare prima dell'arresto, hai un problema costoso.

Come ha sottolineato Frank, questo non è equivalente all'agile. Agile non significa stupido, pigro o spericolato. Agile è solo un modo formalizzato per non lasciare formalismi / overhead al tuo progetto. Se fatto correttamente, riduce anche il rischio di blocco tecnico.

Non ho mai sentito parlare di quel termine, probabilmente perché non ha molto senso - nella mia esperienza non c'è un punto critico. È una cosa graduale.

L'unico vero punto di svolta si verifica quando ti rendi conto che esiste un debito tecnico e devi liberartene. A quel punto la produttività diminuirà in modo massiccio, perché allo stesso tempo è necessario ridefinire il software, riqualificare i tecnici del software e adottare un approccio più misurato quando si lavora su nuovi progetti.

Se quella realizzazione non avviene, l'intera faccenda viene solitamente definita una marcia della morte , ma si tratta di un termine piuttosto generico che comprende vari tipi di insuccessi, non solo il debito tecnico. Descrive una società / progetto / software fallito in cui i responsabili devono ancora rendersi conto di aver fallito, e in generale prova a usare gli stessi metodi per salvarlo, che hanno usato per farlo funzionare nel terreno.

Sembra una marcia della morte con la metodologia dei difetti infiniti .

Joel lo spiega qui come questo

The very first version of Microsoft Word for Windows was considered a "death march" project. It took forever. It kept slipping. The whole team was working ridiculous hours, the project was delayed again, and again, and again, and the stress was incredible. When the dang thing finally shipped, years late, Microsoft sent the whole team off to Cancun for a vacation, then sat down for some serious soul-searching.

What they realized was that the project managers had been so insistent on keeping to the "schedule" that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote "return 12;" and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as "infinite defects methodology".

Non è un nuovo concetto. Questo era molto prima del " manifesto agile " o di qualsiasi altro gergo newfangled degli anni 2000. (You Dang Kids Get Off My Mywn.)

Il termine generico è una cattiva ingegneria del software. Non ha davvero nulla a che fare con l'agile o qualsiasi altra metodologia. Puoi creare questo problema con qualsiasi metodologia.

Ho messo questa risposta qui come una contro al termine "debito tecnico". Non mi piace quel termine perché implica che il "debito" (vale a dire un design scadente) è inevitabile.