Agile france2015 agiliteformation

429 vues

Publié le

Et si on appliquait l’agilité aux formations dans les écoles d’ingénieurs ?
http://lanyrd.com/2015/agilefrance/sdpfqq/

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
429
Sur SlideShare
0
Issues des intégrations
0
Intégrations
29
Actions
Partages
0
Téléchargements
5
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Agile france2015 agiliteformation

  1. 1. Et si on appliquait l’agilité aux formations des ingénieurs ? Mirette BEKHIT Houssam FAKIH Guillaume MICHEL
  2. 2. Plan ❖ Binômage ❖ Backlog ❖ Feedbacks ❖ Cycle court ❖ Refactoring
  3. 3. Binômage ● Qualité du Code, Code Collectif ● Echange de savoir, apprentissage, montée en compétences ● Echanges humains forts, Challenges…Amitié ● Mais…pas facile ● Différence de niveaux à gérer… ● Egos à gérer…gestion du conflit en continu
  4. 4. Binômage ● En entretien d’embauche: « J’ai déjà binômé en TP… » ● Différent du travail en groupe vu en TP ○ Chacun de son côté ○ On se partage le travail (comment ?) ○ Un bosseur et N suiveurs ○ Respect mutuel « limite » (téléphone, absences…)
  5. 5. Binômage ● Apprentissage du travail en commun ● Apprentissage de la communication, gestion du conflit. Mise en place d’un dialogue constructif ● Apprentissage du Respect mutuel (horaires, règles de travail, outils communs…) ● Sensibilisation au travail en équipe pour l’avenir
  6. 6. Binômage ● Comment noter un binôme ? Une même note pour deux, une note d’appréciation ou une note de présentation… ● Comment constituer les binômes ? ● Comment gérer les niveaux ? ● Vraie problématique matérielle ● Comment l’appliquer à des cours magistraux et pas seulement aux TP ?
  7. 7. Backlog ● Visibilité commune du stock à faire…des deadlines ● Visibilité commune de la vélocité… ● Gestion des choix, priorités…que supprimer ? que garder ? ● Mais…pas facile ● Anticiper… ● Prend du temps à préparer et à faire vivre…
  8. 8. Backlog ● « Jamais vu ! » ● Gestion des échéances « à l’arrache » (rapports de stages…). Fin des rapports de stage le dimanche soir. ● Gestion des priorités: impasses sur des matières entières ou des chapitres entiers ● Le « prof » ne s’adapte pas au groupe
  9. 9. Backlog ● Visibilité de « où on en est dans le cours », vélocité du groupe ● Gérer les dérapages: un chapitre prend plus de temps que prévu ● Visibilité des échéances (remise de rapports, de TPs) ● Avoir un stock de sujet: permet au professeur d’adapter son cours ou ses TPs en fonction de l’auditoire ● Gestion des priorités: faire l’impasse sur les détails inutiles
  10. 10. Backlog… par un prof ● Préparer son cours et ses TPs sous forme de User Stories sous Pivotal Tracker
  11. 11. Backlog… par un prof ● Chaque User Story correspond à un chapitre ou un TP, et contient les PDFs, exos, projets…
  12. 12. Backlog ● Plus du temps pour préparer la backlog et la faire vivre ● Un espace visible des élèves pour la consulter ● Backlog numérique ? ● Un espace par cours et/ou par matière ● Compliqué à gérer pour l’étudiant
  13. 13. Feedback ● Retrospectives ● Resolution de problèmes, PDCA, QRQC ● Apprendre de ses erreurs, capitaliser ● Augmenter les connaissances de l’équipe ● Mais…pas facile ● Eviter les dérapages, Être constructif
  14. 14. Feedback ● Evaluation du cours à la fin du trimestre…trop tard ● Feedback du Prof vers l’élève: les notes… ● Feedback des élèves vers le prof: après le dernier cours… ● Globalement trop tard et trop succinct
  15. 15. Feedback ● Pourquoi ne pas faire un stand-up au début de chaque cours? ● Retrospective sur le contenu du cours (un retro/fin de mois). ● Faire le point sur les problèmes rencontrés (matériel…) ● Feedback rapide tout au long du cours: ● le professeur adapte ses exercices, TPs en fonction des retours
  16. 16. Feedback ● Un stand-up au début d’un cours en amphi ● Un binôme qui présente le cours précédent ● Risque de dévier l’objectif du cours ● Se concentrer sur les problèmes sur lesquelles on peut influer
  17. 17. Cycle court ● Eviter l’effet tunnel ● S’adapter aux changements de dernières minutes ● Savoir où on en est… ● Pouvoir tout stopper à temps… ● Mais…pas facile ● Garder un cap moyen/long terme visible
  18. 18. Cycle court ● « Inexistant » ● Partiels à la fin du trimestre ou du semestre ● Notes un mois après les partiels, pendant le trimestre suivant… ● Pas de possibilité d’anticiper les dérapages ● Pas d’apprentissage de la conduite de projets
  19. 19. Cycle court ● Simplement plus de notes ? Une vraie moyenne… ● Des cours plus segmentés, avec des points d’étapes réguliers ● Mon approche: ○ une heure de cours / d’un TP de 30mn sur le sujet ○ une heure de cours / d’un TP de 30mn sur le sujet… ○ Le TP est adapté en fonction du niveau et de la réactivité
  20. 20. Refactoring But : Donner la possibilité à l’étudiant d’améliorer son travail de façon continue Pré-requis : Faire un feedback au plus tôt à l’étudiant Plan d’actions ● Travail en cycle à la mantra code : red, green, refactor ● Faire des points réguliers avec l’étudiant (cycles courts) ○ Identifier les points d’amélioration du travail fait ○ Demander à l’étudiant un plan pour améliorer son travail ○ Valider ○ Mettre en place ○ recommencer
  21. 21. Refactoring ● Pas beaucoup de une disponibilité de la part du prof ● Assez conséquent en terme de travail demandé (plusieurs profs ?)
  22. 22. Refactoring ● Accompagnement de l’étudiant ● Evaluation continue avec des points de synchronisation ● Identification des points faibles et possibilités de “rattraper” les élèves en difficulté ● Approche plus formatrice : Apprendre de ses erreurs ● Ne pas avoir un seul but « la note », mais projet long terme
  23. 23. Refactoring ● Chemin d’exercices ○ Problème de notation : exo => note => revenir sur l’exo => changer la note
  24. 24. Questions ● Professeur = scrum master? ● XP, Kanban, post-it => trop théorique? ● MOOC ? ● Apprendre l’agilité sans la mettre en pratique ? ● ...
  25. 25. Merci

×