BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Tracking Schedule Progress in Agile

Tracking Schedule Progress in Agile

Favoris

Le contexte

Je vous présente Vince. Vince est en charge d'un projet où il faut jouer serré. Tout doit partir en production d'ici la fin de l'année et le temps passe vite. Vince n'a pas beaucoup de flexibilité sur le périmètre. Il se demande : "Sommes-nous dans les rails pour livrer le périmètre sur lequel nous nous sommes engagés dans les délais impartis ?". Ce que Vince souhaiterait, c'est que tous les risques de livraison se montrent au plus tôt, de façon à pouvoir les traiter.

Peut-être pouvez-vous voir en Vince quelqu'un de votre entreprise, avec qui vous travaillez. Savoir si on est dans les rails pour la livraison est une interrogation qui a hanté tellement de chefs de projets et de managers, alors que leur organisation passait au développement agile… D'autant plus avec ce mythe qui dit qu'en agile, on ne peut pas savoir, ou que c'est une question sans importance !

Les approches courantes, dans les projets en waterfall ou en chaîne critique

En Waterfall comme avec toute méthode de gestion de projet classique s'appuyant sur un "réseau" de tâches, à la question "sommes-nous dans les rails ?", on répond en regardant les tâches réalisées, la durée restante pour les tâches en cours et la durée des tâches non-commencées. En s'appuyant sur le réseau de dépendances entre ces tâches, on peut projeter une date de fin du projet. L'état de l'art, pour ce style de gestion de projet, est d'ajouter des tampons dans le cycle du projet pour se protéger des incertitudes, tout en minimisant les effets de la loi de Parkinson (le travail s'étend sur la durée allouée).

L'idée, en bref

L'alternative agile consiste à répondre à la question "sommes-nous dans les rails ?" en comparant le "périmètre réalisé" et la taille totale du périmètre. Puisque notre travail est découpé en unités fonctionnelles "de bout-en-bout" (Features/Stories), ce pourcentage simple donne une image précise de l'avancement de toutes les activités liées au périmètre.

Vince peut utiliser cette approche pour savoir où en est son projet, en partant de l'hypothèse qu'il gère ce projet en flux, c'est-à-dire en faisant en sorte que les unités passent à "Done" au plus tôt, le plus souvent possible et de façon continue tout au long du projet. Pour que cela soit possible, Vince doit travailler avec toute son équipe pour définir des unités à la granularité suffisante pour qu'elles puissent être traitées en quelques jours. Vince devrait aussi favoriser un mode d'exécution selon lequel il faut "arrêter de commencer, commencer par finir", c'est-à-dire où l'on se focalise sur un certain nombre prédéfini d'unités de travail à la fois, un niveau de travail en cours (WIP level, "Work In Progress level"), afin d'aboutir à l'émergence d'un rythme continu de réalisation des tâches et de prise en charge des nouvelles.

Avec ces informations, Vince peut obtenir le pourcentage de complétion du projet. L'historique de ces informations lui donne une tendance qui peut indiquer une situation s'améliorant ou se détériorant. C'est ce que l'on visualise généralement dans les "Cumulative Flow diagrams" ou les "Release Burnups".

Les professionnels chevronnés du monde du développement produit savent qu'il existe une grande part d'incertitude inhérente à la quantité réelle de travail à réaliser et donc forcément une différence entre le temps de réalisation prévu et le temps que cela prendra en réalité. Bien sûr, cette incertitude ne disparait pas avec le développement agile. La différence, c'est que le développement agile prend acte de cette incertitude, il en fait un axiome de base de la réalité des projets. Nous structurons notre exécution pour répondre à cette différence de plusieurs façons.

Vince demande d'abord aux membres de son équipe d'arrêter d'introduire des tampons dans les estimés pour absorber les variations liées au quotidien. Vince leur demande de s'attacher à réaliser les tâches, conformément à la définition de "Done", aussi rapidement que possible et de tirer une nouvelle tâche dès que possible. Ceci réduit directement l'effet de la loi de Parkinson. Vince peut envisager d'autres mesures encore mais, à ce stade, il est sage d'évaluer si cette simple approche est suffisante ou pas avant de complexifier davantage le système (nous aborderons d'autres approches, plus loin dans l'article).

Vince continue en revanche de maintenir un "tampon projet" pour se protéger de la variabilité dans le débit. Le système fonctionne de façon similaire à un tampon projet de type "Chaîne critique" : Vince suit l'utilisation du tampon. Il s'attend à ce que le tampon soit utilisé graduellement dans le projet et lorsque cela arrive trop rapidement, il sait qu'il y a un risque. Dans les projets agiles classiques, ce tampon est un "tampon de périmètre", ce qui veut dire qu'il existe un périmètre non-obligatoire, que l'on espère obtenir si la variabilité joue en notre faveur mais que l'on peut abandonner au cas où.

Lenteur au démarrage

Au cours des premières semaines d'exécution, Vince est préoccupé. Ses graphiques ne montrent pas de progrès et il commence à se demander s'il ne va pas se remettre à demander à son équipe des rapports "à l'ancienne", sur le temps restant ou l'effort nécessaire restant. Ce que Vince doit réaliser, c'est que le temps nécessaire pour commencer à voir le progrès dépend directement de la quantité de travail en cours ("WIP, Work In Progress level"), c'est-à-dire du nombre d'unités traitées et de leur taille. Plus le WIP est haut, plus le "Cycle Time", le temps de traitement de bout-en-bout, est long... et plus il aura à rester dans le noir. Même si les rapports sur le temps ou l'effort restant peuvent donner QUELQUES indications sur l'avancement des tâches en cours, ils ignorent dangereusement que la meilleure mesure de l'avancement est celle de la part de "logiciel utilisable". Vince devrait donc s'assurer que les unités de travail sont de granularité suffisante et que son équipe est focalisée sur une quantité de tâches raisonnable, ceci afin de permettre de compléter les tâches initiales rapidement et d'établir un débit de réalisation stable pour le projet.

Lorsque Vince parle avec ses amis Robert et Sandra, il apprend qu'ils ont eux-aussi connu au cours de leurs projets des moments inquiétants. Ils ont tous deux vu une courbe en S dans les premiers jours ou semaines. Vince jette un œil aux courbes en S des précédents projets, afin de savoir s'il faut commencer à s'inquiéter et s'il y a quelque chose qui va au-delà d'un effet initial de "lenteur au démarrage".

Un outil clé que Vince utilise à présent pour piloter correctement ses projets en Kanban est le "Cumulative Flow Diagram", CFD :

Ce diagramme montre non seulement le taux de complétion (en rouge) mais aussi chacune des files d'attentes dans le travail en cours, au cours du temps. Dans cet exemple, nous pouvons voir de gauche à droite le flux de travail depuis le Backlog, à travers la conception, le développement, le test et la complétion.

Sandra partage donc le CFD de son premier projet agile avec Vince. Il est très étonné et a du mal à comprendre ce que signifie ce graphe. Sandra lui montre le graphe et lui demande de se concentrer sur les premiers jours du projet. Voici ce qu'il voit sur les 30 premiers jours :

 Pour Vince, ce qu'il voit correspond au backlog puis rapidement, l'activité de conception qui commence. En gros, c'est la conception de 40% du périmètre du projet qui commence. Sandra est d'accord, c'est exactement ce qui s'est passé. Ainsi, on commence le travail mais on n'aperçoit pas de progression. Pourquoi ? Parce que tant que les éléments sont en conception, dans la perspective du CFD, ils sont vus comme étant immobiles. On ne voit un élément changer de couleur et progresser qu'à partir du moment où il change de phase (de file dans le tableau du Kanban). Le tableau Kanban, à ce stade, ressemblerait à ceci :

(cliquez pour agrandir l'image)

Ensuite Sandra montre à Vince le CFD quelques semaines plus loin dans le projet.

Ici, Vince commence à voir le début du flux : le travail commence à être complété selon un rythme soutenu. Sandra demande son avis à Vince : le projet a-t-il des chances de finir dans les 250 jours comme prévu ? Vince prend un marqueur et allonge la zone rouge de complétion pour obtenir une intersection avec le niveau orange du périmètre global.

(cliquez pour agrandir l'image)

Il semble que le projet ne finit pas à temps, répond Vince. Sandra est d'accord, l'intersection des lignes orange et rouge indique à peu près 300 jours. Elle demande à Vince à quel niveau la complétion devrait être. Vince répond que d'expérience, on observe une accélération de la progression après une phase de mise en place initiale, on s'attend donc à voir une courbe qui remonte au cours du temps. Pour Sandra, c'est une hypothèse raisonnable, particulièrement pour un projet avec une équipe neuve et de nouveaux environnements et clients, plutôt qu'un projet de maintenance ou un projet en cours.

Suite à cela, Sandra montre à Vince quelques courbes de "prévision de complétion". Elle lui demande ce que chaque courbe représente selon lui et laquelle de ces courbes correspond à SON projet.

(cliquez pour agrandir l'image)

Vince réfléchit un instant et dit : "La ligne rouge représente un optimisme naïf. On commencerait à compléter des éléments dès le premier jour du projet et le débit serait parfait du début à la fin. Tu as déjà vu un projet comme ça ?" Rires de Sandra. Vince continue : "La ligne verte est intéressante. Elle reflète le fait que commencer à compléter des éléments prend du temps, donc elle est plus réaliste. Je n'aime pas être dans le noir mais je m'attends à ce que mon projet ressemble à ça". Sandra acquiesce et demande ce qu'il en est de la courbe violette. "Hmm, la différence c'est qu'il semble que le rythme s'améliore tout au long du projet et ralentit un peu sur la fin. Peut-être que le début reflète l'effet de la montée en puissance et des courbes d'apprentissage ; le ralentissement à la fin correspond aux touches finales et quelques éléments sur lesquels l'équipe reste bloquée et sur lesquels il est plus difficile de faire participer toute l'équipe de façon efficace. Cela semble correspondre de façon encore plus réaliste à mon projet." Sandra est d'accord, cela ressemble à la courbe en S que l'on observe sur la plupart des projets. Elle montre maintenant la totalité de la courbe de son CFD et Vince constate qu'elle correspond à la courbe violette. Sandra lui explique qu'une fois qu'elle réalisa que cette courbe en S représentait le comportement attendu d'un projet se passant bien, elle l'avait utilisée comme référence de comparaison. Chaque fois que la ligne réelle de complétion était en dessous de la courbe, elle savait qu'il y avait un risque avéré, son buffer projet était grignoté. Lorsque la ligne était au-dessus de la courbe, Sandra récupérait une part du buffer. En gros, il y a une zone orange autour de la courbe, c'est la zone de warning. Au-dessous, c'est la zone rouge, danger. Et au-dessus, la zone verte, où tout est ok.

(cliquez pour agrandir l'image)

Sandra rappela à Vince que ce qu'il y aurait de mieux à faire pour améliorer la visibilité serait de réduire la taille des éléments de travail et/ou la quantité de travail en cours. Avec les deux options, on complète chaque élément plus tôt et plus vite, ce qui permet d'obtenir tôt de meilleures indications sur le débit réel du projet et permet de voir où l'on est positionné par rapport à la courbe. Vince comprend. Seulement, son équipe lui dit qu'elle ne peut pas découper le travail plus finement et qu'elle ne peut pas se focaliser sur moins d'éléments à la fois. L'équipe rapporte que cela implique que plusieurs personnes travaillent sur les mêmes fichiers en même temps et que cela rend les choses difficiles. Que les personnes sont moins efficaces car il faut revenir sans cesse sur les mêmes portions de code. Rires de Sandra. Elle répond qu'au début, toutes les équipes sont dans ce cas. Ce qui aide, en général, c'est de donner de la visibilité et de se focaliser sur le niveau du WIP, c'est-à-dire le nombre d'éléments en cours et leur taille (un tableau Kanban peut aider ici). Ensuite il faut collecter des exemples de situations où il a été difficile de découper plus finement un élément ou où il a été difficile de maintenir le WIP à bas niveau. À partir de cela, il faut se rencontrer aussi souvent que possible, deux fois par semaine par exemple, pour analyser rétrospectivement ces exceptions et ces cas extrêmes. Un brainstorming sur les causes profondes derrière ces difficultés doit provoquer des idées pour les résoudre ou permettre d'identifier des pratiques classiques qui apportent une réponse (le découpage des User Stories par test d'acceptance, un refactoring, un système de Source Control plus moderne ou des outils de tests, en fonction du challenge). Des leaders comme Vince devraient donner à l'équipe la permission de passer du temps dans cette démarche d'apprentissage, d'expérimentation et d'amélioration s'il souhaite arriver à un meilleur flux de réalisation et un WIP plus bas au cours du temps.

Vince commence à percevoir ce que l'agilité implique et coûte réellement. Alors qu'il comprend que l'investissement serait utile, il se demande comment il peut amener ses équipes à changer leur façon de travailler suffisamment vite pour établir un suivi agile qui fonctionne. Vince décide qu'il va rallier tout le monde autour du besoin de visibilité et de prédictibilité. Il pourra aussi convaincre ses équipes qu'une visibilité réaliste implique des managers moins stressés (en partant de l'hypothèse que le progrès, c'est bien). Et qui dit manager moins stressé dit plus de focus sur le projet, moins de temps à faire du reporting et des points d'avancement et donc plus d'avancement, un projet allant encore mieux et des managers encore moins stressés.

Vince réalise que le temps requis pour obtenir une vision de la part de "logiciel utilisable" à partir du CFD est minime en comparaison des alternatives s'appuyant sur le reste à faire, ce qui est un autre argument en sa faveur. Tout ce que les gens ont à faire est de s'assurer que l'état de chaque élément de travail est reflété correctement. Il n'est pas nécessaire de savoir combien d'heures ont été passées ni même quel est l'effort nécessaire restant. De plus, plus le WIP est bas, moins la maintenance d'un Kanban prend du temps car il y a moins d'activités en cours nécessitant un suivi actif.

Il semble que le découpage fin et la contrainte de travailler sur moins d'éléments à chaque instant sont des changements qui valent l'investissement, afin de rendre la gestion de projet plus facile.

Conclusion

Ce que nous avons vu, c'est qu'il est possible de suivre l'avancement d'un projet agile et qu'il est possible de gérer les risques liés à l'exécution. Nous avons vu comment des situations réelles, provoquées par des implémentations peu poussées de l'agilité, avec de grosses quantités de travail en cours, peuvent réduire la visibilité et la prédictibilité et faire peur. Nous avons vu comment cette peur/incertitude peut être mise à profit pour conduire à utiliser des éléments de travail plus petits et effectuer moins de travail à la fois. Les bénéfices sont une meilleure gestion des risques, une meilleure exécution et un meilleur apprentissage.

Si vous gérez un projet ou un programme agile, pensez au WIP sur votre projet, pensez à quoi votre burnup ou CFD devrait ressembler et ce que vous voulez en faire.

Au sujet de l'auteur

Yuval Yeret dirige la pratique du Kanban/Flow chez AgileSparks, une société de conseil internationale sur le lean/agile, basée en Israël. Il a conduit plusieurs initiatives stratégiques lean/agile, sur du long-terme dans de grandes entreprises. Praticien du Kanban et formateur, il est focalisé sur le monde du développement produit en entreprise. Yuval croit fortement dans les approches de conception pragmatiques, retenant ce qu'il y a de mieux dans chaque approche, éviter les dogmes. Il a récemment reçu le Brickell Key Award pour "Lean Kanban community excellence", grâce à son travail pour l'adoption de Kanban en Israël. Il a publié "Holy Land Kanban", basé sur ses réflexions et ces écrits.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT