Sarei esitante a scartare Waterfall su tutta la linea così in fretta.
Sebbene sia un modello imperfetto per la costruzione di sistemi software, non è un cattivo modello di insegnamento istruire sulle buone pratiche per ogni fase del ciclo di vita. Indipendentemente dal modello di processo che si applica al progetto, si eseguono comunque ingegneria dei requisiti, architettura e progettazione del sistema, implementazione, test, rilascio e manutenzione (inclusi refactoring e miglioramento). La differenza sta nel modo in cui queste fasi sono organizzate e condotte, ma tutte le attività continuano.
Direi che il tuo passaggio da Waterfall a Scrum nel mezzo del progetto non è la migliore idea. Una chiave per il successo di Scrum è un progetto di lunga durata. I primi tre o cinque sprint sono la squadra che si insedia in velocità, apprendendo il processo e attraversando lo sviluppo della squadra. Anche se stai facendo i movimenti, non è proprio Scrum a quel punto. Inoltre, cercare di creare un curriculum basato esclusivamente su Scrum è probabilmente una cattiva idea come Scrum come non un proiettile d'argento: è meglio insegnare le migliori pratiche piuttosto che una singola metodologia. Nella forza lavoro, non tutti i progetti useranno Scrum. In effetti, in alcuni ambienti, Scrum sarebbe dannoso per il successo del progetto.
Hai già riscontrato problemi con Scrum in ambito accademico e alcuni di essi sono difficili da affrontare in modo adeguato.
Il non problema nel tuo elenco di incompatibilità è che la stima è difficile. Sì. Ma l'unico modo per migliorare la stima è stimare e confrontare gli effettivi con le stime. Gli studenti dovrebbero stimare le dimensioni, il tempo e lo sforzo usando vari mezzi (punti della trama, linee di codice sorgente, ore, pagine, ore di persona) in anticipo in modo che siano più preparati a farlo dopo essersi laureati ed entrare nella forza lavoro.
La necessità di documentazione è qualcosa che può essere affrontata sia dal punto di vista del professore che dal punto di vista degli studenti. Gli approcci Lean ci dicono che la documentazione che non aggiunge valore al team o al cliente è dispendiosa (in termini di tempo e costi). Tuttavia, è necessaria della documentazione per raggiungere alcuni obiettivi sia degli studenti che del professore (il cliente / cliente) per vari scopi. Nel complesso, sembra un'opportunità per insegnare l'adattamento dei processi e la gestione quantitativa del progetto (che ha un ruolo anche nei metodi agili).
Per quanto riguarda le riunioni e la programmazione Scrum, mi vengono in mente due idee. Il primo è che questo indica che Scrum potrebbe non essere il miglior processo da utilizzare in un ambiente accademico. Non esiste un "miglior modello di processo" singolare per i progetti software, con fattori quali pianificazione, personale, visibilità ed esperienza del team di sviluppo (tra gli altri).
Nel complesso, suggerirei di enfatizzare le buone pratiche, l'adattamento dei processi e il miglioramento dei processi rispetto a singole metodologie. Ciò ti consentirà di essere il più efficace per tutti i partecipanti ai corsi, esponendoli a una varietà di metodologie di processo e comprendendo quali sono le migliori pratiche per un determinato insieme di condizioni.
Dal momento che si sta lavorando per costruire un curriculum universitario, darò una panoramica di alto livello su come l'ingegneria del software curriculum presso l' università ho partecipato insieme in forma.
Si trattava di un'ingegneria software introduttiva che ha attraversato il progetto in un modello a cascata, con le lezioni durante ogni fase corrispondenti a diversi modi di condurre le attività di quella fase. I team hanno progredito attraverso le fasi allo stesso ritmo. Far sì che quei confini chiaramente definiti si adattino bene al modello di insegnamento per un gruppo di persone che non hanno esperienza minima di lavoro sui team per costruire software. Durante il corso, sono stati fatti riferimenti ad altre metodologie - vari metodi agili (Scrum, XP), Rational Unified Process, Spiral Model - per quanto riguarda i loro vantaggi e svantaggi.
In termini di attività, ci sono stati corsi specifici per discutere di ingegneria dei requisiti, architettura e design (due corsi - uno incentrato sulla progettazione dettagliata utilizzando metodi orientati agli oggetti e uno incentrato sull'architettura di sistema), un numero di corsi incentrati sulla progettazione e l'implementazione di vari classi di sistemi (sistemi integrati e in tempo reale, sistemi aziendali, sistemi concorrenti, sistemi distribuiti e così via) e test del software.
Ci sono anche tre corsi dedicati al processo software. Processo di ingegneria del software e Project Management che si concentra sulle migliori pratiche per la gestione di un progetto software rispetto a più metodologie. Un secondo corso di processo insegna misurazioni, metriche e miglioramento del processo (enfatizzando CMMI, Six Sigma e Lean). Infine, c'è un corso di processo che insegna lo sviluppo di software agile (Scrum, Extreme Programming, Crystal, DSDM discussi) usando un progetto realizzato usando la metodologia Scrum.
Il progetto capstone era un progetto di due quarti che è stato eseguito per una società sponsor e gestito interamente dal team di progetto degli studenti, con la guida di entrambi gli sponsor e un consulente di facoltà. Ogni aspetto di come condurre il progetto spetta agli studenti, entro i limiti stabiliti dagli sponsor. Le uniche scadenze obbligatorie per l'università erano una presentazione intermedia a metà strada (10 settimane) nel progetto, una presentazione finale alla fine e una presentazione a quadretti poco prima della fine. Tutto il resto spettava allo sponsor e al team di accettare.