IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Scrum et les changements pendant un sprint

Traiter les changements en flot continu avec une dose de Kanban

L'agilité se définit souvent comme la capacité à répondre aux changements, voire à les favoriser. Par exemple, Scrum permet au client à travers son représentant (le Product Owner ou PO) d'incorporer des changements dans le périmètre fonctionnel à chaque fin de sprint. Pour beaucoup, c'est un progrès significatif. Maintenant Scrum se diffuse largement vers des équipes qui ne font pas que du développement de logiciel. Le paradoxe, c'est que nombreuses de ces équipes sont dans un mode de changements quasi permanents, et le passage à Scrum peut représenter une transition rude en repoussant les changements au sprint suivant.
Cet article expose des pistes leur permettant une transition plus douce en introduisant une dose de Kanban dans un cadre Scrum.

Kanban est une pratique basée sur l'utilisation d'étiquettes (ou fiches) pour matérialiser des informations sur un processus, présentées sur un tableau, de façon similaire au tableau des tâches Scrum. Mais Kanban pousse à limiter le TAF (travail à finir), c'est-à-dire le nombre de travaux dans une étape du processus.

5 commentaires Donner une note à l´article (4)

Article lu   fois.

L'auteur

Site personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Prise en compte du changement dans les processus

I-A. Processus classique

Quand le développement d'un nouveau projet s'effectue avec un cycle séquentiel (cycle en V ou en cascade), on évite le changement en essayant de le repousser à plus tard.

[ALT-PASTOUCHE]

Pour cela, on essaie de définir le plus précisément possible ce qu'il faut faire en élaborant la spécification pour ensuite partir dans le développement sur cette base. Pendant le développement, les changements ne sont pas acceptés : ils sont repoussés dans la phase de maintenance.

Côté pratiques d'ingénierie, on sépare traditionnellement la gestion des exigences mise en œuvre dès le début et la gestion des changements qu'on met en branle pour la phase de maintenance.

I-B. Processus agile

Avec un processus agile, le changement peut être pris en compte pendant le développement.

[ALT-PASTOUCHE]

Typiquement avec Scrum, un développement est découpé en sprints. À chaque nouveau sprint, il est possible de prendre en compte et de traiter des changements qui sont intervenus pendant le sprint précédent.

I-C. Processus chaotique

Les changements arrivent fréquemment et sont traités de façon opportuniste en fonction de leur degré d'urgence. Bien souvent il n'y a pas de règle bien définie, les interruptions peuvent être nombreuses et provoquer des perturbations.

[ALT-PASTOUCHE]

La tâche T1 est interrompue par la tâche T2 qui est elle-même interrompue par la tâche T3. Des perturbations incessantes ont un effet nocif sur la bonne santé des équipes. De plus les interruptions fréquentes sont génératrices de changements de contexte et donc de perte de temps.

I-D. Transition à Scrum

Scrum apporte une réponse à ces organisations. Pour la plupart des équipes, c'est une bonne nouvelle, à la fois pour celles qui n'acceptaient pas le changement et celles qui le pratiquaient de façon chaotique.

Cependant le passage à Scrum peut être considéré, en particulier pour ces dernières, comme trop difficile.

En effet, il existe des contextes où on ne peut pas supprimer complètement les perturbations pendant la durée du sprint. « Business first », le client sera toujours prioritaire dans des organisations qui ne peuvent pas, pour différentes raisons, dire non à une sollicitation d'un client, au moins dans la phase de transition à Scrum.

C'est ainsi qu'une équipe peut être perturbée par une démo à faire en urgence ou par un bug à corriger rapidement. Dans ces cas-là, l'approche préférable, inspirée du Kanban où la notion de flux contraint moins, permet d'accepter des changements sans attendre une fin de sprint comme avec Scrum.

Pas n'importe quand et n'importe comment cependant si on veut garder les avantages de Scrum.

Le cas, fréquent, où une seule équipe travaille sur plusieurs projets en même temps est aussi typique d'une équipe subissant des changements fréquents : le passage d'un projet à un autre s'apparente à une perturbation.

II. Retour sur la mécanique de Scrum

II-A. Scrum au pied de la lettre

Pendant un sprint, l'équipe ne doit pas être perturbée, c'est une règle (au moins une recommandation de Scrum). Pas perturbée, cela signifie qu'on la laisse travailler pendant le sprint, selon l'objectif et le plan définis pendant la réunion de planification du sprint.

Concrètement, cela veut dire que personne n'a le droit d'ajouter du travail à la liste sur laquelle l'équipe s'est engagée sans son accord. Cela devrait aussi signifier que les ressources de l'équipe ne sont pas changées (à la baisse) pendant le sprint ou encore que du travail ne constituant pas une story, mais prenant du temps n'est pas ajouté non plus au tableau des tâches.

Diminuer les perturbations de cette façon a un effet positif. Cependant cela signifie que le traitement d'un changement est repoussé au sprint suivant. La durée des sprints peut être ajustée pour tenir compte de ce délai et réduire la gêne occasionnée.

II-B. Tâches associées à une story

C'est le tableau des tâches qui définit le travail à faire dans un sprint.

[ALT-PASTOUCHE]

Dans un tableau Scrum, on trouve essentiellement des tâches associées aux stories. Elles représentent le travail détaillé à faire pour réaliser (et finir, selon la définition de ce que signifie fini) une story.

II-C. Tâches récurrentes

Il existe d'autres tâches, qui sont à faire pendant le sprint et qu'on ne peut pas associer à une story en particulier. Ces tâches, sans story associée, proviennent de la définition de fini pour un sprint. Par exemple, la mise à jour d'un document d'architecture, la production de rapports Sonar, le travail de test de charge, sont des tâches qu'on ne peut pas associer à une story spécifique.

Ces tâches ont une autre particularité, en plus de ne pas être associées à une story, c'est qu'elles reviennent à chaque sprint (si la définition de fini ne change pas). On peut donc les qualifier de récurrentes. Elles sont relatives à la qualité du produit. Si elles ne sont pas faites, le sprint n'est pas prolongé (évidemment, cela serait contraire à la notion de bloc de temps), la vélocité n'est pas impactée, mais c'est la qualité du produit qui en pâtit. Cela produit de la dette technique si ces tâches ne sont pas faites, soit qu'on n'y a pas pensé et elles n'apparaissent pas dans la signification de fini, soit qu'elles y sont bien, mais qu'on ne les a pas réalisées pendant le sprint.

II-D. Planification du sprint

Si on applique bien Scrum avec une signification de fini explicite, ces tâches récurrentes sont bien connues au début du sprint. Elles sont ajoutées dans le tableau des tâches au moment de la réunion de planification du sprint.

Si l'équipe travaille bien, elles seront finies à la fin du sprint et une autre instance de ces tâches sera créée lors du prochain sprint.

À la fin de la planification du sprint lorsque l'équipe s'engage, elle le fait en connaissant la durée du sprint, en connaissant les ressources (humaines) dont elle dispose, sur un périmètre défini par la liste des stories et en s'appuyant sur sa définition de ce que signifie fini.

[ALT-PASTOUCHE]

En principe ces paramètres ne varient pas pendant le sprint. En pratique cela arrive tout de même. Pour rester dans le cadre Scrum, nous allons considérer que la durée du sprint, elle, ne peut pas changer pendant le sprint.

III. Changements pendant le sprint

On a vu que l'engagement de l'équipe au début d'un sprint était basé sur :

  • le périmètre fonctionnel de ce sprint, défini par la liste des stories prises en compte ;
  • la signification partagée de fini, qui fait partie intégrante du « contrat » moral ;
  • Lles ressources dont disposait l'équipe.

Un changement arrive quand une de ces grandeurs varie pendant le sprint. Examinons les différentes situations qui peuvent se présenter.

Éliminons tout de suite le cas où l'équipe identifie une nouvelle tâche nécessaire pour réaliser une story, qui avait été oubliée au début du sprint ou parce qu'une grosse tâche est décomposée. Il ne s'agit pas d'un changement puisque le périmètre fonctionnel n'est pas impacté. L'équipe a le droit de définir le travail à faire comme elle l'entend et donc d'ajouter une tâche liée à une story.

Les autres perturbations arrivant pendant le sprint et qui vont nécessiter du travail par l'équipe n'entrent pas dans ce cadre-là, puisqu' elles vont revenir sur l'engagement pris en début du sprint.

III-A. Le périmètre du sprint varie

Si la demande de variation est à l'initiative de l'équipe, cela est un usage normal de Scrum. Une équipe qui se rend compte avant la fin du sprint qu'elle pourra en faire plus que prévu au début du sprint va demander une nouvelle story au Product Owner (ou l'inverse, d'ailleurs plus fréquent).

Si la demande est à l'initiative du Product Owner, c'est différent. Cela signifie qu'il a changé d'avis depuis la réunion de planification du sprint. Il s'est rendu compte qu'une story, qui était déjà dans le backlog de produit, est devenue plus prioritaire.

Scrum permet à une équipe de dire non. Elle peut donc refuser d'ajouter une nouvelle story demandée par le PO pendant le sprint. C'est déjà mieux que d'accepter sans condition au risque de rater le sprint.

Une approche plus subtile est parfois possible, si la demande arrive alors que l'équipe n'a pas encore commencé à travailler sur des stories du sprint. Il est alors envisageable de proposer au PO d'échanger sa nouvelle story contre l'équivalent qui serait enlevé du périmètre du sprint. Ce troc de story est facilité par une estimation préalable en points.

III-B. La définition de fini varie

La signification de fini est partagée par toute l'équipe. En principe elle est définie au début du projet et peut varier légèrement à chaque sprint. Le meilleur moment pour discuter de sa mise à jour est pendant la rétrospective de sprint.

Il peut arriver que l'équipe décèle le besoin de revoir la signification de fini pendant le sprint et que cette révision entraîne du travail à faire.

Quelques exemples : la production ou la mise à jour d'un document transverse, comme celui d'architecture, la mise en place d'un script pour automatiser le déploiement…

C'est à l'équipe de décider, par exemple lors du scrum quotidien, si cette révision peut attendre le sprint suivant ou doit être entreprise au plus vite. Dans ce dernier cas, le travail à faire est considéré comme une tâche urgente, notion sur laquelle nous allons revenir.

III-C. Les ressources du sprint varient

Ce cas se produit quand du travail est demandé à un ou plusieurs membres de l'équipe, alors qu'il n'était pas prévu au début du sprint et qu'il ne s'agit pas d'une story déjà identifiée dans le backlog de produit.

Le travail demandé peut être en relation avec le produit que l'équipe développe. Cela arrive fréquemment quand l'équipe n'est pas confinée au développement, mais s'occupe aussi du support et de l'avant-vente.

Voici quelques exemples de ce qui peut arriver :

  • un défaut (bug) a été trouvé sur le produit, qu'il soit en production (ce qui fait augmenter le degré d'urgence) ou pas ;
  • du feedback est remonté du PO ou d'utilisateurs privilégiés utilisant le résultat du sprint précédent ;
  • une démo doit être faite très vite pour un (futur) client important ;
  • une question posée sur le forum des utilisateurs nécessite une réponse rapide.

Parfois une ressource peut être demandée pour travailler sur quelque chose qui n'a rien à voir avec le produit développé.

Les postures possibles pour une équipe Scrum sont les suivantes :

  • Dire non. Il est probable que certains des travaux demandés peuvent attendre le sprint suivant. La solution est alors pour les demandeurs de ces travaux (en général le PO) d'ajouter une entrée dans le backlog de produit. Mais ce n'est pas possible pour tous les travaux, certains ayant un véritable caractère d'urgence ;
  • Dire oui. Le problème est que cela va avoir un impact sur l'engagement de l'équipe du début de sprint, puisqu'elle va passer du temps sur ces tâches non prévues. Si cela n'est pas contrôlé, on en revient au chaos des changements permanents. Un des risques est que ces travaux n'apparaissent pas explicitement dans le tableau des tâches.

Pour conserver deux notions essentielles de Scrum, la transparence et le timebox du sprint, il est préférable que ces travaux apparaissent explicitement dans le tableau des tâches.

L'approche recommandée est donc d'identifier les tâches vraiment urgentes et de les traiter de façon spécifique, à l'intérieur du sprint Scrum. Les événements qui ne seront pas considérés comme urgents et donc pas traités dans le sprint courant, il convient d'en faire une story qui va dans le backlog de produit.

III-D. Un événement prévisible n'est pas vraiment une perturbation

Dans certaines circonstances, on peut parler de perturbation prévue. C'est le cas lorsqu'un événement ponctuel a lieu pendant le sprint. Cela peut-être la participation à un salon, ou une personne qui part en formation. Une perturbation c'est du travail en plus ou une ressource en moins. Si l'équipe dispose d'un calendrier visuel, l'événement y aura naturellement sa place.

À partir du moment où c'est prévu au début du sprint, cela peut être pris en compte pendant la réunion de planification. L'équipe s'engage en connaissance de cause et on ne peut plus parler de perturbation.

III-E. Des obstacles sont rencontrés

Un autre cas de tâche urgente concerne le travail à faire pour l'élimination d'un obstacle rencontré pendant le sprint.

Exemple : un serveur qui tombe en panne.

IV. Traitement des tâches urgentes : vers du Kanban

Une tâche urgente arrive, la première personne qui finit sa tâche en cours la prend, avant d'en commencer une autre.

Une façon plus proactive de procéder avec les tâches urgentes est de limiter leur nombre par sprint en fixant et ajustant une limite, le TAF. Cette limite peut être globale, par état ou par personne de l'équipe.

Nous sommes là plus proches du Kanban que du Scrum pur. En particulier si on considère qu'il faut limiter le nombre de tâches perturbantes à un moment donné. La limitation du nombre de travaux dans un état constitue un élément fondamental du Kanban, la limite est appelée TAF (WIP en anglais, c'est-à-dire le travail à faire dans le processus, qu'il faut limiter).

IV-A. Limite par état

On suppose qu'une tâche urgente peut être dans un des trois états suivants : à faire, en cours et finie. Le plus usuel est de limiter le nombre de tâches urgentes en cours. Une limite de 1 oblige à avoir fini une tâche urgente avant d'en traiter une nouvelle, ce qui est une bonne chose.

[ALT-PASTOUCHE]

On peut aussi limiter le nombre de tâches dans l'état à faire. Cela contraint le PO à définir les priorités ou le degré d'urgence. Si le TAF dans l'état à faire est limité à 4 et que les 4 places sont prises, le PO peut introduire une nouvelle tâche urgente, mais à condition d'en enlever une.

[ALT-PASTOUCHE]

IV-B. Limite globale

Le nombre de tâches urgentes est limité dans un sprint. Quel que soit leur état. Le PO ne peut plus en ajouter lorsque la limite est atteinte. La limite se discute à chaque rétrospective.

[ALT-PASTOUCHE]

IV-C. Limite par personne

Si la limite de TAF dans l'état en cours est supérieure à 1, il peut être intéressant d'empêcher qu'une seule personne ait plusieurs tâches urgentes en cours.

IV-D. Usage du mou

Le mou permet de faire des tâches non prévues sans remettre en cause les objectifs du sprint.

[ALT-PASTOUCHE]

Dans la boite de temps que constitue le sprint, on peut considérer que lors de la réunion de planification du sprint, une partie est allouée à la réalisation des stories, une autre aux tâches récurrentes pour satisfaire la signification de fini et qu'il faut garder du mou pour les incertitudes sur les estimations et pour les tâches urgentes.

En lissant le temps passé sur les tâches urgentes (avec une des techniques de limitation de TAF), cela revient à garder dans chaque sprint une partie du temps pour traiter l'urgence.

[ALT-PASTOUCHE]

IV-E. Impact sur la vélocité

Les tâches n'ayant pas de points associés, à la différence des stories, elles ne contribuent pas à la vélocité. Mais comme on y passe du temps, ce temps n'est pas passé sur des stories et donc l'impact indirect est de diminuer la vélocité.

Les tâches récurrentes prennent à peu près le même temps à chaque sprint. Leur impact sur la vélocité sera donc à peu près le même pour chaque sprint. Avec l'usage fait de la vélocité, cela revient à dire que les tâches récurrentes n'ont aucune conséquence.

Les tâches urgentes peuvent varier d'un sprint à l'autre, mais la variation est limitée par le TAF.

V. En résumé

Pendant un sprint, il faut s'efforcer de limiter les perturbations. Cela peut se faire de façon proactive lors de la planification du sprint en identifiant comme des stories les événements perturbateurs et de façon réactive en repoussant un changement au sprint suivant.

Si malgré tout, il y a une tâche urgente ajoutée pendant le sprint, cette tâche doit être prise et commencée dès qu'une ressource finit son travail en cours.

Il est préférable de limiter le nombre de tâches urgentes pendant un sprint. La limite peut porter sur le nombre de tâches traitées pendant le sprint ou sur le nombre de celles qui peuvent être traitées de façon simultanée ou sur celles que peut faire une personne.

Seule l'équipe (y compris le PO bien entendu) a le droit d'ajouter une tâche urgente pendant le sprint.

Exemples

  1. Vous êtes dans un sprint. Les stories S1, S2 et S3 sont dans l'objectif du sprint.
  2. Le PO veut ajouter S4. Si S3 n'est pas commencé et a la même taille on peut substituer S3 par S4. Si tout est commencé ou qu'il ne reste qu'une story de taille inférieure, on refuse.
  3. Le boss a besoin de quelqu'un de l'équipe pour préparer une démo à un client important. On lui répond qu'il aurait pu la prévoir et on lui demande s'il peut la décaler au sprint suivant. S'il faut absolument la faire, c'est une tâche urgente qui suit les règles de TAF définies par l'équipe.

VI. Références

Kanban et Scrum, tirer le meilleur des deux par Henrik Kniberg et Mattias Skarin, traduit en français par Claude Aubry, Frédéric Faure, Antoine Vernois et Fabrice Aimetti.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Copyright © 2010 Claude Aubry. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.