Il y a 6 années · 5 minutes · Agile

La prédictibilité au pays de Kanban

Kanban est de plus en plus présent au sein des entreprises et de la communauté Agile. Scrumban, la conjonction des pratiques Scrum associées aux techniques de management visuel proposées par Kanban, en est l’une des formes les plus connues.

Kanban se fait également une place auprès des équipes de maintenance et des équipes IT grâce à sa gestion du travail en flux continu. Toute équipe qui n’a pas besoin de livrable concret à période fixe, adoptera Kanban en prenant quelques éléments de Scrum, tels que le standup meeting ou la rétrospective flottante.

En ce début d’année 2013, nous vous proposons un aspect peu utilisé dans les équipes Agiles, la prédictibilité avec Kanban. Durant l’année dernière, nous avons eu l’occasion de mettre en oeuvre plusieurs Kanbans importants sur des projets de développement et de maintenance. Nous avons utilisé les indicateurs produits par les pratiques de Kanban pour mettre en oeuvre de la prédictibilité sur ces projets. 

 

Le premier tableau fournit le résultat d’indicateurs de performance sur un des projets que nous avons accompagné dans une démarche Kanban. Ce tableau est généré quotidiennement. Il est le résultat du mouvement des tâches sur le tableau Kanban par l’équipe projet. 

 

Définition : Le temps de cycle est le temps passé depuis le démarrage du travail sur une tâche jusqu’à ce qu’elle atteigne l’état "Terminé". À ne pas confondre avec le lead Time qui correspond à l’instant où la tâche est créée jusqu’à sa résolution.

Dans un objectif de simplification, nous n’avons pas fait apparaître le lead Time dans le tableau. Nous reviendrons sur ce sujet dans un prochain article. 

Le deuxième tableau fournit un état des lieux du projet actuel :

Les deux tableaux nous permettent d’obtenir notre tableau de prédictibilité :

Ce tableau nous donne une première idée de ce qu’il est possible de réaliser en analysant quotidiennement les données provenant d’un Kanban. 

La première ligne permet d’identifier la fin du projet. Si nous n’ajoutons aucune nouvelle User Story au projet actuel, le projet prendra fin le 13 février 2013. Si nous ajoutons 10 nouvelles Users Stories, nous finirons le 27 février 2013 et nous aurons 14 jours de retard supplémentaire. 

Les deux autres lignes suivantes indiquent le nombre d’anomalies et le temps pour les résoudre. 

Le tableau ci-dessus est un exemple simplifié dans lequel nous utilisons la vélocité moyenne pour calculer les "dates d’arrivée" et le temps de "résolution des anomalies" en relation avec le nombre de personnes sur le projet. Nous pourrions compléter ce tableau avec la vélocité basse, haute et moyenne pour les User Stories et les anomalies, prendre en compte les périodes de congés, les évolutions par User Story, etc.

Comment fait-on pour calculer la prédictibilité sur notre projet? Pour ce faire, nous prenons le temps de cycle moyen pour terminer une User Story. Dans notre cas, elle est de 22 jours. Nous multiplions ce chiffre par le nombre de Users Stories restantes à faire. Le tout est divisé par la capacité de travail de notre équipe.

Par exemple, si nous devons réaliser 9 Users Stories et que le temps de cycle est de 22 jours, nous aurons 198 jours d’activité. Etant donné que nous avons 10 personnes dans l’équipe pour une capacité moyenne de 200 jours par mois, nous pourrons terminer le projet dans un mois.  

Nous devons également tenir compte des anomalies. Pour ce projet, nous réalisons 3 anomalies pour 1 US, avec un cycle de temps de 19 jours par anomalies, soit 513 jours. Il nous faudra donc 2,5 mois supplémentaire pour corriger l’ensemble des anomalies.

Vous trouverez les formules de calcul détaillées ici.

En complément, nous pourrions ajouter les évolutions, prendre en compte les jours de congé, etc.

Conclusion

Le calcul de la prédictibilité en Kanban est un formidable outil de pilotage. Nous avons eu l’occasion de le mettre en oeuvre sur plusieurs projets depuis 2010. Il s’avère être un outil de plus en plus précis après une première période de stabilisation d’environ 3 à 4 sprints (de 2 semaines). 

Ces données nous permettent d’obtenir des indicateurs Agiles en temps réel en évitant l’effet tunnel des méthodes classiques. Dans les exemples que nous avons proposé, nous extrapolons le nombre potentiel d’anomalies sur le projet, donc le coût réel. Celui-ci est habituellement caché et le client le découvre souvent à la fin de son projet (certaines SSII ajoutent même une pondération de 30% dans leurs propositions commerciales). Obtenir ses données en temps réel permet de remonter des données factuelles auprès des managers et de prendre rapidement des décisions pour réduire ce gaspillage en terme de qualité et de finance. 

Avec un simple reporting quotidien, nous disposons automatiquement d’une vraie visibilité sur notre projet : la date d’atterrissage de notre backlog, le coût d’un nouveau besoin, le nombre et le coût moyen des anomalies par User Stories, etc. Le tout sans estimation! Le cérémonial est réduit au strict minimum. C’est simple, c’est Lean!

Maintenant que nous pouvons analyser nos coûts, nous aborderons la "Réduction des coûts au pays de Kanban" dans un prochain article.

Note : Les chiffres présentés dans cet article sont donnés à titre d’exemple sans lien avec un projet réel. 

 

Yannick Quenec'hdu
Yannick Quenec’hdu est un consultant senior et coach agile expérimenté. Depuis plus de 15 ans, il a mené plusieurs équipes de développement sur l’ensemble du cycle de vie du logiciel, notamment en mettant en œuvre Lean, Scrum et XP. Son expérience d’entrepreneur lui a permis de mettre en place l’agilité aussi bien au niveau technique qu’au niveau métier avec une forte capacité d’engagement. Doté d’une excellente capacité à communiquer et bon pédagogue, Yannick sait fédérer les équipes techniques et métiers autour d’un objectif commun. Yannick est diplômé de Telecom Bretagne, il participe activement aux conférences Agile. Il a réalisé la transformation Agile pour les groupes EDF, DCNS, LVMH, PSA et accompagné des entreprises du Web comme Krop, Behance, Sarenza, LeGuide.com Il intervient dans plusieurs pays, tels que la France, L'Angleterre, USA, Suisse, Pologne, …
Renaud Chevalier
Renaud est directeur de l'offre agile chez Xebia. Il est également formateur au sein de Xebia Training .

5 thoughts on “La prédictibilité au pays de Kanban”

  1. Publié par Sylvain, Il y a 6 années

    Bonjour,

    J’ai 9 choses à faire, sachant que mon temps de cycle est de 22j. Je ne vois pas en quoi avoir une capacité de 200j/mois me garantit leur réalisation en un mois.

    Le temps de cycle comprend en effet des périodes d’attente. 22j ne signifie pas 22j de capacité!
    De même, ce temps de cycle a pu être calculé avec un système normalement chargé d’un certain nombre de stories. L’injection de ces 9 stories correspond-elle à une charge normale du système kanban?

    Quelque chose m’échappe.

  2. Publié par Yannick Quenec'hdu, Il y a 6 années

    Bonjour Sylvain,

    Moi non plus je ne peux pas la garantir « Je ne vois pas en quoi avoir une capacité de 200j/mois me garantit leur réalisation en un mois. ».

    « La prédiction est difficile, surtout celle du futur. » Niels Bohr. Nous présentons dans cet article une alternative aux estimations. Nous sommes dans un système émergent, dans lequel nous ne pouvons pas tout prédire. Mais il y a l’avantage de fournir des indicateurs bien plus précis que la simple vélocité.

    « Le temps de cycle comprend en effet des périodes d’attente », pas nécessairement. Une mauvaise habitude est de proposer une pratique des buffers (pull) comme un élément obligatoire. On oublie de le penser comme un élément de gaspillage qu’il faut réduire à son maximum avec une étude constante de la Value Stream Mapping (VSM).

    C’est l’objectif d’un deuxième article sur la VSM. Je l’admets bien volontiers que nous avons pris certains raccourcis pour présenter la prédictibilité. Dans le cas contraire, nous aurions perdu le lecteur, dans l’étude complète de la chaine du système Kanban.

    « L’injection de ces 9 stories correspond-elle à une charge normale du système kanban? ». En aucun cas, ce chiffre est arbitraire. e. Sur un des projets ou j’ai mis en place cette démarche et les indicateurs, nous avions une charge quasi constante de 10 Users Stories par Sprint. Pour arriver à cela, nous avions mis en place un travail important dans la rédaction des US, pour obtenir des US de petites tailles (vélocité de 1, 3 et 5)

    Yannick

  3. Publié par Sylvain, Il y a 6 années

    Merci pour votre réponse!

    J’ai repensé au sujet et j’ai 2 remarques:
    -ce que j’ai dit à propos de la charge du système était idiot puisqu’en flux tiré l’équipe tire ce qu’elle est capable de faire. Peu importe donc le nombre de stories en attente.

    -concernant la predictibilite il peut être intéressant de se servir du débit du système (nb de stories ou de story points par unité de temps (semaine par ex)).

    Tout à fait daccord sur ce que vous dites à propos des files d’attente. Ne pas les mettre par défaut.

  4. Publié par Kanban digest #2 - L'accompagnement agile !, Il y a 3 années

    […] un blog Xebia sur la prédictibilité au pays de Kanban. La prédictibilité est effectivement encore peu utilisée et rebute un peu les praticiens. Et […]

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *