Introduction
De par ma formation d’ingénieur dans les sciences et procédés industriels alimentaires (biologie et thermodynamique) puis pétrolières (thermodynamique, finance et optimisation mathématique) – avec en parallèle des cours de DEA en Gestion de Production & Gestion de la Qualité – je reste très orientée process & méthodologies. Des statistiques à la Finance en passant par l’architecture fonctionnelle j’ai toujours eu une approche systémique (au sens de Bertalanffy ou de Ackoff / Deming) et plus particulièrement fractale (je présenterai un jour une architecture réactive & mvc fractale et une méthode unifiée fractale). Mais au delà des théories c’est surtout leur mise en pratique qui m’intéresse, ceci dans l’esprit de la qualité originelle de Walter Shewhart et Edwards Deming pour qui le concept d’opérationalité est essentiel (concept malheureusement non mis en avant dans les méthodes qui se réclament pourtant de Deming comme Six Sigma, ITIL ou CMMI).
De ce fait l’informatique n’est pour moi qu’un outil permettant de réaliser des solutions. Bien que les outils de programmation présentent peu d’intérêt en soi me concernant, en tant que chef de projet dans le domaine, j’estime qu’on ne peut pas mener dans des conditions de coût, délai pour une qualité maximale un projet informatique si on ne dispose pas d’une culture générale technique suffisamment approfondie pour les combiner ensemble à la fois pour implémenter une solution mais également pour accroître la productivité (par exemple avec la génération de code et la méta-modélisation). De ce fait je veille en permanence sur les évolutions technologiques en devenir pour guetter le moment où elles sont suffisamment mâtures pour leur mise en oeuvre (rien ne sert de courir …). Ma spécialité est d’orienter le client vers les meilleurs choix de solutions du moment tout en me souciant de la maintenance évolutive de ses architectures dans le futur grâce à une véritable approche de la modélisation soit du point de vue métier (mission MOA) pour une cartographie des processus métiers soit du point de vue technique (mission MOE) pour le dossier de choix de solutions et la conception d’ensemble lors de la phase d’étude préalable puis la conception détaillée en concertation avec les experts techniques et les développeurs lors de la phase de réalisation.
Dans la gestion de projet au quotidien, pour comprendre les difficultés de programmation des développeurs, bien que n’étant pas codeuse, j’essaie d’apprendre à écrire moi-même quelques lignes d’intégration voire des prototypes de frameworks ne serait-ce que pour anticiper des problèmes qu’ils rencontreront ou pour tester des livraisons critiques. Je rédige aussi souvent moi-même la documentation afin de m’assurer qu’elle est vraiment utile et compréhensible par une personne nouvelle qui arriverait sur le projet.
Mon cheval de bataille depuis plus de 15 ans reste avant tout la méthodologie logicielle pragmatique (par égard au concept d’opérationnalité ci-dessus) mais sans compromis sur l’architecture ou la documentation. Mais ma démarche n’est jamais d’exiger immédiatement l’Agile car sa mise en oeuvre intégrale nécessite un socle d’architecture de base qui soit lui-même évolutif et une gestion de changement progressive tout comme pour un développement logiciel (car les organisations de type corporate ne sont pas des startups comme Google) pour qu’elle puisse s’implanter efficacement et durablement au delà des modes. Malheureusement, les praticiens ont tendance à confondre Agile avec l’utilisation des outils RAD (Rapid Application Development) qui en soi conduisent malheureusement à du code spaghetti sans véritable architecture qui posera des soucis d’évolution lorsque la complexité s’accroîtra. J’ai dédié récemment un blog sur le sujet – en anglais car les spécialistes aux US sont bien plus nombreux qu’en France: