2006, agilité timide

Ma première année de blog, qui a démarré le 4 avril.

Durée fixe des itérations

Lorsque je présente Scrum ou plus généralement une approche agile à un néophyte, il ne comprend pas bien pourquoi la durée des itérations (sprints) doit être fixe.

Je donne l’argument du rythme (sustainable pace) pour justifier cette recommandation, mais on ne peut vraiment la comprendre qu’une fois qu’on a pratiqué. L’intérêt d’avoir une durée identique pour toutes les itérations permet effectivement de donner un rythme à l’équipe et présente d’autres avantages : les revues sont plus faciles à organiser, les intervenants peuvent planifier à l’avance… C’est l’intérêt des blocs de temps (time box).

Poules et cochons

Poules et cochons

C'est l'histoire d'une poule et d'un cochon qui…

Quand j’ai lu cette histoire de “pigs and chickens”, puis quand on me l’a racontée lors de la formation, je l’ai trouvée pour le moins naïve et pour tout dire très américaine. On m’avait proposé d’en faire le thème de ma présentation lors des Valtech Days. J’avais refusé trouvant cela un peu anecdotique dans l’ensemble de Scrum.

OpenUP

Un processus de la communauté Eclipse

Jeudi dernier j’ai fait une présentation dans le cadre du Cercle Génie Logiciel de Toulouse. Le sujet principal était la modélisation de processus de logiciel.

Quels processus sont utilisés dans les entreprises ?

Quelle est la pénétration des processus itératifs et agiles ? Les sondages et les enquêtes se multiplient.

La dernière enquête publiée est celle de VersionOne. J’en avais déjà relaté plusieurs dans des billets précédents, dont celui-ci.
J’avais moi-même lancé un sondage. Je viens de refaire une enquête auprès de stagiaires à propos des processus utilisés dans leurs entreprises. Voici les résultats (25 réponses dont 22 significatives) :

OpenUP/Basic 0.9

Un processus agile ?

OpenUP est publié en Open Source par le projet EPF (Eclipse). La dernière mouture d’OpenUP/Basic apporte des compléments sur le positionnement. OpenUP se place dans le courant de pensée de l’Agilité.

C’est même dit dans le Getting Started :

…that takes an agile approach to software development.

Discipline et agilité

Discipline et agilité

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 empirique

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 ?"

Forfait agile

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.

Savoir finir une histoire

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.

Des histoires d'utilisateur

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 :

SchtroumpfMaster

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.

Roadmap IceScrum

Roadmap IceScrum

IceScrum 2.0 ?

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.

Résumé type pour une histoire

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 :

Vision agile

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.

La vie d'une histoire avant le sprint

La vie d'une histoire avant le sprint

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.

Backlog : critères pour établir les priorités

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.

Chèvre de montagne

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 !

Séminaire à Toulouse le 8 décembre

Le premier SIGMAT !

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 !

Backlog : quand examiner les priorités

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.

RUP vs Agile

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.