Je travaille actuellement avec un professeur de mon université pour développer de nouveaux programmes pour les cours de génie logiciel et de conception Capstone offerts dans mon collège.
Jusqu'à récemment, les deux cours utilisaient exclusivement le modèle de la cascade, et les étudiants passaient donc la majorité de leur temps à rédiger de longs rapports. Après beaucoup de pression de ma part, mon professeur a décidé d'inclure Scrum dans le programme de génie logiciel du semestre dernier.
La première moitié du semestre était encore en cascade, les étudiants rédigeant des rapports de conception de 40 pages et des documents de spécification de logiciel. Au milieu du semestre, toutes les équipes ont été tenues de publier une démo de leurs applications. À ce moment-là, le cours est passé à Scrum, avec deux sprints de 3 semaines. Nous essayons maintenant de comprendre comment éliminer complètement la cascade et créer un programme exclusivement basé sur Scrum.
Malheureusement, nous avons rencontré quelques incompatibilités entre Scrum et les étudiants:
- Les réunions quotidiennes Scrum sont presque impossibles pour les étudiants. Même pendant le cours lui-même, il est gênant pour les étudiants de tenir des réunions Scrum car le professeur donne généralement des cours.
- L'estimation des points / heures est difficile, car les étudiants sont inexpérimentés et ne peuvent donc pas prédire avec précision le temps que prendra quelque chose.
- Scrum fonctionne mieux avec des développeurs à temps plein et colocalisés, mais les étudiants ne le sont pas non plus. Tout au plus, les étudiants consacrent 15 à 20 heures par semaine au cours, et l'organisation de réunions de travail peut être extrêmement difficile. Les équipes peuvent avoir jusqu'à 10 étudiants (et il y a toujours un ou deux slackers).
- Les professeurs ont soif de documentation! Je n'ai entendu parler d'aucun rapport Scrum - juste les arriérés et les graphiques de burndown (qui je ne suis pas sûr que ce sera suffisant pour apaiser les universitaires).
- Les étudiants supposent souvent que agile signifie "Aller droit au but et commencer à coder sans regarder en arrière". Cela conduit à certains des codes les plus horribles imaginables. Par conséquent, je cherche un moyen d'appliquer une conception appropriée sans avoir besoin d'un document de 50 pages ou d'une pile de diagrammes UML.
Compte tenu de ces problèmes, comment pensez-vous que mon professeur et moi pouvons adapter Scrum pour fonctionner dans un environnement universitaire (et devrions-nous même nous embêter avec Scrum en premier lieu)? En outre, est-il toujours utile d'enseigner le modèle de la cascade?
Merci d'avance pour tout commentaire!
Réponses:
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.
la source
Quand j'ai fait ma maîtrise en génie logiciel, il y avait un cours appelé Processus logiciel qui traitait de XP, Scrum et d'autres approches agiles. Essentiellement, toute la classe a formé une société de logiciels hypothétique et a été chargée de développer un logiciel assez élaboré pendant la durée du cours. Les conférences portaient sur des choses telles que les pratiques XP, l'organisation de réunions debout, etc.
La plupart des étudiants ont entendu parler de ces techniques et souhaitent généralement les appliquer. Bien sûr, il n'y a aucun moyen de forcer l'équipe à travailler réellement de manière itérative, etc. c'est tout simplement le moyen le plus simple et le plus fiable de produire quelque chose de valeur avec un groupe de personnes et un peu de temps.
Une chose à retenir: assurez-vous de bien jouer le client et modifiez certaines exigences clés à mi-chemin. Ou "oubliez" de les mentionner initialement.
la source
Le but est-il de faciliter le développement, ou d'apprendre Scrum, ou - je suppose - les deux? Je considérerais des sprints plus courts pour accélérer le processus d'apprentissage.
Vous pouvez peut-être remplacer les stand-ups quotidiens par une forme moins stricte, quand cela fonctionne le mieux pour les étudiants. De plus, tout le monde n'a pas besoin de participer à chaque réunion.
Estimer le temps du calendrier est encore plus difficile, pour les mêmes raisons :-) Avec les points d'histoire, vous n'évaluez pas le temps que prendra quelque chose: vous estimez sa taille relative. La durée est dérivée.
Peut-être essayer avec des équipes plus petites? 10 est sur l'échelle supérieure pour une équipe Scrum. Je pense que vous pouvez aussi réussir avec des équipes réparties non à plein temps, mais bien sûr, c'est plus difficile! Que cela soit une leçon en soi.
Scrum ne dicte pas le type de documentation requis. En fait, même les tableaux de burndown ne sont pas obligatoires. Cela ne signifie pas que la documentation est interdite: l'équipe doit produire la documentation nécessaire, y compris les rapports que les professeurs jugent nécessaires.
Non seulement les étudiants :-) La plupart des équipes Scrum utilisent des pratiques XP telles que TDD (Test Driven Development) et refactoring: je vous propose de l'intégrer dans les programmes.
Oui, au moins pour deux raisons: premièrement, il n'est pas certain que vos élèves utiliseront Scrum dans leur vie professionnelle, et deuxièmement, j'imagine qu'il est plus facile de comprendre l'essence du développement agile si vous avez quelque chose à comparer.
la source
Cela ressemble un peu à un sujet que j'ai pris une fois.
Quelques idées:
la source
Mon conseil est de séparer et d'isoler ce que vous essayez d'enseigner. S'il s'agit d'un cours de conception de logiciels ou d'un autre sujet de génie logiciel (algorithmes ou autres), concentrez-vous là-dessus. Si la participation à SCRUM devient un obstacle (comme vous le laissez entendre), ne vous en faites pas.
Comment nous avons fait cela quand j'étais à l'université, c'était d'avoir un cours dédié aux méthodologies agiles. Le cours comprenait un projet de développement qui devait être exécuté selon SCRUM ou XP. Le logiciel qui devait être livré était insignifiant, car le cours n'était pas axé sur la programmation ou la conception, mais sur le processus. Le raisonnement ici est le même que pourquoi vous ne devriez pas mélanger des sujets de développement logiciel "noyau dur" avec des sujets de méthodologie car l'un a tendance à éclipser l'autre et les étudiants ne sont généralement pas prêts ou suffisamment qualifiés pour gérer les deux à ce stade.
Les livrables du cours étaient des choses comme les rapports de planification de sprint, les rapports d'étape hebdomadaires, les rétrospectives, les rapports de burndown et chaque semaine, nous avons eu au moins deux sessions qui comprenaient une réunion debout / mêlée de groupe où les assistants techniques circulaient et écoutaient.
Ce cours comprenait également TDD (Test Driven Development) et cela fonctionnait très bien.
C'est certainement le cas. De nombreuses entreprises utilisent des versions de ce modèle pour leurs projets (PPS, RUP, PROPS, etc.). Beaucoup trouvent (correctement, à mon avis) que SCRUM "pur" est mieux adapté à la maintenance continue que les projets. SCRUM (et Agile en général) requiert une certaine flexibilité dans la portée et la possibilité de négocier les exigences et la livraison en cours de route. Tous les projets ne fonctionnent pas comme ça, ils sont binaires: livrer X au point Y dans le temps, tout le reste est un échec.
la source
Le but d'un cours académique de génie logiciel est d'enseigner les étapes fondamentales du cycle de vie du logiciel - analyse, conception, mise en œuvre, tests ainsi que l'utilisation de normes de qualité logicielle réelles au lieu du code de qualité des devoirs.
Il est utile de démontrer la pratique en utilisant un processus sans cascade , cependant, pour les raisons que vous avez mentionnées, SCRUM n'est pas un processus approprié - les étudiants suivent de nombreux cours par semestre, beaucoup ont également de vrais emplois pendant leurs études, donc vous ne pouvez pas en avoir 100 % de membres dévoués de l'équipe ou organisent des réunions quotidiennes.
Envisagez d'utiliser à la place un processus itératif moins agile tel que UP (RUP).
Pour afficher la valeur par rapport au processus en cascade, modifiez les exigences entre les itérations. Cela montrera la différence entre UP et la cascade et indiquera la valeur de l'utilisation de processus agiles.
La démonstration de la cascade après cela sera redondante car UP couvre toutes les étapes de la cascade.
Comme les semestres sont relativement courts, 2 petites itérations seraient réalistes.
Fournir un cadre général aux étudiants, car ce cours ne devrait pas mettre l'accent sur la profondeur de la mise en œuvre, il existe d'autres cours pour cela, mais plutôt des normes de codage et des tests unitaires.
Pendant le cours, les cours enseignent la théorie de quelques processus, par exemple la cascade, UP, XP, SCRUM et Kanban (ainsi que d'autres sujets tels que les exigences d'écriture, UML, les tests, etc.).
Pour les étudiants qui ont terminé le cours ci-dessus, considérez un atelier SCRUM distinct comme un cours électif qui prend une période de deux semaines à temps plein pendant le semestre d'été.
la source
Scrum fonctionne si vous avez un projet long terme / semestre et que la classe est divisée en groupes de 6 à 10 personnes. Ensuite, vous pouvez consacrer les 10 dernières minutes de cours à la réunion de mêlée.
la source