J'hésiterais à rejeter Waterfall à tous les niveaux si rapidement.
Bien qu'il s'agisse d'un modèle imparfait pour la construction de systèmes logiciels, ce n'est pas un mauvais modèle d'enseignement pour enseigner les bonnes pratiques à chaque étape du cycle de vie. Quel que soit le modèle de processus que vous appliquez au projet, vous effectuez toujours l'ingénierie des exigences, l'architecture et la conception du système, la mise en œuvre, les tests, la publication et la maintenance (y compris la refactorisation et l'amélioration). La différence est la façon dont ces phases sont organisées et conduites, mais toutes les activités se déroulent toujours.
Je dirais que votre transition de Waterfall à Scrum au milieu du projet n'est pas la meilleure idée. La clé du succès de Scrum est un projet de longue date. Les trois à cinq premiers sprints sont l'équipe qui s'installe à une vitesse, apprend le processus et passe par le développement de l'équipe. Bien que vous ayez terminé les motions, ce n'est pas vraiment Scrum à ce stade. De plus, essayer de créer un programme exclusivement basé sur Scrum est probablement une mauvaise idée car Scrum n'est pas une solution miracle - il vaut mieux enseigner les meilleures pratiques plutôt qu'une méthodologie unique. Dans la population active, tous les projets n'utiliseront pas Scrum. En fait, dans certains environnements, Scrum serait préjudiciable à la réussite du projet.
Vous avez déjà rencontré des problèmes avec Scrum en milieu universitaire, et certains d'entre eux sont difficiles à résoudre de manière adéquate.
Le non-problème dans votre liste d'incompatibilités est que l'estimation est difficile. Oui, ça l'est. Mais la seule façon d'améliorer l'estimation est d'estimer et de comparer les chiffres réels aux estimations. Les étudiants devraient estimer la taille, le temps et l'effort en utilisant divers moyens (points d'histoire, lignes de code source, heures, pages, heures-personnes) tôt afin qu'ils soient mieux préparés à le faire après avoir obtenu leur diplôme et entrer sur le marché du travail.
Le besoin de documentation est quelque chose qui peut être abordé à la fois du point de vue du professeur et du point de vue des étudiants. Les approches Lean nous disent que la documentation qui n'ajoute pas de valeur à l'équipe ou au client est un gaspillage (en termes de temps et de coût). Cependant, une documentation est nécessaire pour atteindre certains objectifs des étudiants et du professeur (le client / client) à diverses fins. Dans l'ensemble, cela ressemble à une occasion d'enseigner la personnalisation des processus et la gestion de projet quantitative (qui a un rôle même dans les méthodes agiles).
En ce qui concerne les réunions Scrum et la programmation, deux idées me viennent à l'esprit. La première est que cela indique que Scrum n'est peut-être pas le meilleur processus à utiliser dans un milieu universitaire. Il n'existe pas de «meilleur modèle de processus» unique pour les projets logiciels, avec des facteurs tels que le calendrier, le personnel, la visibilité et l'expérience de l'équipe de développement (entre autres).
Dans l'ensemble, je suggérerais de mettre l'accent sur les bonnes pratiques, l'adaptation des processus et l'amélioration des processus par rapport aux méthodologies uniques. Cela vous permettra d'être le plus efficace pour tous ceux qui suivent les cours, de les exposer à une variété de méthodologies de processus et de comprendre quelles sont les meilleures pratiques pour un ensemble donné de conditions.
Puisque vous travaillez à l'élaboration d'un programme universitaire, je vais donner un aperçu de haut niveau de la façon dont le programme de génie logiciel de l' université que j'ai fréquenté s'intègre.
Il s'agissait d'une introduction à l'ingénierie logicielle effectuée à travers le projet dans un modèle en cascade, avec les conférences au cours de chaque phase correspondant à différentes façons de mener les activités de cette phase. Les équipes ont progressé à travers les phases au même rythme. Faire en sorte que ces limites clairement définies s'intègrent bien dans le modèle d'enseignement pour un groupe de personnes n'ayant pas ou peu d'expérience de travail en équipe pour créer des logiciels. Tout au long du cours, des références ont été faites à d'autres méthodologies - diverses méthodes agiles (Scrum, XP), Rational Unified Process, Spiral Model - en ce qui concerne leurs avantages et leurs inconvénients.
En ce qui concerne les activités, il y avait des cours spécifiques pour discuter de l'ingénierie des exigences, de l'architecture et de la conception (deux cours - un axé sur la conception détaillée utilisant des méthodes orientées objet et un axé sur l'architecture du système), un certain nombre de cours axés sur la conception et la mise en œuvre de divers classes de systèmes (systèmes temps réel et embarqués, systèmes d'entreprise, systèmes simultanés, systèmes distribués, etc.) et tests de logiciels.
Il existe également trois cours dédiés au processus logiciel. Processus de génie logiciel et gestion de projet qui se concentre sur les meilleures pratiques pour gérer un projet logiciel en respectant plusieurs méthodologies. Un deuxième cours sur les processus enseigne les mesures, les métriques et l'amélioration des processus (en mettant l'accent sur CMMI, Six Sigma et Lean). Enfin, il y a un cours sur les processus qui enseigne le développement de logiciels agiles (Scrum, Extreme Programming, Crystal, DSDM discuté) en utilisant un projet réalisé en utilisant la méthodologie Scrum.
Le projet Capstone était un projet de deux quarts réalisé pour une entreprise parrainante et géré entièrement par l'équipe de projet étudiant, avec les conseils des sponsors et d'un conseiller pédagogique. Chaque aspect de la façon de mener le projet appartient aux étudiants, dans les limites définies par les sponsors. Les seules dates limites imposées par l'université étaient une présentation intermédiaire à mi-chemin (10 semaines) du projet, une présentation finale à la fin et une présentation quadruple par affiche peu de temps avant la fin. Tout le reste était à la discrétion du sponsor et de l'équipe.