DevOps & le Gaspillage Lean

Rework

Dans le domaine du développement de logiciels, le Rework est une source de tension et de gaspillage bien connue causée par des problèmes de qualité qui entraînent des défauts et la reprise du code.
L’approche DevOps se concentre sur la collaboration et la qualité. La mise en œuvre de feedbacks rapides et précis au moyen d’un CI (Continuous Improvement) efficace avec des tests automatisés de type « build-acceptance » – combinant différents types de tests, unitaires, fonctionnels, d’intégration et de bout en bout – réduira le nombre de défauts échappés. La qualité du code et le temps de disponibilité du service sont des mesures dont toute l’organisation devrait se préoccuper et aucune équipe ne devrait être récompensée pour avoir terminé plus tôt si la qualité est médiocre.

Transfert / Motion

En ce qui concerne le gaspillage des transferts, le problème provient d’un trop grand nombre de dépendances entre les individus – par exemple, pour approuver une tâche ou accepter des modifications. Pour résoudre ce problème, les équipes DevOps doivent éliminer les silos autant que possible.
Les équipes peuvent utiliser le regroupement d’équipes cross-fonctionnelles pour résoudre ce problème. Par exemple, les développeurs peuvent travailler en binôme avec les testeurs pour approuver des éléments en cours d’exécution plutôt qu’en cours de route. L’intégration continue (CI) est un autre moyen de résoudre le problème du gaspillage des transferts : la mise en place d’un processus de CI unique pour couvrir les différents aspects de la validation doit servir de véhicule pour la livraison des logiciels entre les différents membres de l’équipe.

Processus supplémentaire / Overengineering 

Il s’agit probablement du type de gaspillage le plus facile à résoudre et le plus sous-estimé. Ce type de gaspillage consiste à consacrer trop d’efforts à des choses qui ne sont pas vraiment nécessaires. Il s’agit par exemple d’investir du temps et des ressources dans des éléments qui ne sont pas essentiels à la fonctionnalité ou au système, ou prévoir comme procédure d’onboarding de l’équipe de réapprendre le code hérité et non documenté. Pour éviter cela, concentrez-vous sur les fonctionnalités clés qui apportent la valeur ajoutée nécessaire par le biais d’user stories claires.
Un lien plus étroit entre la gestion de produit et le développement permet aux équipes de savoir ce qui est nécessaire et quand s’arrêter. À la place des Product Managers ou des Business Analystes qui écrivent des spécifications de 150 pages et les jettent par-dessus le mur aux développeurs, il est plus judicieux que ces équipes s’appuient sur une compréhension approfondie du domaine d’activité pour élaborer des user stories initiales avec lesquelles les développeurs peuvent commencer à travailler au lieu d’attendre qu’une spécification parfaite soit complétée.

Inventaire

Dans une usine, un inventaire est constitué de tous les travaux en cours (WIP) et des produits finis qui attendent les commandes des clients sur les étagères [Push]. Dans le cadre de DevOps, l’inventaire est constitué de tous les travaux partiellement réalisés. Un exemple d’inventaire WIP est le backlog des tickets ouverts. Ce travail en cours peut être en suspens, en attente d’informations ou tout simplement dans la file d’attente. Le gaspillage associé à l’inventaire est constitué par les coûts de redémarrage associés à la reprise d’un travail partiellement achevé, au temps nécessaire à sa gestion et aux retards dans la découverte des problèmes de qualité.

 Changement de tâche

Il s’agit du basculement contextuel des tâches qui ralentit l’ensemble du processus de développement et de livraison de logiciels et qui entraîne un épuisement mental résultant des actions (répétitives) infligées par le processus. Cela inclut le changement de tâches ou de responsabilités ou la gestion de ressources éloignées ou inaccessibles. La réponse à de meilleurs processus réside dans la gestion des gaspillages de transfert et d’inventaire, ainsi que dans l’attribution d’un environnement et d’outils efficaces, qui aideront les équipes à mieux collaborer et communiquer.

Temps mort / Waiting

Celui-ci est facile à identifier : l’attente d’une réponse à une question spécifique à propos d’un produit de la part des clients, ou d’environnements prêts et à jour.
Le modèle DevOps y contribue, car il s’agit d’une question d’efficacité. Les équipes peuvent partager le même système de tickets afin qu’une équipe de développement puisse immédiatement commencer à travailler sur un défaut dès qu’il a été enregistré par l’équipe de Support Technique. Cette approche est également axée sur la responsabilisation et l’autonomie des équipes, qui peuvent agir sur les tâches qui le nécessitent au lieu d’attendre quelqu’un.
Par exemple, les mises à jour d’environnement ou la mise en place d’une infrastructure en tant que code (IaC) pour soutenir la création d’environnements DevOps. Contrairement à la mise en place d’un environnement traditionnel qui comprend la configuration du réseau, des machines virtuelles, etc., l’IaC génère automatiquement l’environnement requis à la demande.

Surproduction / Overproduction

La surproduction consiste à fabriquer un produit en quantité supérieure à celle qui peut être vendue, par exemple lorsque l’entreprise dépasse les commandes des clients ou continue à fabriquer un produit même si les ventes diminuent.
Dans le domaine du développement de logiciels, le gaspillage lié à la surproduction résulte du développement de fonctionnalités et de solutions qui ne seront jamais utilisées.
Pour y remédier, il convient de concentrer le développement logiciel uniquement sur les bonnes user stories à développer, clairement rattachées à des epics, des initiatives, des thèmes, etc. Des révisions appropriées et fréquentes au sein de l’équipe chargée des fonctionnalités permettent d’identifier les écarts par rapport au scope défini et aident les membres de l’équipe à rester dans les bonnes voies de livraison.
Dans le Lean et le DevOps, l’objectif ultime est de fournir ce dont le client a besoin, quand il en a besoin. Si l’équipe de test est occupée à écrire des scripts inutiles simplement parce qu’elle s’ennuie en attendant un code à tester, c’est le signe que vous avez un problème. Il y a probablement un goulot d’étranglement ou une contrainte qui bloque le flux et vous oblige à surproduire dans un domaine pour compenser. Dans un autre exemple, envisagez de provisionner des environnements d’application et de demander délibérément plus de capacité que nécessaire, juste pour éviter de revenir en arrière et d’en redemander plus tard. Dans un environnement Cloud, ce type de surproduction n’est pas nécessaire. Au lieu de produire une capacité supérieure à celle demandée, vous pouvez acquérir et payer exactement ce dont vous avez besoin.

Conclusion

DevOps est plus qu’une technologie, c’est avant tout une culture et un état d’esprit. Il n’existe pas de solution unique pour tout. C’est à chaque organisation d’identifier ses propres ralentissements. Comprendre et mettre un nom sur les différents gaspillages au sein d’un processus peut vous aider à appliquer le bon type d’amélioration (continue) à apporter. L’amélioration peut porter sur les personnes, les processus, la technologie ou une combinaison des trois. Le cloud en lui-même ne permet pas de rationaliser une organisation si des changements de processus (et de culture) correspondants ne l’accompagnent pas. Vous devez apprendre à « voir le système » et à reconnaître où se trouvent les contraintes et les gaspillages et à les remédier.