Tag: Agile

Comprendre la loi de Little

L’un des principaux objectifs de Lean est de diminuer le Lead Time c’est à dire le temps de latence entre la prise en charge d’une tâche et son execution totale. Si l’on suit une stratégie Lean, diminuer ce lead time permettra d’un part d’augmenter notre capacité à produire mais aussi d’augmenter notre niveau de prédictibilité. La première façon de diminuer le Lead Time est de réduire la taille des tâches (batch size), la seconde est de comprendre la loi de Little :

Comprendre la loi de Little

Pour l’historique, cette loi fut trouvée par John Little dans les années 60. Son principe est simple : le nombre de clients dans une file d’attente (l) est égale au taux d’arrivée moyen des clients (λ) multiplié par le temps de traitement (ω).

l = λω

En résumé, si je prends l’exemple d’une caisse de supermarché, si j’ai 3 clients par minutes qui arrivent à la caisse et que le traitement d’un client prends 2 minutes, le temps d’attente moyen d’un client est de 6 minutes.

Voici un très bon article sur la loi de Little et les processus Stochastiques. Si vous voulez vous remettre au maths, cela ne fait pas de mal :).

Et Lean dans tout ça ?

Dans une équipe Agile, le lead time est déterminé à partir du moment où l’implémentation d’une fonctionnalité est prise en charge par l’équipe de développement. Il s’en suit l’implémentation, les tests et le déploiement pour que celle ci soit totalement finalisée.

Imaginons une équipe qui délivre 10 fonctionnalités (Features) tous les 3 mois. Si l’équipe prends en charge 20 fonctionnalités en même temps, il lui faudra probablement au moins 6 mois afin de finaliser les fonctionnalités associées. Le temps d’attente moyen (Lead Time) sera donc de 6 mois quelle que soit la fonctionnalité à développer.

Limiter le WIP

Le WIP ou Work-In-Process/Progress est le nombre de tâches exécutées en parallèle par une équipe de développement. Sur un Kanban, on cherchera à mesurer ce WIP et à le limiter. En effet, limiter le nombre de tâches à traiter en parallèle est clé si l’on veut conserver un bon niveau de productivité sans mettre à mal la qualité.

Revenons à notre équipe agile, si je cherche à limiter mon Lead time, je peux jouer sur deux facteurs :

  1. Le niveau de productivité de l’équipe. Sa vélocitié de façon à ce qu’elle délivre plus de fonctionnalités en une itération donnée
  2. Le nombre de fonctionnalités sur lesquelles l’équipe travaille

Chercher à augmenter la vélocité d’une équipe agile n’est clairement pas l’option la plus satisfaisante (voir mon article précédent). Nous allons donc facilement pouvoir jouer sur le nombre de fonctionnalités dans la file d’attente.

Exemple:

  • L’équipe délivre 10 fonctionnalités tous les 3 mois
  • L’équipe travaille sur 8 fonctionnalités

Par conséquent, le temps de traitement (Lead Time) moyen sera de 2,4 mois. Il a donc de forte chances que l’équipe arrive à délivrer à l’issue de cette itération de 3 mois avec un bon niveau de confiance.

En résumé

En résumé, la loi de Little met en évidence que plus le travail en cours (WIP) est limité, meilleur est le Lead Time et notre capacité à produire.

Scrum – The Art of Doing Twice the Work in Half the Time

C’est sans doute un des titres les plus long de la littérature mais il correspond tellement bien à ce livre ! Jeff Sutherland est le co-rédacteur du Scrum Guide avec Ken Schwaber. Ensemble, ils ont créé Scrum, un Framwork Agile simple et léger permettant de développer des projets ou  produits complexes.

Jeff nous emporte dans la génèse du Framework Scrum où il expirimenta ses premières versions dans les années 80. De par ses expériences, il a pu démontrer que lorsqu’une équipe  s’auto organise et évolue de manière itérative autour d’un objectif commun, les résultats obtenus sont souvent de bien meilleure qualité qu’une équipe executant les ordres d’un suppérieur hierarchique. Cette approche permet de construire des produits ou des projets complexes, en capitalisant sur l’expérience et le professionalisme de l’équipe de développement. Vous découvirez que l’ensemble du Scrum Guide peut s’appliquer à de nombreux contextes.

Je vous conseille ce livre si vous souhaitez en savoir plus sur la génèse du Framework Scrum et sur la vie d’un de ses inventeurs.

Bonne lecture !

DevOps – Comment joindre l’ITIL à l’agréable ?

Le chemin vers le DevOps peut être long et sinueux. Nous ferons face à de nombreux obstacles, à la fois culturels et organisationnels.  Une équipe DevOps doit être avant tout Agile et s’adapter en toutes circonstances. L’objectif de cet article et de partager une vision long terme et les étapes qui nous y amènent.

Pourquoi l’ITIL ?

La plupart des grosses structures ont, par définition et d’un point de vue RH, des groupes d’entités « métier » et « techniques ». Les entités métiers ont pour but d’apporter de l’innovation dans le métier de l’entreprise, d’augmenter le chiffre chiffre d’affaire et optimiser les dépenses. Les entités techniques, quant à elles, ont pour objectif d’implémenter, d’héberger et d’assurer le fonctionnement des outils nécessaires aux entités métiers pour exercer leurs fonctions. Les besoins sont multiples : performance, stabilité, sécurité, disponibilité. Afin que l’ensemble de ces critères soit satisfait, des méthodes et process ITIL ont été mis en place dans le but de contrôler et canaliser les changements pour plus de stabilité opérationnelle.

Un peu d’historique

Avant l’avènement des méthodes agiles, la plupart des projets suivaient un cycle de livraison en V. Les principes de cette méthode s’inspirent directement de l’industrie. On commence par recueillir le besoin initial puis définir des Blueprints d’architecture. L’ensemble des besoins est ensuite détaillé à la fois sur les aspects fonctionnels et techniques. Vient ensuite les phases d’implémentation, de test et de déploiement.

Cette méthode couplée à des processus ITIL permet une stabilité opérationnelle optimale. On modifie peu la production et lorsque cela arrive on canalise au maximum le changement via des processus définis. Cette façon de fonctionner a fait ses preuves durant de nombreuses années. Cependant, elle est de plus en plus controversée au bénéfice d’approches plus agiles. En effet, la plupart des équipes de développent travaillent en agile au plus près du métier. Elle délivrent des incréments régulièrement et sont souvent confrontés à la latence des process une fois l’incrément livré. Cela apporte de la frustration à la fois au niveau métier mais aussi au niveau des équipes de développement.

« Individuals and interactions over processes and tools »

Il s’agit du premier concept souligné par l’agile manifesto. Les fondements de l’agile sont la transparence, l’inspection et l’adaptation. Le principe est d’analyser les situations, d’apprendre de ses échecs et d’évoluer de manière empirique dans des environnements complexes. Le chemin vers l’agile et de DevOps peut être long et complexe, voici quelques étapes à franchir en s’inspirant de l’échelle de Tuckman :

Forming – Démarrer du bon pied

Devops est une histoire de personnes et de compétences avant tout. La formation est nécessaire afin que l’ensemble des équipes adoptent l’état d’esprit et la philosophie portée par le DevOps.

Storming – Etre confronté à la réalité

Une fois sur le terrain, les équipes formées feront face aux vraies difficultés. Durant cette phase, les interactions devront se mettre en place et les rôles et responsabilités de chacun en découler.

Norming – Mettre de l’huile dans les rouages

Une fois les process éprouvés, chaque équipe DevOps devra :

  • Mettre en place des processus d’amélioration continue.
  • Mesurer pour mieux améliorer.
  • Adapter et simplifier les process devant l’être.
  • Être pragmatique. Les objectifs communs seront l’augmentation de la réactivité des équipes et la diminution du Lead Time à son minimum.

Performing – en route vers l’excellence

À ce stade, l’équipe tire les fruits des changements opérés dans l’étape Norming. Les processus d’amélioration continue tireront l’équipe DevOps vers l’excellence, à la fois technique et collaborative. L’objectif : Changer son métier pour plus d’innovation et de performance !

Exemples à suivre: Amazon, Netflix, Spotify

En conclusion, DevOps est une histoire de personnes avant tout ! Les process ne doivent pas en bloquer l’adoption. Ils devront être au cœur de la transformation et potentiellement adaptés grâce à l’expérience des équipes. Une vision long terme est déterminante dans le succès d’une transformation Agile et DevOps. Changez votre métier pour le meilleur !

Comment prioriser son Product Backlog à l’aide du WSJF ?

WSJF ? Qu’est ce que c’est ? Encore un acronyme de plus dans notre vocabulaire. J’ai découvert cette technique dans le Framework SAFe. WSJF veut tout simplement dire « Weighted Shortest Job First » ou en français « la plus importante ou la plus courte fonctionnalité d’abord ! ». Organiser ou prioriser le Product Backlog est souvent un casse tête pour le Product Owner. Sur des projets complexes avec beaucoup de fonctionnalités, il est parfois très chronophage de faire l’exercice de raffiner son Product Backlog de manière efficace. Cet outil pourra nous y aide. Je vois plutôt le WSJF comme un outil plutôt qu’un indicateur. Il permet de déterminer un chiffre représentant le bon compromis entre la valeur qu’apportera la fonctionnalité si on la livre et le temps que l’on prendra à la développer.

D’où vient le WSJF ?

SAFe part du principe que toute fonctionnalité non livrée à temps à un coût : The Cost of Delay. Dans la philosophie de Lean, l’objectif est donc de réduire ce coût au minimum pour augmenter notre efficacité et livrer le maximum de valeur à l’issue d’un Sprint. Prenons quelques exemples simples. Imaginons que nous avons deux fonctionnalité à développer. Elle ont la même valeur métier mais l’une d’entre elle est plus courte à développer. Le product Owner priorisera sans aucun doute la plus courte. Par contre, si l’une des fonctionnalité prends moins de temps à développer mais est aussi moins prioritaire, il est difficile de la prioriser dans le Product Backlog. Le Product Owner devra trouver le bon compromis. L’idée du WSJF est de lui fournir un outil factuel permettant de l’aider dans cette tâche!

Comment se calcul-t-il ?

Le calcul du WSJF prends en compte les critères suivants. On utilisera pour tous ces indicateurs une notation suivant une suite de Fibonacci par ordre croissant:
– User-Business Value : la valeur métier de la fonctionnalité.
– Time Criticality : détermine si la fonctionnalité doit être livré rapidement ou non.
– Risk Reduction or Opportunity Enablement: Détermine si cette fonctionalité réduit le risque ou facilite le développement d’autres fonctionalités par la suite
– Job Size : Taille de la fonctionnalité à développer. On parle aussi d’effort. Cette valeur peut être estimée par l’équipe de développement.

Calcul du « Cost of Delay »

Cost of Delay = User-Business Value + Time Criticality + Risk Reduction and/or Oppty Enablement
WSJF = Cost of Delay / Job Size

Plus le WSJF a une valeur importante, plus la fonctionnalité pourra être priorisée. On voit ici que dans cette formule, nous prenons en compte à la fois la valeur métier mais aussi la contrainte de temps et la réduction du risque. Le facteur ayant le plus de poids sur la formule est donc la taille ou l’effort.
Cela met en évidence plusieurs chose. D’une part plus les Features sont petites, plus elles sont faciles à estimer et à ordonnancer les unes par rapport aux autres. On parle en général de MMF (Minimum Marketable Feature). D’autre part, ce n’est pas parce qu’une fonctionnalité semble importante qu’elle doit être priorisée. Il faudra prendre en compte l’impact si celle-ci n’est pas développée à court terme. Dernier point, ce calcul n’est pas figé dans le temps. L’ensemble des facteurs pourra être revu au fil des sessions de Product Backlog Refinement.

En conclusion, le WSJF est un outil relativement puissant permettant une bonne priorisation du Product Backlog en entrée de chaque Sprint. Il fera aussi gagner beaucoup de temps à la Scrum Team dans les sessions de Product Backlog Refinement où l’équipe pourra se focaliser sur les fonctionnalités les plus cruciales.

Pour aller plus loin:

http://www.scaledagileframework.com/wsjf/

Votre Daily Scrum est-il efficace ?

Il est souvent très difficile de conserver la durée du Daily Scrum à 15 minutes surtout lorsque l’équipe est constituée de nombreux membres (maximum 9). L’objectif de cet article est de souligner les problèmes fréquemment rencontrés et de proposer une approche pour les résoudre.

Avant de commencer, le Daily Scrum n’est pas un Status Meeting. Il s’agit simplement d’un point de synchro synthétique entre les membres de la Development Team. Le Scrum Master devra s’assurer que cet événement a bien lieu chaque jour à heure fixe et que l’ensemble de l’équipe y soit présent. Le Product Owner, quant à lui, pourra y assister mais sans y participer. On dit aussi qu’il peut y assister en mode « chicken ».
De tous les évènements Scrum, je pense que le Daily Scrum est le plus difficile à réaliser. Il doit être synthétique et mené de manière professionnelle pour qu’il soit vraiment efficace. Un mauvais Daily Scrum récurrent mènera à l’échec n’importe quelle équipe Scrum. Voici quelques conseils pour un Daily réussi :

Time boxing

Le meilleur moyen pour respecter la time box de 15 minutes est d’utiliser un chronomètre, un téléphone par exemple. De le poser sur une table visible de tous et de s’assurer qu’il sonne à l’issue des 15 minutes. L’équipe pourra ainsi mieux gérer son temps. Pour l’avoir testé, c’est assez efficace !

Une personne à la fois

Il est crucial que cette règle soit respectée. Si ce n’est pas le cas, cela peut vite partir en débat et déborder. Le Scrum Master veillera à ce que cela soit le cas. Des réactions peuvent arriver mais il faudra s’assurer de les contenir.

Un dialogue construit

Une équipe Scrum travaille sur des projets complexes et par conséquent, les PBI inclus dans le Sprint le sont aussi. Il arrive très souvent que certains membres de l’équipe cherchent à expliquer de manière détaillée à l’équipe l’implémentation du PBI Durant le Daily Scrum. Parfois, cela dérive en discussion ouverte et arrive sur un autre sujet.

Proposition

Formuler les prises de paroles de la façon suivante:
« Depuis le dernier Daily Scrum » : J’ai travaillé sur le PBI A, j’ai pu avancer sur …. Et j’ai pu travaillé avec ….
« Jusqu’au prochain Daily Scrum » : Je vais continuer sur le PBI A (ou travailler sur autre chose), je compte faire …. Et je vais travailler avec …
Impements :
– Pas d’Impediments
Ou
– Impediment
○ Exemple: L’équipe X n’a pas livré le composant sur lequel nous avons une dépendance. Le PBI A ne pourra pas être livré si le composant n’est pas livré à l’issue de la deuxième semaine du Sprint.
○ A la suite de l’annonce de l’impediment, un membre de la Dev Team peut se manifester pour aider à résoudre le problème en dehors du Daily Scrum.

La prise de parole formulée de cette façon permettra de synthétiser en quelques phrases les pensées du développeur. Le temps de parole par personne ne devrait pas dépasser 2 minutes.

Pas de débat !

Le Daily Scrum n’est pas un forum. Son objectif est que l’équipe de développement puisse se synchroniser efficacement et avoir une vision claire et précise des challenges à relever pour la journée. De plus, c’est un évènement qui mobilise toute l’équipe de développement. Leur temps est précieux. Protégeons le !
Le Scrum Master ainsi que l’équipe de développement veilleront à ce qu’il n’y ai pas de place au débat.
Phrase magique : « Ceci n’est pas l’objet du Daily Scrum. Pourriez vous échanger à ce sujet plus tard dans la journée ? »

Une équipe professionnelle et mature pourra s’auto discipliner et gérer son Daily Scrum en deçà des 15 minutes. Plus cet évènement est court, plus il est efficace !

Les 7 points clés de la réussite du DevOps

Beaucoup d’articles parlent de DevOps, des clés du succès de DevOps sur leur projet, dans leur contexte. Voici ma vision des 7 ingrédients principaux qui font pour moi le succès d’une approche DevOps réussie. Cette liste n’est pas exhaustive, le sujet est vaste, d’autres ingrédients pourront être ajoutés suite à vos commentaires

1. Une culture commune

La culture sont la clé de voûte du DevOps. On parle aussi de DevOps comme un mouvement culturel, une philosophie qui vise à rapprocher les Dev des Ops. La culture du DevOps est pour moi la culture d’entreprise, du métier qui induit le professionnalisme des équipes. Une culture similaire facilite les échanges et la communication entre les personnes et ainsi créé une bonne synergie pour accomplir de grands exploits !

2. Une communication ouverte et transparente

La transparence est un des pilier de Scrum et de l’Agile. L’ensemble des membres d’une équipe DevOps doivent communiquer le plus efficacement possible et de manière transparente avec un objectif de partage de connaissance maximale. C’est crucial pour assurer une bonne dynamique du projet. Cela réduit aussi le stress de l’équipe et partage le fardeau de la responsabilité  sur l’ensemble de l’équipe DevOps en réduisant considérablement le risque de syndrome du Héro. « Tout seul on va vite. Ensemble on va plus loin ! »

3. Des outils communs

Tout comme dans la mécanique, il faut avoir de bons outils pour travailler de manière professionnelle ! Les outils améliore considérablement l’efficacité de l’équipe et réuni par nature les métiers nécessaire à la création d’un logiciel réussi. Ces outils peuvent travailler et doivent s’intégrer en toute ergonomie à l’environnement de travail de l’ensemble des membre de l’équipe DevOps.

La plateforme Visual Studio Team Services est un excellent exemple de plateforme DevOps. Via une interface intuitive, elle centralise l’ensemble des artefacts du projet et permet le suivi du déploiement continu sur les environnements cibles du projet. De plus, cette plateforme est extensible et peut s’élargir au besoin d’autre fonctionnalités à partir d’un market place bien fourni !

4. Partager les victoires et les défaites

Historiquement, les Dev et les Ops ne partagent pas la même culture et exercent des métiers très différents. Les uns cherchent à intégrer le plus de changement et d’innovation possibles dans un produit sur la base des besoins des utilisateurs. Les autres recherchent la stabilité, la sécurité et la performance de l’application en production. Il existe parfois des tensions ou des incompréhensions entre ces deux population qui sont la plupart du temps dues au manque de vision globale du projet. Le DevOps a pour but d’adresser ce problème en fournissant une vision plus large à l’ensemble des membre du projet. Tout comme en agile, les succès sont partagés et toute l’équipe doit être récompensée ou remerciée (c’est un minimum !). Il en est de même pour les défaites. Ensemble, l’équipe DevOps est bien meilleure dans la défaite et pourra en tirer les enseignements pour les futures version du produit !

5. Un budget partagé

C’est sans doute la point le plus difficile à adresser dans les grands groupes où les process des finances sont bien enracinées dans la culture traditionnelle. Il faudra donc s’adapter pour que l’équipe DevOps soit vue comme une équipe à part entière et non comme deux équipes distinctes. En DevOps, par définition, il n’y a pas de phase Projet et de phase de Run à proprement parler. On délivre une première version le plus rapidement en production (Minimum Viable Product) et on la fait évoluer le plus souvent possible avec une équipe polyvalente et compétente. Si possible la taille de l’équipe DevOps doit rester identique sur toute la durée du projet (Consistancy Removes Complexity). D’un point de vue budget, cela correspond un peu à un mode d’abonnement au mois où l’on va garder la même charge. En théorie, c’est plus simple à calculer. C’est un peu comme si l’on payait un forfait mobile avec un iPhone. Cela revient au même coût au final, mais on a pas besoin d’avancer le coût du téléphone à chaque nouvelle mise à jour.

Dans la pratique, c’est un peu plus compliquer à aborder, il faut donc s’adapter aux systèmes de facturation existants… (Inspect and Adapt !)

6. Une méthode commune et appliquée

Dans le cadre d’un projet DevOps, l’application d’un framework Agile doit être très rigoureuse et partagée par l’ensemble de l’équipe. En DevOps, tout le monde parle la même langue, utilise les mêmes outils et communique efficacement. Il est toujours plus facile de jouer à un jeu lorsque les règles sont clairement définies. Un Scrum Master veilleura à l’application de ces règles et à la suppression de tout obstacle (Impediment) empéchant l’évolution de l’équipe DevOps.

Je conseille vivement la mise en place d’un Framework Agile à la fois strict et simple à comprendre tel que Scrum pour que l’ensemble de l’équipe puisse connaitre et maitriser ces règles rapidement dès le début du projet.

7. Des objectifs communs

Cela va sans doute de soi mais lorsque l’on est sur l’autoroute du DevOps, tout le monde doit rouler dans le même sens ! Notre destination doit être commune et notre équipe doit évoluer de concert en visant un objectif commun à court terme et en partageant une vision commune du produit !

J’espère que ces quelques points vous ont permis de mieux comprendre les enjeux et la philosophie du DevOps. Je suis preneur de vos retours d’expérience.

DevOps, Rugged DevOps et DevSecOps ?

DevOps, Rugged DevOps et DevSecOps : depuis quelques temps, nous voyons fleurir sur les réseaux sociaux ces termes qui font le buzz. L’idée de cet article est de comprendre d’où provient cette tendance et les enjeux de la sécurité au cœur de développement logiciel dans les prochaines années.

Le chemin du DevOps

La philosophie de DevOps est de fluidifier au maximum le flux de livraison entre l’idée provenant du métier et l’utilisateur final. Sur ce chemin, nous faisons face à de nombreux obstacles ou freins. Je reviendrai sur ces challenges de manière exhaustive dans un prochain article. Le challenge le plus important est celui de la communication entre les individus ne partageant pas le même métier. Souvent, en gestion de projet, nous prenons l’exemple de la tour de Babel. Un projet colossal de l’antiquité qui n’a jamais vu le jour à cause du manque de compréhension entre les ouvriers qui ne parlaient pas le même langage. C’est un peu la même chose avec le DevOps. La réussite d’un projet dépend du professionnalisme de l’ensemble des personnes impliqués au projet et surtout à leur aptitude à travailler en synergie dans un objectif commun.

Sur un projet informatique, on retrouve souvent le même schéma d’organisation:

Sur toute la durée du projet, on retrouve:

  • Le métier
  • Les analystes fontionnels et les testeurs
  • Les développeurs (Les Devs !)
  • L’équipe en charge des opérations (Les Ops !)

Et ponctuellement, on fait appel à des experts pour :

  • L’exécution de tests spécifiques : Tests de Performance, Penetration Tests
  • La revue et la validation de l’architecture
  • La revue des process de sécurité
  • Etc.

En résumé, sur un projet complexe, beaucoup de personnes sont impliquées dans le dispositif et n’exercent pas le même métier à priori. Cependant, leur objectif et intérêt commun reste le même: « réussir le projet ».

Du Métier au Dev

Depuis plusieurs années, les méthodes et Frameworks Agiles ont permis de rapprocher les métier de l’équipe de développement et ainsi de travailler le manière itérative avec pour priorité principale de satisfaire l’utilisateur final. Ces équipes Agile font souvent face à beaucoup de frustration lors de la mise en production de leur incrément à l’issue de chaque itération. Les contraintes et process existant dans l’organisation n’ont pas été conçus pour absorber le flux de déploiement continu des équipes Agiles en perpétuelle évolution.

Du Dev à l’Ops

Le DevOps est né de ce besoin. L’élargissement des méthodes de travail jusqu’à l’équipe opérationnelle a permis de fluidifier les échange et voir les groupes travaillant sur le même projet comme une seule et unique équipe à part entière. Les processus d’ALM (Application Lifecycle Management) ont évolués aux besoins de l’agilité, ce sont transformés en Continuous Integration puis Continuous Delivery pour déployer de manière automatisée et systématique les incréments livrés par l’équipe de Dev à l’issue de chaque Sprint. La production est rarement l’environnement de destination de l’incrément à l’issue du Sprint. Dans la plupart des cas, cet incrément est déployé sur un environnement d’UAT (User Acceptance Test) ou encore sur la pré-production. A ce stade, il reste encore à obtenir le « Go » de la « Sécu » et cela peut prendre un certain temps suivant les contraintes de sécurité du projet ou de l’organisation…

La Sécu : l’affaire de Tous !

La sécurité est l’affaire de tous. Les aspects de sécurité doivent être pris en compte au cœur du design de l’application, de son développement et de ses opérations. La plupart des failles de sécurité se retrouvent la plupart du temps en production par manque de vigilance dès la conception même de l’application. Si l’on veut conserver la dynamique agile d’un projet DevOps et que l’on a de grosses contraintes de sécurité, il est primordial de considérer la sécurité comme la clé de voûte du projet dans son ensemble.

Tout comme le DevOps, le DevSecOps vise à fluidifier la communication entre les Devs,les Ops et les équipes sécurité grâce à la mise en place de process et d’outils communs.

« Rugged DevOps is about Tools, DevSecOps is about people »

Image result for devsecops

Rugged DevOps est un terme « Buzz » désignant les outils et process permettant de fluidifier le cycle de livraison d’un projet jusqu’en production en prenant en compte les contraintes de sécurité dès l’implémentation du code de l’application. Alors que DevSecOps s’appuie sur les personnes, Rugged DevOps s’appuie sur les outils.

L’idée derrière tout ça est de faciliter le travail des équipes sécurité et des Pen Testers en fournissant un niveau d’information à jour sur la qualité du code produit d’un point de vue sécurité. La prise en compte des aspects sécurité est dès lors pris en compte par l’équipe de developpement lors de l’implémentation du code et les cycle de continuous delivery intègrent potentiellement une validation automatique du code à l’aide de « Quality Gates ». La génération de rapport d’analyse statique de code (SAST) facilitent grandement l’exécution des tests de pénétration et l’approbation de l’autorité de sécurité  de l’organisation pour le déploiement en production.

Conclusion

Le DevSecOps et le Rugged DevOps sont intimement liés. Le DevOps n’étant pas une méthodologie à part entière mais plus un mouvement culturel, il en va de même pour le DevSecOps. L’objectif est de trouver le chemin qui abouti plus de fluidité et d’efficacité  à tous les étages du projet. Un changement de philosophie, une adaptation des processus et la mise en place d’outils performants permettront cette transformation au rythme que se fixera l’équipe DevOps.