Dans le monde de la gestion de projet, nombreuses sont les méthodes pour aller d’un point de départ à un résultat final. La méthode « traditionnelle » consiste en un établissement d’un cahier des charges, puis d’une mise en application de celui-ci par les pôles correspondants. Généralement, l’équipe A s’occupe de la tâche A dans une durée A, puis la même chose pour l’équipe B, et ainsi de suite. Ce mode de fonctionnement implique deux choses :
-
Le projet se fait par étapes prévues à l’avance, ce qui signifie que le moindre problème rencontré peut remettre en cause tout le travail qui a été effectué au préalable, par les pôles précédents. La perte de temps peut dans ces cas-là s’avérer importante, notamment si c’est en fin de projet que l’on s’aperçoit de ces problèmes.
-
Humainement parlant, le travail s’effectuant sur le modèle que l’on appelle de « silos » (c’est-à-dire des équipes bien distinctes, qui font partie du même projet mais qui n’interagissent pas entre elles), la communication est rare ou inexistante. Les seuls échanges arrivent lors d’éventuels transferts de documents entre deux jalons, ou lors de détection d’anomalies (comme expliqué ci-dessus)
Pour pallier ces difficultés, il existe une culture, mise en place il y a quelques années : la culture DevOps, dont on parle notamment au niveau des Directions de Systèmes d’Informations (DSI).
Kézako ?
Le DevOps, c’est l’inverse du travail en silos. Pour comprendre le principe, intéressons-nous d’abord à la terminologie : quand une DSI crée une solution logicielle – si elle pratique le DevOps – celle-ci est créée par les développeurs (la partie « Dev »), et mise en ligne ou déployée par les exploitants (la partie « Ops »). Au lieu que les Ops attendent que les Dev aient terminé, au risque de devoir retravailler des choses bien plus tard, ceux-ci travaillent ensemble.
A l’image de la méthode agile, il s’agit ici de fixer des étapes à plus court terme, et de travailler en collaboration afin de pouvoir avancer de faon plus sûre, et avec une dimension humaine importante ajoutée. Ainsi, à l’inverse des méthodes « habituelles » de travail, le travail en collaboration est mis en avant : la communication en interne devient totalement indispensable.
Seul petit bémol…
Le DevOps est une belle culture, mais malheureusement trop méconnue des entreprises. Ou plutôt, et c’est tout aussi regrettable, est connue mais trop peu mise en application. Même au sein d’un même groupe, il se peut que plusieurs DSI réparties dans plusieurs villes ne pratiquent pas cette méthode. Certes, cela ne crée en aucun cas une incohérence au sein de l’entreprise, mais il est dommage de constater qu’une méthode de travail aussi souple et humaine n’a pas encore tout à fait ses lettres de noblesse. Les raisons sont nombreuses : remise en question de tout une mode de fonctionnement, compréhension de la problématique (tout le monde peut ne pas se sentir concerné)… Mais à défaut, elle a un début de réputation, ce qui est un bon point de départ.
Ce serait bien qu’on est quelques références complémentaires et des liens qui iraient avec. Attention cet article est dans la catégorie “merci de m’enlever des points”