Ich würde zögern, Waterfall so schnell auf der ganzen Linie zu verwerfen.
Obwohl es sich um ein fehlerhaftes Modell für die eigentliche Erstellung von Softwaresystemen handelt, ist es kein schlechtes Lehrmodell, in jeder Phase des Lebenszyklus bewährte Vorgehensweisen zu vermitteln. Unabhängig vom Prozessmodell, das Sie auf das Projekt anwenden, führen Sie weiterhin Anforderungsengineering, Systemarchitektur und -design, Implementierung, Test, Freigabe und Wartung (einschließlich Refactoring und Erweiterung) durch. Der Unterschied besteht darin, wie diese Phasen organisiert und durchgeführt werden, aber alle Aktivitäten finden immer noch statt.
Ich würde argumentieren, dass Ihr Übergang von Waterfall zu Scrum in der Mitte des Projekts nicht die beste Idee ist. Ein Schlüssel zum Erfolg von Scrum ist ein langjähriges Projekt. Die ersten drei bis fünf Sprints bestehen darin, dass sich das Team auf eine Geschwindigkeit einstellt, den Prozess lernt und die Teamentwicklung durchläuft. Obwohl Sie die Bewegungen durcharbeiten, ist es zu diesem Zeitpunkt nicht wirklich Scrum. Darüber hinaus ist der Versuch, ein ausschließlich auf Scrum basierendes Curriculum zu erstellen, wahrscheinlich eine schlechte Idee, da Scrum kein Königsweg ist - es ist besser, Best Practices zu vermitteln, als eine einzelne Methodik. In der Belegschaft werden nicht alle Projekte Scrum verwenden. Tatsächlich würde Scrum in einigen Umgebungen den Erfolg des Projekts beeinträchtigen.
Sie haben bereits Probleme mit Scrum in einem akademischen Umfeld festgestellt, und einige davon sind nur schwer angemessen anzugehen.
In Ihrer Liste der Inkompatibilitäten steht außer Frage, dass das Abschätzen schwierig ist. Ja ist es. Die einzige Möglichkeit, die Schätzung zu verbessern, besteht darin, die tatsächlichen Werte zu schätzen und mit den Schätzungen zu vergleichen. Die Schüler sollten Größe, Zeit und Aufwand mit verschiedenen Mitteln (Handlungsstränge, Quellcode, Stunden, Seiten, Personenstunden) frühzeitig abschätzen, um nach Abschluss und Eintritt in die Belegschaft besser darauf vorbereitet zu sein.
Der Dokumentationsbedarf kann sowohl aus Sicht des Professors als auch aus Sicht der Studierenden angegangen werden. Die Lean-Ansätze verdeutlichen, dass Dokumentation, die weder für das Team noch für den Kunden von Nutzen ist, zeit- und kostenaufwändig ist. Es sind jedoch einige Unterlagen erforderlich, um einige Ziele sowohl der Studenten als auch des Professors (des Kunden / Kunden) für verschiedene Zwecke zu erreichen. Insgesamt scheint es eine Gelegenheit zu sein, Prozess-Tailoring und quantitatives Projektmanagement zu unterrichten (was auch bei agilen Methoden eine Rolle spielt).
In Bezug auf Scrum-Meetings und -Planungen fallen mir zwei Ideen ein. Das erste ist, dass dies darauf hinweist, dass Scrum möglicherweise nicht der beste Prozess für eine akademische Umgebung ist. Es gibt kein einzigartiges "bestes Prozessmodell" für Softwareprojekte, mit Faktoren wie Zeitplan, Personalausstattung, Sichtbarkeit und Erfahrung des Entwicklungsteams (unter anderem).
Insgesamt würde ich vorschlagen, Good Practices, Prozessanpassung und Prozessverbesserung gegenüber einzelnen Methoden hervorzuheben. Auf diese Weise sind Sie für jeden, der an den Kursen teilnimmt, am effektivsten. Sie können sie einer Vielzahl von Prozessmethoden aussetzen und die Best Practices für einen bestimmten Satz von Bedingungen verstehen.
Da Sie an der Erstellung eines Universitätslehrplans arbeiten, gebe ich einen allgemeinen Überblick darüber, wie der Lehrplan für Softwaretechnik an der Universität, an der ich teilgenommen habe, zusammenpasst.
Das war eine Einführung in die Softwareentwicklung, die das Projekt in einem Wasserfallmodell durchlief, wobei die Vorlesungen in jeder Phase unterschiedlichen Methoden zur Durchführung der Aktivitäten dieser Phase entsprachen. Die Teams durchliefen die Phasen im gleichen Tempo. Diese klar definierten Grenzen haben sich gut in das Unterrichtsmodell für eine Gruppe von Menschen eingepasst, die keine oder nur minimale Erfahrung in der Erstellung von Software in Teams haben. Im Verlauf des Kurses wurde auf andere Methoden verwiesen - verschiedene agile Methoden (Scrum, XP), Rational Unified Process und Spiral Model - hinsichtlich ihrer Vor- und Nachteile.
In Bezug auf die Aktivitäten gab es spezielle Kurse zur Diskussion von Requirements Engineering, Architektur und Design (zwei Kurse - einer mit Fokus auf Detail-Design mit objektorientierten Methoden und einer mit Fokus auf Systemarchitektur), eine Reihe von Kursen mit Fokus auf Design und Implementierung verschiedener Systemklassen (Echtzeit- und eingebettete Systeme, Unternehmenssysteme, gleichzeitige Systeme, verteilte Systeme usw.) und Softwaretests.
Es gibt auch drei Kurse, die sich mit Softwareprozessen befassen. Software-Engineering-Prozess- und Projektmanagement mit Schwerpunkt auf Best Practices für die Verwaltung eines Softwareprojekts in Bezug auf mehrere Methoden. In einem zweiten Kurs werden Messungen, Metriken und Prozessverbesserungen unterrichtet (Schwerpunkt CMMI, Six Sigma und Lean). Schließlich gibt es einen Prozesskurs, in dem die agile Softwareentwicklung (Scrum, Extreme Programming, Crystal, DSDM) anhand eines Projekts unter Verwendung der Scrum-Methodik vermittelt wird.
Das Schlusssteinprojekt war ein zweivierteljährliches Projekt, das für eine Sponsorfirma durchgeführt und vollständig vom studentischen Projektteam unter Anleitung der Sponsoren und eines Beraters der Fakultät durchgeführt wurde. Jeder Aspekt der Durchführung des Projekts unterliegt den Studenten und unterliegt den von den Sponsoren festgelegten Einschränkungen. Die einzigen von der Universität vorgegebenen Fristen waren eine Zwischenpräsentation in der Mitte (10 Wochen) des Projekts, eine Abschlusspräsentation am Ende und eine Quad-Poster-Präsentation kurz vor dem Ende. Alles andere war Sache des Sponsors und des Teams.