Backlog pour les débutants
81 views
Skip to first unread message
Jean-Luc Lambert
Jun 14, 2012, 9:18:25 AM6/14/12
to enseign...@googlegroups.com
Bonjour à tous,
Le message d'Olivier m'incite à rebondir, je suis tout-à-fait en phase avec le fait qu'il faut enseigner des concepts plus que des principes et l'enseignement de l'agilité à des étudiants amène nécessairement à s'interroger sur les principes à enseigner pour que les étudiants parviennent à capter les concepts.
Cette année j'ai enseigné aux étudiants de licence à faire un Backlog pour leur projet tuteuré. Le projet tuteuré consiste en un développement logiciel fait par l'étudiant seul ou en binôme sur une période de 4 à 6 mois encadré par un tuteur. Mon enseignement vise à leur donner une approche de conduite de projet adaptée à ce cadre, qui n'est pas celui d'un atelier dont je serais l'animateur.
Je pars du principe que le Backlog doit être orienté vers le client et décrire l'usage du produit dans les termes du client. Ce principe est-il adapté à cet enseignement ? Je me pose la question, je crois qu'aucun étudiant ne réussit à écrire des stories sur son projet tuteuré, en tous les cas pas des stories telles que je les leur ai enseignées, comme par exemple:
En tant que permanent, sur le tableau de bord du conseil je peux visualiser la liste des livres demandés
Pourquoi ?Je n'ai pas de réponse certaine mais je pense qu'on cumule deux problèmes:
- Décrire l'application en petites unités maîtrisables, pouvant être priorisées, attribuées à des sprints et dont la liste va évoluer au cours du projet.
- Exprimer ce que sera l'application en termes d'usages par un client
Or pour un étudiant de licence, mais aussi je crois pour la plupart des enseignants, exprimer une application en termes d'usages par le client est très abstrait pour ne pas dire contre-intuitif alors que le découpage en petites unités est concret, pragmatique et relativement aisé à enseigner. Je crois qu'à vouloir exprimer le Backlog en termes de stories client on n'arrive qu'à ne pas avoir de Backlog du tout. Lorsque c'est moi le tuteur j'impose le backlog mais il n'est pas vraiment intégré par les étudiants.
Je me demande donc si un axe d'amélioration de mon enseignement de licence ne serait pas de leur faire réaliser un Backlog non pas à base de stories mais à base de mini-livrables (par exemple pour un site web: la page d'accueil, les pages d'administration, le menu...) lesquels devraient être justifiés par une description de leur usage par un client (par exemple l'enchaînement des écrans). Je crois qu'ils seraient, ainsi que leurs tuteurs, plus à l'aise avec cela et qu'il nous sera plus facile de faire un développement incrémental.
Bien sûr nous n'abandonnerons pas les stories mais on les fera plus tard dans le cursus, en mastère, quand ils auront un peu plus d'expérience.
Avez-vous déjà été confronté à des problèmes de ce type ? Avez-vous des solutions à proposer ? Ma proposition vous semble-t-elle raisonnable ou au contraire inadaptée ?
Merci pour votre aide,
Amicalement,
Jean-Luc
Bernard Notarianni
Jun 14, 2012, 9:51:08 AM6/14/12
to enseign...@googlegroups.com
> Avez-vous déjà été confronté à des problèmes de ce type ?
Oui. Le découpage incrémental d'une application est à mon sens une des
principales difficultés de l'agile. Les équipes préfèrent parfois ne
pas s'y frotter et rester dans un système proche de la cascade.
De mon expérience, la formulation des stories en tant que telle n'a
pas vraiment d'importance. Le format "canonique" (en tant que... ) que
tu décris peut parfois aider à trouver une formulation, mais pas
toujours. Le mieux est de laisser l'équipe trouver ce qui marche pour
elle.
> Avez-vous des solutions à proposer ?
complexification". J'utilise la métaphore d'une table de mixage audio,
sur laquelle l'équipe pourrait monter le niveau de complexité de
manière sélective sur plusieurs curseurs en parallèle. Des exemples
d'axes possibles:
- la sécurité
- la richesse d'une base de données
- synchro temps reel, ou pas
- etc...
Cela peut parfois aider à découper un gros sujet de manière incrémentale.
Il existe d'autres techniques qui marchent plus ou moins bien selon
les équipes et qui font l'objet de présentations dans les conf agiles,
par exemple le User Story Mapping.
Il faut également faire très attention aux solutions technique
retenues, car le découpage incrémental est intimement lié à la
capacité de l'équipe de livrer souvent un produit fini. Une
technologie compliquée à mettre en oeuvre sera plus pénalisante qu'une
techno plus simple.
Par exemple, il est fréquent d'entendre les équipes parler de "socle
technique" qui leur parait indispensable avant de pouvoir faire
quoique ce soit, et qui prendre plusieurs jours (semaines parfois) de
réalisation. C'est un anti-pattern dangereux qui peut planter un
projet rapidement.
> Ma proposition vous semble-t-elle raisonnable ou au contraire inadaptée ?
où dans chaque itération (une ou deux semaines) l'équipe est en mesure
de livrer plusieurs "mini-livrables".
Si vous avez un seul "mini-livrable" par itération alors c'est que
vous n'avez pas un découpage suffisamment fin, et vous perdez tout le
bénéfice de la planification agile basée sur une mesure de vélocité.
La formulation des stories, que ce soit sous forme de "En tant
que...", sous forme de "mini-livrable" ou autre n'est pas
fondamentalement importante. Cela devient critique uniquement dans des
contextes dans lequel les responsabilités sont floues, comme par
exemple lorsqu'il existe de nombreux rôles/responsabilités (chef de
projet, client, Maîtrise d'Ouvrage, Maîtrise d'Oeuvre, utilisateurs,
architecte, etc...) Il devient alors utile de formuler les stories
dans un langage non technique laissant la responsabilité de la
réalisation à l'équipe de développement.
Hope this help,
Bernard.
Géry Derbier
Jun 14, 2012, 10:07:56 AM6/14/12
to enseign...@googlegroups.com
Je pense qu'il faut enseigner au plus tôt la rédaction des cas d'utilisation sous forme textuelle. Ca peut-être effectivement un problème puisqu'il s'agit essentiellement d'écrire des phrases en français avec un sujet un verbe et un complément au présent de l'indicatif. Plaisanterie mise à part, c'est essentiel à mon sens.
Expliciter les objectifs métiers qu'ont des parties-prenantes vis-à-vis d'un système ne me parait pas extrêmement abstrait et contre-intuitif. Mais j'ai peut-être trop baigné dedans pour m'en apercevoir.
Je constate que les approches regroupées sous les vocables ATDD, Specifying by example, etc... reviennent à ça.
Je recommande bien entendu l'étude et l'enseignement de "Ecrire des cas d'utilisation efficaces" (et de préférence la version anglaise).
--
Géry Derbier
Tél : 06 31 57 89 08
Twitter: @Gery7
"La perfection est atteinte non pas quand il n'y a plus rien à ajouter mais lorsqu'il n'y a plus rien à enlever" - Antoine de Saint Exupéry
"Listen and play" - Miles Davis
Géry Derbier
Tél : 06 31 57 89 08
Twitter: @Gery7
"La perfection est atteinte non pas quand il n'y a plus rien à ajouter mais lorsqu'il n'y a plus rien à enlever" - Antoine de Saint Exupéry
"Listen and play" - Miles Davis
Emmanuel Gaillot
Jun 23, 2012, 4:51:18 PM6/23/12
to enseign...@googlegroups.com, Jean-Luc Lambert
Bonjour Jean-Luc,
> Le message d'Olivier m'incite à rebondir, je suis tout-à-fait en phase
> avec le fait qu'il faut enseigner des concepts plus que des principes et
> l'enseignement de l'agilité à des étudiants amène nécessairement à
> s'interroger sur les principes à enseigner pour que les étudiants
> parviennent à capter les concepts.
Disons que c'est une certaine manière de transmettre, qui convient bien
aux personnes qui apprennent en généralisant à partir de plusieurs
exemples. À ma connaissance (et ça a peut-être changé depuis l'époque où
j'étais à l'école) les structures d'enseignement françaises privilégient
une autre manière de transmettre, qui consiste à mettre en avant les
modèles abstraits, desquels les élèves peuvent ensuite déduire les cas
particuliers concrets.
Il me paraît intéressant de diversifier les manières de transmettre, car
cela permet de rendre plus efficace la transmission elle-même, notamment
auprès d'une population d'apprenants (dont je fais assurément partie)
qui a du mal à manipuler les concepts théoriques tant qu'elle ne peut
pas les rattacher à des cas concrets.
En revanche, je suis gêné à l'idée qu'il "faille" faire X "plus que" Y.
Je crains qu'il ne s'agisse là que d'un mouvement de balancier inverse,
qui risque d'exclure une autre population d'apprenants. Dit autrement :
au-delà de préférences personnelles, il me paraît important de raisonner
en termes d'objectif. S'il s'agit d'augmenter le nombre de personnes qui
"comprennent" l'agilité, j'aurai envie de suggérer un enseignement à la
fois des principes abstraits sous-jacents à une démarche agile (ex. :
mise en place de boucles de feedback) et des pratiques concrètes qui
illustrent (anecdotiquement, contextuellement) une mise en œœvre de ces
principes (ex. : livraisons fréquentes). C'est à mon avis de
l'aller-retour entre pratiques et principes que surgit la compréhension
de la pensée agile, plus que du privilège de l'un au nécessaire
détriment de l'autre.
> Je pars du principe que le Backlog doit être orienté vers le client et
> décrire l'usage du produit dans les termes du client. Ce principe est-il
> adapté à cet enseignement ?
C'est une question importante. Peut-être pourrait-on aller encore plus
loin en se demandant si les structures d'enseignement classiques sont
adaptées à l'enseignement de techniques de création d'un produit
tournées vers le client.
J'ai l'impression que ces structures d'enseignements (je parle ici des
écoles, instituts et universités de l'enseignement supérieur français)
vivent encore aujourd'hui dans une forte culture de la transmission de
connaissances, et que le débat principal est de savoir si telle ou telle
connaissance fait partie du corpus à transmettre.
La notion de client est largement absent de la culture de l'enseignement
supérieur, est c'est à mes yeux une très bonne chose. Il ne s'agit pas à
mon sens de satisfaire le besoin ou le désir d'un client, mais de
permettre à un groupe de sachants de transmettre leurs connaissances et
une certaine pensée critique qui permettra dans le futur de réévaluer la
pertinence de ces connaissances.
La frontière que je fais est probablement aujourd'hui rendue poreuse par
le fait qu'on attend des structures d'enseignement qu'elles "forment"
les élèves à un métier, qu'elles satisfassent les demandes du marché de
l'emploi. C'est à mon sens dommage.
Peut-être que ce n'est pas le rôle de l'enseignement supérieur français
d'enseigner les méthodes agiles. Peut-être qu'il n'y a rien à enseigner
sur ce sujet, d'ailleurs, sinon un ensemble de connaissances sur la
programmation, l'organisation du travail et la gestion de (ses)
relations interpersonnelles, qui manque cruellement aujourd'hui chez les
constructeurs professionnels de logiciel.
Ou alors - peut-être que c'est un rôle que l'enseignement supérieur
français peut assumer, au même titre que les universités américaines
assument aujourd'hui le rôle d'enseignement de disciplines de création.
Je soupçonne néanmoins que cela nécessitera un changement culturel
significatif.
Il se peut aussi que je me trompe complètement - mon raisonnement étant
surtout fondé sur mon expérience personnelle et quelques observations
qui sont loin d'être exhaustives. Si toi ou quelqu'un d'autre peut me
suggérer des lectures sur le sujet, qui me permettraient de m'en faire
une opinion plus solide (dans un sens ou l'autre), ça m'intéresse au
plus haut point.
> Avez-vous déjà été confronté à des problèmes de ce type ? Avez-vous des
> solutions à proposer ? Ma proposition vous semble-t-elle raisonnable ou
> au contraire inadaptée ?
Lorsque Olivier Pizzato et moi avons monté notre cours de Master hébergé
par l'École Polytechnique, nous nous sommes beaucoup posé la question de
comment favoriser l'apprentissage de techniques de travail d'équipe dans
un environnement où chacun est noté individuellement, de comment
favoriser une démarche où les élèves sont responsables de leur
apprentissage dans un environnement où c'est d'habitude le professeur
qui leur dit ce qu'il "faut" apprendre, de comment enfin habiter, en
tant qu'"invités" du monde de l'entreprise, un environnement qui en est
largement déconnecté (ne serait-ce que par sa situation géographique).
Il y a pour moi une responsabilité importante chez l'enseignant d'être
conscient du point jusqu'où il souhaite amener ou non ses élèves à
remettre en cause non seulement le savoir établi (ou pseudo-établi, dans
le cadre des métiers de la construction logicielle) mais aussi la
structure sociale qui permet la transmission du savoir. Selon moi,
l'enseignant a en particulier le devoir de mesurer combien il place ses
élèves dans une situation de contestation vis-à-vis de la structure
d'enseignement, sans leur donner les moyens d'assumer cette
contestation. À l'inverse, de combien il les place dans une situation de
soumission, qui les empêche de prendre du recul sur ce qu'ils pourraient
interpréter comme une situation d'échec. Je repense en particulier à cet
élève qui me disait que dans le cours à côté, le prof leur apprenait que
pour mener un projet correctement il faut suivre un processus phasiste
(specification, conception, implémentation, test, livraison). Et de me
demander, anxieux : "que dois-je répondre si la question tombe à son
examen ?"
Je ne pense pas qu'il y ait de réponse simple à la question de cet
élève, pas plus qu'aux autres questions que je soulève, et que tu
soulèves. En particulier, je ne pense pas qu'il y ait une "bonne"
réponse qui s'appliquerait à tous les contextes.
Plutôt que de décider de ce qui est raisonnable ou inadapté, je préfère
t'encourager à réfléchir à /ton/ objectif. Que cherches-tu à obtenir ?
En quoi la ligne d'actions que tu te proposes de suivre sert-elle cet
objectif ? Quels moyens te donnes-tu de mesurer la progression vers cet
objectif avant la fin du projet ? Qu'est-ce qui pourrait se passer de
travers ? Quels moyens te donnes-tu pour détecter les catastrophes à un
moment où tu pourras corriger ta ligne d'actions ?
Bien amicalement,
-- Emmanuel.
> Le message d'Olivier m'incite à rebondir, je suis tout-à-fait en phase
> avec le fait qu'il faut enseigner des concepts plus que des principes et
> l'enseignement de l'agilité à des étudiants amène nécessairement à
> s'interroger sur les principes à enseigner pour que les étudiants
> parviennent à capter les concepts.
aux personnes qui apprennent en généralisant à partir de plusieurs
exemples. À ma connaissance (et ça a peut-être changé depuis l'époque où
j'étais à l'école) les structures d'enseignement françaises privilégient
une autre manière de transmettre, qui consiste à mettre en avant les
modèles abstraits, desquels les élèves peuvent ensuite déduire les cas
particuliers concrets.
Il me paraît intéressant de diversifier les manières de transmettre, car
cela permet de rendre plus efficace la transmission elle-même, notamment
auprès d'une population d'apprenants (dont je fais assurément partie)
qui a du mal à manipuler les concepts théoriques tant qu'elle ne peut
pas les rattacher à des cas concrets.
En revanche, je suis gêné à l'idée qu'il "faille" faire X "plus que" Y.
Je crains qu'il ne s'agisse là que d'un mouvement de balancier inverse,
qui risque d'exclure une autre population d'apprenants. Dit autrement :
au-delà de préférences personnelles, il me paraît important de raisonner
en termes d'objectif. S'il s'agit d'augmenter le nombre de personnes qui
"comprennent" l'agilité, j'aurai envie de suggérer un enseignement à la
fois des principes abstraits sous-jacents à une démarche agile (ex. :
mise en place de boucles de feedback) et des pratiques concrètes qui
illustrent (anecdotiquement, contextuellement) une mise en œœvre de ces
principes (ex. : livraisons fréquentes). C'est à mon avis de
l'aller-retour entre pratiques et principes que surgit la compréhension
de la pensée agile, plus que du privilège de l'un au nécessaire
détriment de l'autre.
> Je pars du principe que le Backlog doit être orienté vers le client et
> décrire l'usage du produit dans les termes du client. Ce principe est-il
> adapté à cet enseignement ?
loin en se demandant si les structures d'enseignement classiques sont
adaptées à l'enseignement de techniques de création d'un produit
tournées vers le client.
J'ai l'impression que ces structures d'enseignements (je parle ici des
écoles, instituts et universités de l'enseignement supérieur français)
vivent encore aujourd'hui dans une forte culture de la transmission de
connaissances, et que le débat principal est de savoir si telle ou telle
connaissance fait partie du corpus à transmettre.
La notion de client est largement absent de la culture de l'enseignement
supérieur, est c'est à mes yeux une très bonne chose. Il ne s'agit pas à
mon sens de satisfaire le besoin ou le désir d'un client, mais de
permettre à un groupe de sachants de transmettre leurs connaissances et
une certaine pensée critique qui permettra dans le futur de réévaluer la
pertinence de ces connaissances.
La frontière que je fais est probablement aujourd'hui rendue poreuse par
le fait qu'on attend des structures d'enseignement qu'elles "forment"
les élèves à un métier, qu'elles satisfassent les demandes du marché de
l'emploi. C'est à mon sens dommage.
Peut-être que ce n'est pas le rôle de l'enseignement supérieur français
d'enseigner les méthodes agiles. Peut-être qu'il n'y a rien à enseigner
sur ce sujet, d'ailleurs, sinon un ensemble de connaissances sur la
programmation, l'organisation du travail et la gestion de (ses)
relations interpersonnelles, qui manque cruellement aujourd'hui chez les
constructeurs professionnels de logiciel.
Ou alors - peut-être que c'est un rôle que l'enseignement supérieur
français peut assumer, au même titre que les universités américaines
assument aujourd'hui le rôle d'enseignement de disciplines de création.
Je soupçonne néanmoins que cela nécessitera un changement culturel
significatif.
Il se peut aussi que je me trompe complètement - mon raisonnement étant
surtout fondé sur mon expérience personnelle et quelques observations
qui sont loin d'être exhaustives. Si toi ou quelqu'un d'autre peut me
suggérer des lectures sur le sujet, qui me permettraient de m'en faire
une opinion plus solide (dans un sens ou l'autre), ça m'intéresse au
plus haut point.
> Avez-vous déjà été confronté à des problèmes de ce type ? Avez-vous des
> solutions à proposer ? Ma proposition vous semble-t-elle raisonnable ou
> au contraire inadaptée ?
par l'École Polytechnique, nous nous sommes beaucoup posé la question de
comment favoriser l'apprentissage de techniques de travail d'équipe dans
un environnement où chacun est noté individuellement, de comment
favoriser une démarche où les élèves sont responsables de leur
apprentissage dans un environnement où c'est d'habitude le professeur
qui leur dit ce qu'il "faut" apprendre, de comment enfin habiter, en
tant qu'"invités" du monde de l'entreprise, un environnement qui en est
largement déconnecté (ne serait-ce que par sa situation géographique).
Il y a pour moi une responsabilité importante chez l'enseignant d'être
conscient du point jusqu'où il souhaite amener ou non ses élèves à
remettre en cause non seulement le savoir établi (ou pseudo-établi, dans
le cadre des métiers de la construction logicielle) mais aussi la
structure sociale qui permet la transmission du savoir. Selon moi,
l'enseignant a en particulier le devoir de mesurer combien il place ses
élèves dans une situation de contestation vis-à-vis de la structure
d'enseignement, sans leur donner les moyens d'assumer cette
contestation. À l'inverse, de combien il les place dans une situation de
soumission, qui les empêche de prendre du recul sur ce qu'ils pourraient
interpréter comme une situation d'échec. Je repense en particulier à cet
élève qui me disait que dans le cours à côté, le prof leur apprenait que
pour mener un projet correctement il faut suivre un processus phasiste
(specification, conception, implémentation, test, livraison). Et de me
demander, anxieux : "que dois-je répondre si la question tombe à son
examen ?"
Je ne pense pas qu'il y ait de réponse simple à la question de cet
élève, pas plus qu'aux autres questions que je soulève, et que tu
soulèves. En particulier, je ne pense pas qu'il y ait une "bonne"
réponse qui s'appliquerait à tous les contextes.
Plutôt que de décider de ce qui est raisonnable ou inadapté, je préfère
t'encourager à réfléchir à /ton/ objectif. Que cherches-tu à obtenir ?
En quoi la ligne d'actions que tu te proposes de suivre sert-elle cet
objectif ? Quels moyens te donnes-tu de mesurer la progression vers cet
objectif avant la fin du projet ? Qu'est-ce qui pourrait se passer de
travers ? Quels moyens te donnes-tu pour détecter les catastrophes à un
moment où tu pourras corriger ta ligne d'actions ?
Bien amicalement,
-- Emmanuel.
Jean-Luc Lambert
Jul 3, 2012, 11:37:19 AM7/3/12
to enseign...@googlegroups.com, Jean-Luc Lambert
Bonjour Emmanuel,
Merci pour ta réponse. Ton message comporte beaucoup de questions, qui pour la plupart me passionnent, mais auxquelles je ne peux répondre sans m'éloigner du sujet, bien spécifique, de cette discussion sur un Backlog pour les débutants. Je te répondrai donc mais pas ici.
Par contre ta question sur "ce que je cherche à obtenir" mérite que je précise ici ce que je cherche à faire. Mon cours de conduite de projet en licence a 3 objectifs qui sont de même priorité:
- Donner aux étudiants, pour leur projet tuteuré (réalisé en binôme ou individuellement), une base méthodologique qui leur permette de maîtriser un développement informatique
- Donner aux enseignants qui sont tuteurs de ces projets (et dont je fais partie) un appui méthodologique applicable à ce projet tuteuré
- Donner aux étudiants une base fondamentale de réflexes professionnels en matière de gestion d'un projet informatique
et c'est tout, mais c'est déjà pas mal. On apprendra plus en mastère plus tard.
Le principe de mon enseignement est d'apprendre peu de choses mais qu'elles résolvent effectivement des problèmes rencontrés par les étudiants. C'est en quelque sorte de l’apprentissage par résolution de problème. Je ne cherche pas à apprendre quelque chose qui corresponde à un savoir institutionnalisé. Je cherche d'abord à ce que cela marche, aussi bien du point de vue des étudiants que de celui de mes collègues.
Aujourd'hui le backlog ne marche pas sauf chez un ou deux étudiants qui ont fait sauter la contrainte d'exprimer des stories et ont alors parfaitement compris la priorisation et la maîtrise par l'évaluation des éléments du backlog. Je me dis donc qu'un backlog qui ne contient pas de stories mais plutôt des éléments techniques à réaliser est efficace pour leur apprendre à maîtriser leur projet dans ce cadre-là. Je m'interroge donc sur les bonnes idées ou les expériences que vous pourriez avoir eu à ce sujet.
Est-ce que le cadre est plus clair pour toi ?
Amicalement,
Jean-Luc
Jean-Luc Lambert
Jul 9, 2012, 11:39:55 AM7/9/12
to enseign...@googlegroups.com
Bonjour Emmanuel,
Je réponds à ton mail en dehors de la liste afin de ne pas dévier du
thème de la discussion.
Oui nous sommes d'accord sur la variété des modes d'apprentissages. Je
prône d'ailleurs de les varier et je n'hésite pas, par exemple, à faire
des cours d'amphi magistraux sur le sujet. Par contre je connais peu
d'étudiants capables d'en tirer quelque chose d'applicable (c'est un
truc de polytechnicien d'arriver à appliquer l'abstraction des cours
magistraux) ce qui ne signifie pas que les étudiants n'ont rien appris:
ils ont entendu un langage différent et une mise en perspective, ils en
tireront profit plus tard dans leur vie professionnelle. Je me sens un
peu gourou quand je fais mon cours d'amphi.
>
>
>> Je pars du principe que le Backlog doit être orienté vers le client et
>> décrire l'usage du produit dans les termes du client. Ce principe est-il
>> adapté à cet enseignement ?
>
> C'est une question importante. Peut-être pourrait-on aller encore plus
> loin en se demandant si les structures d'enseignement classiques sont
> adaptées à l'enseignement de techniques de création d'un produit
> tournées vers le client.
En général non mais on peut les détourner, en fait nous avons sur bien
des points de grandes liberté d'enseignement. Le problème c'est
d'arriver à le faire reconnaître par l'administration. Je ne penses pas
qu'il y ait de frein essentiel de ce côté mais on est fortement ralenti
par l'administration.
comme le juge de paix qui validera le résultat. L'aspect économique peut
être laissé de côté. J'ai donc besoin d'un client mais je ne fais pas
des cours de commerce pour autant.
>
> La frontière que je fais est probablement aujourd'hui rendue poreuse
> par le fait qu'on attend des structures d'enseignement qu'elles
> "forment" les élèves à un métier, qu'elles satisfassent les demandes
> du marché de l'emploi. C'est à mon sens dommage.
C'est largement un faux débat à mon avis. Personne ne nous demande de
satisfaire les demandes du marché par contre nous devons former des
étudiants capables de s'intégrer au marché du travail. Non pour
satisfaire une demande économique mais pour leur permettre de vivre dans
notre société. S'intégrer dans le monde du travail demande d'apprendre
et de comprendre des choses fondamentales aussi. Lorsque j'enseigne à
mes étudiants à se protéger en déclarant des risques projet, est-ce que
je leur apprend une technique professionnelle ou est-ce que je les fais
réfléchir sur l'univers dans lequel ils vont vivre ? A mon avis les deux.
>
> Peut-être que ce n'est pas le rôle de l'enseignement supérieur
> français d'enseigner les méthodes agiles. Peut-être qu'il n'y a rien à
> enseigner sur ce sujet, d'ailleurs, sinon un ensemble de connaissances
> sur la programmation, l'organisation du travail et la gestion de (ses)
> relations interpersonnelles, qui manque cruellement aujourd'hui chez
> les constructeurs professionnels de logiciel.
>
> Ou alors - peut-être que c'est un rôle que l'enseignement supérieur
> français peut assumer, au même titre que les universités américaines
> assument aujourd'hui le rôle d'enseignement de disciplines de
> création. Je soupçonne néanmoins que cela nécessitera un changement
> culturel significatif.
>
> Il se peut aussi que je me trompe complètement - mon raisonnement
> étant surtout fondé sur mon expérience personnelle et quelques
> observations qui sont loin d'être exhaustives. Si toi ou quelqu'un
> d'autre peut me suggérer des lectures sur le sujet, qui me
> permettraient de m'en faire une opinion plus solide (dans un sens ou
> l'autre), ça m'intéresse au plus haut point.
Pour ma part j'aime beaucoup les écrits de François Dubet (par exemple
"L'hypocrisie Scolaire"), ils concernent d'abord le collège mais
éclairent de façon essentielle les débats sur ce qui doit être enseigné.
En particulier il faut savoir que l'enseignement en France a toujours
privilégié la formation des clercs à celle des professionnels laquelle a
toujours été vue comme un dévoiement (qui se traduit par des slogans
comme "ne pas livrer l'école à l'entreprise"). Ton discours d'ailleurs
semble montrer que tu as été influencé par cette opinion, comme je l'ai
moi-même été. La raison est surprenante mais directement liée à
l'origine religieuse de notre enseignement laïc, l'enseignement est à
l'origine une institution visant à former une élite qui a besoin de
concepts lui permettant de penser et de comprendre le Monde, une culture
d’honnête homme en sorte.
Le problème est que cette vision élitiste est en totale contradiction
avec notre époque et ses 80% d'étudiants au Bac. Nos étudiants ne
viennent pas pour que nous leur donnions les capacités de comprendre le
Monde mais pour que nous leur permettions de trouver leur place dans la
société. Nous devons leurs enseigner des compétences. En soi ce n'est
pas une si grande révolution (on le fait déjà) mais ce n'est pas noble
et donc pas reconnu. Par exemple l'avancement des enseignants-chercheurs
est uniquement lié à leurs publications scientifiques et absolument pas
à leur enseignement.
L'exemple que tu cites est biaisé car ce n'est pas l'entreprise qui va
sanctionner l'étudiant mais son prof. Cela ne me pose aucun problème,
tout étudiant sait qu'à l'examen du prof X on doit ressortir le cours de
X. Ils font cela très bien.
Il me semble contradictoire avec notre rôle de formateur initial de
former uniquement à ce qui se pratique aujourd'hui. Les entreprises que
je rencontre nous demandent de former les étudiants à des techniques et
des concepts nouveaux. Je n'avais pas beaucoup d'estime, quand j'étais
dans le privé, pour un étudiant sortant de la fac et qui avait un
savoir-faire professionnel, il était forcément mauvais. Un étudiant
sorti de l'Université doit savoir des choses que l'entreprise ne sait
pas, c'est pour lui une valeur ajoutée importante. Et les étudiants nous
sont reconnaissants de leur apprendre des innovations qui remettront en
cause ce qui est pratiqué. Maintenant je suis d'accord il ne faut pas
faire n'importe quoi: il faut rester modeste et permettre à des
professionnels de présenter des points de vue différents du nôtre.
>
> Je ne pense pas qu'il y ait de réponse simple à la question de cet
> élève, pas plus qu'aux autres questions que je soulève, et que tu
> soulèves. En particulier, je ne pense pas qu'il y ait une "bonne"
> réponse qui s'appliquerait à tous les contextes.
Si je crois qu'il y a une bonne réponse (cf ci-dessus) mais elle ne
s'applique qu'au contexte de l'examen du prof d'à côté.
moi et je t'ai répondu sur la liste à ce sujet. Par contre ce n'est pas
le seul enseignement que je fais, et j'enseigne du management de projet
classique (risques, communication, plan projet etc) et dés l'année
prochaine je vais animer des projets en mode agile.
Mon objectif n'est pas d'enseigner telle ou telle méthode mais
d'inculquer des compétences aux étudiants. Je suis en train de réfléchir
à la liste des compétences attendues (un socle de base en quelque sorte)
des étudiants au terme d'un cursus licence-mastère, je te l'enverrai si
cela t'intéresse. Elle ne sera sûrement pas complète du premier coup.
Pour enseigner une compétence, j'utilise une ou plusieurs méthodes, mais
l'objectif de mon enseignement n'est jamais la méthode, c'est la compétence.
Pour corriger la ligne d'action, je me suis mis sur un poste de chargé
des relations avec le monde professionnel. Je m'occupe des stages, des
projets, j'anime le club agile caennais,... enfin je me donne
suffisamment d'occasions de voir ce que deviennent les étudiants que
j'ai formés: ont-ils les bonnes compétences ? On verra s'il faut corriger.
Bien amicalement,
Jean-Luc
>
> Bien amicalement,
> -- Emmanuel.
--
Jean-Luc LAMBERT
================================================
Professeur
Bureau S2 303
Universite de Caen - Departement Info / GREYC
6 Boulevard Marechal Juin, 14000 Caen
Tel: 02.31.56.73.72 Fax: 02.31.56.73.30
------------------------------------------------
"There is surely nothing quite so useless, as doing with great efficiency, something that should not be done at all."
Peter F. Drucker
Je réponds à ton mail en dehors de la liste afin de ne pas dévier du
thème de la discussion.
prône d'ailleurs de les varier et je n'hésite pas, par exemple, à faire
des cours d'amphi magistraux sur le sujet. Par contre je connais peu
d'étudiants capables d'en tirer quelque chose d'applicable (c'est un
truc de polytechnicien d'arriver à appliquer l'abstraction des cours
magistraux) ce qui ne signifie pas que les étudiants n'ont rien appris:
ils ont entendu un langage différent et une mise en perspective, ils en
tireront profit plus tard dans leur vie professionnelle. Je me sens un
peu gourou quand je fais mon cours d'amphi.
>
>
>> Je pars du principe que le Backlog doit être orienté vers le client et
>> décrire l'usage du produit dans les termes du client. Ce principe est-il
>> adapté à cet enseignement ?
>
> C'est une question importante. Peut-être pourrait-on aller encore plus
> loin en se demandant si les structures d'enseignement classiques sont
> adaptées à l'enseignement de techniques de création d'un produit
> tournées vers le client.
des points de grandes liberté d'enseignement. Le problème c'est
d'arriver à le faire reconnaître par l'administration. Je ne penses pas
qu'il y ait de frein essentiel de ce côté mais on est fortement ralenti
par l'administration.
>
> J'ai l'impression que ces structures d'enseignements (je parle ici des
> écoles, instituts et universités de l'enseignement supérieur français)
> vivent encore aujourd'hui dans une forte culture de la transmission de
> connaissances, et que le débat principal est de savoir si telle ou
> telle connaissance fait partie du corpus à transmettre.
C'est incontestable, je suis d'accord.
> J'ai l'impression que ces structures d'enseignements (je parle ici des
> écoles, instituts et universités de l'enseignement supérieur français)
> vivent encore aujourd'hui dans une forte culture de la transmission de
> connaissances, et que le débat principal est de savoir si telle ou
> telle connaissance fait partie du corpus à transmettre.
>
> La notion de client est largement absent de la culture de
> l'enseignement supérieur, est c'est à mes yeux une très bonne chose.
> Il ne s'agit pas à mon sens de satisfaire le besoin ou le désir d'un
> client, mais de permettre à un groupe de sachants de transmettre leurs
> connaissances et une certaine pensée critique qui permettra dans le
> futur de réévaluer la pertinence de ces connaissances.
Pour moi il n'y a pas de projet sans client mais on peut voir le client
> La notion de client est largement absent de la culture de
> l'enseignement supérieur, est c'est à mes yeux une très bonne chose.
> Il ne s'agit pas à mon sens de satisfaire le besoin ou le désir d'un
> client, mais de permettre à un groupe de sachants de transmettre leurs
> connaissances et une certaine pensée critique qui permettra dans le
> futur de réévaluer la pertinence de ces connaissances.
comme le juge de paix qui validera le résultat. L'aspect économique peut
être laissé de côté. J'ai donc besoin d'un client mais je ne fais pas
des cours de commerce pour autant.
>
> La frontière que je fais est probablement aujourd'hui rendue poreuse
> par le fait qu'on attend des structures d'enseignement qu'elles
> "forment" les élèves à un métier, qu'elles satisfassent les demandes
> du marché de l'emploi. C'est à mon sens dommage.
satisfaire les demandes du marché par contre nous devons former des
étudiants capables de s'intégrer au marché du travail. Non pour
satisfaire une demande économique mais pour leur permettre de vivre dans
notre société. S'intégrer dans le monde du travail demande d'apprendre
et de comprendre des choses fondamentales aussi. Lorsque j'enseigne à
mes étudiants à se protéger en déclarant des risques projet, est-ce que
je leur apprend une technique professionnelle ou est-ce que je les fais
réfléchir sur l'univers dans lequel ils vont vivre ? A mon avis les deux.
>
> Peut-être que ce n'est pas le rôle de l'enseignement supérieur
> français d'enseigner les méthodes agiles. Peut-être qu'il n'y a rien à
> enseigner sur ce sujet, d'ailleurs, sinon un ensemble de connaissances
> sur la programmation, l'organisation du travail et la gestion de (ses)
> relations interpersonnelles, qui manque cruellement aujourd'hui chez
> les constructeurs professionnels de logiciel.
>
> Ou alors - peut-être que c'est un rôle que l'enseignement supérieur
> français peut assumer, au même titre que les universités américaines
> assument aujourd'hui le rôle d'enseignement de disciplines de
> création. Je soupçonne néanmoins que cela nécessitera un changement
> culturel significatif.
>
> Il se peut aussi que je me trompe complètement - mon raisonnement
> étant surtout fondé sur mon expérience personnelle et quelques
> observations qui sont loin d'être exhaustives. Si toi ou quelqu'un
> d'autre peut me suggérer des lectures sur le sujet, qui me
> permettraient de m'en faire une opinion plus solide (dans un sens ou
> l'autre), ça m'intéresse au plus haut point.
"L'hypocrisie Scolaire"), ils concernent d'abord le collège mais
éclairent de façon essentielle les débats sur ce qui doit être enseigné.
En particulier il faut savoir que l'enseignement en France a toujours
privilégié la formation des clercs à celle des professionnels laquelle a
toujours été vue comme un dévoiement (qui se traduit par des slogans
comme "ne pas livrer l'école à l'entreprise"). Ton discours d'ailleurs
semble montrer que tu as été influencé par cette opinion, comme je l'ai
moi-même été. La raison est surprenante mais directement liée à
l'origine religieuse de notre enseignement laïc, l'enseignement est à
l'origine une institution visant à former une élite qui a besoin de
concepts lui permettant de penser et de comprendre le Monde, une culture
d’honnête homme en sorte.
Le problème est que cette vision élitiste est en totale contradiction
avec notre époque et ses 80% d'étudiants au Bac. Nos étudiants ne
viennent pas pour que nous leur donnions les capacités de comprendre le
Monde mais pour que nous leur permettions de trouver leur place dans la
société. Nous devons leurs enseigner des compétences. En soi ce n'est
pas une si grande révolution (on le fait déjà) mais ce n'est pas noble
et donc pas reconnu. Par exemple l'avancement des enseignants-chercheurs
est uniquement lié à leurs publications scientifiques et absolument pas
à leur enseignement.
sanctionner l'étudiant mais son prof. Cela ne me pose aucun problème,
tout étudiant sait qu'à l'examen du prof X on doit ressortir le cours de
X. Ils font cela très bien.
Il me semble contradictoire avec notre rôle de formateur initial de
former uniquement à ce qui se pratique aujourd'hui. Les entreprises que
je rencontre nous demandent de former les étudiants à des techniques et
des concepts nouveaux. Je n'avais pas beaucoup d'estime, quand j'étais
dans le privé, pour un étudiant sortant de la fac et qui avait un
savoir-faire professionnel, il était forcément mauvais. Un étudiant
sorti de l'Université doit savoir des choses que l'entreprise ne sait
pas, c'est pour lui une valeur ajoutée importante. Et les étudiants nous
sont reconnaissants de leur apprendre des innovations qui remettront en
cause ce qui est pratiqué. Maintenant je suis d'accord il ne faut pas
faire n'importe quoi: il faut rester modeste et permettre à des
professionnels de présenter des points de vue différents du nôtre.
>
> Je ne pense pas qu'il y ait de réponse simple à la question de cet
> élève, pas plus qu'aux autres questions que je soulève, et que tu
> soulèves. En particulier, je ne pense pas qu'il y ait une "bonne"
> réponse qui s'appliquerait à tous les contextes.
s'applique qu'au contexte de l'examen du prof d'à côté.
>
> Plutôt que de décider de ce qui est raisonnable ou inadapté, je
> préfère t'encourager à réfléchir à /ton/ objectif. Que cherches-tu à
> obtenir ? En quoi la ligne d'actions que tu te proposes de suivre
> sert-elle cet objectif ? Quels moyens te donnes-tu de mesurer la
> progression vers cet objectif avant la fin du projet ? Qu'est-ce qui
> pourrait se passer de travers ? Quels moyens te donnes-tu pour
> détecter les catastrophes à un moment où tu pourras corriger ta ligne
> d'actions ?
Mon objectif concernant mon cours pour le projet tuteuré est clair pour
> Plutôt que de décider de ce qui est raisonnable ou inadapté, je
> préfère t'encourager à réfléchir à /ton/ objectif. Que cherches-tu à
> obtenir ? En quoi la ligne d'actions que tu te proposes de suivre
> sert-elle cet objectif ? Quels moyens te donnes-tu de mesurer la
> progression vers cet objectif avant la fin du projet ? Qu'est-ce qui
> pourrait se passer de travers ? Quels moyens te donnes-tu pour
> détecter les catastrophes à un moment où tu pourras corriger ta ligne
> d'actions ?
moi et je t'ai répondu sur la liste à ce sujet. Par contre ce n'est pas
le seul enseignement que je fais, et j'enseigne du management de projet
classique (risques, communication, plan projet etc) et dés l'année
prochaine je vais animer des projets en mode agile.
Mon objectif n'est pas d'enseigner telle ou telle méthode mais
d'inculquer des compétences aux étudiants. Je suis en train de réfléchir
à la liste des compétences attendues (un socle de base en quelque sorte)
des étudiants au terme d'un cursus licence-mastère, je te l'enverrai si
cela t'intéresse. Elle ne sera sûrement pas complète du premier coup.
Pour enseigner une compétence, j'utilise une ou plusieurs méthodes, mais
l'objectif de mon enseignement n'est jamais la méthode, c'est la compétence.
Pour corriger la ligne d'action, je me suis mis sur un poste de chargé
des relations avec le monde professionnel. Je m'occupe des stages, des
projets, j'anime le club agile caennais,... enfin je me donne
suffisamment d'occasions de voir ce que deviennent les étudiants que
j'ai formés: ont-ils les bonnes compétences ? On verra s'il faut corriger.
Bien amicalement,
Jean-Luc
>
> Bien amicalement,
> -- Emmanuel.
--
Jean-Luc LAMBERT
================================================
Professeur
Bureau S2 303
Universite de Caen - Departement Info / GREYC
6 Boulevard Marechal Juin, 14000 Caen
Tel: 02.31.56.73.72 Fax: 02.31.56.73.30
------------------------------------------------
"There is surely nothing quite so useless, as doing with great efficiency, something that should not be done at all."
Peter F. Drucker
Emmanuel Gaillot
Jul 14, 2012, 12:46:49 PM7/14/12
to enseign...@googlegroups.com, Jean-Luc Lambert
Bonjour Jean-Luc,
> Aujourd'hui le backlog ne marche pas sauf chez un ou deux �tudiants qui
> �l�ments du backlog. Je me dis donc qu'un backlog qui ne contient pas
> de stories mais plut�t des �l�ments techniques � r�aliser est efficace
> pour leur apprendre � ma�triser leur projet dans ce cadre-l�.
C'est tentant, et effectivement, d'un point de vue pragmatique, cela
permet aux �tudiants de s'approprier l'outil de backlog.
N�anmoins, il me para�t malgr� tout important de replacer l'int�r�t du
backlog dans son contexte de gestion de projet. Pourquoi parle-t-on de
gestion de projet ? � mon sens, pour se donner les moyens de limiter les
risques que le produit final ne soit jamais livr�, ou alors avec un co�t
bien trop �lev� par rapport aux services qu'il propose.
En �tablissant une liste de priorit�s techniques, tu perds de vue que tu
veux pouvoir livrer le produit � tout instant (y compris d�s le d�part),
en particulier au moment o� on aura besoin de rentabiliser les co�ts de
d�veloppement avant d'investir davantage. Un des gros probl�mes des
co�ts dans la fabrication logicielle, c'est qu'au moment o� le sponsor a
investi tout son budget, il n'a toujours pas de produit qui fonctionne,
simplement des briques techniques qui doivent encore �tre assembl�es et
qui n'offrent pas forc�ment une couverture coh�rente du besoin m�tier.
Il doit alors soit continuer � payer plus que de raisonnable, soit
s'asseoir sur son investissement. L� est la raison pour laquelle on
cherche � d�velopper des fonctionnalit�s � chaque it�ration plut�t que
des �l�ments techniques. Et, comme tu le remarques, il s'agit l� de
quelque chose de tr�s difficile � faire, sous des abords trompeusement
simples.
Il y a effectivement d'autres aspects int�ressants au backlog
(focalisation sur une t�che, transparence sur l'avancement, pr�diction
fiable sur le rythme de l'�quipe, etc.) mais si l'utilisation du backlog
ne donne pas les moyens � l'�quipe de r�alisation de livrer un produit
qui fonctionne � n'importe quel moment, cela perd � mon sens beaucoup de
son int�r�t.
En ce sens, je t'encourage � consid�rer l'utilisation du backlog comme
une mesure de, si oui ou non, tes �tudiants arrivent � r�fl�chir en
termes de fonctionnalit�s produit. S'ils ressentent la tentation de
raisonner en termes de d�coupage technique, c'est probablement le signal
pour toi qu'il faut davantage travailler avec eux sur la notion de
fonctionnalit� utilisateur - que ce soit sous forme de "stories" ou non.
Bien � toi,
-- Emmanuel.
> Aujourd'hui le backlog ne marche pas sauf chez un ou deux �tudiants qui
> ont fait sauter la contrainte d'exprimer des stories et ont alors
> parfaitement compris la priorisation et la ma�trise par l'�valuation des
> �l�ments du backlog. Je me dis donc qu'un backlog qui ne contient pas
> de stories mais plut�t des �l�ments techniques � r�aliser est efficace
> pour leur apprendre � ma�triser leur projet dans ce cadre-l�.
C'est tentant, et effectivement, d'un point de vue pragmatique, cela
permet aux �tudiants de s'approprier l'outil de backlog.
N�anmoins, il me para�t malgr� tout important de replacer l'int�r�t du
backlog dans son contexte de gestion de projet. Pourquoi parle-t-on de
gestion de projet ? � mon sens, pour se donner les moyens de limiter les
risques que le produit final ne soit jamais livr�, ou alors avec un co�t
bien trop �lev� par rapport aux services qu'il propose.
En �tablissant une liste de priorit�s techniques, tu perds de vue que tu
veux pouvoir livrer le produit � tout instant (y compris d�s le d�part),
en particulier au moment o� on aura besoin de rentabiliser les co�ts de
d�veloppement avant d'investir davantage. Un des gros probl�mes des
co�ts dans la fabrication logicielle, c'est qu'au moment o� le sponsor a
investi tout son budget, il n'a toujours pas de produit qui fonctionne,
simplement des briques techniques qui doivent encore �tre assembl�es et
qui n'offrent pas forc�ment une couverture coh�rente du besoin m�tier.
Il doit alors soit continuer � payer plus que de raisonnable, soit
s'asseoir sur son investissement. L� est la raison pour laquelle on
cherche � d�velopper des fonctionnalit�s � chaque it�ration plut�t que
des �l�ments techniques. Et, comme tu le remarques, il s'agit l� de
quelque chose de tr�s difficile � faire, sous des abords trompeusement
simples.
Il y a effectivement d'autres aspects int�ressants au backlog
(focalisation sur une t�che, transparence sur l'avancement, pr�diction
fiable sur le rythme de l'�quipe, etc.) mais si l'utilisation du backlog
ne donne pas les moyens � l'�quipe de r�alisation de livrer un produit
qui fonctionne � n'importe quel moment, cela perd � mon sens beaucoup de
son int�r�t.
En ce sens, je t'encourage � consid�rer l'utilisation du backlog comme
une mesure de, si oui ou non, tes �tudiants arrivent � r�fl�chir en
termes de fonctionnalit�s produit. S'ils ressentent la tentation de
raisonner en termes de d�coupage technique, c'est probablement le signal
pour toi qu'il faut davantage travailler avec eux sur la notion de
fonctionnalit� utilisateur - que ce soit sous forme de "stories" ou non.
Bien � toi,
-- Emmanuel.
Reply all
Reply to author
Forward
0 new messages