Devo usare mischia per i grandi progetti? [chiuso]

Sembra che tu ti sia sforzato in un processo di sviluppo incontrollato per creare un sistema di sviluppo senza fine. Ciò si verifica anche in sistemi agili.

Il problema alla radice è una mancanza di requisiti, e mentre la soluzione potrebbe sembrare quella di utilizzare una metodologia agile per risolvere il problema (poiché l'agile è progettato attorno ai mutevoli requisiti) non risolverebbe il problema.

Anche i metodi agili richiedono un punto di partenza abbastanza stabile. Rispondono bene ai mutevoli requisiti, ma sono altrettanto inutili quanto qualsiasi altra metodologia se non si iniziano a soddisfare i requisiti. Devi ancora avere un piano verso cui ti stai dirigendo prima di iniziare. Agile aiuta quando l'obiettivo va alla deriva, non ti aiuta a definire quell'obiettivo.

Ora è vero che un design up-front fisso è troppo rigido se non sai esattamente cosa stai costruendo.

Quindi, penso che dovrai passare dall'attuale metodologia del "caos" a qualcosa di più organizzato e dovrai implementare una buona quantità di progettazione e pianificazione. Puoi provare a farlo in una volta con una metodologia pesante, oppure puoi essere più flessibile con uno più agile. Quello che non puoi fare è aspettare che una metodologia risolva la tua mancanza di pianificazione iniziale.

Per inciso, Kanban sembra più adatto alle tue esigenze. Scrum funziona al meglio con piccoli team e progetti. Kanban può lavorare con progetti più grandi, ma funziona anche con un approccio al work-through, quindi i cambiamenti di design sono continui e non sono suddivisi in sprint. Penso che avresti più successo con quello.

18 mesi, 150 tavoli e ancora non in produzione? Mi sembra molto simile a un marcia della morte per me. L'unico modo per risolvere questo problema, se è possibile salvarlo ora, è quello di restringere l'ambito del tuo progetto in modo drammatico, almeno per la tua prima versione di produzione. Ciò di cui hai bisogno è una corretta pianificazione del rilascio, piccoli obiettivi raggiungibili e il sistema per l'utente finale il prima possibile.

E quando hai il tuo primo rilascio in produzione, con solo un decimo dei requisiti implementati, dovrai estenderlo passo dopo passo al prossimo blocco di requisiti, che causerà il "refactoring". Riceverai anche un feedback, che significa correzione dei bug e requisiti modificati, che causeranno anche il refactoring.

A questo punto - Scrum ti aiuterà? Forse sì forse no. Scrum è uno strumento per supportare lo sviluppo iterativo e le mutevoli esigenze, e concentrarsi innanzitutto sulle cose importanti. Altri metodi "Agili" fanno anche questo, e un processo non così formalizzato potrebbe gestire anche questo. Ma finché si cerca di portare in produzione un mostro come questo in un "big bang", non importa se si utilizza lo sviluppo "agile" o "upfront", entrambi falliranno.

Quindi, prima di pensare a Scrum, ripensare prima i tuoi obiettivi e la tua strategia di rilascio, e quindi controllare se Scrum è lo strumento giusto per questo, non viceversa.

Se non riesci a gestire i requisiti e non hai persone in grado di implementare correttamente i requisiti, SCRUM non ti aiuterà (molto) e questo sembra essere il vero problema che stai affrontando.
SCRUM può aiutarti a gestire meglio i requisiti in evoluzione rispetto a più sistemi di gestione dei progetti statici, ma non è il Santo Graal che magicamente farà funzionare tutto. Infatti, a meno che la tua gente non sia a bordo, disponibile e capace di lavorare con SCRUM, e così anche il resto dell'organizzazione, potrebbe finire per peggiorare le cose.

Se hai un tavolo che è cresciuto così tanto da adattarsi a cose da collegare ad altri sistemi, ho postulato che la progettazione del tuo database sia seriamente imperfetta ad esempio. Nessuna quantità di SCRUM migliorerà la progettazione del tuo database senza che tu includa persone che sono brave nella progettazione di database nel tuo team e che non temano quelle modifiche di progettazione e le modifiche che causeranno al resto del tuo sistema.

Si noti che quando ho scritto questa risposta, non mi ero reso conto che il sistema non era ancora in produzione.

Per come descrivi il tuo prodotto, non penso che il tuo problema immediato sia quello della gestione dei requisiti, né del tuo processo di sviluppo. È quello della tua architettura di sistema.

Sei riuscito a creare un monolite - e uno piuttosto grande a questo. 150 tabelle sono molte per un sistema *. In particolare, dici che hai 40 campi nuovi negli ultimi 15 mesi solo per l'integrazione con sistemi esterni. Prenderò seriamente in considerazione la possibilità di dividere il tuo sistema in diversi servizi autonomi, probabilmente a partire da servizi di integrazione con sistemi esterni, ma in seguito identificare le aree di business separate implementate nel tuo monolite e quindi dividere queste preoccupazioni in servizi separati.

Se riesci a suddividere questo monolito in basi di codice gestibili separate, puoi anche dividere i tuoi sviluppatori in team più piccoli con responsabilità ben definite in aree specifiche della tua attività, e puoi avere un sacco di team agili più piccoli che mantengono il loro codice di base, invece di tutti gli hacker nella stessa base di codice.

Per quanto riguarda il motivo per cui sei arrivato a una tale architettura, la causa principale del tuo problema, ci possono essere molte risposte. Forse è radicato nel tuo processo di sviluppo, forse tutti i tuoi sviluppatori hanno esperienza solo con software transazionale coerente, o forse è una conseguenza di come è strutturata la tua organizzazione (sei vittima di Conway's Law ). Penso che ci siano buone possibilità che sia una combinazione di questi ultimi due.

Non credo che l'implementazione della mischia, o la migliore gestione dei requisiti, possa aiutare a risolvere il tuo problema immediato, né la causa principale. La regolazione dell'architettura per la complessità del tuo sistema e l'eliminazione della causa principale del motivo per cui è stato creato un sistema di questo tipo.

* Alcuni probabilmente sosterranno di poter mantenere un sistema con 150 tabelle - o hanno mantenuto sistemi molto più grandi, ma credo che la maggior parte degli sviluppatori considererà questo un numero elevato di tabelle per un sistema.