Tutorial Scrum : l'agilité et la priorisation par la valeur

Dans la section Informatique

Une Image...

Top Articles

Joomla Templates

Tutorial Scrum : l'agilité et la priorisation par la valeur

Informatique - Méthodes

Écrit par Vincent MARTIN

Comme dans le tutorial sur les niveaux de maturité de CMMI, voici une analogie (minière, d'où le wagonnet) pour aborder quelques-uns des principes de l’agilité et de la méthode Scrum. Simple et facilement compréhensible, elle permet de donner un premier aperçu de la méthode et d’en montrer clairement les principaux bénéfices.

Le principe général de fonctionnement de la méthode Scrum est bien connu, surtout si vous avez pris la peine de lire mes précédents billets (L’essentiel de Scrum) : le carnet de produit est une liste d’items à réaliser pour la réalisation du projet ; de ce carnet de produit, on extrait régulièrement, en fonction de leur valeur métier (les plus valorisés en premier) un ensemble d’items ; ce sont ces items qui sont pris en compte lors du prochain sprint (itération) ; d’une durée généralement constante sur le projet, le sprint délivre un incrément du logiciel, potentiellement livrable et utilisable ; chaque jour du sprint, l’équipe projet, le Product Owner et le Scrum Master font brièvement le point sur leurs actions en cours lors de la mêlée quotidienne (daily scrum).

Schématiquement, cela se passe donc selon la figure ci-dessous :

Imaginons maintenant qu’à la place d’un processus de développement logiciel, on soit en présence d’un processus de transformation minier ; le product backlog est remplacé par du minerai directement extrait de la mine ; le processus de transformation (par exemple : transport en début de chaîne de transformation, tri, concassage, rinçage, traitements chimiques, jusqu’à la fonte des lingots) est connu et a priori globalement satisfaisant. On peut aussi imaginer que le minerai n’est pas homogène, et que la teneur en métal des différents lots, en fonction de leur provenance, est connue, d’où une valorisation des différents lots (les items) de minerai qui constituent le minerai à traiter (le backlog).

Notre exemple permet d’aborder quatre principes de Scrum et de l’agilité : l’itérativité (le minimum pour une méthode agile), la priorisation par la valeur (Scrum), l’amélioration du processus et l’optimisation de la production.

Premier principe mis en œuvre, donc : l’itérativité.

Si l’on décide d’adopter un traitement type « développement en cascade », c'est-à-dire de traiter l’ensemble du minerai en une seule fois, on ne pourra récupérer les lingots de métal qu’à la fin du traitement. Si, en revanche, on décide de suivre un processus itératif, de nouveaux lingots seront disponibles à chaque fin d’itération, et ce dès la fin de l’une des premières (voire la première) itérations.

Quelle est la méthode qui délivre le plus rapidement de la plus-value ?

Si le processus s’avère défaillant, ou que le traitement de transformation, pour une raison ou pour une autre, doive être interrompu (panne, destruction, arrêt de la transformation), quelle est la méthode ou l’on pourra, tout de même, avoir quelque chose de produit (des lingots) ? Quelle est celle où le prix de l’échec est le moins élevé ?

Deuxième principe : la priorisation par la valeur.

Si les différents items (les lots de minerai) qui constituent le backlog (l’ensemble du minerai) peuvent être valorisés (en fonction par exemple de leur teneur en métal et de la valeur de ce métal), Scrum dit qu’il est plus intéressant d’appliquer le processus de transformation en commençant par les lots les plus précieux.

Prioriser le besoin n’est jamais facile (dans 90% des cas, lorsqu’on demande à un client ce qui est important, il vous répond : « tout ! »). Pour vous aider, ou aider votre client à attribuer une valeur à son besoin, il existe plusieurs méthodes. Parmi elles : le modèle de Kano.

Troisième principe : l’amélioration du processus.

Dans le cas où le processus de transformation doit être amélioré, les points d’amélioration pourront être détectés d’autant plus tôt que l’on pourra contrôler tôt la qualité du produit fini (le lingot dans notre cas).

Le processus Scrum permet de délivrer une version du produit fini dès la fin des toutes premières (voire la première) itérations. Si la qualité du produit est contrôlée à la fin de chaque itération, comme c’est le cas pour Scrum (rétrospective de sprint), il est possible d’identifier les points forts comme les défaillances du processus, et ainsi de l’améliorer.

Dernier point : l’optimisation de la production

Si l’on commence à prendre en compte (transformer) les items du backlog (les lots de minerai) en commençant par les plus précieux, cela signifie que l’on termine par les moins précieux. Arrivera peut-être un moment où, si les derniers items ont peu de valeur métier (faible teneur en métal, ou dans un métal peu onéreux), le valeur produite par chaque itération sera inférieure au coût de la mise en œuvre du processus pendant l’itération. En moyenne, dans un projet Scrum, ce seuil arrive lorsqu’environ 80% de la valeur métier a été produite.

Dans le cas de notre analogie, on peut alors se demander s’il faut continuer la transformation du minerai (le projet). D’un point de vue strictement comptable, la réponse est non. Après, tout est fonction du contrat qui lie la compagnie minière (la société du Product Owner) et le maître d’œuvre du processus de transformation (Scrum Master et équipe Scrum).

Que fait-on alors des tas de minerai qui n’ont pas été traités (les items restant dans le backlog) ? C’est une question qui n’est pas simple à trancher. D’un côté, pourquoi continuer à produire si la valeur produite est inférieure au coût de sa production ? De l’autre, cela a-t-il un sens de se priver d’environ 20% de la valeur métier ? Tout dépend évidemment du time to market, et de ce que peut apporter, par exemple vis-à-vis de la concurrence, une mise sur le marché anticipée.

Pour le reste, on pourra conserver les items manquants pour une version ultérieure, en attendant leur éventuel renchérissement. Au passage, c’est la stratégie que suivent aujourd’hui les compagnies pétrolières : les futures zones de prospection sont connues (pour la plupart), mais non utilisées du fait de leurs énormes coûts d’exploitation ; avec le renchérissement du prix du baril, leur exploitation redevient rentable. On retrouve notre analogie.

Un dernier point pour terminer : même si les méthodes agiles et Scrum en particulier s’opposent aux méthodes en cascade et à leur séquencement en phases, les activités correspondant aux phases existent toujours, et s’enchaînent toujours séquentiellement, mais elle le font au cours d’une itération. Dans notre exemple, le processus de transformation lui-même n’est pas en cause, et les opérations sont les mêmes que l’on traite séquentiellement ou itérativement le minerai livré par la mine.

Retrouvez tous nos articles sur www.computure.net

D'autres billet sur l'agilité et la méthode Scrum :

L'essentiel de Scrum : Scrum est aujourd'hui la méthode agile la plus utilisée et la plus riche en termes de retour sur investissement. Voici, en quelques billets, l'essentiel de la méthode. lire la suite...
L’ ess entiel de Scrum (suite). Un deuxième billet sur l’essentiel de la méthode, plus orienté cette fois sur les « cérémonies » (les réunions). lire la suite...
Le mineur, le missile et le marin, ou l'agilité par l'exemple : derrière ce titre aux allures de fable (« fabuleux » donc, selon la première acceptation du terme ), trois exemples parmi ceux que j’utilise parfois à propos de l’agilité et de ses principes. lire la suite...
Computure lance le projet DSA : Les dictionnaires sont à la mode. Les éditions Plon confient depuis quelques années un « Dictionnaire amoureux de ... » à des pointures du monde de la culture. A l'exception du format, évidemment imposé (le lexique classé alphabétiquement), le procédé laisse à son auteur toute liberté quant au choix de ses entrées et de ses textes. lire la suite...
Une expérience intéressante. Les méthodes de développement classiques demandent de spécifier en détail. A l’inverse, pour les méthodes agiles, une liste d’items peut suffire démarrer un projet. Sur ce sujet, voici une expérience intéressante. lire la suite...

Et dans la catégorie « Méthodes », retrouvez également les articles suivants :

Aider le client à prioriser ses exigences. Comment prioriser son besoin à l'aide du modèle de Kano. lire la suite...
Les exigences : définition et classification. La gestion des exigences est aujourd’hui une activité majeure de l’ingénierie du logiciel. Elle est couverte dans CMMI par deux domaines de processus : REQM (Requirements Management : niveau 2) et RD (Requirements Development : niveau 3). Voici le premier de quelques billets consacrés à l’essentiel de l’ingénierie des exigences… lire la suite…
Tutorial : les niveaux de maturité de CMMI. Tout le monde le sait : rien ne vaut une analogie pour comprendre un concept un peu abstrait. Lorsque j’explique les niveaux de maturité du CMMI (Capability Maturity Model Integration), j’utilise souvent une analogie, disons... domestique. lire la suite...
sans oublier le très populaire Petit lexique du chef de projet informatique.