Loi de Brooks

Loi de Brooks

Loi de Brooks

L’un des sujets les plus « touchy » de la gestion de projet est de savoir comment composer avec un projet en retard. Il y a quelques années en arrière, alors que je rencontrais un développeur de ma connaissance qui travaillait alors sur un projet très complexe (dû en parti à une vision produit très floue de la part du Project manager), je me hasardais à lui demander des nouvelles sur l’avancée des développements.
Le projet avait déjà pris beaucoup de retard, de nombreuses features avaient été rajoutées au dernier moment mais pire que tout m’expliqua ma connaissance, il se faisait bombarder de CV par son chef de projet qui avait décidé que la meilleure solution pour finir le projet dans les temps étaient d’embaucher 2 ou 3 développeurs supplémentaires. Autant dire que la perspective de devoir procéder au recrutement et à la formation de nouveaux développeurs en plus de sa masse de travail ne l’enchantait guère.
Résultat, quelques mois après notre rencontre, je retrouvais ma connaissance dans une nouvelle startup et apprenait que la fin du projet avait non seulement été chaotique mais que le produit avait été livré avec des semaines de retard, et qu’il ne convenait pas au client.
Le chef de projet avait reporté la faute sur le manque d’investissement des développeurs et était passé à un autre projet car « nobody ever got fired for buying IBM ». Le chef de projet en question ne devait sans doute pas connaître la loi de Brooks, sinon il n’aurait pas centré sa stratégie sur l’ajout de nouveaux membres à une équipe déja débordée et stressée.

Que dit la Loi de Brooks

« Allouer plus de ressources à un projet en retard accentue ce retard », c’est ce qu’explique Fred Brooks, ingénieur informatique, dans son livre de 1975 « The mythical Man-Month ».

L’idée peut sembler contre intuitive, surtout pour les entreprises qui estime en Jour/Homme ou moi/homme, le temps nécessaire pour accomplir une tâche.  Néanmoins, si on se penche un peu plus sur la question, cette loi peut se comprendre assez facilement pour qui connait un peu la gestion de projet ou le développement de logiciel.

Complexité et canaux de communication

  1. Les projets de développement logiciel sont des opérations complexes et chaque nouveau membre ajouté au projet doit dans un premier temps, être formé sur le projet (méthodes, outils, code base…). Ce qui engendre alors une augmentation des canaux de communication, une augmentation des informations échangées et un ralentissement du temps et de la qualité de traitement de ces informations.
    Il existe une formule pour évaluer le nombre de canaux de communication entre les membres d’une équipe.

(n2 – n) / 2

Exemple : Pour une équipe de 6 personnes, il existe 15 canaux de communications. Parfois, une image est plus simple a appréhender qu’une formule mathématique 👇

  1. Ce moment de prise de poste à un impact sur la productivité car non seulement la nouvelle recrue ne participe pas encore positivement mais surtout car cela détourne des ressources vers un temps de formation (le nouveau membre de l’équipe va devoir être formé et supervisé par un membre de l’équipe qui, ne pourra donc plus se concentrer sur son travail en cours). Il est aussi possible, qu’indépendamment de ses compétences, le nouveau membre de l’équipe introduise des bugs qui ralentiront aussi la productivité.
    On parle alors d’effet de courbe en J.

Pour aller plus loin

 

Fred Brooks l’a dit lui même dans son livre, cette loi est une simplification de la réalité. Rien n’est gravé dans le marbre, il existe tout de même des pistes de solutions qui permettent de ne pas tomber sous le coup de la loi de Brooks.

 

  1. Un développeur n’est pas interchangeable avec un autre. Néanmoins, avec une bonne réflexion concernant les problématiques du projet et une bonne évaluation du profil recherché, il peut être positif pour un projet de rajouter à l’équipe quelqu’un possédant une expertise pointue dans un domaine précis.
  2. Une bonne segmentation du projet peut permettre de minimiser les besoins de communications entre les membres de l’équipe.
  3. Une question de timing : il est possible de rajouter des personnes sur un projet plus tôt dans le processus. Pour cela il faut que le chef de projet se remette rapidement en question, vérifie le scope et l’évaluation de son planning (peut-être était-il trop optimiste).
TAGS:

Lire aussi

Loi de Brooks

Loi de Brooks

L’un des sujets les plus « touchy » de la gestion de projet est de savoir comment composer avec un projet en retard. Il y a...

Les frameworks DevOps

Les frameworks DevOps

Découvrir les frameworks DevOps Comme nous l’avons présenté précédemment, DevOps est avant tout une histoire de culture et une...

Les métriques DevOps

Les métriques DevOps

Découvrir les différents métriques DevOps DevOps est certes une histoire de culture, facilitée par la mise en place de « best...

Les origines du DevOps

Les origines du DevOps

Noces rebelles - les origines du DevOps DevOps est un ensemble de pratiques qui combinent le Développement (Dev) et les...

DevOps & le Gaspillage Lean

DevOps & le Gaspillage Lean

DevOps adopte le même objectif que le Lean, à savoir réduire ou éliminer les gaspillages, et en informatique les gaspillages se...

Les pratiques DevOps

Les pratiques DevOps

DevOps est un ensemble de pratiques qui rationnalisent les processus de développement logiciel (Devs) et de gestion de...

Les frameworks DevOps

Les frameworks DevOps

Les frameworks DevOps

Découvrir les frameworks DevOps

Comme nous l’avons présenté précédemment, DevOps est avant tout une histoire de culture et une philosophie. Et comme dans toute pensée philosophique qui se respecte, il existe plusieurs courants différents. Three Ways – Calms et Accelerate sont les plus connus.

 

Three Ways

Ce courant a été popularisé grâce au « Phoenix Project » et le « DevOps Handbook ». Le « Three Ways » – les 3 Principes – se base sur l’idée que les process et les pratiques DevOps viennent de 3 principes fondateurs : The three ways

 

1er principe

Ce principe se concentre sur l’optimisation générale du « work flow », en adoptant une approche holistique des processus depuis la démarche initiale jusqu’au déploiement et au retour client. Ce principe permet d’appréhender les processus de façon globale et non plus en silos traditionnels.

 

2ème principe

Le point clé ici concerne l’importance du feedback afin de permettre la détection et la correction rapide de tous les problèmes ou bug éventuels avant qu’ils n’arrivent jusqu’à l’utilisateur. Ce principe sous-tend la création d’objectif commun et la reconnaissance de difficultés commune entre les Devs et les Ops mais aussi la mise en place d’une télémétrie efficace sur l’ensemble de la chaîne de valeur.

 

3ème principe

Sans doute le principe le plus important puisqu’il s’agit de la mise en place d’une culture de la collaboration et de l’expérimentation. Le concept fondateur du DevOps est le « Continuous Learning ». Répétition et pratique sont encouragées, y compris grâce à des outils comme « Chaos Monkey » servant à tester la résilience des infrastructures. Ici, il ne s’agit pas de la culture du Héro mais bien celle de l’amélioration continue, en laissant à chacun la liberté d’admettre ses erreurs ou ses questionnements. Cette tolérance de l’erreur crée une sécurité psychologique qui favorise l’expérimentation et l’amélioration.

Keep Calms

Le modèle CALMS est principalement utilisé pour évaluer si votre organisation est assez mature pour adopter la culture DevOps ou plus simplement évaluer la progression de l’initiative en cours. CALMS est l’acronyme représentant les cinq piliers de ce modèle : Culture – Automatisation – Lean – Mesure – Sharing

 

Culture

La culture est la partie la plus importante de ce modèle et du DevOps en général. Il s’agit donc de mettre en place une culture de la communication et de la collaboration mais aussi d’apprentissage continu. L’objectif est d’encourager un état d’esprit fondé sur des hypothèses et une démarche scientifique, remplaçant ainsi une culture de la peur par une culture du partage où les problèmes ne sont pas cachés sous le tapis, mais identifiés et la solution trouvée de façon collégiale.

 

Automatisation

Ce pilier est le plus facile à appréhender puisqu’il est presque systématiquement associé au concept de DevOps. Le DevOps est même souvent réduit à la notion d’automatisation, mais comme l’a très bien exprimé Christopher Little « DevOps ne se limite pas à l’automatisation, tout comme l’astronomie ne se limite pas aux télescopes. ». Mais attention l’automatisation n’en reste pas moins critique, tout système manuel représente un risque majeur pour les entreprises. C’est pourquoi « Continuous Integration » et « Continuous Deployment » sont largement adoptés afin de fluidifier et favoriser les déploiements. Netflix est très connu pour l’efficacité de son process de déploiement (pas moins d’une centaine par jour).
La mise en place du « As-a-Service » comme l’infrastructure as a Service permet aussi de créer de l’environnement à la demande.

 

Lean

DevOps repose aussi sur un grand nombre de principe Lean qui cherchent à créer de la valeur pour le client final grâce au « system thinking ». La philosophie du Lean prévoit une élimination du gaspillage et la maîtrise de la chaîne de valeur grâce à des outils comme la Value Stream Map (VSM)

 Mesure

DevOps est aussi une démarche scientifique et en tant que tel nécessite d’être évaluée par le biais d’une collecte de données et de métriques solides (SLA-SLO-SLI) permettant la prise de décisions d’amélioration sur des informations éclairées. Avant de commencer une révision totale des métriques d’une organisation, il est important de considérer dans un premier temps les mesures existantes pour en faire un inventaire et vérifier leur compatibilité avec la démarche DevOps. Et ensuite seulement mettre en place de nouvelles mesures en adéquation avec les nouveaux outils et process mis en place.

 

Sharing

Ce dernier principe est intrinsèquement lié à la culture du DevOps qui repose sur la collaboration et le partage. Ce principe reprend l’adage « Knowledge is the currency of the new economy”. DevOps se concentre sur la transparence et le partage de connaissances à travers les silos, au-delà du mur de la confusion (l’incompréhension et la non-communication entre les équipes dev et Ops). Les équipes DevOps se concentrent sur des objectifs communs, éliminant ainsi les frictions, et partageant ainsi les responsabilités.

Deployment celebrations should be about the value of new features, not joyful relief that nothing went wrong” — Rebecca Parsons

Accelerate

Ce modèle est défini dans le livre « Accelerate : Building and Scaling High Performing Technology Organization » par Nicole Forsgreen, Jez Humble et Gene Kim.

Points clés : Au sein des organisations les initiatives de la Transformation Technologique sont à des stades différents mais surtout, bien que le DevOps accélère la transition technologique, cette transition est très fréquemment sous-estimée, en particulier par les dirigeants. La clé pour vérifier l’efficacité des changements opérés est de mesurer et comprendre les éléments essentiels en se focalisant sur les capacités et non pas sur la maturité des entreprises, par le biais de 4 facteurs.

Modèle de maturité et modèle de capacités : la battle

1er facteur : les objectifs

Modèle de Maturité : ici, l’objectif est d’aider les organisations à « arriver » à un stade de maturité et une fois ce stade atteint… Mission accomplie. Le problème est que cette vision est antagoniste avec l’objectif DevOps qui se concentre sur le paradigme de l’amélioration continue.

Modèle des capacités : Prise en compte de la constante évolution des technologies et des attentes business. Ce modèle prévoit que l’évolution ne s’arrête jamais.

 

2ème facteur : dimensions

Modèle de Maturité : ce modèle est construit de façon linéaire, prévoyant un ensemble de technologies, d’outils et de ressources identiques quelles que soient les équipes et les entreprises. Evidemment, le problème est que toutes les entreprises ne sont pas identiques.

Modèle des capacités : construit de façon dynamique et multidimensionnelle, ce modèle prévoit la possibilité pour les organisations d’avoir une approche personnalisée de l’amélioration en se concentrant sur les ressources que les organisations jugent comme les plus bénéfique selon leurs contextes actuels.

 

3ème facteur : mesure

Modèle de Maturité : La mesure des performances dans ce modèle se contente de mesurer les performances techniques sans les lier à des résultats quelconques. Autant dire qu’il s’agit plus de Vanity metrics qu’autres choses, puisqu’elles n’apportent aucune information sur l’impact business.

Modèle des capacités : la mesure ici est concentrée sur des objectifs de haut-niveau et sur la façon dont les capacités et ressources permettent d’améliorer les résultats de l’entreprise.

 

4ème facteur – agilité

Modèle de Maturité : Défini un niveau figé de capacités à atteindre autant au niveau des ressources, des processus et de l’organisation.

Modèle des capacités : ce modèle est plus fluide et permet de s’adapter à des environnements en constante mutation et offrent aux organisation la possibilité de se concentrer sur les développements des compétences pour rester compétitif.

Quel que soit le modèle utilisé il y a des désaccords sur les capacités à évaluer. Accelerate propose une série de 24 facteurs clés qui contribuent de façon significative à améliorer les performances de développement et la livraison de logiciels. Ces capacités sont divisées en 5 catégories : livraison continue, Architecture, Produits et process, Lean management et monitoring et enfin culture.

En conclusion

En analysant les différents modèles présentés dans cet article, plusieurs thèmes apparaissent comme récurrents : la Culture – la Collaboration et l’amélioration continue. Ces trois concepts de haut niveau englobent un grand nombre des principes présentés dans ces modèles.

You may also like

Les origines du DevOps

Les origines du DevOps

Noces rebelles - les origines du DevOps DevOps est un ensemble de pratiques qui combinent le Développement (Dev) et les...

DevOps & le Gaspillage Lean

DevOps & le Gaspillage Lean

DevOps adopte le même objectif que le Lean, à savoir réduire ou éliminer les gaspillages, et en informatique les gaspillages se...

Les pratiques DevOps

Les pratiques DevOps

DevOps est un ensemble de pratiques qui rationnalisent les processus de développement logiciel (Devs) et de gestion de...

Les métriques DevOps

Les métriques DevOps

Les métriques DevOps

Découvrir les différents métriques DevOps

DevOps est certes une histoire de culture, facilitée par la mise en place de « best practices » et d’outils appropriés. Cette démarche vise à améliorer la conception de produits et services logiciels, grâce à des feedbacks régulier et du contrôle continu. Mais pour s’assurer de l’efficacité de cette démarche, il vaut mieux savoir quelles métriques évaluer.

Métriques d’incidents

MTT-R Mean Time to R-

Commençons par le métrique qui est sans doute le  plus délicat. En effet le MTTR peut représenter 4 mesures différentes puisque le R peut signifier « repair », « recovery », « respond » ou « resolve » et bien que ces mesures puissent sembler proches, elles ont chacun leurs significations proches.
Il est donc important pour cette mesure précise, d’avoir bien intégré le principe de communication mis en avant par le DevOps est de clarifier de quel MTTR il s’agit. Avant de commencer à évaluer votre MTTR, vos équipes doivent être d’accord sur ce qui va être suivi et s’assurer que chacun parle de la même chose.

 

Mean Time to Repair

Le MTTR (mean time to repair) est le temps moyen nécessaire pour réparer un système. Le MTTR est une mesure critique de la maintenabilité des systèmes, qu’il s’agisse d’applications ou d’infrastructures. Le MTTR est la valeur qui est utilisée pour vérifier l’efficacité de la réparation de ces systèmes lorsqu’un incident informatique se produit. Le MTTR est d’autant plus précieux que près de 90% du MTTR de réparation est dédié à l’identification du problème.

Calcul du temps moyen de réparation
Le MTTR s’obtient en additionnant le temps total consacré aux réparations pendant une période donnée, puis en divisant ce temps par le nombre de réparations.

 

Mean time to recovery – Temps moyen de récupération

Dans les indicateurs DevOps, le MTTR (mean time to recovery) est le délai moyen de récupération après une défaillance produit ou système.
Il couvre toute la durée de la panne, depuis le moment où le système ou le système tombe en panne jusqu’au moment où il est à nouveau totalement opérationnel.

Calcul du temps moyen de rétablissement

Le délai moyen de rétablissement est calculé en additionnant tous les temps d’arrêt pendant une période spécifique et en le divisant par le nombre d’incidents.
Il est généralement mesuré en heures et peut se référer aux heures ouvrables, et non aux heures d’horloge.

Mean time to Resolve – Temps moyen de resolution

Le MTTR (mean time to resolve) est le délai moyen entre la détection d’un incident et le moment où le système ou le composant concernés sont de nouveau disponibles pour les utilisateurs.  Cela englobe le temps nécessaire pour détecter la panne, diagnostiquer le problème et le réparer, mais aussi le temps passé à faire en sorte que la panne ne se reproduise pas. Cet indicateur est fortement corrélé à la satisfaction client.

Calcul du délai moyen de résolution

Pour calculer ce MTTR, il faut additionner le temps total de résolution pendant une période donnée et le diviser par le nombre d’incidents.

 

Mean time to respond – Temps moyen de réponse

Le MTTR (mean time to respond) est le temps moyen nécessaire pour se remettre d’une panne de produit ou de système à partir du moment où vous êtes alerté pour la première fois de cette panne. Ce délai n’inclut pas le temps de latence de votre système d’alerte. Le temps moyen de réponse est utile en cybersécurité, associé au MTTD (Mean Time to Detect).

Calcul du temps moyen de réponse

Pour calculer ce temps moyen de réponse, il faut additionner le temps de réponse complet entre l’alerte et le moment où le service ou le produit est à nouveau pleinement fonctionnel. Divisez ensuite par le nombre d’incidents.

 

MTTD – Mean Time to Detect

Le MTTD est le temps moyen qu’il faut aux équipes pour identifier les problèmes. C’est une métrique très importante à surveiller en matière de cybersécurité.

Calcul du Mean Time to Detect
Pour trouver le MTTD, il suffit d’additionner tous les temps de détection des incidents pour le membre de l’équipe ou la période donnée et de diviser par le nombre d’incidents.

 

Taux d’échappement des bugs

Il est évident que, dans un monde idéal, tous les bugs sont trouvés pendant la phase de test sur le serveur de développement. Cependant, dans la vie réelle, et parce que DevOps vise à livrer du code rapidement, il est important de suivre cette métrique pour minimiser le nombre et la gravité des défauts qui arrivent en production.

Le pourcentage de défauts critiques et échappés est un KPI important, il garantit que l’équipe et ses efforts de test se concentrent sur la rectification des problèmes et des défauts critiques du produit, ce qui les aide à assurer la qualité de l’ensemble du processus de test ainsi que du produit.

« Fueled by data and empowered by automation, IT can operate in real-time, be predictive and rely on detailed data to have a true seat at the table, delivering strategic value for their organization and for their customers.”
— Joseph Bradley

Métriques de fiabilité et de maintenance

MTBF – Mean time between failures – Temps moyen entre les défaillances

Le MTBF (mean time between failures) désigne le temps moyen entre les pannes d’un système. Cette mesure est utilisée pour suivre à la fois la disponibilité et la fiabilité d’un produit. Le MTBF est une mesure de maintenance incontournable pour évaluer les performances, la sécurité des actifs critiques ou complexes. Il s’agit de l’un des rares KPI qui se doivent d’être augmenté : plus le temps entre les défaillances est élevé, plus le système est fiable.

Calcul du temps moyen entre les défaillances

Il s’agit de la somme des heures d’Uptime selon une période diviser par le nombre de défaillances survenues au cours de cette même période. Le MTBF est généralement mesuré en heures, mais si vous avez la chance de pouvoir la mesurer en jours : Félicitations !

 

MTTF – Mean Time to Failure ou Temps moyen avant défaillances

Cette métrique est souvent confondue et employée de manière interchangeable avec le temps moyen entre les défaillances (MTBF).
La principale différence entre MTBF et MTTF est que le MTTF concerne les équipements non réparables, alors que le MTBF s’applique aux systèmes réparables.
Les logiciels peuvent être réparés et subiront de multiples défaillances au cours de leur durée de vie, et auront donc des périodes de temps entre les défaillances, alors que les éléments non réparables, tels que les disques SSD, fonctionneront correctement pendant un certain temps avant de tomber définitivement en panne, et n’auront donc qu’une seule défaillance au cours de leur durée de vie.

Comment calculer le MTTF

Pour calculer le MTTF, il faut diviser le nombre total d’heures de fonctionnement par le nombre total de ressources utilisées. Le MTTF représente le temps moyen avant défaillance.

 

Test automatisé (%)

DevOps se base en grande partie sur l’automatisation, par conséquent le suivi de l’efficacité de vos tests automatisés est important.
Cette métrique compte le nombre de tests automatisés effectués pour un build donné. Cependant, cette mesure ne prend pas en compte la redondance, l’efficacité ou la variabilité des tests.
Cette mesure va au-delà du simple décompte du nombre de tests automatisés et aide à définir clairement les risques métiers. Grâce à cette mesure, ils peuvent concentrer leurs efforts d’automatisation des tests sur les tests qui comptent le plus pour l’entreprise.

Métriques de Déploiement

Lead Time for changes

Il s’agit d’un indicateur important qui permet dans le cadre du modèle DevOps puisqu’il permet de déterminer l’efficacité des processus. La philosophie DevOps implique de déployer des « small batches » code fréquemment, c’est pourquoi il est important d’évaluer le temps nécessaire pour implémenter, tester et livrer le code. Pour cela il faut deux données importantes : le moment où le commit a eu lieu et celui où le code a été déployé.

 

Fréquence de déploiement

Il s’agit du nombre de déploiements de logiciels sur une période donnée. Attention, cette mesure concerne les performances techniques du pipeline de déploiement, et non la fréquence de livraison, en effet tous les déploiements ne sont pas poussés en production. Il peut être mesuré de différentes manières, notamment par des pipelines de déploiement automatisés, des appels API et des scripts manuels.

 

Taux de stabilité des déploiements

Tout déploiement qui peut causer des problèmes ou des défaillances pour vos utilisateurs est considéré comme un échec. La stabilité des déploiements est le pourcentage de temps pendant lequel le dépôt le plus récent pour un repository donné a réussi.

Bien sûr, les équipes DevOps sont censées intégrer la qualité dans le produit dès le début du projet, mais des échecs et des erreurs peuvent survenir. Les « builds » cassés ne sont pas tous dus à des erreurs de code ; il peut s’agir d’un problème d’infrastructure qui doit être résolu. Cela devient un problème lorsque ces erreurs persistent pendant une longue période et commencent à nuire à la productivité des développeurs.

Ce nombre doit être aussi bas que possible : 0 étant le nombre magique, moins de 5% d’échecs de déploiement est considéré comme acceptable.

 

Métriques de services

Volume des tickets

Le volume de tickets ou le nombre total de tickets permet de suivre tous les tickets dans votre file d’attente de support sur une période donnée. Les bogues et les erreurs peuvent parfois passer outre la phase de test et être détectés par l’utilisateur final, ce qui entraîne l’ouverture d’un nouveau ticket.
Le nombre de tickets clients signalés comme des « problèmes » ou des bugs est un indicateur majeur de la fiabilité de l’application. Un grand nombre de tickets indique des problèmes de qualité, tandis qu’un petit nombre indique la robustesse de l’application. En d’autres termes, ce chiffre est une mesure de la satisfaction de l’utilisateur final.
Une variante de cette mesure est le nombre total de conversations qui comptabilise tous les échanges avec les clients, que ce soit par le biais d’un ticket de support officiel, des réseaux sociaux ou de tout autre canal.

Utilisation des applications et de trafic

À l’issue d’un déploiement, il convient de vérifier le niveau d’utilisation des applications ou de contrôler si le nombre de transactions ou d’utilisateurs accédant au système paraît normal. Si tout à coup le trafic est nul ou présente un pic de trafic (si vous utilisez des microservices), il y a un problème.

TAGS:

You may also like

Loi de Brooks

Loi de Brooks

L’un des sujets les plus « touchy » de la gestion de projet est de savoir comment composer avec un projet en retard. Il y a...

Les frameworks DevOps

Les frameworks DevOps

Découvrir les frameworks DevOps Comme nous l’avons présenté précédemment, DevOps est avant tout une histoire de culture et une...

Les métriques DevOps

Les métriques DevOps

Découvrir les différents métriques DevOps DevOps est certes une histoire de culture, facilitée par la mise en place de « best...

Les origines du DevOps

Les origines du DevOps

Noces rebelles - les origines du DevOps DevOps est un ensemble de pratiques qui combinent le Développement (Dev) et les...

DevOps & le Gaspillage Lean

DevOps & le Gaspillage Lean

DevOps adopte le même objectif que le Lean, à savoir réduire ou éliminer les gaspillages, et en informatique les gaspillages se...

Les pratiques DevOps

Les pratiques DevOps

DevOps est un ensemble de pratiques qui rationnalisent les processus de développement logiciel (Devs) et de gestion de...

Les origines du DevOps

Les origines du DevOps

Les origines du DevOps

Noces rebelles – les origines du DevOps

DevOps est un ensemble de pratiques qui combinent le Développement (Dev) et les Opérations informatique (Ops). Il s’agit avant tout d’une culture issue de la fusion de principes de management, du développement traditionnel de logiciels, de processus de gestion d’infrastructure et d’outils qui augmentent la capacité d’une organisation à fournir à un rythme intense des applications et des services.
Faire travailler ensemble tous les services IT, est un concept qui peut sembler évident. Mais la réalité s’avère plus complexe à mettre en place pour une raison, elle, très simple : traditionnellement, Devs et Ops fonctionnent chacun en silos et ont des rôles et objectifs diamétralement opposés. Plus simplement, le DevOps est né de la volonté de réconcilier ces deux camps devenus opposés. Pour mieux comprendre il faut déconstruire cette tragédie en 3 actes, menant à la rupture Dev/Ops.

Des problèmes systémiques

Pour comprendre la notion même de DevOps, il faut remonter un peu dans le temps. Traditionnellement, l’organisation des services IT privilégiait une approche fonctionnelle, organisant les équipes en fonction de leurs spécialités – les administrateurs de bases de données, les administrateurs réseaux, les administrateurs serveurs, les Développeurs etc. Chacun dans des groupes différents, et pour rajouter à la difficulté, chacun ayant des objectifs diamétralement opposés.

Devs

Les développeurs se concentrent sur la réalisation des besoins de l’entreprise en matière de nouvelles caractéristiques et fonctionnalités ainsi que sur leur mise en production le plus rapidement possible.

Ops

Les opérations informatiques ont pour mission de fournir à leurs clients un service informatique à la fois stable, fiable et sécurisé, et par conséquent, cherche à tout prix à éviter l’introduction de changements susceptibles de mettre en péril la production.

“Practice the philosophy of continuous improvement. Get a little bit better every single day.”
— Brian Tracy

Le drame

Commence ici le drame classique, une structure en 3 actes.

Acte 1 – l’exposition (Set Up)

La scène commence au sein des Ops, occupé à maintenir les applications et infrastructure pour s’assurer que l’organisation continue à délivrer de la valeur à leurs clients. La routine consiste à devoir régler les problèmes dû à la complexité des applications, à la dette technique et aux hacks quotidiens. Bien sûre, la promesse est faite de régler le problème plus tard, quand la charge de travail s’allègera…

Acte 2 – Confrontation (confrontation)

Evidemment, les artefacts les plus fragiles, car les plus sujets à modification lourdes et toujours urgentes, sont aussi ceux supportant généralement les projets les plus critiques ou les systèmes apportant le plus de revenues. Et là, c’est le drame. Un bug, un système down, des retards, un problème de sécurité. Et pendant que les équipes Ops s’affairent à résoudre le problème, un Product Manager ou un CEO, un Commercial, arrive avec une idée lumineuse pour une nouvelle fonctionnalité qui résoudra sûrement tous les problèmes préexistant (peu importe la difficulté ou la faisabilité technique). Entre à nouveau en scène les Devs qui vont devoir trouver une solution rapide pour créer cette nouvelle fonctionnalité, relever les défis techniques et parfois prendre des raccourcis pour respecter les deadlines. Et le cycle continue…

Acte 3 – Dénouement – Résolution (climax)

Pas de dénouement heureux ici, le cycle fini par aboutir logiquement à des cycles de livraison rallongés, des résultats de déploiements moins fiable, des pannes, une plus grande résistance des Ops à tout changement, le traitement des feedbacks interne et externe se ralenti… Finalement toute l’entreprise perd de sa compétitivité et les équipes IT qui se sentent coincé dans un système qui prédispose à l’échec dans lequel ils se sentent impuissant et non reconnu. Demandez à n’importe quel administrateur système ce qu’il pense des joies du déploiement du vendredi soir, qui force toutes les équipes à travailler tout le weekend.

Epilogue – Calms down

Au cours de la dernière décennie, les évolutions technologiques et la transformation numérique ont impacté toutes les entreprises. La transformation numérique est pilotée par les interactions avec les clients, les partenaires et les fournisseurs, qui évoluent toujours plus vers le numérique. De nos jours, « Chaque entreprise est une entreprise technologique » et les application et infrastructure sont devenues des facteurs stratégiques clés de différenciation des entreprises.
Autant dire que les enjeux et la pression auxquels sont confrontés les équipes IT est immense.
Et là, entre le DevOps ! L’idée apparait pour la première fois en 2008 de la rencontre d’Andrew Shafer (software Développer) et Patrick Debois (sysadmin) à une session devenue célèbre de la conférence Agile de Toronto : Birds of Feathers. Fini les équipes de Développement et d’exploitation « cloisonnées », souvent fusionnées en une seule équipe où les ingénieurs travaillent ensemble du cycle de vie (build – test – release).
Au fil des années sont aussi apparus des Frameworks regroupant les principes de base du DevOps : CALMS, The Three Ways, Accelerate.

TAGS:

You may also like

Les origines du DevOps

Les origines du DevOps

Noces rebelles - les origines du DevOps DevOps est un ensemble de pratiques qui combinent le Développement (Dev) et les...

DevOps & le Gaspillage Lean

DevOps & le Gaspillage Lean

DevOps adopte le même objectif que le Lean, à savoir réduire ou éliminer les gaspillages, et en informatique les gaspillages se...

Les pratiques DevOps

Les pratiques DevOps

DevOps est un ensemble de pratiques qui rationnalisent les processus de développement logiciel (Devs) et de gestion de...

DevOps & le Gaspillage Lean

DevOps & le Gaspillage Lean

DevOps & le Gaspillage Lean

DevOps adopte le même objectif que le Lean, à savoir réduire ou éliminer les gaspillages, et en informatique les gaspillages se présentent sous plusieurs formes.

 

  1. Rework (le travail effectué pour corriger des bugs ou des défauts et qui coûte jusque 520 milliards par an)
  2. les temps mort (le temps passé par les équipes à attendre – ouverture de tickets par exemple).
  3. Transfert/Transport : Dans le cadre de DevOps, cela inclut le transfert de code entre les développeurs et les opérations, ainsi que les interminables e-mails et messages Teams/Slack qui semblent s’éterniser. Les processus de révision et d’approbation excessifs entrent également dans cette catégorie. Par exemple, le déplacement d’un ticket de service d’une équipe à l’autre avant qu’il n’atteigne la bonne destination.
  4. Processus supplémentaires – n’importe quel travail supplémentaire, features par exemple, effectué qui n’apporte pas de valeur ajoutée au client. Il peut s’agir de documentation non utilisée dans un poste de travail en aval, ou de révisions ou d’approbations qui n’ajoutent pas de valeur au résultat. Les processus supplémentaires ajoutent des efforts et augmentent les délais.
  5. Changement de tâche : lorsque des personnes sont affectées à plusieurs projets et flux de valeur, elles doivent changer de contexte et gérer les dépendances entre les tâches. Ce changement de tâche augmente la charge mentale et les efforts des équipes.
  6. Travail non standardisé ou manuel : Dépendance à l’égard du travail non standard ou manuel
  7. Over-production : Correspond à toute les features et produits développés que personne n’utilise.

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.

“The most dangerous kind of waste is the waste we do not recognize”
— Shigeo Shingo

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.

TAGS:

A lire aussi

Les origines du DevOps

Les origines du DevOps

Noces rebelles - les origines du DevOps DevOps est un ensemble de pratiques qui combinent le Développement (Dev) et les...

DevOps & le Gaspillage Lean

DevOps & le Gaspillage Lean

DevOps adopte le même objectif que le Lean, à savoir réduire ou éliminer les gaspillages, et en informatique les gaspillages se...

Les pratiques DevOps

Les pratiques DevOps

DevOps est un ensemble de pratiques qui rationnalisent les processus de développement logiciel (Devs) et de gestion de...