Toutes les entreprises ne sont pas encore prêtes pour le changement majeur amorcé par le DevOps

Toutes les entreprises ne seraient pas encore prêtes pour le DevOps
Alors qu’il pourrait offrir de meilleures performances à celles-ci

Alors que certains évoquent les bénéfices que peuvent tirer les entreprises suite à l’adoption du DevOps, certains spécialistes estiment que contrairement aux startups, les entreprises ne sont pas réellement prêtes à adopter cette nouvelle culture.

C’est le cas de l’associée de At Work-Bench, Rachel Shannon-Solomon, qui a récemment écrit un article intitulé DevOps Is Great for Startups, but for Enterprises It Won’t Work—Yet. Ce dernier dépeint un tissu économique où le DevOps a du mal à s’imposer dans les entreprises vu les différents changements qu’il implique, tout en avouant que les startups et certains géants de l’IT ont largement bénéficié des pratiques du DevOps.

L’argumentation de Shannon-Solomon repose sur quatre arguments de base :

• Changement organisationnel de l’entreprise : les entreprises obéissent à un schéma organisationnel structuré et axé sur des équipes, cette dernière notion est l’unique manière que connaissent les entreprises pour maximiser leur productivité. Le DevOps va à l’encontre de cette structuration.
• Achat vs Développement : Il y a un manque important d’outils pour le DevOps. Par conséquent, l’entreprise doit acheter ou développer les outils nécessaires, ce qui ne peut se faire qu’après le changement organisationnel et la restructuration de l’entreprise.
• Les fournisseurs de solution DevOps reconnaissant qu’à travers leurs ventes, ils tentent d’introduire une révolution culturelle.
• Retour sur investissement : certains responsables IT évoquent un retour sur investissement minime, voire inexistant, suite à l’adoption du DevOps.

Mais pour d’autres professionnels de l’IT, le passage au DevOps est nécessaire si les entreprises ne veulent pas rater ce virage majeur de l’évolution de l’IT. C’est ce qu’explique le fondateur de Tripware, Gene Kim, à travers un article intitulé Enterprise DevOps Adoption Isn’t Mandatory — but Neither Is Survival.

Kim démontre à travers plusieurs points pourquoi les entreprises devraient adopter le DevOps :

• La valeur d’entreprise du DevOps : le DevOps est « le résultat de l’implémentation des principes Lean au sein des départements IT ». Lorsqu’il est bien appliqué, ses performances sont impressionnantes .
  
  • Des déploiements 8 fois plus fréquents et 8000 fois plus rapides.
  • Un pourcentage de succès 2 fois plus important et des résolutions de bugs 12 fois plus rapides.
• L’adoption du DevOps n’est pas obligatoire : même si son adoption implique des changements majeurs, il faut comparer ce basculement à celui provoqué par l’adoption des principes « Lean » par les manufacturiers.
• Les organisations qui ont adopté le DevOps commencent à être récompensées : en effet, une récente étude auprès de plus de 9 200 professionnels révèle que les entreprises ont gagné en performance suite à son adoption. Ce gain ne se cantonne pas uniquement au département IT, ce qui est une excellente nouvelle.

Et vous ?

:fleche: Etes-vous pour ou contre l’adoption du DevOps ?

Bonjour,

Sur le principe rien à redire, au contraire, c'est même un des points qui me semble le plus important et contradictoire avec nos formes de travail
dans les grands groupes.
Mais sur le fond, je me demande s'il n'y a pas une volonté farouche d'économie d'échelle, ou le dev et l'exploitation se retrouve sur des missions
transverses et ou chaqu'un à force n'est spécialiste de rien et fait le boulot de l'autre, why not, you can ... .
Je m'explique, combien de fois sur des projets, on demande que la personne soit pro HTML, CSS, Java, PHP, JQuery, UML, Merise, DBA Oracle
, pro postgres, un soupçon NoSQL et si possible qu'il fasse correctement le café. Sur le dernier point il est d'ailleurs difficile de trouver des ressources.
Je sais que par expérience, on ne connait parfaitement que un voir deux langages dans ses moindres détails et encore, cela me hérisse le poil
quand on me demande une expertise Oracle, même si j'ai une culture étendue. un DBA, un admin sytem, un spécialiste sécurité sont des métiers. DEVOPS, même si c'est beau
sur le papier ("merci monsieur CLOUD"), je pense qu'il faut rester vigilant.

D'ailleurs, cela me fais penser à de la pub, développé dix fois plus vite ( moins de temps tu auras), Un pourcentage de succès 2 fois plus important
( plus intelligent tu seras .... ) Des déploiements 8 fois plus fréquents et 8000 fois plus rapides ( 8 fois plus serré dans ton calendrier, tu subiras ).

Je pense que comme pour le Cloud, il faut garder la tête froide.:mrgreen:
Je me fais l'avocat du diable, mais c'est pour la bonne cause.:weird:

Olivier

je m'étais jamais interessé à ce qu'était devops avant aujourd'hui et je vois pas ou est la révolution...

d'après ce que j'en ai lu sur la page wikipédia fr (qui n'est pas très fournie certe) il s'agit juste de revenir quelques années en arrière à l'époque ou les différentes équipes des grandes entreprises bossaient ensemble dnas un même but global au lieu de bosser les unes contres les autres pour chacune remplir leurs objectifs individuels.
après, personellement, ça me parait être une excellente idée mais encore une fois, je vois pas ou est la révolution. j'ai l'impression qu'on a juste mis un terme hype sur une philosophie ancestrale.

pour autant, je vais en faire la promotion quand même. ça fait un an que je suis sur une mission dans un très grand groupe ou chaque équipe du groupe est cliente d'une autre équipe du groupe et qui a d'autres équipes du groupes comme clientes. et le résultat c'est que y a des gens qui au seins de chaque équipe (les responsable en général) qui passent plus de temps à tenter de justifier les retards de leur propre équipe par les manquements des autres équipes plutôt qu'à se demander comment faire avancer le boulôt plus vite.
l'autre grand problème de cette organisation est le process super précis et rigide qui régit les échanges entre les différentes équipes: on sait qu'il faut faire une chose d'une façon parce que le client nous a dit à plusieurs reprises que ce qu'il souhaitait, mais comme c'est pas encore écris dans le document officiel, on va plutot passer 3 jours à faire autre chose (ce qui est écrit dans le document pour le moment) et on redéveloppera cette partie quand le document sera à jour. c'est à dire la semaine suivante... ou comment passer 3 jours à développer un truc dont on sait pertinament qu'il ne sera jamais utiliser et qu'il faudra le refaire dans quelques jours. ce genre de situation m'exaspère...

bref, je vais faire la promotion du devops à partir de maintenant puisque c'est la façon hype de dire que les organisations trop cloisonnées sont de la connerie contre productive :)

Citation:

---

Envoyé par nathieb

Mais sur le fond, je me demande s'il n'y a pas une volonté farouche d'économie d'échelle, ou le dev et l'exploitation se retrouve sur des missions
transverses et ou chaqu'un à force n'est spécialiste de rien et fait le boulot de l'autre, why not, you can ... .
Je m'explique, combien de fois sur des projets, on demande que la personne soit pro HTML, CSS, Java, PHP, JQuery, UML, Merise, DBA Oracle
, pro postgres, un soupçon NoSQL et si possible qu'il fasse correctement le café. Sur le dernier point il est d'ailleurs difficile de trouver des ressources.
Je sais que par expérience, on ne connait parfaitement que un voir deux langages dans ses moindres détails et encore, cela me hérisse le poil
quand on me demande une expertise Oracle, même si j'ai une culture étendue. un DBA, un admin sytem, un spécialiste sécurité sont des métiers. DEVOPS, même si c'est beau
sur le papier ("merci monsieur CLOUD"), je pense qu'il faut rester vigilant.

---

Je pense que tu confonds "DevOps" et "Développeur Full Stack"
Le DevOps reste un développeur spécialisé mais il travaille en étroite collaboration avec tous les intervenants du projet (les équipes métiers / design, concepteur, dba, admin système et réseau, équipe de production / run)
On ne demande pas au DevOps de "savoir tout faire" mais de "savoir travailler avec tous le monde"
Et bien évidement, c'est une excellente chose :)

A la différence, le développeur full stack doit savoir tout faire ce qui est une bêtise totale car bien évidement, on ne peut pas être expert dans tout même si on a une culture et des notion
Le développeur full stack convient pour les mini projets dont les exigences de qualité et de perf ne sont pas élevées.

Question con, mais c'est quoi un (ou le?) DEVOPS?

Encore un mouton à cinq pattes qui sait tout faire et demande à être payé de critiques et d'eau fraiche?

Citation:

---

Question con, mais c'est quoi un (ou le?) DEVOPS?

---

http://lmgtfy.com/?q=devops

Citation:

---

Encore un mouton à cinq pattes qui sait tout faire et demande à être payé de critiques et d'eau fraiche?

---

interessant cette façon de se préparer un avis sur un sujet sans rien en connaitre et sans même avoir fait l'effort de chercher la moindre information.

Citation:

---

Envoyé par Saverok

Je pense que tu confonds "DevOps" et "Développeur Full Stack"
Le DevOps reste un développeur spécialisé mais il travaille en étroite collaboration avec tous les intervenants du projet (les équipes métiers / design, concepteur, dba, admin système et réseau, équipe de production / run)
On ne demande pas au DevOps de "savoir tout faire" mais de "savoir travailler avec tous le monde"
Et bien évidement, c'est une excellente chose :)

A la différence, le développeur full stack doit savoir tout faire ce qui est une bêtise totale car bien évidement, on ne peut pas être expert dans tout même si on a une culture et des notion
Le développeur full stack convient pour les mini projets dont les exigences de qualité et de perf ne sont pas élevées.

---

Le problème dans l'histoire est que cette "confusion" n'est pas limitée à une question dans un forum. Et de part son origine (la start-up, limitée en ressources), le "DevOps" est souvent un "full stack". De plus, "Informaticien" reste un métier incompris sur lequel on a du mal à admettre qu'il y a des spécialités. Avant même le terme "DevOps", en SSII (et pas mal de boites), le développeur était aussi bien dev front-end, dev back-end, concepteur de données et admin BDD. Donc pour ma part aussi, j'ai tendance à me méfier de la propagation de cette "culture" surtout quand je la vois associée à des mots clef comme "lean".

Première fois que j’entends ce terme DevOps et que soit la page wikipedia ou le site "http://devops.fr/" ne m'ont pas permis comprendre ce que c'était.

Concrètement, est-ce que c'est un nom qu'on donne à une personne (un développeur) ou à une stratégie d'entreprise? Pas clair

Citation:

---

Première fois que j’entends ce terme DevOps et que soit la page wikipedia ou le site "http://devops.fr/" ne m'ont pas permis comprendre ce que c'était.

Concrètement, est-ce que c'est un nom qu'on donne à une personne (un développeur) ou à une stratégie d'entreprise? Pas clair

---

Moi aussi c'est la première fois que j'entends ce terme. A ce que j'en comprends, c'est améliorer les processus et l'organisation d'une entreprise pour mieux faire communiquer les équipes s'occupant du DEV et celles s'occupant de l'exploitation. L'intérêt est à la fois d'avoir un système d'informations stable et le plus à jour possible (avec les dev).

En fait, c'est ce qui se passe depuis longtemps dans les grandes organisations. Dans tous les projets, et à toutes les étapes, l'exploitation et le dev doivent travailler ensembles.
Rien de neuf (sauf si j'ai rien compris) sous le soleil !

Citation:

---

Envoyé par Tryph

je m'étais jamais interessé à ce qu'était devops avant aujourd'hui et je vois pas ou est la révolution...

d'après ce que j'en ai lu sur la page wikipédia fr (qui n'est pas très fournie certe) il s'agit juste de revenir quelques années en arrière à l'époque ou les différentes équipes des grandes entreprises bossaient ensemble dnas un même but global au lieu de bosser les unes contres les autres pour chacune remplir leurs objectifs individuels.

---

C'est tout-à-fait ça : on prend quelque chose qui existe, on lui applique un mot nouveau, facilement mémorisable (si on peut en faire un hastag sur Twitter, c'est parfait), et hop, ceci est une révolution. On nous avait déjà fait le coup avec le « web 2.0 », que seuls des marketeux réussissaient à expliquer, mais que personne n'arrivait à comprendre.

L'avantage c'est que ça fait parler : on pourra faire des rapports, des colloques, pour expliquer qu'il faut âââbsolument suivre la mode, on aura des articles nous disant que 78% des entreprises souhaitent s'y mettre « dans un avenir proche», et quelques mois plus tard, que personne ne s'y ai mis, faute de comprendre ce qu'il fallait changer par rapport à l'organisation actuelle (qui correspond déjà à la nouvelle organisation).

Je prends les paris : bientôt on aura un nouveau terme à la mode, qui nous dira qu'il faut rapprocher les équipes pour qu'elles discutent entre elles, qu'il faut « décloisonner » les projets, et qu'en plus ça permet de faire des économies sur les locaux, et hop, on aura réinventé l'open-space.

Citation:

---

Envoyé par Jarodd

C'est tout-à-fait ça : on prend quelque chose qui existe, on lui applique un mot nouveau, facilement mémorisable (si on peut en faire un hastag sur Twitter, c'est parfait), et hop, ceci est une révolution. On nous avait déjà fait le coup avec le « web 2.0 », que seuls des marketeux réussissaient à expliquer, mais que personne n'arrivait à comprendre.

L'avantage c'est que ça fait parler : on pourra faire des rapports, des colloques, pour expliquer qu'il faut âââbsolument suivre la mode, on aura des articles nous disant que 78% des entreprises souhaitent s'y mettre « dans un avenir proche», et quelques mois plus tard, que personne ne s'y ai mis, faute de comprendre ce qu'il fallait changer par rapport à l'organisation actuelle (qui correspond déjà à la nouvelle organisation).

Je prends les paris : bientôt on aura un nouveau terme à la mode, qui nous dira qu'il faut rapprocher les équipes pour qu'elles discutent entre elles, qu'il faut « décloisonner » les projets, et qu'en plus ça permet de faire des économies sur les locaux, et hop, on aura réinventé l'open-space.

---

Bonjour,

d'accord sur le fond,

Citation:

---

Je pense que tu confonds "DevOps" et "Développeur Full Stack"

---

et non, je ne confonds pas, pour la petite histoire, j'ai entendu le mot DEVOPS, à la première DEVOX java en 2012, allez voir cela vaut le coup d'oeil, cela ne date donc pas d'hier.
Je me méfie de ce jargon, et on est en droit de ce méfier du rapprochement soit disant "bénéfique", il l'est de façon réel si on applique les fondements. En effet, beaucoup parlent de méthode agile, mais combien l'applique vraiment. En des temps, ou la compression de personnel se profile pour tous, il sera tentant de faire du DEVOPS commercial
mais du full stack en bout de chaine.

Olivier

DevOps c'est comme l'agile ou une autre "méthode" ça ne s'applique pas à tout le monde (certains clients n'en voudront pas, pour certains projets ça se vautrera lamentablement).

Donc je suis contre son application bête et méchante qui consiste à dire "Waaaaah DevOps c'est trop bien c'est le saint Graal." et qui consiste à l'appliquer pour tout et n'importe quel projet, c'est comme mettre un V6 dans chaque voiture ça n'a aucun intérêt.

Mais je suis pour dans le sens où cela peut être utile pour certains projets / structures.

Sinon, ça n'est vraiment pas neuf, pas mal d'entreprises (mais pas encore assez) misent sur la cohésion des équipes en organisant des évènements extérieurs à celle ci à l'intérieur de l'entreprise (journées sportives chez Oxylane entre autre) ou des évènements internes de l'entreprise à l'extérieur de celle ci (after work au bar et j'en passe).

Citation:

---

Envoyé par Tryph

http://lmgtfy.com/?q=devops

---

Merci Tryph, mais ça je l'avais fait, et l'article Wikipedia ne m'a pas franchement éclairé. C'est une liste de bonne pratiques qui devraient en toute circonstance être appliquées. Je vois pas l'intérêt de mettre un nouveau nom là dessus.

Citation:

---

Envoyé par Tryph

interessant cette façon de se préparer un avis sur un sujet sans rien en connaitre et sans même avoir fait l'effort de chercher la moindre information.

---

Comme dit plus haut, l'effort je l'ai fait, c'est bien cela qui m'a permis d'avoir un premier avis sur la question. Mais si tu as des élements concrets à me soumettre, je ne suis pas complètement borné, je suis prêt à changer d'avis si tu m'en convainc.

Agile, Cloud ou DevOps... le nom marketing sert à vendre des consultants pour le coaching / changement, mais la culture change rarement.

Si les entreprises voulaient économiser de l'argent, elles s'attacheraient à revoir leurs prestas / consultants et les mettre dans des contrats Win-Win : au lieu d'une régie "si je suis mauvais mon contrat sera renouvelé (= payé pour échouer)", au lieu d'un forfait "trop de risques et de négociations" (= impossible de changer de plan de bataille), je rêve d'un contrat "ou on gagne tous les deux, ou on perd tous les deux".
Par exemple de nombreux forfaits clairs et bien définis, dans une logique de collaboration ?

Mais pour cela il faut changer de culture à tous niveaux : les métiers (pas trop), les managers (beaucoup), les développeurs (pas trop mais ils se méfient de ce qui vient des managers, souvent à raison mais il faut savoir ne pas se bloquer d'une bonne idée) et... les achats (eux doivent énormément changer mais je doute qu'ils le sachent) !

Citation:

---

Envoyé par abelar_s

Agile, Cloud ou DevOps... le nom marketing sert à vendre des consultants pour le coaching / changement, mais la culture change rarement.

Si les entreprises voulaient économiser de l'argent, elles s'attacheraient à revoir leurs prestas / consultants et les mettre dans des contrats Win-Win : au lieu d'une régie "si je suis mauvais mon contrat sera renouvelé (= payé pour échouer)", au lieu d'un forfait "trop de risques et de négociations" (= impossible de changer de plan de bataille), je rêve d'un contrat "ou on gagne tous les deux, ou on perd tous les deux".
Par exemple de nombreux forfaits clairs et bien définis, dans une logique de collaboration ?

Mais pour cela il faut changer de culture à tous niveaux : les métiers (pas trop), les managers (beaucoup), les développeurs (pas trop mais ils se méfient de ce qui vient des managers, souvent à raison mais il faut savoir ne pas se bloquer d'une bonne idée) et... les achats (eux doivent énormément changer mais je doute qu'ils le sachent) !

---

Ca dépend des boîtes ça. Des managers qui prennent pas leurs collaborateurs pour des cons j'en connais.