SĂ©lectionner une page
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...