Devops et la méthode Kanban

Share

Devops et la méthode Kanban

La méthode Kanban ne prescrit pas un panel spécifique de modèles ni des étapes de processus. En effet, la méthode Kanban commence avec les modèles et les processus que vous avez. La méthode Kanban stimule des changements continus, incrémentaux et évolutionnistes dans votre système.

Votre équipe doit convenir qu’un tel changement est le moyen d’améliorer le système de façon pérenne. Le type actuel de votre organisation doit dépasser ses peurs et sa résistance pour faciliter les changements futurs. En acceptant de respecter les rôles et les responsabilités, les peurs disparaissent. Cette initiative permet aussi de gagner un support élargi dans notre approche Kanban.

Introduction à la méthode Kanban

La méthode Kanban suggère de déployer des changements évolutionnistes et incrémentaux. Kanban ne prescrit pas une méthode spécifique à utiliser.

Kanban a été influencé par la théorie des contraintes (en anglais, « theory of constraints » ou TOC). La base du TOC est l’expression qu’une chaîne n’est pas aussi renforcée que ses faibles liens. Cette expression illustre la gestion et l’ingénierie logicielle. Le plus faible élément de toute la chaîne peut causer l’échec ou affecte défavorablement le résultat. Une des plus importantes influences de Kanban est la méthode Kaizen. Littéralement, Kaizen signifie « amélioration continue ».

Avec la méthode Kanban, les stations reçoivent un « pull » de la demande. De ce fait, la livraison est déterminée selon la demande réelle. La fourniture du produit n’est donc pas déterminée suivant des demandes théoriques, prévues, irréalistes ou académiques.

Les cinq propriétés fondamentales de la méthode Kanban

David Anderson est l’auteur du livre « Kanban : Successful Evolutionary Change for Your Technology Business » (Kanban : un changement évolutionnaire réussi pour vos affaires technologiques), sorti en 2010. Il y identifie cinq propriétés fondamentales constatées dans toute implémentation réussie de la méthode Kanban :

  • Visualiser le flux (workflow) : Par nature, le flux de connaissance est invisible. Le visualiser et le rendre visible est une manière de comprendre comment le travail se poursuit. Dans le cas contraire, effectuer les changements adéquats est difficile. La manière commune de visualiser un flux est d’utiliser un tableau composé de cartes et de colonnes. Chaque colonne représente les différents états ou étapes du flux.
  • Limiter le travail en cours (work in progress/process ou WIP): Le WIP implique qu’un système « sur demande » est en partie ou en totalité en cours d’implémentation dans le flux de travail. Le système en question agira comme l’un des principaux déclencheurs de changements continus, progressifs et évolutifs. Dans cette configuration, les éléments essentiels sont tels que chaque étape du WIP est limité dans le flux de travail. Une nouvelle tâche est insérée si la capacité le permet.
  • Gérer le flux : Tout au long du flux de travail, chaque étape doit être surveillée, mesurée et synthétisée. En gérant activement le flux, on peut évaluer si les changements continus, progressifs et évolutionnaires ont des impacts positifs ou négatifs dans le système.
  • Rendre explicite les politiques des processus : Jusqu’à ce que le mécanisme d’un processus soit explicite, il est souvent difficile ou impossible de discuter sur son amélioration. En effet, tant qu’on ne comprend pas la façon dont le travail s’effectue réellement, toute discussion sur les problèmes aura tendance à être anecdotique, émotionnelle et subjective. Dans le cas contraire, il est possible de discuter des problèmes de manière plus rationnelle, empirique et objective. Ce qui facilite la trouvaille d’un consensus autour des propositions d’amélioration. Le processus est un ensemble de politiques qui régit le comportement. Ces politiques sont sous le contrôle du management.
  • Améliorer de manière collaborative : La méthode Kanban encourage les changements continus, progressifs, évolutionnaires et appropriés. Du moment que les équipes ont une compréhension commune des théorie sur le travail, le flux, le processus et le risque, ils sont plus susceptibles d’être en mesure de construire une compréhension partagée d’un problème. De ce fait, les équipes pourront proposer des actions d’amélioration convenues par tous.

Le tableau Kanban bord pour Devops

Le tableau kanban est un outil utilisé pour l’implémentation de la méthode Kanban. Il utilise des aimants, des punaises, des rondelles colorées ou des notes autocollantes comme élément de travail. C’est ce qu’on appelle le « signal ». Il est placé dans le système Kanban. Le tableau peut aussi être généré à l’aide de logiciels. Chaque élément de travail est déplacé de l’état initial défini aux états finaux. Ces derniers sont regroupés dans des voies verticales. Les voies typiques sont constituées des états possibles. Elles incluent les journaux d’enregistrement, ce qui est prêt, le codage, le test, l’assurance qualité, le déploiement, ce qui est fait ou ce qui est en cours. Les cartes peuvent se dépendre entre elles.

Les cartes Kanban (comme les tickets, les tâches) s’étalent généralement de gauche à droite, de la commande jusqu’à leur achèvement. Donc, un tableau Kanban suit chaque fonction tout en circulant à travers chaque colonne du flux. En effet, selon See Mary et Tom Poppendieck dans « Leading Lean Software Development » : « Tous les systèmes Kanban sont conçus de manière à limiter le travail en cours car le travail en cours ralentit le flux. »

Lorsque la limite de ce qui est cours est atteinte alors que des tâches urgentes surgissent, il faut établir des priorités pour offrir de la valeur au client.

Ci-après un exemple de tableau Kanban :

méthode kanban

Exemple pratique de la méthode Kanban

Illustrons maintenant par un exemple pratique comment combiner concrètement les quatre zones matricielles de DevOps tout en incluant Kanban. Pour ce faire, on commencera par un modèle « anarchique » pour vous démontrer que c’est une approche chaotique. Ensuite, on prendra le même exemple avec l’approche DevOps.

L’approche anarchique

Soit une équipe de développement composée de différentes équipes qui détiennent par exemple une collection différente des artefacts du même logiciel. Chaque groupe maintient ses propres journaux tout en gérant les changements : nouvelles fonctionnalités, corrections de bug… Certains éléments du journal expriment des demandes à l’attention des opérations. Le travail de l’équipe de développement était organisé comme un projet. De l’autre côté, les opérations étaient composées d’une personne qui maintient l’infrastructure, qui était responsable de la livraison du logiciel, qui traitait les demandes reçus du développement et qui prenait en main les incidents produits lors des tests et de la mise en production.

L’équipe des opérations maintenait un journal des éléments de travail. Dans les réunions de planning, les équipes synchronisaient avec une autre et donnaient la priorité aux éléments du journal des opérations. Ensuite, les opérations travaillaient sur ces tâches. Cependant, leur travail était continuellement perturbé par des nouveaux éléments qui arrivaient. Il fallait donc, à chaque fois, se réunir pour modifier le planning en fonction des nouvelles priorités. Les limites des tâches en cours n’ont jamais étaient respectés. Dans l’exemple, les opérations travaillent sur quatre éléments indépendants en même temps. La norme est de travailler au maximum avec six tâches en même temps sauf en cas d’exception. Une classe de service accélérée était en place mais elle n’était pas fonctionnelle.

L’attribution des priorités aux tâches étaient instable. Plusieurs personnes du développement (managers, testeurs et programmeurs) communiquaient de nouvelles tâches aux opérations. Le délai que prenait l’effectivité d’un changement était en moyenne de 60 jours.

Ci-joint une illustration de l’approche anarchique :

approche anarchique de Devops

L’approche améliorée

Avant la mise en place de la nouvelle approche, il faut :

  • Évaluer la disponibilité des données et identifier les points sensibles.
  • Définir les points de départ et d’arrivée pour le contrôle, par exemple : où commence et où s’arrête la visualisation d’un processus.
  • Analyser la chaîne de valeur. La chaîne de valeur est la schématisation de la chronologie à partir de la commande d’un client jusqu’à la réception de l’argent. Cette chronologie est réduite pour éliminer les tâches qui n’apportent pas de la valeur ajoutée. Par exemple, on identifie les différentes étapes du processus et combien de temps prend un élément pour réaliser chaque étape.

Ci-après une illustration de la nouvelle approche :

approche améliorée de devops

La nouvelle approche introduit un « portier » qui filtre et donne la priorité aux éléments du travail. 2 représente la limite des tâches en cours pour les classes standard. 1 représente les voies accélérées.

Les changements principaux dans la nouvelle approche par rapport à l’approche anarchique sont :

  • La quantité des tâches en cours est réduite.
  • Une planification collaborative des équipes de développement et des opérations ayant pour objectif de réduire les activités imprévues. Ce qui implique un perpétuel ordonnancement.
  • Chaque tâche en cours est alignée avec un ensemble de capacités.
  • Les interfaces et les interactions avec l’équipe en amont sont plus intégrées et synchronisées.
  • Les incidents imprévus sont filtrés par un « portier » qui détermine une priorité. Par exemple, si le problème doit être traité dans l’immédiat ou s’il peut être ajouté dans le journal des demandes.
  • L’équipe se focalise sur l’établissement de la confiance tout au long de la chaîne de valeur.
  • Les équipes (développement et opérations) ont des habilités. Le développement peut travailler sans consulter les opérations dans le but de minimiser les requêtes avenantes.
  • Les priorités sont plus ou moins stabilisées.
  • Les tâches sont visibles dans le tableau de Kanban utilisé par les équipes de développement et des opérations.
  • Les réunions sont tenues ensemble par les équipes de développement et des opérations. Ils discutent des futurs changements et spécifiquement des exigences non fonctionnelles.

Les avantages d’un portier incluent les faits suivants :

  • Le portier travaille comme source d’information et améliore la communication est le partage de connaissance entre le développement et les opérations.
  • Le portier libère du temps aux opérations pour qu’ils puissent travailler sur les tâches courantes, les incidents prévus et imprévus.
  • Le portier minimise considérablement le changement de contexte aux opérations.

Outre le portier, on souligne la visibilité dans la qualité et dans le processus de traitement des problèmes. On minimise radicalement les échecs de chargement en réduisant la quantité des tâches en cours et en introduisant une petite marge pour permettre une amélioration continue.

Les principaux catalyseurs de l’approche améliorée sont la cartographie de la chaîne de valeur, l’analyse du flux et des goulots d’étranglement, la fixation des limites des tâches en cours, la mise en œuvre d’un système « pull » (étiré) et l’introduction d’une marge temporelle pour les améliorations et les ajustements.

Save

Save

Save

Save

Save

Save

Posted in Agilité d'entreprise and tagged , , .

Laisser un commentaire

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