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 ...

Ca y'est, le projet est lancé ! Le planning de la quinzaine va être bien chargé, vous avez ici le scénario prévu avec les documents que doivent fournir les différents groupes...
Vous pouvez aussi consulter les configurations matérielles utilisées par les différents groupes  ainsi que le  cahier des charges que nous avions fourni aux étudiants marocains.
Où en est-on ce soir ?
Les 6  groupes 'chefs de projets'  ont transmis leur Cahier des charges aux techniciens de Dijon. Globalement ça s'est bien passé techniquement, et socialement. Pour ce qui est du contenu transmis, j'ai demandé à mes étudiants de Dijon de rédiger un court rapport  de ce qu'ils ont compris de leur cahier des charges. Voici le bilan :
1 équipe n'a rien rendu (aïe, aïe aïe ...)
les 5 autres équipes ont des imprécisions non négligeables sur le fonctionnement général du système et les limites de leur travail.
Aucune équipe n'a fait état d'un cahier de recette ni de tests, peut-être n'ont-ils pas jugé nécessaire d'en parler, ce sera à éclaircir demain.

Il faut donc recadrer cela afin de retourner dans le cadre du projet. Nous pensons demain commencer en donnant à nos étudiants les documents que nous avons fournis aux étudiants marocains afin qu'ils comparent avec ce qu'ils ont compris. Cela devrait leur permettre de retrouver le bon chemin.

L'impression générale de la journée est très bonne, tout le monde s'est pris au jeu, aussi bien les élèves que les profs .... C'est bon de se faire plaisir au boulot !

le début de la réflexion est ici...
En fait, en regardant la carte que je viens de faire, je me suis dit qu'il pourrait être bien agréable de pouvoir se promener dans le blog à partir de ce plan. Je vais donc de ce pas la rendre interactive pour qu'on puisse avoir un itinéraire de découverte autre que la chronologie ....

En manque de méthode pour  piloter le travail de veille que je demande à mes élèves, je suis allé faire un tour sur le web et j'ai trouvé cet article qui  vient de l'Ecole des  Bibliothécaires Documentalistes (dont c'est effectivement  plus le travail). Il nous présente le découpage du travail de veille en 6 étapes : 
1 - familiarisation avec les fils RSS
2 - mise en place du blog (ils utilisent TypePad pro, je pense que dans un premier temps on peut utiliser WordPress qui est gratuit et qui remplit globalement les fonctionnalités que l'on attend d'un blog pour plusieurs auteurs)
3 - alimentation du blog "actualité" (effectivement, on y apprend qu'ils ont des cours de rédactions pour ce type de média, je pourrai en parler avec les prof de communication et français ...)
4 - création d'un sujet documentaire pour initier des novice à leur domaine de veille
5 - mise en place d'un blog pour le dossier documentaire
6 - évaluation du travail, les critères présentés sont : sélection des sources, organisation du contenu, richesse de l'information et  "utilisabilité" du travail.

En fait, je constate qu'on est sur la même longueur d'onde, je pense plus à priori continuer sur mon idée de carte de connaissances du domaine de veille.  La conclusion de cette lecture est que plus que jamais il faut continuer dans ce sens : à moi de motiver mes élèves pour qu'ils poursuivent leurs efforts ...

 

Une formation a eu lieue à Lyon les 17 et 18 janvier sur "Production collaborative de contenu sur internet". Elle parle essentiellement des wikis mais est facilement transposable aux blogs. Elle fournit une grille pour synthétiser un scénario pédagogique de publication collaborative. Le scénario correspondant au travail de veille technologique avec les blogs est ici ...