J'ai posé quelques questions pour les partiels de décembre des étudiants et maintenant me voilà avec une pile de copies à corriger…
Cette année, mes questions étaient ouvertes et la correction n’est pas facile. Il me faut lire entre 5 et 8 pages bien remplies par étudiant. Avec une trentaine d’étudiants, ça doit faire dans les 200 pages.
Le plus souvent c’est plein de fautes d’orthographe. Dans la seule copie où je croyais ne pas en trouver, il est écrit à 2 lignes de la fin : “il … est choisit…”. Dommage, mais cela ne me gêne pas. Plus embêtant pour ma lecture, c’est que ce n’est pas toujours bien présenté ni bien écrit.
Mais j’y trouve quand même du plaisir à voir que ce que j’ai présenté a été bien compris. Et puis je découvre toujours quelques perles amusantes.
Comme le dit Kent Beck, c'est déjà le moyen de faire partager les pratiques de l'équipe
Un article d’InfoQ: Debating the Merits of Pair Programming rappelle que la programmation en binôme est un sujet des plus discutés parmi les pratiques que propose Extreme Programming.
Je viens de lire les prévisions de Fred Cavazza sur le Web2.0 et les anticipations de Louis Naugès sur la bureautique2.0. Et si on faisait l’exercice pour le domaine des méthodes Agiles ?
Nous sommes 33 sur le projet Wilos, c’est bien plus que la taille normale d’une équipe Scrum.
Wilos est un environnement d’exécution de processus. Il y a 32 personnes qui travaillent sur le projet, plus moi qui suis le directeur de produit. La première version de Wilos sortira fin mars. Scrum est appliqué, avec des sprints de 3 semaines. Sur le schéma, l’organisation que nous mettons en place, en adaptant Scrum à la taille de l’équipe.
L’équipe est formée de 3 groupes avec chacun 10 ou 11 personnes. Chaque groupe s’occupe d’un domaine fonctionnel identifié. En plus, un des groupes est plus particulièrement chargé de l’infrastructure.
Il y a un backlog de produit unique.
Formez toute l'équipe, pas seulement le Scrum master
On commence à trouver des formations en France sur Scrum et les méthodes Agiles. Par exemple, Valtech propose un cours de 5 jours “gérer les projets Agiles”.
Quelques commentaires sur le contenu du backlog de sprint :
les tâches, estimées en heures, ne devraient pas dépasser une vingtaine d’heures, soit environ 2 jours de travail pour une personne. Par exemple, une tâche qui s’appelle “Page JSP (interface)” et qui fait 40 heures est probablement le signe d’un travail à faire qui est mal identifié ou mal maîtrisé.
Quand et sous quelle forme le directeur de produit fournit les critères de tests d'une histoire d'utilisateur ?
Aujourd’hui j’ai défini des tests d’acceptation [1] pour des histoires d’utilisateur[2]. C’est mon boulot de directeur de produit[3] de préciser les critères qui permettront de s’assurer qu’une histoire est complète. C’est un exercice indispensable si on veut automatiser les tests d’acceptation. Si on n’automatise pas cela reste tout de même très important.
Par exemple pour l’histoire “En tant que participant à un projet, je démarre une tâche du plan”, des critères de test que j’ai identifiés sont :
Je viens de lire Project Management and Scrum – A Side by Side Comparison(pdf), une comparaison entre le rôle traditionnel de chef de projet (selon le PMBOK) et le rôle de ScrumMaster.
J'entends parfois : les méthodes agiles c'est bien mais chez nous on utilise encore le cycle de vie en V alors…
Un cycle de vie est un ensemble ordonné de phases décrivant la vie d’un projet, la phase n ne pouvant commencer que si la phase n-1 est terminée. Dans la représentation graphique du V, les boites s’appellent Spécification, Conception, Codage, Test et Validation pour prendre la variante la plus simple. La signification du nom de ces différentes boites est à peu prés claire : Spécification on décrit le quoi, Conception le comment etc. Il s’agit des disciplines classiques du développement de logiciel.
Le prochain Séminaire d’Information Gratuit sur les Méthodes Agiles de Toulouse aura lieu le vendredi 16 mars à 16 heures. Le premier SIGMAT du 8 décembre, organisé avec la collaboration de l’IUP ISI, a reçu un accueil favorable. Nous avons décidé de renouveler l’expérience et nous prévoyons d’en proposer régulièrement, 3 ou 4 par an.
Hier j’ai animé 2 sessions de planning poker. Contrairement à ce que cela laisse entendre, il ne s’agit pas de planifier mais d’estimer. Il ne s’agit pas non plus de poker d’ailleurs[1].
Comme le dit très bien Mike Cohn, le planning poker permet d’obtenir une estimation des histoires d’utilisateur(user stories) en points(les story points).
La revue de sprint commence par une démonstration du produit partiel réalisé lors du sprint.
Quelques commentaires suite aux démos de Wilos et Icescrum auxquelles j’ai participé hier en tant que directeur de produit :
le public n’apprécie pas d’attendre plusieurs minutes avant le début réel de la démo. L’installation et le raccordement au vidéo-projecteur doivent être rapides ou préparés avant
Scrum ne traite pas l'aspect modélisation. Ce n'est pas une raison pour ne pas en faire.
Dans la famille Agile, il y a Scrum, il y a XP et on trouve aussi la modélisation Agile.
Scrum donne un cadre dans lequel on peut appliquer des pratiques de modélisation Agile, de la même façon qu’on peut y inclure des pratiques XP, comme les user stories, la vélocité, le TDD…
Je viens de lire un article du Journal Du Net sur la méthode Agile Scrum. Je trouve l’explication très approximative, avec des choses bizarres comme les “4 activités qui s’enchaînent dans un sprint” et l’utilisation de “processus non linéaire” pour qualifier Scrum, ce qui me laisse perplexe. On pourrait aussi discuter de l’insistance à limiter l’utilisation de Scrum à de petites équipes.
Modification du 16 février : l’article du JDNet a été revu suite à mes propositions (voir le billet Correction d’article).
La réunion qui a donné son nom à Scrum est plus efficace si l'équipe dispose d'une aide visuelle comme le tableau des tâches
L’objectif de la mêlée quotidienne ou scrum est de :
Evaluer l’avancement du travail Identifier les obstacles nuisant à la progression Garder l’équipe concentrée sur l’objectif du sprint
L'estimation du temps qu'il reste à passer sur une tâche est plus importante que la mesure du temps qu'on y a passé
La pratique habituelle de gestion de projet consiste à estimer la durée de la tâche avant de la commencer, de relever les heures passées effectivement et d’analyser les écarts constatés.
Avec Scrum, on estime aussi la tâche, et on la ré-estime régulièrement (tous les jours !) pendant son déroulement. Cette ré-estimation s’appelle le reste à faire (RAF). On se préoccupe pas des heures consommées. Une erreur serait de croire que le RAF est l’estimé au départ moins le consommé. En effet on peut avoir estimé une tâche à 20 heures, avoir travaillé 2 heures dessus et se rendre compte que c’est plus facile que prévu et que 10 heures suffiront pour finir la tâche.
Le backlog est un élément clé dans le processus Scrum. Mais il y a plusieurs backlogs…
La notion de backlog n’est pas très difficile à comprendre : c’est une liste dont les éléments sont rangés par priorité. Mais le fait qu’il y ait plusieurs backlogs peut induire une confusion dans la compréhension de Scrum. L’article du JDNet dont je parle dans un billet récent parle de 3 backlogs : un backlog de produit, un backlog de release et un backlog de sprint. C’est une mauvaise interprétation, il n’y a en réalité que 2 backlogs[1] dans Scrum.
La rétrospective, qui fait partie intégrante de Scrum, est probablement la réunion qui est la plus négligée dans la pratique et c’est dommage parce que c’est un bon moyen d’améliorer le processus, moins lourd que le CMM-I…
La rétrospective est une réunion qui vient après la revue du sprint[1].
Scrum recommande que les membres de l’équipe soient invités à répondre à 2 questions :
qu’est-ce qui s’est bien passé pendant ce sprint ? qu’est-ce qui pourrait être amélioré pour le prochain sprint ?
Reformulation de ce qu'est la méthode agile Scrum dans un article du Journal du Net
Dans un billet précédent, je commentais un article du JDNet sur Scrum. Voici la version améliorée…
L’auteur de l’article m’avait suggéré dans un commentaire sur ce billet de proposer des améliorations. C’est ce que j’ai fait.
Mais comme il ne se manifeste pas et que l’article n’a pas été modifié sur le site du JDNet, je vous livre ma version améliorée, paragraphe par paragraphe.
Xavier Borderie vient de me signaler (16 février) qu’il a repris la quasi-totalité de ma réécriture et que la nouvelle version est en ligne.
Cette semaine, au cours de réunions avec des équipes différentes, j'ai eu l'occasion de constater que la croyance qui consiste à considérer une estimation comme un engagement est tenace
Mardi j’animais une rétrospective. On m’a remonté des difficultés à estimer des histoires d’utilisateur en points. Puis une fois l’estimation faite, les doutes qui persistent sur la qualité de ces estimations :
Et si une pour une histoire que nous avons estimée à 3 points, on s’aperçoit que finalement elle vaut 5 points ?
Vendredi lors d’une revue de sprint, j’ai assisté à la présentation d’un tableau montrant la liste des tâches du sprint qui se finissait. Pour chaque tâche, l’orateur (le ScrumMaster) a présenté l’estimation en heures faite au début du sprint et le nombre d’heures effectivement passées sur la tâche, en essayant de justifier les écarts.
Matthieu se demande, à propos des membres d’une équipe qui suit un processus Agile :
Si ceux-ci ne s’engagent pas sur leurs estimations, à quoi s’engagent-ils ?
Je prépare ma présentation de Scrum pour les séminaires Telelogic de mars.
Sur l’Agilité à grande échelle qui est le titre de ces séminaires, j’ai un peu de pratique et quelques idées tirées de mon expérience sur de grands projets.
Dans un billet précédent, je notais que la ré-actualisation en heures du reste à faire pendant un sprint était difficile à obtenir des équipes. Suite à la lecture de When is Scrum not Scrum, j’ai décidé d’essayer la technique proposée pour le suivi du sprint. Je la résume ci-dessous, en mettant en évidence les différences avec la pratique Scrum standard.
Pour obtenir la certification Scrum actuelle, il suffit de suivre un cours de 2 jours. Cela ne garantit pas que vous êtes devenu un maître de Scrum.
Je suis ScrumMaster certifié depuis 2005. J’apparais dans la liste des 10888 CSM[1] de la ScrumAlliance. J’y suis même 2 fois, ce qui me fait douter de la précision du chiffre et de la bonne gestion de la ScrumAlliance.
Ca m’a beaucoup amusé au début, plus d’être ScrumMaster (le côté rugby) que d’être certifié il est vrai. Pour cela, il m’a suffi d’assister aux 2 jours de cours dans une cave de Gentilly. En arrivant en retard. C’était la première formation Scrum en France et à l’époque l’aspect certifiant n’était pas du tout mis en avant.
Le Scrum enseigné dans les cours officiels et présenté dans les livres est un peu dépassé
Tobias Mayer, dans son billet When Scrum is not Scrum?, présente les adaptations qu’il apporte au Scrum de base et se demande s’il s’agit encore de Scrum. Si c’est intéressant, je ne trouve pas ça complètement nouveau : la plupart de ses propositions sont déjà pratiquées dans la communauté Scrum et j’ai déjà parlé de certaines dans mon blog.
Scrum fournit un cadre léger qui facilite le passage à l’Agilité. Les évolutions de Scrum (voir mon précédent billet) empruntent à XP. Cela s’amplifie encore dès qu’on ajoute à ce cadre de nouvelles pratiques d’ingénierie (TDD, binômage, etc.). On peut considérer que beaucoup d’utilisations sont hybrides au sens qu’elles combinent du Scrum et de l’XP.
Pour décider de la livraison d’une release, on a en gros 2 solutions :
dire que la release sera terminée quand le backlog sera vide. C’est ce qu’on appelle une release à périmètre fixé. La planification de la release permet d’estimer la date de fin. définir une date de livraison et s’y tenir absolument. C’est une release à date fixée. Avec une planification de release, on peut estimer quels éléments du backlog devraient être finis à cette date. On peut aussi décider de prendre une position intermédiaire avec la technique MoSCoW1 préconisée par DSDM.
En France on a tendance à abuser des notions de MOA et MOE
De nombreuses organisations utilisent intensivement ces acronymes. Personnellement je trouve que c’est de façon abusive, surtout quand on les utilise au sein d’une seule organisation ou pour des rôles alors que, historiquement, ces notions s’adressent à des personnes morales.
Mais l’essentiel n’est pas dans le nom. L’utilisation de MOA et MOE tend à créer une séparation très nette entre 2 groupes. Cela contribue aux problèmes suivants :
Les titres auxquels vous avez échappé :
lettre à release release tailor Suite aux commentaires sur le billet release à date fixée, je reviens sur la notion de release.
La confusion vient de ce que j’utilise release pour désigner à la fois ce qui est produit et la période de temps nécessaire pour le produire.
Une première photo-merci à Benjamin- où on voit une partie des 42 personnes qui ont assisté au séminaire.
La présentation de Thierry Cros sur le développement responsable est disponible sur son blog. La présentation d’Olivier Azeau sur les freins est disponible sur son blog Celles de Brice Jones (CPAM) et de l’équipe Wilos sont disponibles sur demande. Mes diapositives d’introduction et d’animation sont téléchargeables (Présentations).
Pour ceux qui ont lu mon billet sur la certification Scrum, le débat continue, dans le même sens, sur InfoQ qui se demande si la certification ScrumMaster est bonne pour la communauté Agile.
Ce n'est pas évident d'organiser les processus en catégories
Dans les séminaires ou dans les réunions, quand je présente l’agilité je montre les différences -généralement les bienfaits- par rapport à une approche… pas agile.
Cela revient à séparer le monde des processus en 2 parties[1], ce qui est très schématique… De plus comment qualifier la partie non agile ?
C’est la responsabilité de l’équipe Agile de passer ces tests, pas question de laisser ce travail à une équipe de testeurs indépendante qui attendrait la production d’une release pour commencer.
Les histoires d’utilisateurs doivent être finies à la fin de chaque sprint et a fortiori à la fin d’une release. Une histoire d’utilisateur est considérée comme finie quand elle a passé avec succès les tests d’acceptation qui l’accompagnent.
J’ai eu 13 retours sur les 42 personnes qui ont assisté au Sigmat2 (deuxième Séminaire d’Information Gratuit sur les Méthodes Agiles de Toulouse) du 16 mars.
A noter que les personnes qui ont assisté à ce Sigmat2 n’avaient pas assisté au premier Sigmat pour la plupart, seules 20% environ ont assisté aux 2 (et 4 parmi les 13 qui m’ont fait des retours). Il serait intéressant de savoir pourquoi ceux qui ont assisté au premier ne sont pas revenus. En tout cas ceux qui ont répondu ont l’intention de revenir. Je vous livre les retours :
Sans donner plus d'importance aux outils qu'aux personnes bien sûr !
Pour respecter le manifeste agile.
La présentation de Scrum que j’ai faite pour les séminaires Développez Agile à plus Grande Echelle de Telelogic à Toulouse, Paris et Bruxelles est disponible sur le site de Telelogic France.
Je reviens d’une semaine de déplacements dans le nord[1], ce qui fait que je n’ai pas alimenté le blog pendant cette période. Je ne pensais pas rester aussi longtemps, mais pour rester agile, j’ai adapté mon emploi du temps aux besoins de mes clients et partenaires.
Mieux vaut parler de méthodes agiles que de Scrum pour faire accepter l'idée de l'agilité sans effrayer la population, peut-être ?
J’ai fait la semaine dernière une présentation de Scrum à des personnes qui n’avaient jamais entendu parler des méthodes agiles. Ce n’est pas ce que je fais d’habitude et c’est à éviter pour des novices complets sur le sujet.
C’est qu’avec Scrum on utilise un langage particulier : sprint, scrumMaster, backlog, product owner, scrum daily meeting, etc.
Histoires d'utilisateur et cas d'utilisation, ce n'est pas la même chose
jc de QualityStreet présente les différences entre les cas d’utilisation et les histoires d’utilisateur. Son étude présente bien ce que sont ces 2 techniques, mais sa comparaison s’inscrit dans le cadre de techniques de spécifications des exigences fonctionnelles. Or les histoires d’utilisateur ne sont pas vraiment une technique de spécification.
Les différences exposées dans son billet entre ces 2 techniques sont donc à replacer à l’aune de cette distinction.
Mike Vizdos a finalement publié ma traduction du cartoon Pigs and Chickens. On y apprend aussi que oeufs au lard se dit jaja na boczku en polonais, ça peut toujours servir[1]. Bon pour savoir à quoi fait référence ce cartoon, il faut lire le texte qui lui est anglais ou si on préfère le français chercher un peu dans ce blog.
Plutôt que d'essayer de tout figer au début mieux vaut décider au dernier moment possible.
Il est impossible de connaître toutes les exigences[1] dès le début d’un projet. Depuis 20 ans j’ai participé à de nombreuses définitions et spécifications d’exigences dans différents domaines et il en a toujours été ainsi. En réfléchissant longtemps et en essayant d’imaginer les situations dans lesquelles se trouveront les utilisateurs, on peut bien sûr découvrir un bon nombre d’exigences significatives, mais il existera toujours des exigences que, même en se mettant dans la peau des utilisateurs, on ne pourra pas spécifier voire identifier à l’avance.
Après 3 mois de développement plutôt orienté OpenUp, 3 mois à suivre Scrum mâtiné de XP, le projet Wilos passe au développement communautaire[1] des logiciels libres.
Hier soir avait lieu au Hoegaarden café[2] la deuxième réunion de la communauté Wilos. Wilos a d’abord été développé dans un cadre universitaire, jusque fin mars. Le projet continue, hors de ce cadre, avec actuellement les 11 personnes qui se sont manifesté pour poursuivre l’aventure.
J’ai réalisé le doublé : je suis allé au Stadium samedi soir pour voir le TFC s’emparer de la 2ème place et j’y suis retourné cet après-midi pour la victoire du Stade Toulousain sur Clermont, au cours d’un match somptueux. J’aime bien la ferveur des stades [1]. Les 2 matchs ont été gagnés par Toulouse, le public était ravi, il y a eu des applaudissements et des olas.
J’ai quand même relevé des différences entre le foot et le rugby[2] :
La release de fin mars n'est pas utilisable de façon industrielle.
Aujourd’hui a eu lieu à la Brasserie du Stade[1] la première réunion de la communauté IceScrum. Petite communauté (3) pour l’instant, mais qui ne demande qu’à grandir.
L’état actuel d’IceScrum2 ne permet pas de le mettre à disposition des nombreux utilisateurs qui l’attendent avec impatience[2]. Il reste des fonctionnalités à finir et des bugs à corriger. L’utilisation de Scrum pour développer IceScrum2 n’a pas suffi pour obtenir une release de fin mars de qualité “agile”[3].
En principe une équipe ne devrait pas être perturbée pendant un sprint par du travail à faire suite à des évènements qui surviennent pendant le sprint. Pas toujours possible.
Quand une équipe Scrum travaille sur un projet qui a déjà produit une release, il arrive que pendant le sprint courant, une anomalie détectée sur la release en production nécessite une correction urgente. Pas possible d’attendre le sprint suivant [1]: il faut faire quelque chose (au moins corriger l’anomalie) pendant le sprint courant. C’est évidemment perturbant pour l’équipe mais inévitable dans certains environnements.
Sachant que ça peut arriver, une solution est de prendre ses précautions. C’est le cas de l’équipe pour laquelle je fais une formation actuellement. Elle prévoit un pourcentage de temps dédié[2] à ces travaux intempestifs[3] et en tient compte dans l’engagement qu’elle prend au début du sprint pour réaliser des éléments du backlog. Il est donc essentiel que le pourcentage alloué ne soit pas dépassé, sinon les engagements n’ont plus de sens et cela ne peut que démoraliser l’équipe. L’inconvénient de cette solution est qu’elle réserve du temps que l’équipe aura tendance à utiliser pour la maintenance en général et pas uniquement pour des choses urgentes. Elle oblige également à compter le temps passé sur ces travaux pour ne pas dépasser le plafond. De plus il n’est jamais sûr que ce plafond ne soit pas inadéquat dans un sprint où il y aura beaucoup d’urgences.
