C’est quoi un bon MOOC ?

Mooc pour massive open online course, en français Formation en ligne Ouverte à tous (FLOT)  ou Cours en ligne, ouvert et massif  (CLOM).

Voici ma vision du MOOC idéal, après en avoir suivi plusieurs jusqu’au bout, de différents organismes.

Pour avoir du plaisir à faire un MOOC et avoir envie d’aller jusqu’au bout, il faut :

1. Une notion de récompense, certificat ou équivalent
2. Un livrable en fin de chaque semaine (QUIZZ et/ou Exercice),  avec la possibilité de poursuivre et d’avoir son certificat, si les devoirs n’ont pas été rendus à temps (dans la limite du raisonnable).
3. Une durée courte, quelques semaines
4. Un temps de travail hebdomadaire de quelques heures, en visionnage/lecture et en travail à réaliser.
5. Un plate forme simple à utiliser
6. Des vidéos avec les textes de ces vidéos, la possibilité de télécharger les vidéos, pour une lecture en locale
7. Une progression croissante dans la difficulté, on doit être dans le succès et finalement ne pas sentir la difficulté augmenter
8. Une notion collaborative, comme corriger les « exercices » des autres stagiaires avec une notation guidée, indiscutable et juste avec la correction type du ou des exercice(s) . Mais il faut aller plus loin encore, peut-être des travaux à faire à plusieurs..
9. Un esprit de communauté, d’équipe, même si on est seul devant l’ordinateur, il ne faut pas rester seul dans le MOOC.
10. Le moyen d’aller plus loin (vidéo d’expert, URL etc..), si on veut passer 35h/semaine sur le MOOC ce doit être possible..
11. Un coté décontracté et sérieux à la fois, dans les vidéos, les textes..
12. Une pédagogie forte, qui s’appuie sur des exemples simples et compréhensibles par tous.
13. Une disponibilité de la plateforme 24h/24h

Voici ma vision du MOOC idéal.

des liens sur le sujet :

1. http://parlonsmooc.fr/QuEstCeQuiFaitUnBonMooc.htm
2. https://www.fun-mooc.fr/
3. https://unow-mooc.org/
4. http://openclassrooms.com/
5. http://mooc-francophone.com/
6. http://www.firstbusinessmooc.org/
7. http://www.france-universite-numerique.fr/
8. La révolution MOOC, Matthieu CISEL

Liens vers mes badges « gagnés » sur unow : badge.unow.fr

Retour d’expérience écran tactile grand format

Dans le cadre de l’amélioration de nos outils de production, nous avons développé une interface de classification de documents, sur un écran tactile 23″.

Nous avons développé en interface tactile, car l’utilisateur classifie des images numérisées en recto-Verso et on souhaitait lui présenter une interface et une utilisation proche de celle qu’il avait avant avec les originaux papiers.

Dans notre contexte, l’utilisateur est assis devant cet écran qui est dans la position habituelle d’un écran d’ordinateur, mais plus proche et plus penché.

L’objet de cet article est le retour de cette expérience.

Le développement a été fait en utilisant WPF en C# avec Visual Studio 2012, aucun soucis à ce stade.

Les retours au niveau interface, par rapport à une interface souris, sont les suivants :

– les zones sensibles doivent être plus grandes,
– les zones les plus utilisées doivent être en bas de l’écran,
– les barres de défilement doivent être adaptées (plus large)

Les points de vigilance sont :

– l’écran doit être penché, il doit être assez proche de l’utilisateur
– l’écran ne doit pas être brillant car son inclinaison peut être la cause de reflet (lumière d’en haut)
– prendre en compte la fatigue des membres plus sollicités que lors de l’utilisation de la souris
– la nécessité de saisir de temps à autre, n’est pas pratique sur ce type d’écran. Il n’y a pas la  possibilité de faire apparaître le clavier à l’endroit de son choix. Le fait d’utiliser un vrai clavier éloigne de l’écran l’opérateur, ce qui n’est pas bon dans ce contexte.

Au final, après plusieurs mois d’utilisation, on s’aperçoit, un abandon pour certains opérateurs et un retour à la souris, d’autres utilisent un mixte souris/écran tactile. aucun n’est au final resté au tactile pure.

Attention : une simple mouche sur l’écran peut être prise en compte par le système, voir une simple poussière … 😉

5 ans de développement en méthode Agile, retour d’expérience

Pourquoi cet article ?

Tout ce que j’ai lu et appris sur le sujet concerne des équipes qui sont sur un seul projet, ce qui n’est pas notre cas. Il m’a semblait intéressant de partager cette expérience très différente du mono-projet.

En plus de lire sur le sujet, nous sommes allés à plusieurs reprises aux conférences proposées dans le cadre de l’Agile tour : http://at2013.agiletour.org/fr/at2013_bordeaux.html

Cela fait environ 5 ans que l’on travaille en méthode agile, mélange d’EXtrême Programming (XP), scrum et sauce maison.

Voici le contexte :

• Service informatique dans une société qui n’est pas une SSII, l’équipe est composé de 15 développeurs
• il y a en parallèle une dizaine de projets, avec des équipes de 3 développeurs, jusqu’à 1/4 de développeur
• Les développements concernent en grande partie les besoins internes à l’entreprise
• Développement en C#, l’équipe de développement à une moyenne d’age de 27 ans (je ne me compte pas dedans .. heureusement pour la moyenne…)

Nous avons au fil du temps testé différents aspects :

• Le management visuel
• les planning poker
• les post-it
• le travail en binôme
• les tests unitaires
• les tests fonctionnels
• les points quotidiens avec le client
• Le refactoring de code
• etc..

Les points positifs qui dans le temps tiennent :

• le travail en binôme, qui apporte un plus réel au niveau polyvalence, formation, arrivé de nouveaux développeurs
• le planning poker, qui en comparant l’estimation et le réel donne d’excellent résultat. Des alertes naturelles sont faites, afin d’éviter de refaire un code déjà réalisé sur un autre projet
• les test fonctionnels, mais qui restent difficiles à automatiser, au regard de nos applications (clients lourds et clients légers, contexte parfois difficile à reproduire etc…)
• La notion de fiche scénario courte, qui donne un sentiment, pour le développeur d’une bonne journée. On essai de faire des fiches d’une 1/2 journée et pas de 5 jours.
• l’effet tunnel qui n’existe plus

Les points négatifs :

• l’utilisation des post-it, qui n’a pas de sens en multi-projet, qui tombent, qui sont trop petits pour tout écrire dedans etc..
• le travail en binôme, si décalage important de niveaux ou dans un contexte de développement simple
• la notion d’itération qui ne peut être unique si multiples projets
• l’ambiance de l’équipe par des pastilles de couleurs, n’a pas marché, même si cela donnait une bonne vision par jour et dans le mois du ressenti de l’équipe.
• Les points quotidiens avec le client, sont difficiles à faire, en raison notamment de la charge de nos clients internes. Ceux qui peuvent jouer le jeu ont de meilleurs développements, c’est indéniable.

Même si on peut voir que tout n’est pas utilisé les grands concepts sont compris et appliqués, par exemple :

• En parallèle nous faisons les tests, les développements et le manuel de référence. Il y a donc 3 lectures différentes de ce qui doit être réalisé.
• la part de test a explosé et à permis d’avoir des développements plus fiables
• On ne développe plus que ce qui est demandé par le client
• On ne pose plus de questions au client du type « est que cela pourrait vous intéresser ? »
• Le client est plus en avant qu’avant.. ce qui est l’essentiel, pas de surprise pour lui ..

En espérant que cet article aidera des équipes de développement comme la notre…