Lorsque j'interviens pour introduire les méthodes agiles, je commence par évaluer le degré d'agilité souhaitable en fonction du contexte
Barry Boehm, est un des grands noms du génie logiciel, a publié Balancing Agility and Discipline qui présente des critères pour évaluer la quantité d’agilité à instiller. Certains critères sont discutés(personnel) ou utilisés de façon un peu binaire (criticité, taille), mais cela reste une vue du contexte à prendre en compte.
Scrum est un processus empirique. Ce qui ne veut pas dire un processus qui empire.
Avant-hier, je présentais Scrum comme étant un processus empirique à des étudiants. J’en vois quelques uns qui ouvrent des yeux ronds et puis la question qui vient :
" Qu’est-ce que ça veut dire, empirique ?"
Une approche agile pour des prestations au forfait
J’ai participé en septembre à une réponse à un appel d’offres. Le document de consultation donnait des indications sur la nature de la prestation demandée : une prestation au forfait comportant des livrables et engagement du délai de fourniture. En revanche, il ne donnait pas beaucoup d’informations sur le contenu de ces livrables. Impossible avec ça de faire une estimation raisonnable. Même dans un domaine -les processus- et dans un contexte que nous connaissions particulièrement bien.
Un principe des méthodes agiles est qu'une user story doit être complètement finie en une itération. Pas si facile…
Benoît a fait des investigations sur un projet que j’ai initié aux méthodes agiles. Un des constats qu’il fait est que de nombreuses user stories ne sont pas finies en une itération. Quelques unes durent même 5 itérations !
Ce problème est souvent dû à l’accostage développeurs-testeurs. Quand le testeur reçoit le logiciel à tester en toute fin d’itération, au mieux il découvre des erreurs qui ne sont pas corrigées dans l’itération, au pire il diffère ses tests à l’itération suivante.
Cela n’est pas spécifique à cette équipe, comme le montrent des billets récents de Kane Mar et Ed Gibbs.
C’est un dysfonctionnement sérieux auquel il faut s’attaquer.
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 :
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.
Le développement d’IceScrum a repris.
La version courante est IceScrum3, sortie en août. Les travaux effectués pour les releases 2 et 3 sont décrits dans le rapport de stage de Cédric. Le développement était au ralenti depuis la fin de son stage, mais le site du projet est actif, avec son wiki et ses forums. Il reçoit une cinquantaine de visites par jour en moyenne.
Une nouvelle équipe, composée de 5 personnes pour le moment, toujours avec Cédric, a commencé à travailler sur la release 4. L’objectif est de porter l’application de type client lourd actuelle sur un environnement J2EE. Cela devrait permettre de faciliter l’installation et l’utilisation du produit, et aussi améliorer les performances et assurer l’intégrité des données. Le développement se fait bien entendu avec Scrum et IceScrum. Le plan de la release prévoit 4 sprints de 2 semaines.
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”.
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.
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.
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.
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 !
Avec Laurent Bossavit, président de XP France, nous organisons le vendredi 8 décembre entre 16 heures et 19 heures un Séminaire d’Information Gratuit sur les Méthodes Agiles.
Au programme des retours d’expérience, des présentations, des débats, des démonstrations.
Ce premier SIGMA Toulouse, organisé en collaboration avec l’IUP ISI, se tiendra sur le Campus de Rangueil.
À noter sur vos agendas !
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 :
je fais un première passe sur les priorités une séance d’estimation a lieu avec l’équipe. Les exigences sont estimées en suivant les priorités que j’ai définies (la durée de la séance étant limitée, il est préférable de traiter en premier les exigences les plus prioritaires). j’ajuste les priorités en tenant compte des estimations. Je peux, par exemple, monter dans la liste une exigence estimée peu chère.
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 :
En 1999, c’était un cycle en V avec plan qualité qui était appliqué. A partir de 2000, j’ai introduit le RUP puis des variantes allégées. Les étudiants pratiquent un développement itératif et incrémental. A partir de 2005, je suis progressivement passé d’une approche style RUP à une approche plus agile type Scrum.
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.
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.
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 :
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.
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 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 ?
Je prépare une présentation pour le séminaire de vendredi. Mon idée était de présenter Scrum en une seule diapo, animée.
Je me suis battu avec OpenOffice Impress. Pour l’instant, j’en suis là (sans les animations) :
Non, ce n'est pas pour le téléthon ni pour la fondation de France, mais pour la fondation Eclipse.
Pour essayer Eclipse Project Framework Composer, j’avais pris comme exercice le “processus” Scrum, comme raconté dans ce billet et celui-ci.
Je me suis pris au jeu, j’ai complété la description de Scrum et j’ai continué en ajoutant l’utilisation d’Icescrum avec des “tool mentors”.
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.
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 ?
