Comment intégrer l'OPS dans les pratiques Agiles

Aujourd’hui, beaucoup de monde, d’équipe et d’entreprise parle d’Agilité et plus précisément du FrameWork SCRUM qui est très largement répandu.
On y parle de :

  • PO
  • Scrum Master
  • Parties Prenantes
  • L’équipe de réalisation
  • Du ou des Testeurs

Mais au fait, où est l’OPS ?
A quoi cela sert d’être agile si ce n’est pas pour mettre en production ?
Et comment intégrer l’OPS dans le FrameWork SCRUM ?
Je sais, vous allez me dire que l’on va vert les bonnes pratiques DevOps, mais la question m’interpelle.

Ayant échangé avec d’autres sociétés, beaucoup tente de rajouter une nouvelle définition à ces acteurs :

  • Ops Master
  • Tech Lead

Et définissant ainsi de nouveau ticket : Tech Story.

Et vous, comment voyez-vous la chose ?
Mais surtout, comment avez-vous intégrer l’OPS ?

Pour vous aider à répondre, voici une petite vidéo de la chaine Scrum Life.
Être Agile - Peut-on être agile sans gérer sa prod ? #DevOps - #ScrumLife 102

Hello,

Juste deux petites phrases du scrum guide sur l’équipe de développement que je dépose ici :

  • « Elles sont pluridisciplinaires, avec toutes les compétences nécessaires, en tant qu’équipe,
    pour créer un incrément produit ».
  • « Scrum ne reconnaît pas d’équipes au sein de l’équipe de développement
    indépendamment des domaines qui doivent être couverts tels que l’exécution de tests,
    l’architecture, la gestion opérationnelle ou l’analyse fonctionnelle »

Maintenant que j’ai dis ça je sais que ça n’est pas une solution miracle, mais penses-tu que ça réponde en partie à ta question ? Faut-il vraiment intégrer l’ops dans le framework scrum ou y est-il déjà ?

C’est un peu ce que dit Vincent Jobard dans la vidéo, l’agilité concerne l’ensemble des acteurs. Encore une fois pas de solution miracle mais tendre vers une organisation ou on « casse » les silos est très important pour réellement être agile. Qu’ils soient cassé grâce à une équipe scrum unis ou par tout autre moyen.

Et enfin, tu connais mon point de vue sur les tech story…je ne vois pas l’interet, il me semble qu’on ne fait jamais rien pour le plaisir de la technique mais bien pur répondre à un besoin. La fameuse tech story sert bien trop souvent à cacher des besoins mal ou non compris. Dans certains cas, il s’agit même d’un moyen pour contourner les règles de l’équipes. Qu’on utilise les user story ou quoique ce soit d’autre l’idée est surtout de comprendre le besoin pour trouver une solution adaptée.

Bref, je m’arrête la sinon j’écris un livre.

Bonne journée!

Bonjour Marc,

C’est un OPS qui te parle avec une expérience de 20 ans.

La réponse est simple: il suffit de créer des équipes pluridisciplinaires intégrant des OPS.

Amazon l’a très bien compris avec son dicton « You Build It, You Run It ».

Mais sur le terrain, la notion de DevOps se traduit par la mise en oeuvre de solutions de déploiement automatisées à l’initiative des développeurs et généralement sans les Ops avec de l’Infra As Code, du Kubernetes,de l’Ansible, etc …

Présenté autrement, je n’ai pas le sentiment que l’industrie informatique française ait bien comprit la logique qui se cache derrière le terme DevOps, à savoir la collaboration étroite entre des développeurs et des ingénieurs systèmes pour que la créativité des Devs trouve un peu de sagesse et de retenue dans la rigueur des Ops et que la psychorigidité des Ops soient un peu débridée sur certain aspect par cette même créativité.

C’est de l’intelligence collective de base à savoir que l’intelligence d’un groupe est d’autant plus stimulée et efficace qu’il est diversifié dans sa composition.

Mais l’Ops n’est pas le seul dans ce cas là et je pense notamment aux DBAs qui sont eux aussi considérés comme secondaires dans le staffing des équipes voire des projets et qui mériteraient tout autant d’être intégrés systématiquement dès le processus de développement.

En conclusion, pour répondre plus précisément à la question, je pense qu’il y a un gros travail d’évangélisation et de reformulation sur la notion de DevOps avant toute chose.

1 J'aime

Hello Philippe,

Complètement d’accord, aujourd’hui lorsqu’on parle de devops on parle souvent de l’outillage. Pour moi il s’agit surtout d’une culture, présente dans l’agilité, que l’on a oublié au profit du dev. D’où mes citations du scrum guide :).

Ma vision de DevOps est la suivante : les dev et les ops ont toujours eu des objectifs très différents. Tout changer et faire évoluer pour les dev. Le moins de risque possible pour que ça marche coté ops. Logiquement, ils ont donc été séparé en entreprise comme nous dit de le faire ce bon vieux taylorisme. L’idée derrière DevOps est à l’inverse, de rapprocher les deux entités pour créer de la compréhension des problématiques de l’autre. Qui finalement sont l’ensemble des problématiques produits. De cette manière on peut composer et avancer vers des solutions plus adaptés :).

Encore une fois je suis d’accord, il y a un gros travail à faire là-dessus dans les entreprises françaises qui, parfois, rajoutent un DevOps entre le dev et l’ops, et créer encore plus de silos.

@Taz_agile , pour répondre plus simplement à ta question, s’il y a des soucis à ce niveau je pense que la première chose que je ferais serai d’essayer de casser ces silos. Que ça soit par la création d’une équipe unique pour par tout autre moyen possible en s’adaptant à ton contexte :slight_smile: .

Je pense que ce n’est pas lié au Taylorisme mais à cartésianisme que la pensée de Descartes à propulsée en occident qu’il faut pointé du doigt.

Le cartésianisme suppose de diviser un problème en plusieurs petits problèmes et se traduit par un phénomène de silotage des équipes comme constaté sur le terrain.

A l’opposé, je pense qu’il faut commencer à envisager les choses sous un angle systémique qui ne suppose plus d’appréhender les choses par réductions successives mais bien au contraire dans son ensemble.

Cela qui suppose de modéliser et cartographier les structures sociales et de déterminer les interactions les plus efficientes possibles.

La systémie, à l’opposé du cartésianisme, défend l’idée que l’efficience d’un système dépend entre autre de la diversité des éléments qui la compose.

Donc des équipes non mono-compétence comme c’est souvent le cas mais polyvalente dont on prendra soin de mesurer la fluidité des interactions.

Je suis partiellement d’accord. Je ne pense pas qu’une vue systémique soit forcément en opposition avec la division d’un problème en plus petits problèmes. Ce découpage ne mène pas nécessairement à des silos mais plutôt à un système de systèmes qui peuvent interagir et évoluer ensemble.

Ainsi plutôt que de créer un gros ensemble on a un ensemble d’ensemble qui créer la richesse du système. Dans ce cas le découpage des problèmes peut même permettre de les appréhender à plus petite échelle et d’influer sur l’ensemble du système de manière organique. A condition bien sûr qu’il ne s’agisse pas de silos mais bien de sous ensemble.

C’est pourquoi nous prônons souvent, en agilité, le découpage. En temps, en permettre, en taille d’équipe, etc, sans pour autant renforcer les silos.

Peut être ai-je mal compris le cartésianisme mais il me semble que ça n’est pas opposé à la systémique :slight_smile:

Merci à tous les deux pour ces retour très riches voir philosophique :slight_smile: .
Comme indiqué, il est claire que le fait de travailler avec l’ensemble des acteurs et au niveau de l’équipe permet d’un premier temps de casser les silos très localement, qui pourrait avoir un effet de raisonnance sur les autres équipes pour ensuite faire bouger de façon systémique.

Il est clair qu’il n’y a pas de recette miracle, chaque cas, chaque contexte et chaque équipe est différente et il faut le prendre en tant que tel pour que les équipes puissent avancer.

Pour faire de grandes choses, il ne faut pas être un si grand génie ; il ne faut pas être au-dessus des hommes, il faut être avec eux. (Montesquieu)

Descartes dans son Discour de la méthode, propose une approche pratique qui consiste à décomposer chaque problèmes en problèmes plus petits, lesquels sont ensuite traités de manière linéaire les uns après les autres. Un problème ne peut pas être résolu sans avoir résolu le problème précédent.

C’est du silotage et c’est ce qui gouverne le modèle organisationnel en vigueur en France. C’est ainsi que le développement est décorélé de la production et ce qui fait qu’il est très difficile de créer des équipes pluridisciplinaires qui reviendrait à une vision systémique et plus spinozienne.

Un vision systémique c’est un peu comme si une organisation ressemblait à une toile d’araignée: lorsque l’on tire sur un fil, c’est toute la toile qui se déforme avec plus ou moins d’intensité en fonction des endroits mais l’ensemble est impacté. Cela suppose d’avoir une logique plus holistique et d’être extrêmement vigilant sur les interactions la fluidifité de l’information voire même faire de mesure de l’empathie chez un candidat au recrutement (avec le test « Reading the Mind in the Eyes » par exemple) car on sait aujourd’hui que l’empathie est une qualité importante pour l’efficacité du travail en groupe.

Dans l’approche cartésienne, celle que nous connaissons, on isole les compétences puisqu’elles sont associés à des problèmes distincts sans envisager une continuité et un chevauchement des problèmes. Les interactions entre des domaines de compétences distincts sont difficiles car non juger critiques et fondamentales. La notion de DevOps, qui consiste uniquement d’après moi à rapprocher des entités distincts découle d’une volonté de contrecarrer ça.

Bref, je pense que c’est tout une philosophie qu’il faut remettre en cause, même si cete philosophie, il faut bien l’avouée, à engendrée le siècle des lumières et nous a apportée beaucoup de choses.

1 J'aime