Un premier article a présenté DevOps dans ses grandes lignes. Nous verrons que l’état d’esprit DevOps, car c’est un état d’esprit, est extensible au delà des problématiques techniques. Cet article propose une application des concepts DevOps autour des problématiques de conceptions fonctionnelles et métiers.
Réaliser une application est une chose. Réaliser une application répondant au besoin en est une autre. Nous parlons ici de besoin, et non pas des exigences fonctionnelles exprimées. Le besoin est ce que l’Assistance à Maitrise d’OuvrAge devra extraire et formaliser à force d’enquêtes et de feedback métiers.
La valeur ajoutée qui sera facturée au client se retrouve à ce niveau. Fondamentalement, le client connait son métier mais ne connait pas son besoin. En effet, les responsables métiers sont rarement des spécialistes de la médiatisation des processus, connaissant les enjeux de leurs exigences en terme d’audit, de développement, d’intégration, d’administration système.
Le client est bien souvent mis de côté dans l’approche DevOps. Le client est représenté par le “producteur” (MOA) et les utilisateurs finaux. Le premier transmet ses exigences au lancement et les derniers sont les futurs opérateurs de l’application. Il ne faut pas oublier ces deux types d’acteurs car après tout, le financier de l’application a le pouvoir de valider la réalisation et l’utilisateur final a le pouvoir de la dénigrer. On doit donc les considérer à parts égales dans tous les artefacts produits au cours de la réalisation.
Pour caricaturer, on ne peux pas dire qu’un projet superbement réalisé mais ne répondant pas au besoin réel soit plus efficace qu’un projet bancal accompagnant néanmoins l’utilisateur dans sa fonction métier. Dans cet exemple, le premier projet a peu de chance d’entrer un jour en service, et le second va tellement frustrer tous les types d’utilisateurs que le producteur ne vous rappellera certainement plus jamais à ses côtés.
Les indicateurs
DevOps insiste sur la qualité des logs et du monitoring. Il est aisé de transposer ces bonnes pratiques dans le métier de l’AMOA. Il faut donc, dès la première réunion, s’assurer des conditions qui vont nous permettre de valider la réalisation du projet, du premier au dernier jalon. Un conseil : choisissez en priorité des indicateurs mesurables AVANT même que le projet soit lancé. Vous verrez ainsi bien souvent les indicateurs s’améliorer au fur et à mesure que votre équipe définira l’existant puis la cible, par la simple prise de conscience d’anomalies parfois immédiatement corrigées par les équipes métiers elles-même !
La taille de la base, le nombre d’utilisateurs connectés sont des exemples d’indicateurs de performance classiques, centrés sur le logiciel en lui même. D’autres indicateurs relevant l’utilisation métier du logicielle doivent être davantage explorés : nombres d’actions métiers réalisées par jours/mois/années, volumétrie des instances métiers à traiter/en cours de traitement/réalisées/archivées, etc … Si vous déclinez ces indicateurs par acteurs, par structure organisationnelles, certains de ces chiffres vous aiderons à détecter quels seront les sites pilotes, qui sont les utilisateurs finaux “leaders d’opinion” à impliquer dans le projet, et bien d’autres informations-leviers toujours bon à utiliser avant, pendant et après le projet.
Les écrits DevOps suggère que les indicateurs les plus intéressant sont souvent communiqués de la base vers le sommet (bottom-up), de l’exploitation vers les développeurs, et c’est également le cas des opérationnels métiers vers les décideurs : Il vous faudra donc vous concentrer sur les processus opérationnel pour repérer et afin de détecter les indicateurs pertinents pour votre projet.
La communication
Un travail efficace de votre part ne peux être livré de la même manière aux différents types d’acteurs. Aux utilisateurs finaux, il faudra schématiser les impacts sur leurs processus et les interactions avec les autres entités de l’entreprise. Aux producteurs, il faudra détailler les axes d’amélioration et les jalons de mises en service effective. Pour vous y retrouver, vous même et votre équipe utiliserons un langage neutre, clair et objectif, c’est-à-dire déccorélé des différents enjeux et points-de-vue propres aux deux acteurs pré-cités. Tous les médias (cahiers des charges, modélisations, simulations, indicateurs) doivent être confrontés régulièrement avec la réalité pour être ajustés.
Une communication efficace peut être appuyée par des modélisations UML complètes, telles qu’on peut les réaliser sous les solutions Rational d’IBM ou PowerDesigner de Sybase. Ces usines de conceptions sont le parfait parallèle à l’automatisation prôné par DevOps : mises en confrontation continue des points de vu au sein d’un référentiel commun, FailFast pour détecter les incohérences des concepts “mal-partagés” au seins de l’organisation (nécessité de DSL communs), générations de rapports basés aux formes différentes pour une diffusion ciblés aux types d’acteurs. La boucle est bouclée.
Conclusion
Nous avons vu dans ce second article qu’il est possible d’anticiper et d’améliorer les phases de conceptions fonctionnelles et d’accompagnement du changement tout comme le socle DevOps propose d’anticiper les phases de développement et de mise en production du logiciel. Alors un bon conseil, même si elles peuvent paraître un peu technique, imprégnez-vous de toutes les bonnes pratiques DevOps ; participez aux communautés, et vos projets gagneront naturellement en qualité avec des économies de coûts et de délais.
