SCRUM : Gérer la maintenance, le quotidien au sein d’un Sprint

De Cyril Kirche dans Méthodes et Organisation

21 juil 2012

Gérer le quotidien au sein d’un Sprint (imprévus, incontournables, mises en production…)

Il s’agit de l’une des thématiques proposées et discutées lors de la journée Agile Innovation du 12 juin 2012. Voici une synthèse de l’atelier auquel j’ai participé. Pour faire simple nous considérerons ici que l’ensemble des imprévus est englobé dans la SMA (Support et Maintenance des Applications).

Le mode de production itératif, tel que préconisé par SCRUM, suppose que l’équipe travaille à 100% sur un projet, sans perturbation extérieure.
Malheureusement, il se peut que dans les faits, ces conditions optimales ne soient pas tenables.
Pour parler de notre cas (iMDEO), nous devons à la fois assumer le développement de projets au forfait, tout en assurant la maintenance corrective et évolutive de certaines applications avec des délais d’intervention contractualisés (bug bloquant 4 heures ouvrées).

Il se peut que SCRUM du coup ne soit pas forcément la bonne méthode agile à employer… mais cela pourra faire l’objet d’un prochain article. Cela fait en tout cas l’objet d’une réflexion intense :)
L’idéal serait bien sûr d’avoir une équipe dédiée pour chacune de ces activités mais :

1. Le volume de notre SMA est insuffisant pour occuper une équipe à plein temps

2. Les développeurs sont rarement motivés pour ne faire que de la SMA…

Chaque sprint démarre donc avec une part d’incertitude : quels vont être les tickets SMA qui vont tomber, et quel impact sur le planifié ?
Notre but est donc de limiter au maximum cet impact. Plusieurs moyens ou leviers sont à notre disposition :

1. Prévoir : la première chose à faire est déjà de prévoir un pourcentage de production consacré à la maintenance, quitte à traiter des scenarios en plus si on a prévu trop large . Il est toujours préférable d’avoir une bonne surprise que l’inverse.

2. La taille de l’équipe : plus vous avez de personnes productives, plus vous avez une forte capacité de produire le planifié, et moins les interventions de maintenance seront perturbantes au regard du volume total

3. La durée du sprint : si vous ne pouvez passer du jour au lendemain de 3 à 8 personnes, l’alternative est d’augmenter la durée du sprint. Si celui-ci dure 8 jours, et que 2 sont consacrés à la maintenance impossible de se rattraper pour atteindre les objectifs. S’il dure plus longtemps en revanche cela laisse plus de latitude pour s’organiser et lisser les imprévus dans le temps.

4. Définir clairement ce qui est urgent et ce qui peut attendre : il convient de faire un travail pédagogique auprès des clients et ne pas hésiter à requalifier les bugs s’ils ne sont pas majeurs ou bloquants, et planifier le cas échéant leur traitement (idéalement le sprint suivant).

Une donnée importante reste la vélocité de l’équipe… qui va permettre de prévoir, planifier au mieux d’un sprint à l’autre. Pour que celle-ci soit le plus proche de la réalité il peut être intéressant de pointer à posteriori les tâches dites réactives (imprévues).
Une autre problématique reste dans notre configuration qui traite quoi ? Nous avons essayé dans un premier temps de « griller » un développeur (que nous appellerons Jean) par sprint pour la maintenance. L’objectif était que chacun monte ainsi en compétence sur les différents projets concernés par un contrat SMA. Très vite nous avons abandonné :

1. Pour un projet inconnu Jean sollicitait constamment le « sachant » concerné… sans pour autant devenir sachant lui-même, car intervenant 1 fois tous les 6 sprints au mieux (pour une équipe de 6 développeurs)

2. N’ayant pas une vue globale de l’application, certaines corrections apportées pouvaient provoquer des “dommages collatéraux” ce qui du coup augmentait le volume de la maintenance … !

L’idéal semble être d’arriver à une auto-gestion de l’équipe : à chaque nouveau ticket, le « sachant » établit le diagnostic, quitte à ce que ce soit un autre que lui qui intervienne après concertation. Cela permet de limiter le temps d’intervention et de sécuriser au maximum celle-ci.
Enfin pour conclure, la meilleure solution, pour que la maintenance ne perturbe pas ou peu  l’équipe et sa production, reste d’améliorer constamment la qualité des développements :

Plus de qualité = moins de bugs… = moins de maintenance.

Commentaire

neuf − = 3

iMDEO recrute !

REJOIGNEZ-NOUS

A la recherche de nouveaux talents (développeurs web et mobile, chefs de projet,...)

Voir les annonces