Étiquette : Efficiency

DevOps : NoOps ou NewOps ?

Cette question revient de plus en plus lorsque l’on aborde la mise en place d’une approche DevOps dans une grande entreprise. Certaines personnes voient le DevOps comme le NoOps : « You build it, you run it! ». Est ce vraiment la réalité du terrain ?

« You build it, you ship it, you run it! »

Dans le monde du NoOps, l’équipe de développement agile est en charge des opérations. Les incréments produits par l’équipe sont revus, testés, validés par un maximum de processus automatisés afin de canaliser le déploiement jusqu’en production de manière sécurisée. Plus on déploie de petits incréments souvent, moins on a d’incidents de production. La mise en production devient donc un « non évènement ». Côté production, la supervision, la mise à l’échelle et la maintenance sont totalement automatisés par l’équipe de développement. Si un incident survient, n’importe quel membre de l’équipe de développement est à même d’intervenir pour resource le problème et prendre les actions nécessaires pour que celui ci ne se reproduise pas.

Est ce que cela fonctionne à tous les coups ?

De même que pour l’agilité, le niveau de maturité DevOps peut être très différent d’un contexte à l’autre. Le NoOps nécessite un très fort niveau de maturité. Google, Amazon, Netflix, Facebook, Microsoft travaillent sur leurs processus opérationnels dans un contexte cloud depuis des années pour en arriver là et ils continuent de s’améliorer. Est ce vraiment envisageable à court terme pour votre organisation ? Cela dépend de nombreux facteurs. Certaines personnes pense que le NoOps ne permet que de réduire les coûts en supprimant les Ops. C’est peut être le cas sur du très long terme mais cela n’est pas l’objectif premier du NoOps. Il s’agit de pouvoir délivrer de la valeur à un produit de manière beaucoup plus rapide. De réduire le « Lead Time » à son minimum et de pouvoir réagir rapidement dans un contexte changeant.

Le NoOps c’est bien mais est ce que cela correspond à la vision de mon organisation ?

Tout d’abord, lorsque l’on cherche à mettre en place une démarche DevOps, il faut se donner une vision. Quels sont les objectifs que je cherche à atteindre dans 1 an, 6 mois, 3 mois ? Ensuite, il faut trouver le ou les chemins pour y arriver.

Les grosses organisation ont cherché depuis de nombreuses années à diminuer leurs coûts opérationnels en mutualisant les infrastructure et en créant des pôles d’expertise technique. Cette approche a créé un silo naturel entre les entités métier et les entités opérationnels. Les développeurs se sont rapproché depuis quelques années du métier et travaillent en agile. Ils délivrent des incréments qui sont « prêts » à être déployer en production par les Ops. Ils envoient leur package par dessus le mur de la confusion aux équipes opérationnelles qui le déploient à leur tour.

Le NoOps est il pertinent dans mon contexte ?

Les opérations sont avant tout une histoire de rôles et de responsabilités. En cas d’incident, qui est responsable de trouver une solution ? Quel est l’engagement de service vis à vis du client (SLA)? C’est aussi une question de métier et de compétences. Certains développeurs sont extrêmement polyvalents mais sont ils en mesure d’opérer 24h sur 24 une plateforme de production ? Peuvent ils s’organiser pour le faire d’un point de vue logistique ? Ont ils assez de compétences opérationnels sur la supervision, le réseau et la sécurité ?

Ce sont les raisons pour lesquelles le NoOps complet n’est pas applicable dans beaucoup d’organisations.

Vers le NewOps…

La mise en œuvre d’une approche DevOps impacte fortement l’organisation et nécessite un accompagnement à la fois sur la mise en place des outils mais aussi sur le changement de culture. Cet accompagnement débouchera sur de nouveaux processus opérationnels, plus légers, plus agiles et adaptés aux enjeux du cloud. Le NewOps réinvente le métier de l’Ops et le recentre sur le métier par le biais de l’agilité. Le métier d’Ops n’est pas compromis, bien au contraire. Il évolue vers l’excellence opérationnelle au sein d’un écosystème agile.

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 (le maximum est de 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 activement. On dit aussi qu’il peut y assister en mode « chicken » 🐓.
De tous les évènements Scrum, le Daily Scrum est l’un des plus difficiles à 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 fois l’équipe habituée, les 15 minutes tiendront sans chrono.

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. Si une discussion, un choix technique doit être pris, un session de travail pourra être prévue à la suite du Daily sans impacter l’ensemble de l’équipe.

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.

L’objectif du Sprint est d’atteindre le Sprint Goal. Il est important que l’ensemble de l’équipe l’ai en tête afin qu’elle puisse évoluer dans la bonne direction.

Voici un exemple de prise de parole synthétique durant le Daily :
« Dans le but d’atteindre le Sprint Goal (rappeler éventuellement celui ci), depuis le dernier Daily Scrum » : J’ai travaillé sur le PBI A, j’ai pu avancer sur …. avec ….
« Jusqu’au prochain Daily Scrum » : Je vais continuer sur le PBI A (ou travailler sur autre chose), je compte faire …. Et j’ai besoin de 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 !