Enseignement
Avec travaux pratiques
Les formations que j’ai faites cette année, pour mes clients industriels ou pour mes étudiants :
Ma première année de blog, qui a démarré le 4 avril.
Avec travaux pratiques
Les formations que j’ai faites cette année, pour mes clients industriels ou pour mes étudiants :
Dans Scrum (comme dans XP ou OpenUP), la rétrospective est la pratique recommandée pour améliorer le processus.
Lors des revues d’itération de vendredi, une discussion a commencé sur les fournitures relatives à la gestion de projet. Les équipes doivent-elles fournir une liste des risques, un relevé des heures passées, un bilan de l’itération ? Sous quelle forme cela doit-il être élaboré ? Ces informations doivent-elles être écrites ou présentées oralement lors de la revue ?
L'estimation des histoires d'utilisateur en points (story points) est une pratique qui suscite beaucoup de discussions.
Lors du séminaire du 8 décembre, Benoit est revenu sur ses doutes -dont il m’avait déjà fait part- dans la technique d’estimation en points. A partir des relevés individuels de charges sur les tâches, il a calculé les heures passées sur les histoires. Il a constaté que des histoires estimées à 2 points ont finalement pris plus de temps à développer que des histoires à 3 points. Il a mesuré que pour 2 histoires avec le même nombre de points, il pouvait y avoir des variations du simple au double dans les heures passées. Il a calculé qu’un point ça faisait en moyenne 1,25 h/j mais que la variance était importante. Cela le pousse à mettre en doute la technique d’estimation en points.
Feedback
Voici quelques commentaires après le séminaire de vendredi dernier. Encourageants ! Et des sujets à débattre pour une prochaine fois.
Non, ce n'est pas pour le téléthon ni pour la fondation de France, mais pour la fondation Eclipse.
Comme au cinéma
Un résumé du rôle, appelé Product Owner dans Scrum et Customer dans XP
Le directeur de produit [1] est le représentant du “métier” dans le projet.
Simple à comprendre, difficile à faire
La planification d'une release repose sur l'ajustement de 2 variables : le contenu et la durée
La planification agile permet de s’adapter à la situation courante : à tout moment on donne la priorité à ce qui apporte le plus de valeur.
Une release est une série de sprints. Mais quand arrête t-on de faire des sprints pour finir la release ? A la lecture du premier article de Scrum(1996), voilà comment on décide :
quand les variables de temps, de concurrence, d’exigences, de cout et de qualité concourent à sortir une release.
Que penser de ces variables ?
A la fin de chaque itération on livre un produit potentiellement livrable. Quel usage en fait-on ?
Qu’est ce qui fait la différence avec la fin de release où on livre vraiment le produit ?
Avec les méthodes Agiles, on cherche à obtenir un produit partiel potentiellement livrable- pour reprendre la formulation Scrum- à la fin de chaque itération. Lors de la revue de fin d’itération, l’équipe fait une démonstration de ce produit. Et après ?
La release, du demi-fond
Les présentations de Scrum, notamment les courtes, mettent particulièrement en évidence la notion de sprint. On comprend que la livraison du produit (complet) se fait suite une série de sprints et on pourrait croire que le backlog de produit a une vie uniquement liée à cette suite de sprints. En fait la vie du produit, et donc de son backlog, va bien au delà.
Après une série de sprints, il y en a une autre, puis encore une autre, jusqu’à la fin de vie du produit. J’ai pris l’habitude d’appeler une série de sprints une release. La release est le chainon manquant entre le produit et le sprint.
Comment expliquer à son directeur ce qu'est Scrum en 100 mots
Récemment une discussion sur le forum Scrum : comment expliquer à un DSI DG ce qu’est Scrum en 100 mots. Le point de vue est celui d’un ScrumMaster qui parle pour son équipe. Voilà ce que ça donne en français, avec mes adaptations, mais en restant dans l’esprit du texte anglais :
Quand une difficulté à estimer cache un risque technique.
Nous avions aujourd’hui une séance d’estimation pour le projet IceScrum2.0. Une cinquantaine d’histoires d’utilisateur déjà réalisées dans la première version client lourd Java sont à porter dans un environnement J2EE.
Plus d'information sur le séminaire du 8 décembre
Ci-dessous le programme du séminaire sur les Méthodes Agiles à Toulouse. Vous pouvez télécharger la Plaquette de présentation du SigmaT1, un grand merci à Frédéric. Pour vous inscrire et obtenir un plan d’accès, envoyez-moi un message.
Retours d'expérience sur ce qu'apportent les processus agiles
Je suis impliqué dans des projets étudiants depuis 8 ans. Avec en moyenne 7 projets en parallèle par an, cela fait plus de 50 projets suivis :
Le backlog de produit est mis à jour régulièrement. Les priorités sont revues. A quel rythme ?
C’est le Directeur Produit (product owner) qui définit les priorités. Quand je joue ce rôle sur des projets, j’utilise et mets à jour les priorités de la façon suivante :
Au début du projet, une fois que le backlog contient suffisamment d’exigences :
Le premier SIGMAT !
Mountain goat
Elle est agile, c’est sûr, cette chèvre qui n’existe pas dans les Alpes ni les Pyrénées, mais peuple uniquement les Rocheuses.
Ca doit être pour ça que Mike Cohn en a fait son emblème et a appelé sa société Mountain Goat Software. Comme si je m’appelais BouquetinLogiciel !
Sur quels critères baser les priorités ?
Un des points forts de Scrum est le backlog de produit, qui regroupe toutes les exigences, ce qui facilite leur gestion. Il est -techniquement- simple de définir les priorités entre les éléments du backlog. Mais sur quels critères se baser ?
Il faut d’abord bien comprendre que la priorité correspond à l’ordre de développement. Ce ne sont pas 2 notions différentes. La priorité est souvent comprise autrement -que pour définir le contenu des itérations-(voir ce billet précédent), tant qu’on n’a pas pratiqué Scrum.
Pour être sélectionnée et développée dans un sprint, un histoire d'utilisateur doit être dans un état nécessitant du travail avant le début de ce sprint
Un principe agile est qu’une histoire d’utilisateur soit développée et finie dans une itération. Une histoire possède une carte, une conversation et une confirmation. Ce qu’on met sur la carte, c’est le titre de l’histoire et cela est fait (bien) avant que l’itération ne commence. On pourrait croire qu’au début de l’itération on n’a que ça et que la conversation et la confirmation ont lieu pendant l’itération.
Il n’en est rien.
Pour être agile, il faut commencer par avoir une bonne vision
J’ai entendu parler pour la première fois de document Vision avec les premières versions du RUP, vers 1997. Un bonne vision, c’est quand même autrement utile que les documents d’EB (expression des besoins) ou les pseudo cahiers des charges que je lis souvent dans les entreprises.
En tant que…
Une histoire d’utilisateur est composée d’une “carte”, d’une conversation et de sa confirmation. Sur la carte (bristol, post-it, ou carte virtuelle), on écrit le “résumé de l’histoire”.
Mike Cohn, auteur de User Stories Applied, préconise l’emploi de la formulation suivante :
As a , I want so that
En français, cela donne :
IceScrum 2.0 ?
Scrum un nom bizarre pour une méthode utilisée dans l'informatique ?
J’ai déjà parlé de la visite de Michel et d’autres français chez Google : voyant marqué Scrum sur une porte, un de ces visiteurs a pensé au rugby " tiens ils font des mêlées chez Google ?". En Angleterre, en Australie et en Nouvelle-Zélande grandes terres rugbystiques et pour des français aussi donc, c’est une réaction normale -quand on n’a pas entendu parler de la méthode Scrum- on pense à la mêlée du rugby.
Les histoires d'utilisateur servent de rappel pour tenir des conversations et existent dans le but de faciliter la planification.
C’est clair ?
Je prépare une formation sur la façon de spécifier des exigences “agiles” avec des user stories. Bien sûr je me suis posé la question de comment traduire user story en français et j’ai regardé ce qu’en disaient les autres, dans la communauté XP :