Publications de Yannick Martel

L'Agile est aujourd'hui un outil puissant d'amélioration de la qualité des produits et de la satisfaction des acteurs, utilisateurs comme artisans du système d'information. Si la méthode commence à être connue, sa mise en œuvre peut néanmoins se heurter à des difficultés, notamment sur le volet contractuel. Ainsi, dans les organisations où les pratiques d’achats reposent sur une définition exhaustive des besoins (i.e. cahier des charges) et une obligation de résultat portant sur un périmètre figé et qui ne peut évoluer qu’à l’aide d’avenants, il…

Un double paradoxe Le titre de ce billet est doublement paradoxal. Le terme de "rituel" lui-même surprend en milieu professionnel. Souvent associé à un contexte religieux, il appartient au registre de l'anthropologue et pas du professionnel ou du consultant en entreprise. Qui plus est, il est associé plutôt à des actions répétées dans un ordre fixe et immuable, et pas au changement Pourquoi alors ce terme apparait-il, notamment mais pas seulement dans l'Agile?

Le court terme Un manager disait à l'un des chefs de projet : "Bien sûr, je suis d'accord: il faudrait prendre le temps de former les développeurs aux techniques de tests; mais là, ce qui est crucial c'est de corriger les bugs et de relivrer d'ici vendredi".

Ce me semble être un des secrets les mieux gardés du moment en informatique : nous opérons souvent sur un paradigme qui est faux en utilisant la métaphore de l'usine et de la production "industrielle".

Pour développer une application informatique, nous partons d'un besoin "du marché", c'est à dire des utilisateurs, donneurs d'ordre, marketeurs et stratèges, clients ou autres, qui ont mot à dire par rapport au nouveau "produit", qui est donc ici une application ou un système informatique. Entre le besoin et le produit, on trouve la formulation du besoin, que nous désignerons par spécification du besoin. Cette spécification peut être écrite, rédigée et présentée comme exhaustive, ou être le résultat d'interactions quotidiennes. Cette spécification est en général formulée…

Certains pensent qu'il est impossible de concevoir un bon contrat agile au-delà de la simple mise à disposition de moyens, et que tout mécanisme plus complexe priverait des bénéfices d'une démarche Agile bien comprise, voire serait amoral. Explorons aujourd'hui cette question, pour essayer d'aller au-delà d'un constat à mon goût trop limitatif et envisager des formes contractuelles nouvelles qui pourraient s'adapter à des environnements culturels, relationnels et applicatifs variés.