Créer un management visuel pour des développeurs

Les clients d’une équipe de développement de logiciels trouvent que la qualité des livraisons est insuffisante. Ils aimeraient aussi avoir plus de feedback et de visibilité pendant le développement de leurs demandes. De plus, ils considèrent que ces demandes ne sont pas toujours produites dans les délais souhaités.

Avec le leader de l’équipe, pour comprendre ce qui se passe concrètement, nous décidons de créer un management visuel. En réalité, nous le voyons comme une manière de développer ensemble une meilleure capacité de découvrir les problèmes, pour ensuite apprendre à les résoudre de la bonne manière.

Nous initions alors un atelier de 3 heures avec quelques développeurs. Voici ce à quoi nous arrivons :

Nous convenons ensemble qu’il s’agit d’une première version, à modifier et adapter selon nos découvertes au fur et à mesure de son utilisation.

Création

Notre atelier a démarré par une observation des dernières demandes assignées à l’équipe. Ainsi nous avons identifié quatre types de demandes entrantes : des incidents (Incidents), des demandes de développement (Dev), des défauts à corriger (Defects) et des demandes de support (User Support).

Après une observation du parcours de quelques demandes déjà traitées, les développeurs se sont entendus sur les grandes étapes de leur processus actuel de production :

1. ToDo : c’est là où apparaît toute demande qui est arrivée, en attente, et qui n’a fait l’objet d’aucun traitement par un membre de l’équipe.
2. Analyse : à cette étape, le développeur définit le design de sa future implémentation, identifie des dépendances par exemple. Cela peut être aussi une phase de discussion ou d’évaluation sur l’organisation ou des choix techniques.
3. Construction : c’est la phase de développement ou codage de la demande. Elle inclut aussi le cas de la mise à jour ou correction d’une demande existante.
4. Unit Tests : c’est la phase de codage des tests de composants automatisés.
5. Terminé : les tests unitaires s’exécutent avec succès, la demande est terminée et le développeur est passé à une nouvelle tâche.

Une étape spéciale appelée « Red bin » ou « Bac rouge » existe après chaque étape majeure du processus de production. Les développeurs ont convenu d’y mettre toute demande provenant de l’étape précédente et qui génère des questionnements ou des incertitudes.

Fonctionnement

Dès qu’une demande est assignée à l’équipe, le leader la traduit en un post-it de couleur, selon son type : Incident, Dev, Defect ou User Support. Il est posé dans la colonne « ToDo ». Le prochain développeur disponible, s’attribue un post-it de cette colonne selon ses compétences. Il démarre la tâche mentionnée et s’assure de la faire évoluer sur le management visuel, de colonne en colonne, de sorte à refléter sa situation exacte à tout moment.

Il faut noter qu’à intervalle régulier, au moins une fois par jour, le leader de l’équipe s’empare des demandes qui attendent dans les colonnes « Red bin ». Il les analyse, ensemble avec quelques développeurs, et s’attache à guider une résolution de problème collective qui aboutit sur de simples modifications de gestes. Ainsi, formés, les développeurs savent de suite adapter leur manière de faire pour désormais éviter ce problème. Le traitement de bac rouge est une technique éprouvée pour faire de la qualité dans le développement de logiciels .

Dès les premiers jours, cette vision du flux réel des tâches au sein de l’équipe, soulève très vite plusieurs questions.

Découvertes et adaptation

• Voir les délais

La première question concerne le respect des délais, car c’est un point demandé par les clients. Comment se rendre compte facilement qu’une tâche qui évolue sur le management visuel est en retard ?

L’équipe décide alors de codifier toute tâche, représentée par un post-it, de la manière suivante :

L’observation de ces dates par rapport à la date du jour et à l’étape en cours dans le processus de production, permet à l’équipe de prévoir sa capacité à être dans les délais.

• Apprendre à respecter les délais

Avec ces informations, l’équipe réagit en conséquence : réorganisation pour mettre l’effort sur des tâches prioritaires, accompagnement technique de certains développeurs, fonctionnement en binôme pour une montée en compétence.

La date « T » (pour « target ») à laquelle il faut finir la tâche pour respecter les délais clients, est une date positionnée dès la création de la tâche. Elle vient, en réalité, de la date à laquelle il faut finir le projet au complet dans les délais voulus par les clients. Connaissant cette date « T », chaque jour l’équipe se demande si les tâches sont à l’étape où elles doivent être pour être effectivement terminées à la date « T ». Si non, elle essaye de comprendre pourquoi et réagit en conséquence. C’est le début de la technique du flux tiré.

• Gérer la capacité

L’équipe voit apparaître beaucoup de tâches dans la colonne « Analyse » et trop peu en « Construction ». Dans un premier temps, elle prend l’habitude de s’organiser de façon dynamique dans la journée pour absorber ces déséquilibres. Ensuite, à force d’affiner ses estimations et de découvrir peu à peu sa capacité réelle, elle met en place une limitation du nombre de tâches par étape.

Il faut noter que ces limitations de volumes de tâches ne sont pas définitives. Elles sont liées à la matrice de compétence de l’équipe, mais aussi à la variation du volume entrant par type de demandes. Une semaine avec beaucoup d’incidents entrants entraînera une faible bande passante pour le développement de nouvelles fonctionnalités.

• Clarifier la prise en compte et définir des critères de fin

Traiter des tâches posées dans la 1^ère colonne « Red bin », amène l’équipe à définir quelques critères d’admissibilité. Une tâche à faire, ne peut passer en « Analyse », c’est-à-dire être prise en compte par l’équipe, que si ces critères sont tous satisfaits. Exemples de critères : la tâche est testable, les règles d’acceptation sont identifiables.

De la même manière, à la fin, une tâche ne peut être considérée terminée que si certaines conditions sont remplies. Par exemple : le package à installer sur les serveurs de test a bien été généré sans erreurs.

Apprentissage et évolution

Ce visuel a permis à l’équipe de faire émerger au fur et à mesure des problèmes qui existent sur son flux de traitement des demandes, pour les résoudre de façon simple et rapide. L’approche structurée de résolution de problème adoptée ici, est le PDCA. Dans cette dynamique, les développeurs doivent se rendre compte de leur progression. C’est ainsi qu’ils rajoutent, petit à petit, des indicateurs de performance qui sont alors une composante additionnelle et naturelle de leur management visuel: la satisfaction client sous la forme d’un score, les délais sous la forme du nombre de tâche en retard par jour, la qualité qui compte le nombre de défauts et d’incidents.

Des équipes de développement, avec un management visuel du même type, ont résolu des problèmes pour mettre en place des modifications telles que :

• Faire, régulièrement, des formations courtes et spécifiques de sorte à avoir une meilleure répartition des compétences au sein de l’équipe. Ayant développé une meilleure connaissance du flux des demandes en entrée, c’est une manière d’éviter les goulots d’étranglement observées.
• Travailler avec des tâches plus petites, car elles permettent de mieux voir les causes de lenteur et de les traiter rapidement. Le délai perçu par le client étant maintenant visible, avec ses causes, c’est une approche pour le réduire de façon progressive.
• Adopter une approche TDD pour développer. Dans ce cas, le management visuel est modifié car il démarre plutôt par les tests unitaires avant la phase de « Construction ». C’est la conséquence de problèmes de qualité qui viennent d’une couverture fonctionnelle insuffisante et d’un mauvais design des tests unitaires.

Ce type de management visuel est souvent appelé “Kanban”. Bien qu’il ne soit en réalité pas le même que celui qu’on peut voir dans une usine par exemple, il en reprend quelques principes. Qu’il soit sous forme digitale ou non, le Kanban reste un formidable outil pour faire de l’amélioration continue.

Contactez-nous pour en savoir plus sur la mise en place d’un management visuel.