Release et moi

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.

Release comme produit

Le dictionnaire du jargon français définit une release comme suit :

nom féminin. Version d'un logiciel effectivement diffusée, donc lâchée dans la nature. Synonyme de « Mise sur le marché ». Exemple : Unix system V release 4.

Cette définition me convient parfaitement. Elle dit clairement qu'il y a des versions qui ne constituent pas des releases. Dans le cadre d'un développement de type Scrum, on produit deux autres types de version :

  • la version démontrée à la fin d'un sprint. En plus d'être montrée lors de la revue, elle peut être utilisée par des clients sélectionnés pour qu'ils jouent avec, dans le but de limiter les risques sur l'ergonomie et le fonctionnel.
  • les versions intermédiaires produites pendant le sprint. Elles sont parfois appelées des builds. Elles sont utilisées par l'équipe de développement et le directeur de produit pour passer les tests fonctionnels.

Release comme période

J'appelle également release la période de temps qui permet de la produire[1]. J'aurais pu utiliser un autre terme mais je n'en ai pas trouvé qui aille bien. Alors je devrais dire le cycle de production d'une release.

Ce cycle est répété dans la vie du produit. Il se compose de 2 phases :
phase.jpg

La phase des sprints comprend les sprints et, éventuellement, des travaux nécessaires pour la livraison de la release :

sprints.jpg

Réponses aux questions de mes lecteurs

Si on attend que le backlog soit vide, cela suppose qu'il n'y a qu'une release donc?

Dans la vie d'un produit, c'est rare qu'il n'y ait qu'une release... Donc effectivement le backlog de produit contient toujours ce qui est à faire pour les releases à venir et ne devrait jamais être vide.

Je pense que Claude parle du backlog de release, qui en fait n'est qu'un sous-ensemble du backlog de produit

Je ne parle jamais de backlog de release mais ce serait effectivement le sous-ensemble du backlog de produit dont les éléments sont associés à la release courante.

Si chaque sprint est censé produire une version utilisable du produit, qu'est-ce que le sprint qui termine une release a de spécial ?

Sur le premier point j'y ai répondu ci-dessus. Un sprint produit une version utilisable mais pas lâchée dans la nature, comme la release. Si on peut faire des releases très souvent, pourquoi pas, on peut même imaginer des cycles de production de release ne contenant qu'un sprint. Cependant cela n'est généralement pas possible, pour 2 raisons :

  • les travaux de livraison ne sont pas négligeables et constituent un overhead à la production d'une release. On peut le faire tous les 3-4 mois, mais pas plus souvent. Je l'ai évoqué dans le dernier sprint d'une release.
  • pour être utilisable, une release doit comporter un ensemble de fonctionnalités minimal (MMF[2]) ce qui nécessite plusieurs sprints, surtout pour la première release.

Est-ce qu'on ne donne le produit aux utilisateurs finaux que lorsqu'on a terminé une release ?

oui. Avant on peut donner une version à quelques uns pour jouer avec.

Dans ce cas, j'ai du mal à concevoir une release à date fixe, car on ne peut pas être sur que tout soit fonctionnel... Quand on a des impératifs de fonctions à rendre disponible dans une version donnée, la release devra attendre que les fonctions souhaitées soient terminées pour être finalisée non?

Je connais plein de projets pour lesquels la date de fin de release est fixée à l'avance. L'objectif de l'équipe (y compris le directeur de produit) est de fournir un produit fonctionnel. Le directeur de produit doit s'assurer que les priorités permettent de finir les fonctions indispensables avant le dernier sprint.

Notes

[1] j'ai même écrit un billet sur le sujet

[2] minimal marketable features