Discussion:Plateforme pédagogique/Feuille de route - Historique des versions

imported>Benjamin le 25 octobre 2019 à 16:32

2019-10-25T16:32:50Z

imported>Benjamin le 23 octobre 2019 à 16:03

2019-10-23T16:03:37Z

imported>Benjamin le 23 octobre 2019 à 16:02

2019-10-23T16:02:58Z

imported>Najmam : /* Naji (23/10 13h15) */ nouvelle section

2019-10-23T11:12:35Z

Naji (23/10 13h15) : nouvelle section

imported>Najmam : mise en page

2019-10-23T11:11:27Z

mise en page

imported>Benjamin le 23 octobre 2019 à 07:26

2019-10-23T07:26:31Z

imported>Benjamin le 23 octobre 2019 à 07:24

2019-10-23T07:24:18Z

imported>Benjamin le 22 octobre 2019 à 19:10

2019-10-22T19:10:25Z

imported>Benjamin le 22 octobre 2019 à 15:41

2019-10-22T15:41:47Z

imported>Benjamin le 22 octobre 2019 à 13:47

2019-10-22T13:47:13Z

← Version précédente		Version du 25 octobre 2019 à 16:32
Ligne 125 :		Ligne 125 :
	Ensuite, on peut démarrer le 1er cycle, c'est à dire définir ce qu'on met dans la version 1 (sprint 1 pour reprendre le jargon scrum). Idéalement ca se fait en séance entre métier et admin/dev.		Ensuite, on peut démarrer le 1er cycle, c'est à dire définir ce qu'on met dans la version 1 (sprint 1 pour reprendre le jargon scrum). Idéalement ca se fait en séance entre métier et admin/dev.
	Le but est de constituer le contenu en US du sprint, en détaillant ensemble les US si besoin. Normalement un sprint a une durée fixe...évidemment dans notre cas ca pourra être variable. Mais je propose qu'on essaye de se fixer une durée de 1 mois, ce qui fera une nouvelle version / mois.		Le but est de constituer le contenu en US du sprint, en détaillant ensemble les US si besoin. Normalement un sprint a une durée fixe...évidemment dans notre cas ca pourra être variable. Mais je propose qu'on essaye de se fixer une durée de 1 mois, ce qui fera une nouvelle version / mois.
		+
		+	Dernière chose sur les user stories, idéalement il faudrait qu'elles respectent le principe du INVEST :
		+	https://yodiz.com/help/what-is-i-n-v-e-s-t/

← Version précédente		Version du 23 octobre 2019 à 16:03
Ligne 111 :		Ligne 111 :


−	== ~~Naji~~ (23/10 18h) ==	+	== Benjamin (23/10 18h) ==

	Hello Naji,		Hello Naji,

← Version précédente		Version du 23 octobre 2019 à 16:02
Ligne 109 :		Ligne 109 :

	3) S'inspirer de ResearchGate : pertinent ! Il faudra bien distinguer ce qui est utile à une activité de recherche et ce qui pourrait être utile dans notre cas. Quelqu'un a un compte dessus ? Delphine ? Pour ma part j'avais essayé d'en créer un l'année dernière, et vu que je n'avais pas d'adresse mail dans une institution de recherche, ma demande a été refusée. Et les copains thésards ont fini leur thèse :p		3) S'inspirer de ResearchGate : pertinent ! Il faudra bien distinguer ce qui est utile à une activité de recherche et ce qui pourrait être utile dans notre cas. Quelqu'un a un compte dessus ? Delphine ? Pour ma part j'avais essayé d'en créer un l'année dernière, et vu que je n'avais pas d'adresse mail dans une institution de recherche, ma demande a été refusée. Et les copains thésards ont fini leur thèse :p
		+
		+
		+	== Naji (23/10 18h) ==
		+
		+	Hello Naji,
		+
		+	Concernant le parcours utilisateur vs use cases, la différence est pas énorme pour moi donc c'est pas très grave d'utiliser l'un ou l'autre.
		+
		+	A propos des user stories tu as compris le principe;), mais petite précision tout de même :
		+	En fait, il faut le voir comme un objet de communication entre le représentant métier (si possible unique), et l'équipe d 'admin/dev moodle.
		+	En principe, elles sont écrites par ce représentant métier qui les regroupe dans un backlog (ensemble des users stories ordonnées par priorité).
		+	Donc pour moi la première étape, c'est qu'un représentant des enseignants (qui peut selon moi aussi représenter les simple "visiteurs") s'occupe de constituer ce backlog (premier tableau qu'on positionnera idéalement à gauche sur trello)
		+	C'est pas très grave si les US du backlog ne sont pas détaillées, mais à minima elles doivent être catégorisées par périmètre et priorisées.
		+	Pour la première , on peut évidemment le faire ensemble en remote si vous voulez, idéalement il faudrait 1 métier, les pilotes, toi et moi.
		+	Ensuite, on peut démarrer le 1er cycle, c'est à dire définir ce qu'on met dans la version 1 (sprint 1 pour reprendre le jargon scrum). Idéalement ca se fait en séance entre métier et admin/dev.
		+	Le but est de constituer le contenu en US du sprint, en détaillant ensemble les US si besoin. Normalement un sprint a une durée fixe...évidemment dans notre cas ca pourra être variable. Mais je propose qu'on essaye de se fixer une durée de 1 mois, ce qui fera une nouvelle version / mois.

← Version précédente		Version du 23 octobre 2019 à 11:12
Ligne 67 :		Ligne 67 :
	On m'a parlé de research gate, c'est pour chercheurs et scientifiques et apparemment c'est pas mal fait.		On m'a parlé de research gate, c'est pour chercheurs et scientifiques et apparemment c'est pas mal fait.
	Moi professionnellement, comme je suis ni l'un ni l'autre je n'ai pu avoir qu'un accès "visiteurs", mais avec ce rôle on peut accéder à la recherche...bref ca vaut peut être le coup de creuser un peu le fonctionnement de cette plateforme pour s'en inspirer.		Moi professionnellement, comme je suis ni l'un ni l'autre je n'ai pu avoir qu'un accès "visiteurs", mais avec ce rôle on peut accéder à la recherche...bref ca vaut peut être le coup de creuser un peu le fonctionnement de cette plateforme pour s'en inspirer.
		+
		+	== Naji (23/10 13h15) ==
		+
		+	Merci Lionel et Benjamin !
		+
		+	1) Je vous rejoins sur l'aspect incrémental + tester au plus tôt.
		+
		+	Parmi les fonctionnalités à développer, on peut identifier des groupes de fonctionnalités indépendantes ("orthogonales") des autres groupes. Disons "périmètres indépendants" histoire d'avoir un terme. Ces périmètres indépendants seraient :
		+	* pouvoir s'informer sur l'initiative
		+	** étape 1 : page d'accueil, pages de présentation ("c'est quoi ?" + "enseignants"), autres pages statiques. Sur la page d'accueil, pour pouvoir mener les tests d'utilisabilité tôt, remplacer les éléments "quelques discussions récentes" et "des exemples de cours" par des contenus figés, pas du tout issus de la base de données.
		+	** étape 2 : après avoir connecté les éléments de la page d'accueil à des contenus réellement présents sur la plateforme
		+	* en tant qu'enseignant, pouvoir m'inscrire, me connecter, et changer un mot de passe perdu
		+	* en tant qu'enseignant, pouvoir me présenter (profil) et trouver d'autres enseignants (annuaire + profil)
		+	* en tant qu'enseignant, pouvoir partager un cours
		+	* en tant qu'enseignant, pouvoir discuter autour d'un cours (qu'ils gérés par d'autres ou bien par moi)
		+	* en tant qu'enseignant, pouvoir discuter d'un sujet non attaché à un cours en particulier
		+	* (compléter avec les rôles support)
		+	Possible qu'un de ces éléments soit trop grand ou trop petit ou bien pas tant que ça indépendant d'un autre, corrigez-moi svp.
		+
		+	Merci Benjamin d'avoir parlé d'user stories et donné des exemples :)<br>
		+	Si je comprends bien, l'approche consiste à 1) écrire des user stories décrivant des besoins 2) conjuguer ça autour de fonctionnalités qu'on propose de fournir via la plateforme ; une user story se décline hiérarchiquement en plusieurs user stories 3) grouper ces fonctionnalités en périmètres indépendants.<br>
		+	Faute de temps, et parceque j'ai déjà trainé à répondre à Lionel, j'ai rédigé la liste ci-dessus assez rapidement et je n'ai pas fait les exercices 1) et 2). Faire l'exercice complet nous permettrait peut-être de révéler des choses ? Dans tous les cas, je vous invite à corriger/compléter la liste des périmètres.<br>
		+	''Au passage, vu vos professions, vous allez peut-être pouvoir m'aider à clarifier mon vocabulaire. Dans la feuille de route et le document de conception, j'utilise le terme "parcours utilisateur" sans en avoir de définition claire, et quand j'ai l'impression que ça ne colle plus trop je passe à "scénarios d'utilisation", puis "cas d'utilisation", et je cycle entre ces termes :p Si vous avez des définitions en tête qui marchent pour vous, je vous invite à les partager svp :)''
		+
		+	J'adhère à l'idée de travailler, sur chacun de ces périmètres, en cycles conception-implémentation-test. Ça nous permettra :
		+	* de dire "ça c'est fait" plus tôt et plus régulièrement. C'est bon pour le moral ♫ Il faut garder en mémoire que les tests en phase "on a intégré tous les périmètres ensemble" révéleront de nouvelles choses, mais ça a moins de chances de se produire que si on teste tout simultanément.
		+	* de concentrer les efforts d'un petit groupe
		+	* si les tests prennent du temps (ce qui ne dépend pas de nous), on gagne du temps en commençant à implémenter le périmètre Y pendant qu'on attend les résultats de test du périmètre X, vu qu'ils sont indépendants
		+	* d'introduire le test tôt dans la pratique de l'équipe, ce qui nous fait adresser des incertitudes (avec qui on les fait ? comment on s'y prend, si on a jamais fait de test d'utilisabilité ?) tôt, ce qui est généralement préférable
		+	* que les discussions au cours des tests soit plus riches. Par exemple, si le périmètre du test est "en tant que visiteur, je souhaite m'informer sur l'initiative Enseigner le Climat" et qu'on n'a pas à passer du temps sur la vue "liste des cours", ça nous laisse du temps pour demander "après avoir lu ces pages, quelles questions vous vous posez au sujet de l'initiative ?"
		+
		+	'''Actions :'''
		+	* Lionel, Benjamin, et qui veut : retours sur la liste des périmètres indépendants
		+	* X : éditer la feuille de route, en remaniant "vers la beta" en 2 sections "conception initiale" et "cycles conception-implémentation-test". Inclure la liste des périmètres indépendants ci-dessus, éventuellement corrigée.
		+	** (Naji) je n'aurai pas le temps de m'en charger avant ce week-end
		+
		+	2) Sur les plugins Moodle, je vous rejoins... dans l'idée. Oui sur l'aspect fouillu de Moodle par défaut, je l'ai utilisé aussi en tant qu'étudiant. Et sur mon installation locale, en effet, une de mes premières recherches a été ce qu'on peut enlever.<br>
		+	Il en est ressorti que des plugins Moodle, dans l'installation par défaut, il y en a un paquet (402 !), et leur nommage n'est pas forcément indicatif de ce qu'ils font. En fait, le code source de Moodle 3.7.x est structuré en plugins. Il me semble qu'il serait fastidieux de les désactiver un par un.<br>
		+	Ce qu'on veut, c'est que l'interface apparaisse claire aux enseignants. (Pour les visiteurs, l'idée est qu'ils ne s'aperçoivent même pas que c'est Moodle.) Pour y arriver, je pense qu'il vaut mieux partir de l'interface qu'il y a, et enlever ce qu'il y a ''de visible'' dont on ne se sert pas, limiter les façons de se perdre. Ça peut passer par désactiver des plugins, ça peut aussi passer par configurer l'interface pour les enseignants ("tableau de bord" + "blocs") et les empêcher de la changer, ce qu'un administrateur Moodle peut faire.<br>
		+	On dit peut-être la même chose différemment ?
		+
		+	3) S'inspirer de ResearchGate : pertinent ! Il faudra bien distinguer ce qui est utile à une activité de recherche et ce qui pourrait être utile dans notre cas. Quelqu'un a un compte dessus ? Delphine ? Pour ma part j'avais essayé d'en créer un l'année dernière, et vu que je n'avais pas d'adresse mail dans une institution de recherche, ma demande a été refusée. Et les copains thésards ont fini leur thèse :p

@@ Ligne 1 : / Ligne 1 : @@
-Ajoutez svp vos questions/remarques entre les deux barres horizontales ci-dessous.
+Vous pouvez cliquer sur "ajouter un sujet" ci-dessus, auquel cas mettez "Nom (date)" dans le sujet.
-----
+== Vincent (16/10) ==
 <code>Utilisateurs : tous les enseignants intéressés</code>
@@ Ligne 21 : / Ligne 17 : @@
 ''Vu et intégré (Naji 16/10 15h20)''
-------------
+== Lionel (16/10 22h45) ==
 Bravo pour la feuille de route ! Après lecture détaillée, ca m'a bien éclairé.
@@ Ligne 46 : / Ligne 40 : @@
 Du coup est ce que l'on n'a pas intérêt au début à désactiver le plus d'option/plugin possible pour que l'essentiel ressorte ?
-------------
+== Benjamin (22/10 15h30) ==
 Hello ! Bravo Naji pour la feuille de route.

@@ Ligne 68 : / Ligne 68 : @@
 Ce sont juste quelques exemples pour te donner l'idée générale.
-Il faudrait idéalement identifier de grandes fonctionnalités plus ou moins décrites dans inscription / recherche / partage / commentaire / historique / modération.., découper en lot et prioriser avec un ou deux "représentants métier", typiquement des enseignants qui vont utiliser la plateforme. Cela permettrait comme le dit Daniel d'avoir un fonctionnement en cycle cours dev - test et pouvoir corriger le tir plus rapidement.
+Il faudrait idéalement identifier de grandes fonctionnalités plus ou moins décrites dans inscription / recherche / partage / commentaire / historique / modération.., découper en lot et prioriser avec un ou deux "représentants métier", typiquement des enseignants qui vont utiliser la plateforme. Cela permettrait comme le dit Lionel d'avoir un fonctionnement en cycle cours dev - test et pouvoir corriger le tir plus rapidement.
 Je suis d'accord aussi avec la désactivation du maximum de plugins (quitte à réactiver plugin par plugin si besoin).

@@ Ligne 52 : / Ligne 52 : @@
 Hello ! Bravo Naji pour la feuille de route.
-Je rejoins Daniel sur le côté incrémental, plutôt que d'essayer dès aujourd'hui d’être exhaustif sur l'ensemble des fonctionnalités à implémenter.
+Je rejoins Lionel sur le côté incrémental, plutôt que d'essayer dès aujourd'hui d’être exhaustif sur l'ensemble des fonctionnalités à implémenter.
 On pourrait s'inspirer du modèle des user stories, utilisées assez souvent au sein des équipes agile scrum.
 Le template est le suivant :

@@ Ligne 74 : / Ligne 74 : @@
 Enfin, je pense que la plateforme pédagogique est un genre de réseau social académique, et comme il en existe déjà on pourrait s'en inspirer.
 On m'a parlé de research gate, c'est pour chercheurs et scientifiques et apparemment c'est pas mal fait.
-Moi professionnellement, comme je suis ni l'un ni l'autre je n'ai pu avoir qu'un accès "visiteurs", mais le rôle permet d'accéder déjà à la recherche...bref ca vaut peut être le coup de creuser un peu le fonctionnement de la plateforme pour s'en inspirer...
+Moi professionnellement, comme je suis ni l'un ni l'autre je n'ai pu avoir qu'un accès "visiteurs", mais avec ce rôle on peut accéder à la recherche...bref ca vaut peut être le coup de creuser un peu le fonctionnement de cette plateforme pour s'en inspirer.

← Version précédente		Version du 22 octobre 2019 à 13:47
Ligne 47 :		Ligne 47 :

	------------		------------
		+
		+	Benjamin (22/10 15h30)
		+
		+	Hello ! Bravo Naji pour la feuille de route.
		+
		+	Je rejoins Daniel sur le côté incrémental, plutôt que d'essayer dès aujourd'hui d’être exhaustif sur l'ensemble des fonctionnalités à implémenter.
		+	On pourrait s'inspirer du modèle des user stories, utilisées assez souvent au sein des équipes agile scrum.
		+	Le template est le suivant :
		+	"En tant que [X] je veux [Y] afin de [Z]"
		+
		+	Pour la plateforme, cela donnerait :
		+	"En tant qu'enseignant je veux accéder à du contenu de formation en ligne sur le climat pour pouvoir dispenser un cours sur le sujet auprès de mes étudiants"
		+	Et puis cela serait décliner en :
		+	"En tant qu'enseignant je veux pouvoir faire une recherche sur une plateforme regroupant du contenu structuré sur le climat, afin de m'en inspirer (le réutiliser) pour dispenser un cours"
		+	"En tant qu'enseignant, je souhaite pouvoir m'inscrire sur cette plateforme afin d'accéder au téléchargement du contenu"
		+
		+	Il y a aurait aussi, "en tant qu'enseignant, je souhaite partager mon support de formation sur une plateforme dédiée afin d'en faire profiter une communauté"
		+	..
		+
		+	Ce sont juste quelques exemples pour te donner l'idée générale.
		+
		+	Il faudrait idéalement identifier de grandes fonctionnalités plus ou moins décrites dans inscription / recherche / partage / commentaire / historique / modération.., découper en lot et prioriser avec le "product owner", ici vincent ou delphine. Cela permettrait comme le dit Daniel d'avoir un fonctionnement en cycle cours dev - test et pouvoir corriger le tire plus rapidement.
		+
		+	Je suis d'accord aussi avec la désactivation du maximum de plugins (quitte à réactiver plugin par plugin si besoin).
		+
		+	Enfin, je pense que la plateforme pédagogique est un genre de réseau social académique, et comme il en existe déjà on pourrait s'en inspirer.
		+	On m'a parlé de research gate, c'est pour chercheurs et scientifiques et apparemment c'est pas mal fait.
		+	Moi professionnellement, comme je suis ni l'un ni l'autre je n'ai pu avoir qu'un accès "visiteurs", mais le rôle permet d'accéder déjà à la recherche...bref ca vaut peut être le coup de creuser un peu le fonctionnement de la plateforme pour s'en inspirer...