Comment puis-je convaincre les développeurs de mon équipe d'adopter «vous le construisez, vous l'exécutez»?

Comment puis-je persuader les développeurs de mon équipe d'embrasser "Vous le construisez, vous l'exécutez"? Par cela, j'ai cette citation de Werner Vogels à l'esprit:

Donner aux développeurs des responsabilités opérationnelles a considérablement amélioré la qualité des services, tant du point de vue client que technologique. Le modèle traditionnel est que vous amenez votre logiciel au mur qui sépare le développement et les opérations, que vous le jetez puis l'oubliez. Pas sur Amazon. Vous le construisez, vous l'exécutez. Cela met les développeurs en contact avec le fonctionnement quotidien de leur logiciel. Il les met également en contact quotidien avec le client. Cette boucle de retour client est essentielle pour améliorer la qualité du service.

Je pense spécifiquement à un ensemble de développeurs qui:

• Ont été embauchés dans un rôle de développeur, avec peu ou pas de mention des tâches liées aux opérations.
• Traditionnellement, on a «jeté du code par-dessus le mur» à une équipe d'opérations.
• Ont traditionnellement un horaire de travail 9-5, et sont activement hostiles à l'idée de «devoir de téléavertisseur», participant à la reprise après sinistre, écrivant des autopsies, etc., surtout en dehors des heures normales de travail. (Remarque: je n'ai que très rarement des pannes en tête pour cela; je ne propose pas d'ajouter le support client en dehors des heures normales de travail à cette équipe.)
• Ne sont pas actuellement responsables de la rédaction / du support de la surveillance ou de l'alerte sur leurs applications.

Supposons qu'une équipe développe rapidement de nouveaux micro-services cloud avec un profil qui devient tel que la remise de ces services à une équipe d'opérations est sous-optimale car ils ne peuvent pas suivre pour acquérir une connaissance approfondie de les services nécessaires pour les gérer et les surveiller efficacement. «Vous le construisez, vous l'exécutez» fonctionnerait mieux pour cette équipe car les tâches pourraient être déléguées à chaque membre responsable de l'équipe. Ainsi, cette équipe commencerait à participer à la conception de l'infrastructure, aux outils de surveillance / alerte des services et (très rarement) à répondre aux pannes.

Je m'intéresse spécifiquement aux méthodologies, appuyées par des exemples réels. Comment cela a-t-il été mis en œuvre avec succès dans d'autres lieux de travail, et s'il existe des étapes canoniques à suivre lors de la mise en œuvre? Tout lien vers des articles pouvant soutenir des réponses serait très utile.

Je pense que le moyen le plus simple est de modifier leurs objectifs de performances afin qu'ils soient basés sur la fiabilité ainsi que sur la livraison de code. Vendez-le car l'entreprise ne peut réussir sans les deux, alors pourquoi les développeurs ne devraient-ils être évalués que sur un seul? La meilleure façon pour eux d'atteindre leurs objectifs de performance est alors de s'impliquer dans les opérations.

En fin de compte, vous devez les convaincre que c'est le meilleur moyen pour l'entreprise de réussir et donc de réussir. C'est difficile et vous ne pouvez pas vous attendre à ce qu'ils soient à bord dès le départ. Ils doivent également être vendus sur la valeur.

Quand il s'agit d'affecter la culture d'entreprise, le meilleur moyen est probablement d'utiliser la méthode bien connue "bouillir la grenouille". Vous devez introduire ces tâches lentement aux développeurs, car je sais que moi-même (en tant que développeur) rechignerais à avoir toutes ces nouvelles responsabilités à la fois.

Tout d'abord, commencez par introduire une ou deux nouvelles tâches à effectuer uniquement pendant les heures normales de bureau. Ils doivent apprendre à faire des devops, ce qui pourrait être tout à fait le processus d'apprentissage pour un développeur (jusqu'à présent) uniquement code et pourrait nécessiter une certaine supervision. Ils seront également probablement hostiles à l'idée de modifier leur équilibre entre vie professionnelle et vie privée, car vous mentionnez qu'ils sont habitués au 9-5. À ce stade, enregistrez les données sur les nouveaux processus pour une utilisation ultérieure (demandez-leur d'écrire ce code, les données sont toujours utiles).

Plus tard, alors que vous êtes à court de nouvelles tâches devops-y à introduire (de sorte que les première, deuxième et quatrième puces sont presque terminées), amenez les premières tâches que vous avez présentées en tant que candidats à exécuter en dehors des heures de travail standard . Vous pouvez voir un contrecoup à ce sujet et vous pouvez même voir une certaine attrition en fonction de la force avec laquelle vous poussez cela et de la gravité de la culture du travail à cinq ans. Pour vous défendre contre cela, nous espérons que vos données soutiennent l'idée que le travail au-delà des heures normales sera rare, ne se produira que dans des situations extrêmes et bénéficiera grandement à la fois à l'entreprise et au client. Si vos données ne le supportent pas, vous feriez mieux d'être prêt à faire face aux conséquences de ce choix.

Même avec des données, il peut encore être plus facile d'avoir les développeurs à écrire le suivi / code d' alerte (afin qu'ils deviennent dev ops mais surtout dev) et garder l'équipe ops autre que le soutien de première ligne (comme quelques autres ont suggéré). Comme je l'ai dit, de petits changements sont importants pour éviter les contrecoups. L'intégration du travail des développeurs au-delà des heures normales sera difficile, car ils peuvent savoir qu'ils peuvent chercher un emploi ailleurs s'ils ne l'aiment pas, car le marché des développeurs est fort en ce moment, surtout s'ils avaient déjà des compétences en devops. Caveat emptor!

En particulier en dehors de DevOps, si vous parlez d'environnements de grande entreprise (ish), la méthodologie SAFe a un assez bon moyen d'encourager ce type de comportement.

Il se résume essentiellement à quelques étapes clés:

• les projets commencent comme des trains de lancement. L'intention (et l'attente de celui qui la finance) est qu'elle durera longtemps. Je parle depuis des années, rien de tout cela "constituer une équipe pendant 3 mois puis les abandonner".

• au cours d'un projet, le train de versions amassera inévitablement plus de personnes, car davantage de nouvelles exigences de projet basées sur les opportunités commerciales nouvellement réalisées ainsi que la taxe en cours sur les travaux de style de maintenance.

• Je vois presque toujours les trains exécuter leur premier échelon en tant qu'équipes de projet / changement à 100%, le deuxième incrément alloue un pourcentage de temps pour exécuter le travail. La gestion du 3e incrément se rend compte qu'ils sont sur le point d'avoir un problème et commencent à ajouter des équipes pour essayer de gérer le débordement d'exécution pour donner à leurs développeurs et ingénieurs maintenant chevronnés le temps de continuer à travailler sur de nouvelles exigences.

• si le bon équilibre est atteint, les équipes de projet étant en mesure de continuer à fournir les résultats du projet sans être trop embourbées dans les travaux de maintenance et les nouvelles équipes qui rejoignent le train ne devraient pas être immédiatement des équipes de support à 100%, mais une bonne partie du travail de changement qui allait être géré, puis vous vous retrouvez avec des équipes de livraison qui possèdent les produits qu'ils construisent par défaut, il n'est pas nécessaire de les aborder tous en même temps que maintenant ils sont une équipe Run, au lieu de cela, il s'intègre lentement dans leurs activités quotidiennes.

Là où ce modèle a évidemment quelques faiblesses, c'est dans la tarification d'une entreprise. En général, je m'attendrais à payer beaucoup plus pour une ressource de changement qu'une ressource exécutée, généralement les contrats exécutés avec les principaux fournisseurs sont à prix fixe et l'intention est qu'ils gagnent de l'argent en amélioration continue et donc en économies.

Cela étant dit, il n'est pas si difficile de considérer que les équipes de changement se sont levées dans le cadre d'un train de versions pour simplement apporter des améliorations continues. S'il y a quelque chose qu'ils peuvent construire ou faire qui améliorera leur capacité à se concentrer sur les livraisons de nouveaux projets et à se soucier moins du travail «comme d'habitude», alors cela devrait être en retard et priorisé en fonction des avantages perçus par celui qui détient l'argent pour le libérer le train.

IMHO You build it, you run itne doit pas être pris au pied de la lettre. Pour commencer - cela ressemble presque à une punition;)

Aucune personne ou même petite équipe de développeurs ne peut raisonnablement prendre en charge un outil ou un ensemble d'outils utilisés dans le processus de développement logiciel (c'est-à-dire en production!) Pendant de longues périodes. J'y suis allé, j'ai fait ça :)

Les tâches de support ont tendance à s'étendre à mesure que la base de clients d'outils (ensemble) augmente. Si elle assumait ces fonctions exclusivement, l'équipe de développement pourrait finir par fournir principalement du soutien, avec peu ou pas de temps pour le développement en cours de route. En fait, une impasse - combien de développeurs voudraient rester dans un tel environnement?

Avoir une équipe de support technique de première ligne est essentiel pour éviter la frustration, le stress et d'autres effets d'une exposition à long terme aux tâches de support sur les membres de votre équipe de développeurs.

Bien entendu, l'équipe d'assistance de première ligne se tournerait vers l'équipe de développement (encore une fois, l'équipe, pas une seule personne!) Pour les problèmes qu'elle ne peut pas traiter directement. Oui, cela peut être difficile au début, mais la situation ira mieux. Cela devrait être une collaboration - cela fait partie de la raison d'être de DevOps.

Cela dépend en fin de compte de la taille et de la structure de l'entreprise. Il y a vraiment trois étapes dans lesquelles votre entreprise peut être:

1. La phase de démarrage (moins de 150 ingénieurs). Bien sûr, les développeurs doivent exécuter leur propre logiciel. Tout le monde le fait dans une startup. Vous pourriez même ne pas avoir d'équipe opérationnelle pour commencer, mais même si vous en avez, elle est petite et la vitesse de progression est si rapide qu'il n'y a aucun moyen de transmettre les connaissances nécessaires pour la faire fonctionner avec succès sur une autre équipe assez rapidement pour qu'elle puisse avoir du succès.

2. L'entreprise de taille moyenne (plus de 150 ingénieurs, mais une seule équipe d'exploitation). À ce stade, le taux de désabonnement de l'entreprise commence à être trop élevé, les ingénieurs qui créent des logiciels ne restent pas nécessairement là aussi pour les exécuter. Vous ne connaissez plus tout le monde et il est difficile de communiquer efficacement pour que tout le monde soit en opération. Cela commencerait à se transformer en chaos. À ce stade, vous souhaitez vous tourner vers le modèle Google, où chaque équipe doit opérationnaliser son logiciel, mais pas nécessairement le faire fonctionner. Ils le feront fonctionner au début, mais une grande partie du logiciel de construction consiste à réduire le coût de son fonctionnement à un point où la charge est suffisamment petite pour que l'équipe des opérations puisse signer pour l'exécuter. Alors seulement, il est considéré comme terminé.

3. Grande entreprise avec plusieurs unités commerciales (où chacune a sa propre équipe opérationnelle): à ce stade, vous pouvez revenir au modèle Amazon, où chaque équipe essentielle développe et exploite ses propres services. Chacune des unités commerciales doit être suffisamment petite pour que tout le monde se connaisse, donc environ 150 ingénieurs et vous opérez chacun essentiellement comme une startup. Amazon a chaque service AWS fonctionnant plus ou moins séparément et cela fonctionne pour eux.

Vous devez déterminer dans quelle étape votre entreprise se trouve et / ou évoluer et agir en conséquence. Il n'y a pas de solution unique.

Mon point de vue sur ce point (si j'étais confronté à un tel commandement, ou peu importe comment vous l'appeliez), serait quelque chose comme " What else would you expect?!?!". Parce que, accidentellement:

• Je ne pourrais même pas vivre sans ça, et
• J'adore manger ma propre nourriture (pour chiens).

Laissez-moi vous expliquer un peu plus loin ...

Mon entreprise / hobby / passion est scm , plus spécifiquement dans les environnements mainframe . Et partout où je vais (pour affiner les choses pour répondre aux besoins des clients), la toute première exigence que j'impose (dans mon contrat), c'est que tout réglage effectué sur le système que nous implémentons, se fasse via ce même système. Et ce faisant (vrai, cela prend quelques heures, disons une demi-journée au maximum), nous en tirons ces avantages (liste incomplète):

• Je documente à peine tout ce que j'ai fait pour faire fonctionner le système. Si des questions sont posées, je ne fais qu'interroger le système (et j'enseigne au client comment interroger le système sans mon aide).
• Si je suis appelé dans X mois / années (pour passer à une nouvelle version?), Je veux savoir (me souvenir) ce que "je" faisais auparavant (et la seule chose en laquelle j'ai confiance est ce que le système me dit, alias me rappelle).
• Je n'ai qu'une seule fois à demander au client comment faire des choses spécifiques sur son site (les conventions de nommage sont difficiles à retenir), ou à les convaincre d'accorder les autorisations requises au "système" (pas à moi ...).
• Vous continuouslytestez QA votre propre système ... en production. Il y a de fortes chances que vous rencontriez vous-même des bugs, des erreurs logiques ou des fonctionnalités manquantes (et ce qui ne l'est pas). Et ceux-ci sont extrêmement motivants pour les aborder dès que possible ... par exemple pour devenir plus productifs.
• ... et si vous le souhaitez, je peux ajouter une douzaine de raisons supplémentaires ...

Cependant, avant d'essayer vous-même à la maison, soyez conscient de certains pièges à éviter:

• vous voulez que tout le monde rejoigne le parti (utilisez le système), car une seule "exception" (alias le directeur / propriétaire de l'entreprise?) peut ruiner le parti (vous penseriez que vous pouvez faire confiance à votre système, mais alors quelqu'un a fait quelque chose sans demander / utiliser le système). Ce cas peut vous coûter des jours à découvrir ...
• les nouveaux utilisateurs pourraient se plaindre qu'en utilisant ce (nouveau) système, cela leur prend beaucoup plus de temps pour faire leur travail (par rapport à tout ce qu'ils utilisaient auparavant). Et partout où cela aura du sens, ils s'en serviront comme excuse pour expliquer pourquoi ils sont en retard pour terminer leur travail. À ce stade, il vaut mieux que la haute direction vous couvre, car sinon votre projet / système pourrait être blâmé.
• assurez-vous que vous connaissez votre propre système et comment le configurer en fonction de vos besoins. À titre d'exemple (dans mon cas): vous voulez configurer le système afin que vous utilisiez l'environnement opérationnel pour livrer à votre environnement expérimental, et non l'inverse ... J'ai vu cela se produire dans le passé ... utiliser (abuser) du système de test pour livrer dans des environnements hautement sécurisés.