È 'processo di debito' un termine con cui le persone lavorano

Spero di aver interpretato correttamente la cosa, chiamerei questo debito tecnico. Il software consiste in più di un semplice codice sorgente. La fonte è probabilmente inferiore al 10% e non più del 20% dello sforzo di SDLC (almeno a livello commerciale). Se non è possibile costruire e distribuire il codice sorgente in modo affidabile e semplice, causando problemi e costi in pista, non è diverso dal codice sorgente che è difficile da mantenere, buggato e lento.

Il fatto che tu abbia provato qualcosa di diverso e che non fosse buono come quello che hai lasciato non cambia nulla. Il software è ora in uno stato meno gestibile rispetto a prima, a causa delle tecnologie scelte (VSS vs SVN) - debito tecnico.

Il debito di processo a cui fai riferimento esiste indubbiamente, ma ciò è dovuto al processo che ti porta a fare cose che non sono più necessarie. Ad esempio, se avessi un processo che richiedeva l'esecuzione manuale e il markup di un libro di prova stampato su ogni versione, ma avevi implementato test automatici, sarebbe un debito di processo, poiché è qualcosa che non è più rilevante a causa dei cambiamenti nel modo in cui le cose sono fatti.

Il processo "debito" non può esistere e certamente non può maturare.

Hai un "buco" nel tuo processo in cui la squadra B sta facendo "più" lavoro perché la squadra A sta facendo "meno" lavoro.

Questo non si accumula. È solo uno spostamento del carico di lavoro.

Se qualcosa sta maturando, tra un anno, la squadra B avrà un enorme arretrato di cose da fare. Aspettare. Questo è un arretrato di lavoro tecnico. Ecco cos'è il debito tecnico.

Un "debito di processo" sarebbe un arretrato di passaggi di processo che devono essere eseguiti. Arrivo Partenza? Gli aggiornamenti via email che qualcosa sta per cambiare? È sciocco. E neanche molto agile.

Sembra che tu stia descrivendo muda , spreco dall'ingegneria del software Lean . Ovviamente, vuoi ridurre lo spreco il più possibile ...

Non una risposta alla domanda diretta, ma una per risolvere il problema VSS:

Ho migrato un VSS DB in SVN alcuni anni fa, avevamo pochi file condivisi. È stato orribile. Così ho identificato questi file e trasferito ognuno di essi in una directory "comune" (fortunatamente non avevamo file condivisi da un progetto arbitrario, beh non molti).

Una volta che sono stati collocati in una cartella comune lontano dai progetti, possono essere recuperati e aggiornati utilizzando la funzionalità di estensioni SVN e gli spazi di lavoro del progetto potrebbero essere aggiornati per fare riferimento ai file condivisi nella cartella di file condivisa. Da quel momento in poi, il codice è diventato molto più bello e ci sono state molte meno interruzioni quando è stato modificato 1 file che ha interessato un progetto non correlato.

Il problema qui non è che il tuo software sia più adatto alla versione controllata in VSS rispetto a SVN e il conseguente "debito di processo" come risultato.

Il problema è che il tuo software ha un difetto di progettazione che incoraggia le cattive pratiche e crea molto più lavoro per il team a lungo termine. Questo è essenzialmente debito tecnico non a causa di una cattiva implementazione, ma a causa di una progettazione scadente.

Il difetto di progettazione è che il lavoro sulle funzionalità non può essere suddiviso adeguatamente tra gli sviluppatori senza incorrere in problemi di fusione significativi con una manciata di file che cambiano frequentemente da un numero di persone diverse. Certi framework, naturalmente, si prestano a questi tipi di problemi, Struts (), ASP.NET (web.config) ecc ... tuttavia la fusione su larga scala è stata uno dei punti deboli di SVN. Forse Git o Mercurial potrebbero essere più adatti al tuo progetto e contribuire a mitigare questo problema.