Dans Scrum, il y a un terme que je n'apprécie plus trop: le Sprint.ITÉRATION OU SPRINT?
Après 130 jours ouvrés de développement, nous en sommes à notre septième itération et nous en avons encore pour plus d'un an de développement.
Déjà, nos itérations se sont transformées en sprints dans le sens premier du terme. Nous n'en sommes plus à un rythme durablement soutenable.
VÉLOCITÉ ET COURSE
Nous mesurons notre vélocité, nous la publions et nous l'utilisons pour planifier les itérations. Nous subissons une forte pression provenant de nous même comme du management pour améliorer continuellement cette vélocité.
Classiquement, une telle course à la productivité se fait au détriment de la qualité. C'est la nature même du développeur. Heureusement, le secteur du logiciel critique n'autorise pas de prendre la qualité comme variable d'ajustement. Alors, nous rognions sur certaines tâches de fond que nous poussons devant nous au risque de nous ralentir un jour. Par exemple, nous délaissons la réorganisation de la base de gestion de configuration, la rapidité du build et la rotation des développeurs sur les différentes parties de l'application.
TUNNEL ET TRANSPARENCE
Ce qui est fou, c'est que nous sommes à l'origine de cette course à la vélocité.
Avant, nos projets avançaient "tranquillement" dans un tunnel. La pression venait tard car nous n'avions que tardivement une vision objective et réaliste de l'avancement du projet.
Depuis quelques projets, avec la publication régulière d'une vélocité pertinente et des estimations basées sur cette productivité, nous sommes rapidement conscients de la partie immergée de l'iceberg. La vision réaliste du projet est vite révélée. Et la pression arrive tôt.
DU MOU
En rétrospective d'itération, l'équipe a identifié la course à la vélocité comme étant le principal problème à régler. Nous avons demandé à expérimenter la chose suivante: le premier jour d'une itération sera exclusivement consacré à des tâches de fond et à des améliorations. Ce jour là, personne ne cherche à produire un incrément de fonctionnalité. Cela peut paraître un peu maigre comme avancée, mais il n'est pas évident de convaincre les managers de ralentir une locomotive rapide, mais en retard sur un horaire.
UNE QUESTION DE VOCABULAIRE?
Je suppose que le mot "sprint" plait aux managers et aux clients. Il sous-entend que l'équipe ne peut aller plus vite sans prendre le risque d'un claquage. Le problème est que nous ne pouvons sprinter longtemps. Je préfère le mot "itération". Il me parait plus serein. Il reste à concrétiser cette nuance de vocabulaire en un rythme durablement soutenable pour l'équipe.
Nous rencontrons des problèmes similaires. Et la pression vient bien de l'équipe elle-même, pas particulièrement du management. La dernière rétrospective nous a permis de clarifier la métaphore du sprint : il s'agit bien de voir clairement la ligne d'arrivée le jour du départ mais en aucun cas de rejoindre le plus rapidement possible cette ligne. La vision claire du projet doit apporter de la sérénité ("on a le temps de faire qqch de bien") et pas de la pression ("on peut améliorer la vélocité"). Cependant, il nous reste le problème d'avoir à la fois une estimation fine de la vélocité et une qualité constante dans les itérations.
RépondreSupprimerPeut-être que le nombre de tâches a effectuer (fonctionnellement parlant) ou la deadline sont a modifié.
RépondreSupprimerLa vélocité ne semble pas être une caractéristique que l'on peut modifier, cela me semble être plus une information qu'une caractéristique.
Ceci dit, je me trompe peut-être, d'autant que je n'ai jamais vraiment pu mettre en pratique un calcul de vélocité ...
Je ne sais pas si ça vous aidera, mais tenez bon ! ;-)
Bonjour,
RépondreSupprimerPour moi le sens Iteratif est incomplet car il manque la partie incrementale. Un Sprint est sensé représenté ces deux termes.
Ce que tu décris ressemble fort a de la technical debt cf la prez de kniberg:
http://blog.crisp.se/henrikkniberg/2008/08/08/1218174720000.html
Je te conseilles de bien re-définir la DoD et de mettre les taches non fonctionnelles dans le backlog.
Ansi le travail technique de l'equipe sera comtabilisé dans la vélocité et le travail total (non fonctionel compris) sera suivi et prioritisé par le PO.
Si cela peut aider ;)
+ Toutes nos itérations produisent bien un incrément de fonctionnalité potentiellement livrable.
RépondreSupprimer+ La définition de "done" est claire et le travail fourni est de qualité.
+ Le backlog aussi des tâches non-fonctionnelles.
Le problème est que l'enchainement des itérations sans temps de pause et avec une pression pour augmenter la vélocité fait que:
1.On s'épuise;
2.On délaisse certaines réflexions de fond qui nécessitent de prendre sereinement du recul sur le développement.
Certes, le temps accordé aux rétrospectives permet de prendre momentanément du recul. Cette fenêtre de temps permet d'identifier des chantiers à mener, mais ils ne seront effectivement menés que lorsqu'ils seront prioritaires, ce qui ne permet pas de les traiter de manière sereine et préventive. S'ils ne sont pas menés en tâche de fond, c'est bien parce qu'il y a la pression de la course à la vélocité. Les itérations sont devenus des sprints.
ManU, je pense que tu as une piste de solution dans ton dernier commentaire. Pourquoi ne pas faire un temps de pause entre les itérations (plutôt que de garder un temps dans l'itération - ce que tu décrivais dans l'article principal), disons 1 jour minimum, voir 2 jours.
RépondreSupprimerEn ce qui me concerne, je gère la vélocité comme un indicateur de pilotage. L'erreur (induite par le nom "vélocité"), c'est de vouloir à tout prix améliorer ce chiffre. Je préfère donner comme objectif de maintenir la vélocité entre 60% et 65% : en-deçà, l'équipe peut s'améliorer ; mais au-delà, on voit apparaître de la non-qualité liée à un rythme non soutenable.
RépondreSupprimer