Prodagéo : première synthèse
Voilà que notre expérimentation de mini-projet Prodagéo touche déjà à sa fin et pour l'instant, je n'ai pas beaucoup écrit à ce sujet. Je vais donc essayer de me rattraper aujourd'hui en faisant un compte rendu des observations et premières conclusions que nous pouvons faire à la fin de ces quinze jours.
1 - le transfert du cahier des charges de Safi vers Dijon
Le transfert d'information en lui-même s'est plutôt bien passé, l'erreur était plus au niveau des étudiants marocains qui n'ont pas bien assimilé le découpage du projet. En effet, il était précisé dans les cahiers des charges que les techniciens faisaient leur mesure et transmettaient le résultat sur la ligne série, tandis que les ingénieurs remplissaient leur base de données à partir d'un fichier texte (cela n'est pas très judicieux mais il faut se débrouiller pour trouver une solution d'interface entre des techniciens qui ne connaissent pas encore les fichiers et des ingénieurs qui n'ont pas entendu parler de la ligne série : nous fournissions un petit exécutable qui lit la ligne série et remplit le ficher texte). Nulle part il n'y a de précision sur ce qui se passe entre les deux et c'est une imprécision du cahier des charges que j'assume. Cependant, il est du rôle du chef de projet de comprendre le fonctionnement global du système et de questionner le client pour éclaircir tous les points obscurs. Je doute fort qu'un chef de projet rencontre une fois dans sa carrière un cahier des charges exhaustif et complet ... Les étudiants marocains ont fait un raccourci tranquillisant en disant, tout ce qu'on a pas à faire, c'est aux techniciens de le faire. Il en est ressorti que le résultat du transfert de cahier des charges est un échec.
Quelles conclusions en tirer ? D'abord chercher à avoir des documents pour les étudiants plus précis et complet (c'est toujours possible), ensuite, inciter les chefs de projet à analyser l'ensemble du projet avec toutes les contraintes et précisant toutes les interfaces (composée de quelques schémas UML par exemple).
Force est de constater que l'éloignement et l'impossibilité de se rencontrer en face à face ne simplifie pas les échanges mais cela fait partie de l'exercice. C'est une situation qui peut se rencontrer régulièrement dans la vie professionnelle. Il est, me semble-t-il, important de sensibiliser et former les étudiants à la reformulation pour qu'ils puissent s'assurer d'avoir bien compris les consignes ou informations.
Pour palier le problème de transmission de cahier des charges et ne pas embrigader les étudiants dans une mauvaise piste, nous, enseignants, sommes intervenu pour recadrer le projet en fournissant le 'vrai' cahier des charges. nous aurions dû aussi informer les étudiants marocains de ce recadrage afin qu'ils puissent repartir sur les bonnes bases.
2 - la gestion du temps
On retrouve en condensé tous les travers des projets que vivent les étudiants en 2ème année :
- Difficulté à appréhender le problème et à rentrer dans le projet
- A la fin de la période d'analyse du problème et de découverte des outils et logiciels, les étudiants sont déjà en retard par rapport au planning.
- Le travail de réalisation (développement, mise en oeuvre du matériel) est intense et correspond à peu près à ce qui est planifié. Mais cela ne suffit pas à rattraper le temps perdu au début.
C'est une très bonne sensibilisation à la gestion du temps dans un projet et cela servira de base sur laquelle on pourra s'appuyer pour dynamiser les étudiants lors des prochains projets en insistant sur les risques à ne pas respecter les délais intermédiaires.
3 - le travail en équipe
Sur un petit projet de quinze jours, il est difficile de découper le travail à réaliser pour responsabiliser chaque étudiant sur une tâche spécifique. Les groupes ont dans l'ensemble fonctionné de manière fusionnelle : "on fait tout tous ensemble". Cela ne correspond pas au fonctionnement normal d'un projet et c'est une limite de notre exercice. Il est apparu un étudiant qui ne s'est pas intégré dans son groupe et qui s'est donc mis en marge par rapport à l'équipe. C'était un des deux groupes de 4 étudiants : c'est trop ! Il apparaît que pour cet exercice, un groupe ne doit pas contenir plus de 3 étudiants.
4 - l'utilisation des outils proposés
pour cette première expérience, on s'était centré sur 3 outils :
- Moodle pour régler les délais et synchroniser les tâches
- Subversion pour gérer des versions d'un document
- TestLink pour rédiger des plans et campagnes de tests
L'utilisation de Moodle n'a pas posé de problèmes à Dijon puisque les étudiants sont habitués à rendre leur travaux sur un serveur FTP, Les marocains ont eu plus de réticences à l'utiliser.
TestLink est un logiciel sûrement puissant mais qui n'est pas aisé de prise en main et nécessite un apprentissage. Aucun enseignant disponible à ce moment ne maîtrisait l'outil, il a été abandonné lors du travail préparatoire d'analyse des marocains. Leur plan de tests s'est réduit à un tableau.
Enfin, je ne sais pas comment Subversion a été utilisé à Safi mais à Dijon, il n'a pas servi ou presque. Les étudiants ne sont pas sensibles au problème de versions et de restauration ...
En conclusion, il faut que les étudiants soient formés aux outils de gestion de projet utilisés avant un mini-projet Prodagéo.
5 - les tests
Nos techniciens ne savent pas tester !!! Ils nous font des beaux plans de tests, mais au moment du test, si on prend le temps de le faire, on modifie les paramètres, on adapte, on biaise les tests ...
Un exemple significatif est le test d'émission d'une trame toutes les heures. Les étudiants nous disent : "à quoi ça sert de faire le test pendant la nuit puisqu'on a vu que ça fonctionne quand on demande une émission toutes les 10 minutes ? ". On a bataillé pour que le test se fasse quand même en respectant le protocole défini. Le lendemain matin, oh ! surprise ! au bout de 2 trames, plus rien : les PCs s'étaient mis en veille !!!
6 - la position des enseignants
Nous avions prévu que nous serions support technique. Il s'est avéré dès le résultat de la transmission du cahier des charges que nous devions aussi superviser l'avancement du projet et nous donner la liberté de recadrer les étudiants après chaque jalon d'avancement du projet. Il faut alors envisager le projet comme une course à la boussole par étape. On joue le rôle de la voiture balais pour tous les candidats qui se sont trompés sur la position de l'arrivée d'une étape : on les amène sur la ligne de départ de l'étape suivante.
7 - correction à prévoir dans le planning
Afin de mieux responsabiliser les ingénieurs dans leur rôle de chef de projet, il faudra la prochaine fois leur demander de réagir à l'analyse faite par les techniciens pour préparer leur travail. Les techniciens devront en avoir le retour avant le début du codage afin de pouvoir le prendre en compte.
8 - intégration des différents éléments du projet
Deux groupes ayant finalisé leur travail 4 heures avant la fin du temps imparti, nous leur avons proposé de travailler sur l'intégration générale de tous les composants (acquisition, interface, portail). Ils ont ainsi pu sentir la difficulté de reprendre le travail d'un autre et l'utilité de tous les documents demandés (manuel d'installation, d'utilisation, analyse, commentaires dans le code, ...). Espérons que cela leur sera profitable et qu'ils s'en souviendront lors de la rédaction de leurs prochains documents. L'intégration n'a pour l'instant pas abouti.
9 - intégration du projet dans la progression pédagogique à Dijon
Nous avons pu pendant cette quinzaine faire une synthèse de tout le premier semestre : analyse, intégration de matériel, acquisition, ... Cela nous a permi aussi de sensibiliser à la vie d'un projet, ses étapes, ses documents, son rythme. Deux points spécifiquement disciplinaires sont à soulever :
- cela a été l'occasion d'avoir une vraie mise en situation pour valider des tâches de l'habilitation électrique (et ça, je trouve que c'est un petit exploit)
- nous avons pu faire travailler nos étudiants avec du matériel de mesure : GBF et oscilloscope afin de valider le comptage d'événement et de visualiser les trames échangées entre le SHT71 et le PC (ou DK41)
La quinzaine a donc été bien riche, je ne pense pas qu'on ait fait le tour complet de son analyse mais c'est déjà bien riche. Je ne peux pas vous quitter sans préciser que tous les groupes sont arrivés à acquérir les informations demandées. Le calibrage du travail demandé était donc correct, ce n'était pas forcément gagné d'avance.
C'était passionnant de monter tout cela et de le partager pendant deux semaines avec nos élèves. C'est à faire et à refaire.
Nous sommes ouvert pour fournir toutes les informations nécessaires à qui voudrait tenter l'aventure ...
1 - le transfert du cahier des charges de Safi vers Dijon
Le transfert d'information en lui-même s'est plutôt bien passé, l'erreur était plus au niveau des étudiants marocains qui n'ont pas bien assimilé le découpage du projet. En effet, il était précisé dans les cahiers des charges que les techniciens faisaient leur mesure et transmettaient le résultat sur la ligne série, tandis que les ingénieurs remplissaient leur base de données à partir d'un fichier texte (cela n'est pas très judicieux mais il faut se débrouiller pour trouver une solution d'interface entre des techniciens qui ne connaissent pas encore les fichiers et des ingénieurs qui n'ont pas entendu parler de la ligne série : nous fournissions un petit exécutable qui lit la ligne série et remplit le ficher texte). Nulle part il n'y a de précision sur ce qui se passe entre les deux et c'est une imprécision du cahier des charges que j'assume. Cependant, il est du rôle du chef de projet de comprendre le fonctionnement global du système et de questionner le client pour éclaircir tous les points obscurs. Je doute fort qu'un chef de projet rencontre une fois dans sa carrière un cahier des charges exhaustif et complet ... Les étudiants marocains ont fait un raccourci tranquillisant en disant, tout ce qu'on a pas à faire, c'est aux techniciens de le faire. Il en est ressorti que le résultat du transfert de cahier des charges est un échec.
Quelles conclusions en tirer ? D'abord chercher à avoir des documents pour les étudiants plus précis et complet (c'est toujours possible), ensuite, inciter les chefs de projet à analyser l'ensemble du projet avec toutes les contraintes et précisant toutes les interfaces (composée de quelques schémas UML par exemple).
Force est de constater que l'éloignement et l'impossibilité de se rencontrer en face à face ne simplifie pas les échanges mais cela fait partie de l'exercice. C'est une situation qui peut se rencontrer régulièrement dans la vie professionnelle. Il est, me semble-t-il, important de sensibiliser et former les étudiants à la reformulation pour qu'ils puissent s'assurer d'avoir bien compris les consignes ou informations.
Pour palier le problème de transmission de cahier des charges et ne pas embrigader les étudiants dans une mauvaise piste, nous, enseignants, sommes intervenu pour recadrer le projet en fournissant le 'vrai' cahier des charges. nous aurions dû aussi informer les étudiants marocains de ce recadrage afin qu'ils puissent repartir sur les bonnes bases.
2 - la gestion du temps
On retrouve en condensé tous les travers des projets que vivent les étudiants en 2ème année :
- Difficulté à appréhender le problème et à rentrer dans le projet
- A la fin de la période d'analyse du problème et de découverte des outils et logiciels, les étudiants sont déjà en retard par rapport au planning.
- Le travail de réalisation (développement, mise en oeuvre du matériel) est intense et correspond à peu près à ce qui est planifié. Mais cela ne suffit pas à rattraper le temps perdu au début.
C'est une très bonne sensibilisation à la gestion du temps dans un projet et cela servira de base sur laquelle on pourra s'appuyer pour dynamiser les étudiants lors des prochains projets en insistant sur les risques à ne pas respecter les délais intermédiaires.
3 - le travail en équipe
Sur un petit projet de quinze jours, il est difficile de découper le travail à réaliser pour responsabiliser chaque étudiant sur une tâche spécifique. Les groupes ont dans l'ensemble fonctionné de manière fusionnelle : "on fait tout tous ensemble". Cela ne correspond pas au fonctionnement normal d'un projet et c'est une limite de notre exercice. Il est apparu un étudiant qui ne s'est pas intégré dans son groupe et qui s'est donc mis en marge par rapport à l'équipe. C'était un des deux groupes de 4 étudiants : c'est trop ! Il apparaît que pour cet exercice, un groupe ne doit pas contenir plus de 3 étudiants.
4 - l'utilisation des outils proposés
pour cette première expérience, on s'était centré sur 3 outils :
- Moodle pour régler les délais et synchroniser les tâches
- Subversion pour gérer des versions d'un document
- TestLink pour rédiger des plans et campagnes de tests
L'utilisation de Moodle n'a pas posé de problèmes à Dijon puisque les étudiants sont habitués à rendre leur travaux sur un serveur FTP, Les marocains ont eu plus de réticences à l'utiliser.
TestLink est un logiciel sûrement puissant mais qui n'est pas aisé de prise en main et nécessite un apprentissage. Aucun enseignant disponible à ce moment ne maîtrisait l'outil, il a été abandonné lors du travail préparatoire d'analyse des marocains. Leur plan de tests s'est réduit à un tableau.
Enfin, je ne sais pas comment Subversion a été utilisé à Safi mais à Dijon, il n'a pas servi ou presque. Les étudiants ne sont pas sensibles au problème de versions et de restauration ...
En conclusion, il faut que les étudiants soient formés aux outils de gestion de projet utilisés avant un mini-projet Prodagéo.
5 - les tests
Nos techniciens ne savent pas tester !!! Ils nous font des beaux plans de tests, mais au moment du test, si on prend le temps de le faire, on modifie les paramètres, on adapte, on biaise les tests ...
Un exemple significatif est le test d'émission d'une trame toutes les heures. Les étudiants nous disent : "à quoi ça sert de faire le test pendant la nuit puisqu'on a vu que ça fonctionne quand on demande une émission toutes les 10 minutes ? ". On a bataillé pour que le test se fasse quand même en respectant le protocole défini. Le lendemain matin, oh ! surprise ! au bout de 2 trames, plus rien : les PCs s'étaient mis en veille !!!
6 - la position des enseignants
Nous avions prévu que nous serions support technique. Il s'est avéré dès le résultat de la transmission du cahier des charges que nous devions aussi superviser l'avancement du projet et nous donner la liberté de recadrer les étudiants après chaque jalon d'avancement du projet. Il faut alors envisager le projet comme une course à la boussole par étape. On joue le rôle de la voiture balais pour tous les candidats qui se sont trompés sur la position de l'arrivée d'une étape : on les amène sur la ligne de départ de l'étape suivante.
7 - correction à prévoir dans le planning
Afin de mieux responsabiliser les ingénieurs dans leur rôle de chef de projet, il faudra la prochaine fois leur demander de réagir à l'analyse faite par les techniciens pour préparer leur travail. Les techniciens devront en avoir le retour avant le début du codage afin de pouvoir le prendre en compte.
8 - intégration des différents éléments du projet
Deux groupes ayant finalisé leur travail 4 heures avant la fin du temps imparti, nous leur avons proposé de travailler sur l'intégration générale de tous les composants (acquisition, interface, portail). Ils ont ainsi pu sentir la difficulté de reprendre le travail d'un autre et l'utilité de tous les documents demandés (manuel d'installation, d'utilisation, analyse, commentaires dans le code, ...). Espérons que cela leur sera profitable et qu'ils s'en souviendront lors de la rédaction de leurs prochains documents. L'intégration n'a pour l'instant pas abouti.
9 - intégration du projet dans la progression pédagogique à Dijon
Nous avons pu pendant cette quinzaine faire une synthèse de tout le premier semestre : analyse, intégration de matériel, acquisition, ... Cela nous a permi aussi de sensibiliser à la vie d'un projet, ses étapes, ses documents, son rythme. Deux points spécifiquement disciplinaires sont à soulever :
- cela a été l'occasion d'avoir une vraie mise en situation pour valider des tâches de l'habilitation électrique (et ça, je trouve que c'est un petit exploit)
- nous avons pu faire travailler nos étudiants avec du matériel de mesure : GBF et oscilloscope afin de valider le comptage d'événement et de visualiser les trames échangées entre le SHT71 et le PC (ou DK41)
La quinzaine a donc été bien riche, je ne pense pas qu'on ait fait le tour complet de son analyse mais c'est déjà bien riche. Je ne peux pas vous quitter sans préciser que tous les groupes sont arrivés à acquérir les informations demandées. Le calibrage du travail demandé était donc correct, ce n'était pas forcément gagné d'avance.
C'était passionnant de monter tout cela et de le partager pendant deux semaines avec nos élèves. C'est à faire et à refaire.
Nous sommes ouvert pour fournir toutes les informations nécessaires à qui voudrait tenter l'aventure ...