Far fronte a un progetto infinito non risolvibile

Abbiamo un sito Web di grandi dimensioni (oltre 1200 ore) che presenta molti debiti tecnici. Ciò è principalmente causato dai seguenti (soliti) motivi.

1. Più programmatori che vanno e vengono durante lo sviluppo.
2. Modifica delle specifiche durante lo sviluppo.
3. Numerose funzionalità aggiunte (in breve tempo).

Il cliente desidera molte nuove funzionalità, e questo in pratica si riduce a lavorare su questo progetto settimanalmente per oltre 10 ore.

A causa del debito tecnico, passiamo MOLTE ore a risolvere o investigare i problemi, che di solito trovano la loro origine in uno dei seguenti:

1. Un insetto spudorato e sciocco che fa piangere le persone.
2. Una nuova funzionalità si traduce in quanto sopra perché non avevamo previsto tutti i luoghi in cui la nuova funzionalità avrebbe avuto un'influenza.
3. Alcuni altri problemi che abbiamo affrontato (migrazione del server fe, aggiornamenti)

Abbiamo problemi quotidianamente e abbiamo cercato di seguire le cose per fermare questo:

1. Creazione della documentazione tecnica relativa all'importazione, al pagamento e al funzionamento generale del sito Web.
2. Riunione all'inizio della settimana per discutere delle questioni o dei miglioramenti attuali e di come affrontarli.
3. Avere un piano di test. Test programmatore A test B, B test C e C A. Quindi il nostro Project Manager eseguirà alcuni test. Per quanto riguarda l'impatto della funzione, la gettiamo in un ambiente di gestione temporanea e lasciamo che il cliente controlli da solo.

Il problema è che i problemi continuano a verificarsi ... e in qualche modo non riusciamo a controllarlo. Le nuove funzionalità causano ancora bug e i vecchi bug continuano a salutare. In qualche modo - forse a causa delle dimensioni del progetto - non possiamo avere un'idea di questo progetto.

Presumo che ci siano molti programmatori che lavorano su progetti più grandi di questo. Ecco perché vengo alla mia domanda:

Che cosa possiamo fare, o cosa si fare per evitare questi problemi su progetti di grandi dimensioni?

Modifica minore, informazioni extra:

1. Usiamo il controllo versione (SVN).
2. Abbiamo un processo di sviluppo DTAP.

Interpreterò l'avvocato del diavolo, avendo visto fin troppo spesso come risulta: non puoi farcela. Ti garantisco che sei l'unico che vede effettivamente un vero problema con il sistema così com'è, altrimenti non dovresti chiedere come affrontarlo perché la cultura aziendale sarebbe quella di eliminare i bug e correggere il codice ove possibile, vale a dire come funzionano i veri professionisti.

Scommetto che è troppo grande per iniziare a scrivere unit test, perché non ha avuto nessuno che sappia come testare l'unità prima di te (e per fortuna altre persone nella tua squadra) ed è impossibile sapere da dove cominciare, e forse addirittura impossibile test perché si basa su esatte implementazioni e dati concreti, quindi ci vorrebbe troppo tempo per rimuovere tutto ciò da interfacce, mock, stub e simili per poterlo testare in primo luogo. Scommetto anche che non puoi semplicemente andare a refactoring di ciò che deve essere refactored perché è accoppiato troppo strettamente e, dato che non ci sono test, chissà cosa verrà risolto correggendo il codice errato. In breve, probabilmente è diventato troppo canceroso per risolverlo seriamente, ma ovviamente non può essere semplicemente tagliato e ricominciare da capo.

Stai combattendo una battaglia persa, amico mio. O ti esaurirai per la frustrazione e alla fine lascerai o impazzirai, o se ti lamenti abbastanza a lungo cercando di convincere gli altri a capire i problemi, penseranno che l'unico problema sei tu e ti verrà mostrato la porta.

Le cose di test unitari sono un buon punto di partenza se non le fai. Per lo meno ti proteggeranno dall'aggiunta di nuovi bug durante la correzione di vecchi bug.

Anche il controllo del codice sorgente aiuta, a meno che non lo si stia utilizzando. Le caratteristiche di colpa e registro, in particolare, sono meravigliose per inchiodare come / perché un pezzo di codice difettoso sia mai stato commesso.

Da parte del cliente, ho scoperto che la discussione del prezzo e (lunghi) ritardi non appena vengono richieste modifiche / funzionalità aggiuntive funziona abbastanza bene, così come l'addebito per il tempo impiegato a discuterne / progettarle. Spesso, i clienti decideranno che, ripensandoci, possono aspettare.

(Al contrario, se scavi immediatamente in specifiche e idee di implementazione con lui, in genere ti prepareranno per un "oh, pensavo che avessimo concordato che lo avresti fatto comunque" o (peggio, dopo diversi giorni di ritorno e avanti sui dettagli) "ma guarda, è già progettato e noi ciò di cui abbiamo discusso non sembra così difficile!".)

Ultimo ma non meno importante, ho scoperto che essere in anticipo che leggo e-mail solo una volta al giorno (all'arrivo al lavoro) e che ho un telefono per qualcosa di più urgente, porta a un enorme aumento della produttività.

Ti suggerisco di aggiungere alcuni test basati su CI, principalmente sulle aree che si rompono più frequentemente. Ciò ti aiuterà ad aumentare la qualità mentre si sta lavorando al progetto.

È anche più evidente quali aree / funzionalità si rompono più spesso e quindi è più facile decidere quali parti necessitano di refactoring, o almeno test aumentati.

L'aggiunta di ulteriori rischi per i test manuali comporta che il progetto vada nella direzione sbagliata in termini di $$$ e tempo richiesto per funzionalità aggiunta.

Qualche revisione del codice è buona, ma forse fa parte dello schema di test A-> B-> C->. (Forse la revisione del codice nell'altra direzione?)

Lascia che ti lanci una favola. Prima facevi una passeggiata con una persona in fondo alla strada e raggiungevi la tua destinazione. La persona con cui stai camminando scopre rapidamente che ha perso il suo anello da qualche parte lungo la strada in modo che entrambi decidiate di tornare indietro e andare a cercarlo. La persona con cui stai camminando si ferma rapidamente a un lampione e inizia a guardare freneticamente. Dici "Perché guardi il lampione quando penso che potresti averlo perso quando attraversiamo il vicolo?". Egli risponde: "Lo so, ma la luce è migliore qui".

Sono stato in questa situazione più di un paio di volte e ho notato alcuni punti in comune. Questi tipi di progetti da incubo per la manutenzione vengono in genere eseguiti in un ambiente pesante di processo con una pesante supervisione e miglioramenti del processo imposti dalla direzione. Non sto dicendo che i miglioramenti dei processi siano una cosa negativa, ma il più delle volte i tipi di miglioramenti dei processi che la Direzione vorrà in genere avere due punti chiave.

1) Generalmente non disturbano la politica dell'ufficio e l'equilibrio di potere. 2) Sono riusciti a creare l'illusione del controllo da parte della direzione piuttosto che colpire il cuore della questione.

La gestione della "luce qui è migliore" pensa in genere dicendo: "Ogni nuova funzionalità deve avere una specifica tecnica dettagliata", o "Consente di avere una riunione oraria ogni giorno per discutere di problemi e come risolverli".

Nessuna di queste cose colpisce davvero il cuore dei problemi e potrebbero semplicemente ridurre la produttività, ma certamente convalidano l'illusione del controllo da parte della direzione.

Gli unici veri cambiamenti che puoi aiutare a spingere sarebbero quelli che scuotono le cose. Sospetto però che la tua mostruosità di un sito web sia probabilmente irreparabile a questo punto e che tu saresti ancora più avanti per riprogettare e riscrivere. Per il futuro, tuttavia, è possibile tenere presente l'importanza della metodologia Agile, dell'integrazione continua, dello sviluppo guidato dai test, delle revisioni del codice e delle specifiche dei requisiti aziendali che sono regolate da rigorose procedure di controllo delle modifiche per aiutare a ridurre al minimo lo scorrimento dell'ambito senza adeguamenti della pianificazione.

Questi tipi di cambiamenti richiedono veramente un cambiamento nel modo di pensare a livello di management e in tutta la mia esperienza professionale non ho mai avuto questo fatto senza un tipo di shakeup a livello di middle management. Spero che non sia troppo scoraggiante in quanto dovresti cercare ciò che è giusto, indipendentemente dal fatto che tu stia combattendo una battaglia in salita, perché probabilmente incontrerai una forte resistenza da parte di persone che amano lo status quo.

Sono stato nello stesso posto qualche tempo fa. Non sono più grazie a due semplici regole:

• Ogni settimana vengono trascorsi uno o due giorni per correggere / riscrivere la maggior parte delle parti pelose dell'app. Nessuna ricerca di bug, nessuno sviluppo di nuove funzionalità.
• Durante l'implementazione di nuove funzionalità ci sforziamo di farlo bene anche quando abbiamo trascorso più tempo di quanto i clienti si aspettino.

L'unico problema è convincere altre persone a rispettarle. La parte facile sorprendentemente era il cliente. Non riesco davvero a spiegare perché, ma in qualche modo lo abbiamo convinto che quando lavoriamo su una funzione un po 'più a lungo è meglio per tutti. Il rispetto della prima regola si rivela più problematico, ma riteniamo che ci aiuti molto. Garantisce progressi costanti man mano che le diverse parti dell'applicazione stanno migliorando.

Revisioni del codice. Test unitari. Test di qualità reali. Processo di raccolta delle specifiche e sviluppo incrementale: queste sono alcune cose che dovrebbero risolvere la maggior parte dei problemi.

Inoltre, non lasciare che i clienti eseguano direttamente il ping dei tuoi sviluppatori: questo è di solito il modo più improduttivo di risolvere i problemi. Assumi un buon Program Manager che formerà l'interfaccia tra i tuoi clienti e sviluppatori. Il suo compito sarebbe quello di conoscere il prodotto end to end, lo stato attuale, le direzioni future e così via. Ogni volta che il cliente desidera un'altra nuova funzionalità, dovrebbe essere in grado di fornire l'elenco corrente degli articoli e mostrare ai clienti cosa verrà escluso se questa nuova richiesta deve essere accettata.

Il processo è negativo quando viene utilizzato troppo poco o troppo. Penso che tu sia allo stato precedente.

Come menziona Deni, se sei in grado di aggiungere test unitari al progetto, questo ti aiuterebbe. Avere un test che copre una parte del sistema che si sta per modificare / correggere, quindi quando si utilizza il codice di refactoring, utilizzare quel test come guida per assicurarsi di non interrompere nulla.

Inoltre, triage le parti più rotte del codice. Cerca di mettere le persone più colpite in un elenco di rischi e gestirli in modo indipendente. Prova a farti un'idea della quantità di codice non funzionante presente nella base di codici eseguendo una query su dove si verificano maggiormente i bug. È quindi possibile elencare l'area interessata in base al conteggio dei bug (o ai problemi segnalati, qualunque cosa funzioni per te.).

L'applicazione di patch e la pulizia del codice richiederà tempo, ma se ogni sviluppatore del team può lasciare il codice un po 'più pulito, è stato prima che lo raggiungessero, quindi nel tempo il codebase migliorerà. Se stai cercando uno stile rapido e militare, risolvilo subito, dubito che ci sia qualcosa di pratico (o raccomandato) che possa aiutare.

Saluti. Giac.

Scrivi chiare specifiche funzionali; pedanticamente, quindi se puoi sopportarlo e rivedere regolarmente le funzionalità rispetto a tali specifiche. Meno un'idea ha uno sviluppatore su ciò che si suppone stia sviluppando, minori sono le possibilità che ciò avvenga nel modo in cui dovrebbe svilupparsi.

Prima di iniziare a scrivere codice, esegui alcuni lavori di progettazione; questo non deve essere perfetto, o enorme, o contenere UML, ma dovrebbe delineare una soluzione abbastanza solida al problema che deve essere risolto. Per quanto ne so, meno software è pianificato, peggio è. Discutere il progetto prima di iniziare a lavorarci.

Quando inizi a lavorare su un'area del codice chiaramente negativa e che ostacola realmente i tuoi progressi; smetti di aggiungerlo, fai un passo indietro dal problema, scopri come potresti riprogettare l'architettura in modo che gli ostacoli non esistessero e che in futuro sarebbe più adattabile. Più a lungo lo lasci prima di affrontare il debito tecnico, più sarà difficile affrontarlo senza una riscrittura completa. Direi che è una cosa esponenziale.

Progetta test che testano il comportamento e non si accoppiano strettamente alla tua architettura. Non è molto di moda, ma direi di non iniziare i test fino a quando il vero scopo del tuo codice non sarà chiaro. In particolare, non iniziare i test fino a quando non sai cosa vuoi veramente testare; IMO un test mal pensato è peggio di nessun test. E più test hai, più è difficile cambiare il tuo codice internamente. Tratta il tuo codice di test come faresti con il codice di produzione; deve essere pianificato e ben scritto.

Esegui revisioni periodiche / giornaliere del codice: si tratta più che altro del controllo di integrità per assicurarsi che lo sviluppatore non sia andato troppo lontano. Utilizzare queste sessioni per pianificare i prossimi giorni di lavoro. Ci possono essere giorni in cui questi richiedono 5 minuti o 1 ora; il punto è mantenere un dialogo aperto e dare agli sviluppatori la possibilità di discutere il loro lavoro con altri sviluppatori e chiedere consigli. Effettua alcune sessioni di accoppiamento su parti difficili del codice o per prototipare idee, ma lascia che le persone abbiano il loro tempo per lavorare.

Semplifica la creazione e la distribuzione del codice. Cerca di ridurre i tempi di costruzione. Più facile è costruire, più sarà costruito, più veloce sarà, più sarà costruito.

Adottare standard di codifica e applicarli rigidamente. Questo dovrebbe coprire tutto da dove un progetto dovrebbe vivere nel file system al case di una const privata. Questo può sembrare inutile e fastidioso, ma le buone abitudini sono la pietra angolare di un processo di sviluppo.

Fondamentalmente non penso che il processo che usi sia così importante, le mode vanno e vengono. Ciò che conta davvero è che tu sia professionale su come sviluppi il software e che sei disciplinato nella tua pratica.

Comincerei progettando e automatizzando i test del fumo e gettandoli nell'ambiente CI. Quelli dovrebbero essere funzionali. Quando il cliente ti dice che qualcosa dovrebbe funzionare così e così, chiedi di scriverlo, in modo da poterlo fare riferimento in un secondo momento. Quando vedi una determinata soluzione nel software, fai domande e non appena ricevi le risposte, le incorpori nella knowledge base e le rendi tracciabili.

Assicurati che la funzionalità di base per casi positivi funzioni. Quindi iniziare a costruire test incrementali per la gestione errata dei dati, posizionando i difetti dove ritenuto necessario. Avere una lunga e profonda discussione sulle priorità e farne conoscere al responsabile del test, in modo che possa assegnare i tempi di prova di conseguenza. Non tentare di automatizzare tutto, ma non appena alcuni test hanno senso essere automatizzati, non esitare.

In generale, utilizzare i test per aumentare la fiducia nel prodotto e non come strumento che aumenterà istantaneamente la qualità. Sii calmo, ma deciso :). Forse prova ad andare agile, ma solo se assolutamente, positivamente puoi impegnare un PM certificato. Presentare Agile da una persona che non conosce Agile, molto probabilmente ucciderà il progetto.