Soyons en contact

 

You build It you Run It

12-10-2016 - 07:1527-10-2016 - 22:49

Amazon a popularisé la maxime You Build It, You Run It (interview de Werner Vogels ? There is another lesson here: Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service). Petite tentative d'explication en rapprochement progressif avec d'autres notions connexes.

Amazon et le monde

Ce qu'Amazon entend par You Build It, You Run It, c'est tout simplement la prise en compte de bout en bout, par la même équipe d'une application, ou partie d'application, ou produit. Vous l'avez construit?? Parfait?! Vous allez le maintenir et le supporter maintenant?! et si vous n'avez pas fourni de la qualité, c'est vous qui vous vous y collerez ?! C'est de cela dont il s'agit lorsque Werner Vogels prononce cette phrase.

Il est d'ailleurs bien difficile de démêler l'écheveau entre %"%You Build It, You Run It”, long-lived Teams (ou long-standing Teams), DevOps, élimination des silos, Extend the Shadow of the Future, Feature Team, Product Team, Cross-functional Team, etc. Et cela, c'est ce que le monde du logiciel en a fait.

Alors j'ai décidé de tout m?langer car cela a le mérite de vous présenter les choses exactement comme elles sont ! Dans SAM je me suis longuement exprimé sur cette notion au travers de la page DevOps. Ici, pour ce billet, je me range du côté du résum?, de ceux qui veulent se faire une opinion simple et pourtant compl?te.

the Devops movement addresses the dysfunction that results from organizations composed of functional silos. Thus, creating another functional silo that sits between dev and ops is clearly a poor (and ironic) way to try and solve these problems. DevOps proposes instead strategies to create better collaboration between functional silos, or doing away with the functional silos altogether and creating cross-functional teams (or some combination of these approaches). — Jezz Humble in There is no such thing as a "Devops Team"

Y a-t-il un problème à résoudre ?

Un problème à résoudre?? Un peu mon neveu?!

Toutes les organisations de grande taille ont créé des silos. Les plus petites ont copié les grosses par syncrétisme. Aujourd'hui, tout le monde souffre du même mal, SAUF les entreprises qui ont ignoré les autres, soit par choix, soit par chance.

Ce mal, j'ai l'habitude de le mettre en images de la manière, vulgaire, suivante : si le Management avait existé il y a 100.000 ans, l'Homme serait une espèce éteinte faute de ne plus être arrivé à pisser sans passer par 15 processus en série. Le malheur étant que celui qui était responsable de l'ouverture de la braguette (qui n'existait pas à l'epoque, entendons-nous), était en congé de maladie lorsque notre grand aïeul a eu besoin de se soulager ! Gonflement des parties qui ont fini par éclater; influence sur l'appareil génital reproducteur; extinction ! Le tout est dit.

Les silos créent des relais, les relais entraînent des délais, les délais entraînent des coûts, les coûts trop élevés entraînent des mesures de performance plus sévères, qui entraînent le désengagement professionnel et le découragement du personnel, decouragement qu'on cherche à contrecarrer avec des programmes d'incentive et de motivation, le tout entraînant également des pressions sur les salaires (seule réponse habituelle d'une imbécillité sans nom car d'une facilité débilitante), etc. etc.

Et on n'en sort pas ! Voyez, à titre de rappel, cette excellente vidéo d'Yves Morieux, consultant auprès du Boston Consulting Group:

As work gets more complex, 6 rules to simplify

On ne saurait être plus clair !

Alors, aux méthodes obsolètes appliquées par tous les Management du monde ('fin pas tous … j'avoue basculer de temps à autre dans la dramatisation !), quelques-uns répondent avec %"l"You Build It, You Run It%"r", long-lived Teams, DevOps, élimination des silos, Extend the Shadow of the Future, Feature Team, Product Team, Cross-functional Team, etc. et vous en venez à comprendre la sortie de Jezz Humble !

CE BILLET N'EST PAS FINI

Mort du modèle Change et Run

“You Build It, You Run It” c'est la disparition du mode Change et Run à l'oeuvre dans nombre d'entreprises, à tout le moins, sa profonde métamorphose. La disparition de certains silos ne justifie plus que l'entreprise organise le travail en différenciant ce qui est création de nouveaux produits et leur exploitation, m?me si on comprend l'intention.

Le modèle porte en lui-même sa propre malédiction : une équipe se charge de la construction puis confie à d'autres le soin de maintenir ce qui a été construit et s'en va travailler sur quelque chose d'autres. Il y a là plusieurs problèmes majeurs comme par exemple :

  • Les personnes qui ont construit l'applicatif ne sont plus disponibles pour corriger, le cas échéant, ce qui ne fonctionne pas forcément bien et c'est donc à d'autres qu'échoit la tâche de maintenir un software qu'ils n'ont pas créé, une tâche que personne n'aime et qui est ? l'origine de tensions qu'il faut, par la suite, aplanir.
  • La transition entre l'équipe de construction et l'équipe de maintenance génère un besoin de documentation disproportionné (on pense que la documentation peut remplacer les nombreuses interactions humaines qui ont pris place dans la période de construction – ce qui n'est quan même pas tout à fait faux) et l'abondance de documentation n'est d'ailleurs pas étrangère à l'amplification du problème de qualité (chercher dans des conditions de stress – incident de production – quelque information utile à la résolution du problème parmi une documentation pléthorique met les nerfs à vif)
  • Lorsque des pr?cisions sont nécessaires, l'équipe de maintenance s'en va “déranger” ceux qui ont conçu l'applicatif (ils n'ont pas le choix) qui, eux, sont maintenant à travailler sur autre chose que, de facto, on interrompt provoquant ainsi des délais incontrôlables dans les nouveaux projets auxquels ils sont affectés.
  • ?

Certains bozos qui exercent d'ailleurs des fonctions C-Level, ne l'ont toujours pas compris et continuent à imposer une organisation centrée sur des projets (on assemble une equipe pour une période donnée, on passe à la maintenance ce qui a été construit, on désassemble l'équipe et on réaffecte ses membres à de nouveaux projets) alors qu'il serait souhaitable de s'organiser autour de produits.

CE BILLET N'EST PAS FINI

Revoir les exercices budgétaires

La modification du paysage Change et Run a une cons?quence imm?diate : la transformation radicale des exercices budg?taires. D?sormais, il n'y a plus ou peu de diff?rence entre le Change et le Run, d?sormais la m?me ?quipe est charg?e de la conception et de la maintenance, corrective et perfective, d'une application. Désormais donc, on est amené à financer l'équipe et tout le travail qu'elle doit fournir sur ladite application, et que cet argent serve à construire de nouvelles fonctionnalités ou qu'il serve à maintenir les anciennes n'a, du strict point de vue budgétaire, que peu d'importance.

On se rend dès lors compte d'un autre aspect de la maxime : désormais les équipes sont plutôt faites pour durer. C'est pas mal, se dit-on. On gaspille moins d'argent à assembler des équipes puis à les désassembler, une fois le projet de construction terminé, puisqu'au fond c'est la même équipe qui va devoir maintenir le produit. Et au fond, cela se marie bien avec cette tendance qui veut qu'une équipe puisse traiter son travail de bout en bout, end-to-end.

CE BILLET N'EST PAS FINI

Nouveaux processus d'Incident et Problem Management

CE BILLET N'EST PAS FINI

D'une organisation centrée sur des projets à une organisation centrée sur les produits

CE BILLET N'EST PAS FINI

Sources à consulter: pour en savoir plus

https://essentials.xebia.com/build-it-run-it/ http://blog.octo.com/devops https://medium.com/aws-enterprise-collection/part-3-in-the-enterprise-devops-series-why-you-should-run-what-you-build-c62f0990f4c3#.1xgh7m834

Thoughworks

Safari books

CE BILLET N'EST PAS FINI

Top
Le Blog Apocryphe utilise des cookies pour sauver vos préférences et RIEN d'autre. Je vous demande de bien vouloir accepter les cookies qui sont positionnés sur mon blog et je vous promets en retour de ne RIEN laisser transparaître de votre parcours de visite, dont d'ailleurs vous me faites l'honneur. Au cas où néanmoins vous n'accepteriez pas d'utiliser les cookies, vous aurez probablement une navigation LÉGÈREMENT dégradée sur le Blog Apocryphe. Bonne visite!X