Appliquer Kanban aux processus informatiques (4)
Auteur : Eli Weinstock-Herman
Source : Applying Kanban to IT Processes (Part 4)
Date : 22/12/2009
Traducteur : Fabrice Aimetti
Date : 13/07/2011
Traduction :
Cet article est le quatrième d’un ensemble d’articles qui décrit les bases de Kanban et son application dans les processus informatiques :
- La première partie donnait un aperçu de Kanban et la façon dont il est utilisé dans l’industrie.
- La deuxième partie donnait un aperçu de Kanban et la façon de l’utiliser dans un service helpdesk (fictif).
- La troisième partie donnait un aperçu de Kanban et la façon de l’utiliser dans un projet de déploiement de PC (fictif).
Les articles qui suivent explorent différents scénarios pour vous aider à trouver des idées s’appliquant à votre propre contexte. »
Dans la quatrième partie de cette série « Appliquer Kanban aux processus informatiques », nous allons suivre une équipe de développement logiciel. Ils appliquent actuellement un processus qui a été baptisé le modèle sashimi, un modèle en cascade modifié avec recouvrement des phases : exigences, conception, développement et tests. Cet exemple se concentre sur l’utilisation de Kanban pour améliorer et affiner un processus actuellement utilisé plutôt que d’exécuter un processus de conversion complet.
Bienvenue à la société GHI
GHI est une petite société de développement qui se spécialise dans la construction et l’intégration de systèmes d’inventaire et de valorisation des stocks dans le B2B et le B2C. Un des défis qu’ils ont choisi de relever est le suivi et le reporting d’activités. Étant donné que leurs produits nécessitent de grands développements côté logique métier et administration et très peu côté interface utilisateur, le client ne peut pas voir la façon dont le produit évolue. Améliorer les mécanismes de suivi et de reporting fournira au client de plus amples informations sur la façon dont le projet progresse, augmentant ainsi leur niveau de confiance à la fois dans la solution et dans la société. Cette dernière estime que l’amélioration de cette confiance n’affectera pas seulement la relation avec ce client, mais améliorera également son image sur le marché et avec d’autres clients potentiels.
"État courant"
Le processus actuel de l’équipe commence par le recueil des exigences de haut niveau et la construction de l’architecture générale, sans aborder aucune des règles métier. Une fois le squelette développé, l’équipe se concentre sur le fait de mener de façon itérative le recueil des exigences et la construction des plus petits modules nécessaires pour ajouter la chair au squelette. La conception globale du système suit une approche N-tier, avec des couches définies pour l’accès aux données, la logique métier, la séparation des processus de transaction et de traduction pour chaque système externe et une interface utilisateur limitée. Cette démarche itérative permet de découvrir plus avant la logique métier et les exigences pendant le développement. Cette approche modulaire permet également de développer en pilotant par les tests des parties du système sans disposer des vrais systèmes tiers donc sans exiger que la solution soit complète. Ce pilotage par les tests permet également au personnel technique du client et aux analystes métier d être impliqués et de relever d’éventuelles contradictions au plus tôt.
On a demandé à l’équipe de fournir une meilleure visibilité et des indicateurs clairs qui puissent être partagés avec le client. Bien que de nombreux membres de l’équipe sont intéressés pour essayer des méthodes Agile, comme Scrum ou XP, l’équipe décide qu’appliquer Kanban à leur processus initial constituera un faible changement du point de vue du client. Une fois que l’équipe disposera d’une meilleure visibilité et de meilleurs indicateurs, elle a bien l’intention de réévaluer le potentiel d’utilisation de Scrum ou de tout autre méthode Agile, mais elle perçoit qu’un changement progressif sera acceptable pour les clients là où un changement de processus complet ne le sera pas.
Dans le cadre de ses efforts continus, l’équipe est également à la recherche d’un moyen d’améliorer sa vitesse de livraison. La plupart des membres de l’équipe approuvent le fait qu’un développeur supplémentaire permettrait d’accélérer leur processus de livraison d’au moins 15%, mais ils ne seront pas en mesure de défendre le recrutement d’effectifs supplémentaires sans disposer d’indicateurs convaincants permettant de légitimer leurs demandes.
Définir le processus
Suite à plusieurs longues réunions, l’équipe a élaboré son processus comme une série d’étapes clairement définies qui suivent des cycles, en se concentrant de manière itérative sur de plus petits morceaux.
Processus en cascade itératif (Sashimi)
Bien que le processus suivi soit presque fractal dans son exécution, chaque passe détaillée de plus en plus finement suit une série d’étapes :
Reste à faire : travaux non encore bien déterminés qui doivent être conçus et développés
Exigences : recueil d’exigences métier ou système tiers pour une tâche ou un module
Conception : application des standards de conception, de modélisation et d’exigences externes pour concevoir la tâche ou le module
Développement : développement selon la conception et les exigences
Test : test des développements terminés pour détecter les défauts* et valider l’alignement aux exigences
Revue client et acceptation : groupes de revue des tâches avec le personnel technique, les analystes métier ou les services tiers
L’équipe compte actuellement un chef de projet, cinq développeurs et une personne pour la QA. Une fois défini son processus, l’équipe a décidé que l’un des développeurs serait en charge de l’architecture (exigences et conception), le chef de projet sera responsable des étapes client et de la priorisation du reste à faire (avec l’aide de l’architecte), le reste des développeurs et la personne QA prendront en charge le développement et les tests. L’architecte sera également responsable d’une partie du développement si l’équipe prend de l’avance sur les exigences et la conception.
- "Les défauts sont des imperfections du produit qui apparaissent en situation de production ou d’exploitation normale. Des exemples de défauts dans l’ingénierie logicielle sont du code mal saisi, un référencement incorrect des variables et d’autres erreurs techniques. Les problèmes au niveau des exigences sont par exemple des options manquantes dans les filtres de recherche, une mise en page incorrecte d’un formulaire et d’autres éléments directement liés au client."
"Exemple : le client n’exigera jamais explicitement que la fonction de validation ne bloque pas le serveur, donc une erreur dans une fonction de validation qui bloque le serveur est classée dans la catégorie défaut."
Tableau visuel 1
A des fins de visualisation et de suivi, l’équipe découpe plusieurs étapes en sous-étapes. Les étapes d’exigences et de conception ont été définies comme une série de trois sous-étapes, la dernière étape étant une étape « prêt » qui indique que les tâches peuvent être sélectionnées et commencées par les développeurs. Le développement a été découpé en deux sous-étapes, une étape « en cours » et une étape « terminé ». Les éléments de la sous-étape « terminé » » sont mis à disposition pour être sélectionnés et testés par la QA.
Le premier tableau visuel
L’équipe utilise un grand tableau blanc magnétique pour son tableau Kanban. Au lieu d’utiliser des couloirs pour visualiser les travaux en cours, l’équipe a créé des emplacements spécifiques sur le tableau pour les tâches et pour la photo de chaque membre de l’équipe. Par exemple, lorsque l’architecte de l’équipe recueille les exigences pour une tâche, il place sa photo dans la colonne exigences avec la tâche sur laquelle il travaille actuellement. Le chef de projet a donné une série de timbres d’animaux colorés aux membres de l’équipe pour estampiller les tâches qu’ils terminent, permettant au reste de l’équipe de suivre facilement qui a travaillé sur une tâche donnée. Cela permet à la personne de la QA ou à un développeur qui prend la suite de communiquer facilement avec le développeur d’origine sans faire appel à des mécanismes complexes de traçabilité.
Limites Kanban
Les limites Kanban ont été définies en fonction du nombre de personnes affectées à chaque étape et de quelques approximations sur la quantité de travail attendue à chaque étape sans que les étapes avales du processus manquent de travail. Les étapes d’exigences et de conception sont limitées à trois tâches pour trouver un équilibre entre conserver des informations fraîches sur les exigences et fournir suffisamment de travail pour l’étape de développement. La étapes de développement possèdent une limite de cinq tâches pour permettre à l’architecte d’avancer et de développer de petites tâches lorsque la limite est atteinte pour les exigences et la conception. L’étape de QA est limitée à une seule tâche, tirée à partir des tâches de développement terminées. Cela permet à la personne QA de terminer une série de tests sans être perturbée par de nouveaux développements déployés en cours de tests. La file d’attente des éléments en attente de la revue clients n’est pas limitée car le chef de projet a déjà des réunions hebdomadaires avec le client pour discuter des tâches terminées. La file d’attente permet au chef de projet de sélectionner des ensembles de tâches terminées et d’en discuter avec les participants, ou d’envoyer des rappels assez tôt pour s’assurer que les bons participants seront présents à la réunion.
"Exécuter le nouveau processus"
Initialement, le processus est un peu brut puisque l’équipe tente de terminer les tâches qui dépassent les limites à travers le flux. L’architecte commence à s’acclimater à un rôle qui exige de consacrer plus de temps avec des tableaux blancs et moins avec un éditeur de code. Le chef de projet commence à opérer la transition de la gestion des flux de tâches dans le processus vers la gestion des priorités et l’amélioration des communications avec le client.
Après quelques semaines, le processus est plus fluide. Le chef de projet priorise les tâches dans la file d’attente, parfois en impliquant l’architecte pour s’assurer que les exigences de conception sont prises en compte. L’architecte sélectionne les tâches prioritaires en haut de la pile, recueille des exigences plus détaillées de la part du client, et construit une conception globale qui intègre les exigences et les aligne avec la conception de haut niveau. Lorsque les étapes d’exigences et de conception atteignent la limite Kanban, l’architecte passe à l’étape de développement et soit aide les développeurs soit sélectionne une petite tâche de développement qu’il finira lui-même. Les développeurs sélectionnent des tâches de l’étape d’architecture et les implémentent. Après avoir terminé une tâche, ils la déplacent dans la sous-étape « fini » et soit aident l’un des autres développeurs soit sélectionnent une nouvelle tâche. Lorsque l’étape de développement atteint sa limite Kanban, les développeurs sans tâches attribuées se déplacent en amont du processus pour aider la personne QA à tester afin de supprimer les obstacles. La personne QA teste chaque tâche, à la recherche d’anomalies ainsi que pour vérifier l’alignement avec les exigences clients et la conception interne.
Les tâches de QA retournent au développement ou passent à la suite
Après avoir testé une tâche, la personne QA soit la renvoie dans la colonne de développement pour être corrigée soit la déplace dans la file d’attente. Renvoyer une tâche aux développeurs causera souvent l’atteinte ou le dépassement de la limite Kanban pour le développement. Le développeur qui prend la suite et qui atteint ce point d’arrêt, soit aide à continuer les tests soit sélectionne la tâche renvoyée pour corriger les problèmes en suspens.
Première révision
Dans le cadre de la définition du processus initial, l’équipe a convenu d’examiner et de réviser son processus régulièrement. Pendant les premières semaines, le chef de projet a recueilli des statistiques de haut niveau pour mesurer le débit du processus et fournir des informations pour la réévaluation du processus. L’information détaillée comprend des statistiques sur la fréquence des tâches renvoyées par l’étape de test, le nombre de fois où l’architecte ou les développeurs sont amenés à se déplacer en aval du processus pour aider à débloquer les obstacles, et une estimation générale de la façon dont le client réagit lors chaque réunion hebdomadaire.
"Évaluation"
Il y avait un certain nombre de tâches partiellement terminées lorsque l’équipe a commencé et ils attendaient l’étape de QA pour se stabiliser. Malheureusement, cela n’a pas eu lieu, et afin de maintenir un flux régulier de tâches, les développeurs sont souvent aller en aval du processus pour aider la personne de la QA à traiter son backlog. Les quelquefois où les développeurs ont eu des journées exceptionnelles, la QA a presque immédiatement bloquée, nécessitant plusieurs développeurs pour aider à traiter le backlog.
Le rôle d’architecte requiert moins de temps que prévu, conduisant l’architecte à développer environ 50% de son temps. Cela exige, pour quasiment chaque tâche réalisée par l’architecte, un débogage et une correction par l’un des développeurs et réduit encore un peu plus l’efficacité du processus en forçant quelqu’un, peu familier avec les exigences et le code de la tâche concernée, de dépanner rapidement et d’apporter les corrections.
"Changements de processus"
Initialement l’équipe croit que la plus grande limitation pour accomplir des tâches est la main-d’œuvre et qu’augmenter le nombre de développeurs conduirait à une augmentation directe du nombre de tâches qu’ils réalisent chaque semaine. Toutefois, après avoir travaillé pour obtenir un processus plus raffiné et mesurable, ils ont constaté que l’ajout de développeurs offrirait peu ou pas d’avantages parce que la contrainte actuelle sur leur processus est le goulot d’étranglement sur la QA. S’ils augmentent le débit de cette étape, alors le processus entier sera beaucoup plus fluide et générera un débit plus élevé, puisque la QA sera en mesure de tirer des tâches de la zone de développement plus rapidement.
L’équipe a pris en compte plusieurs idées pour accroître la main-d’œuvre à l’étape de test, y compris l’embauche d’une personne supplémentaire pour la QA et même utiliser l’architecte à temps partiel sur la QA au lieu de le faire développer. Après avoir discuté de plusieurs options, un membre de l’équipe a suggéré d’utiliser l’architecte et tout développeur disponible pour construire des tests automatisés. La théorie est que l’automatisation de certains des tests ne réduira pas seulement la quantité de travail pour la personne QA, mais réduira aussi le nombre de tâches qui sont renvoyées par la QA au développement pour débogage et correction. L’équipe a décidé d’essayer cette idée parce qu’elle ne nécessite pas de dépenses supplémentaires et qu’il y a peu d’impact négatif d’avoir l’architecte travaillant sur les tests unitaires au lieu d’aider à terminer les travaux de développement en respectant la limite Kanban.
Tableau Kanban révisé avec des étapes supplémentaires
Le tableau Kanban a été modifié pour inclure une sous-étape de création de tests en plus des exigences et de la conception. L’architecte est responsable de la construction d’un certain nombre de cas de test pour chaque tâche à définir. Lorsque les limites de la zone exigences sont atteintes, l’architecte travaille sur la construction. Cela garantit que les tâches en cours ont des tests automatisés et qu’au fur et à mesure que le temps passe, la couverture augmente pour tester l’intégration des modules et tout risque d’effets de bord ou de lacunes lors de l’intégration des modules conçus ensemble.
La limite pour l’étape de développement sur le tableau est augmentée et une petite zone est créée pour les tâches renvoyées par la QA. Ces tâches sont traitées avec une priorité plus élevée que les tâches de la zone d’exigences pour s’assurer que la plupart des tâches seront corrigées et terminées avant que tout nouveau travail démarre. Pour aider à augmenter l’efficacité des développeurs à corriger ou déboguer le code écrit par d’autres, une nouvelle revue de code est mise en place. Chaque fois qu’une tâche est terminée, le développeur revoit le code avec un ou plusieurs des autres développeurs pour s’assurer qu’il est simple, commenté où il faut et qu’il suit les standards existants. Ce processus est relativement rapide et réduit les coûts et le temps supplémentaire consommé lorsque quelqu’un d’autre dépanne les tâches réalisées initialement par quelqu’un d’autre.
Analyse finale
Bien que l’équipe continue à réévaluer et réviser son processus selon une fréquence de quelques semaines, elle a déjà réalisé un certain nombre d’améliorations par rapport à son processus original et à la première version des limites de Kanban.
"Flux de processus"
L’équipe n’a pas révisé ses priorités, exigences ou processus de conception, de sorte que ces étapes continuent à travailler de la même manière qu’avant l’application des limites Kanban. Le nouveau processus de création de tests unitaires pour les tâches a été lent pendant la première semaine, mais comme l’architecte a acquis une expérience avec le framework de tests, le processus de construction de tests est devenu plus fluide et a commencé à donner du temps pour construire des tests sur les modules déjà terminés. Au fur et à mesure que les développeurs terminent leurs tâches, ils regardent en premier la file d’attente des « corrections » provenant de la QA pour voir si des tâches sont en attente d’être déboguées ou corrigées. Cela met donc la priorité sur les tâches précédemment commencées et assure que les nouvelles tâches ne sont démarrées que lorsque la zone à corriger est vide. Le nouveau framework de tests unitaires a donné aux développeurs un moyen rapide de tester leur travail avant de déclarer qu’il est terminé et leur a également fourni des informations d’une toute autre dimension sur les exigences métier et de conception. Les tests unitaires ont également réduit le nombre de tâches correctives sur lesquelles les développeurs doivent travailler parce qu’ils signalent la plupart des défauts que la QA avait l’habitude de trouver auparavant.
L’étape de QA est devenue beaucoup plus rapide et il semble probable que la personne QA aura besoin d’un second boulot bientôt, l’équipe des 4 développeurs a été maintenue mais la QA a subi deux « périodes de sécheresse » la semaine précédente puisqu’elle était en avance sur les développeurs. Le nombre moyen de tâches retournées a été considérablement réduit, avec seulement environ 5% des tâches retournées pour dépannage là où plus de 50% étaient autrefois retournées. L’étape QA évalue et utilise aussi des tests automatisés pour s’assurer qu’aucun défaut n’a été négligé et le gain de temps, lié au fait de ne pas avoir à construire des tests et ne pas avoir à les passer manuellement pour chaque tâche, est énorme.
Avec l’étape de QA terminant l’évaluation des tâches plus rapidement, la file d’attente des éléments à revoir par le client croît à un rythme beaucoup plus rapide. Le chef de projet commence à avoir des difficultés à couvrir le tout en une seule réunion hebdomadaire, car le nombre d’éléments terminés a augmenté et se révèle un peu compliqué à traiter dans le format de réunion actuel. Des modifications des méthodes de communication sont susceptibles de survenir dans un proche avenir pour aider à gérer le flux croissant des tâches accomplies. Les mesures globales du débit des tâches et l’estimation des dates de fin sont plus cohérentes et ne varient pas énormément par rapport à avant. Alors que les indicateurs ont reflété l’amélioration du processus, la variation ou la plage des valeurs s’est considérablement restreinte.
Succès
L’équipe a seulement travaillé sur son processus quelques mois, mais elle a déjà commencé à voir des améliorations positives et elle envisage déjà des pistes pour son prochain cycle d’amélioration. Voici quelques-uns des succès qu’elle a déjà obtenus :
- Augmentation de la productivité : le rythme global de développement a augmenté par rapport au rythme constaté avant mise en œuvre de Kanban
- Augmentation de la confiance : l’amélioration de la vitesse de développement, l’utilisation d’outils automatisés et de nouveaux indicateurs ont tous contribué à l’amélioration de la confiance du client
- Clarté de la vision : la définition du processus et le tableau Kanban ont donné à l’équipe une meilleure vue de leur processus et un moyen de comparer avec d’autres méthodologies
- Estimation de la variabilité réduite : la capacité à mesurer le débit et de meilleures estimations ont permis à l’entreprise de mieux évaluer le moment d’approcher de nouveaux clients potentiels
- Mesurabilité : de bons indicateurs fournissent un outil important pour continuer à améliorer le processus et évaluer si des améliorations potentielles ont amélioré le processus ou non
- Support à la formation : des améliorations dans le processus ont contribué à diminuer les coûts et fournir un argument pour consacrer ce temps à se former, pour aider à conduire de futures améliorations ou empêcher la société de se lancer sur une technologie qui n’offrira pas ce qui est demandé
Dans le prochain article, nous conclurons cette série en 5 parties, « Appliquer Kanban aux processus informatiques », avec des idées issues d’autres domaines de l’informatique. Nous allons également discuter de certains processus non-humains pour lesquels Kanban peut être appliqué, ainsi que quelques brèves informations sur certains des autres concepts qui ont été abordés dans la série (tels que l’amélioration continue).
A propos de l’auteur
Eli Weinstock-Herman : Eli a plus d’une dizaine d’années d’expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l’administration de bases de données, l’architecture et l’intégration de systèmes industriels, l’administration de systèmes, … dans plusieurs secteurs industriels, en passant par l’éducation et l’industrie pour aller jusqu’au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l’amélioration des processus, le codage, la qualité, l’administration de systèmes, les pratiques de développement et l’architecture logicielle.
