Donner un nom de version aux itérations scrum / scrumban?

photo credit: NPF.1 via photopin cc

Lorsque l’on parle de sprint, on fait souvent référence à un numéro pour les identifier. On commence avec le sprint zéro pour aller vers des sprints où la vélocité devient de plus en plus précise. En maintenance logicielle, le développement d’une application peut s’étaler sur plusieurs années et comprendre de multiples versions. Dans ce contexte, donner un nom de version à chaque itération du cycle de développement présente certains avantages.

Les règles de nommage d’une version (technique) d’un logiciel sont définies par la personne en charge de l’application. Il est possible de définir une version technique (par exemple, une suite de quatre nombres séparés par un point) et une version commerciale (pour faciliter la communication autour d’un lot de nouvelles fonctionnalités par exemple).

Pour la version technique, certaines équipes adoptent le format A.B.C.D où chaque membre correspond à:
– A: la version majeure
– B: la version mineure
– C: la version de maintenance
– D: le numéro de build ou autre indicateur.

Utiliser le membre D comme incrément de sprint permet de faire le lien entre numéro de version technique, éléments compilés et numéro d’itération à laquelle est raccrochée de nombreux développements. Le membre D est réinitialisé à chaque fois que l’un des trois autres membres change.

Les avantages à adopter cette règle sont nombreux en maintenance.
1) Cette règle de nommage des itérations rend les développements sur les versions assez étanches. Lors d’un sprint, la version cible est évidente (2.10.0.5) et l’itération associée ne doit pas porter des éléments de travail d’un correctif à réaliser sur une autre version (2.8.0.0). Ce correctif sera à aménager dans le sprint par le responsable du projet.
2) En branche principale, les itérations sont assez courtes. En branche de maintenance, elles n’ont plus la même signification et peuvent s’étaler sur plusieurs mois (une itération peut par exemple accumuler des correction de bugs mineurs jusqu’à ce qu’un déploiement soit décidé).
3) Lorsqu’un bug se produit sur une vielle version d’un logiciel, il est assez facile de retrouver tous les éléments de travail de l’itération associée.

Ce procédé de nommage s’utilise assez bien avec la solution T.F.S où on pourra donner le même nom de version aux éléments compilés, aux branches de développements associées ainsi qu’aux « iteration path ».

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s