LES ACTEURS DU PROJET

Dans les méthodes de développement traditionnelles, on distingue généra- lement le profil de l’expert fonctionnel ou de l’analyste (chargé de traduire en besoins et spécifications intelligibles par le programmeur les demandes exprimées par les utilisateurs métier) du profil du programmeur (chargé de la rédaction du code logiciel). En méthode agile, si ces dominantes demeurent (le premier audite et définit le besoin, le « quoi ? », le second établit la solution, le « comment ? »), la communication entre les deux est renforcée. Ce rapprochement vise à impliquer davantage le programmeur dans la finalité métier du produit qu’il développe et à faire en sorte que l’analyste soit de son côté au plus près des implications techniques de réa- lisation du développement, notamment en termes d’évaluation des coûts.

motivant et lui apporter soutien, atten- tion et confiance ;

•  la méthode la plus efficace pour trans-

mettre l’information et comprendre un besoin est une conversation en face à face ;

•  un  logiciel  fonctionnel  (que  l’on  peut  voir, tester et faire fonctionner dans des conditions quasiment opérationnelles) est la meilleure unité de mesure de pro- gression d’un projet ;

•  les  processus  agiles  promeuvent  un  rythme de développement soutenable. C’est-à-dire qu’une attention constante est portée au réalisme des plannings et à l’évaluation des ressources et des efforts requis pour réaliser les dévelop- pements souhaités. Commanditaires,

développeurs et utilisateurs devraient théoriquement pouvoir maintenir le rythme de développement suivi indéfi- niment sans épuiser les équipes ; •  une  attention  continue  à  l’excellence 

technique et à la qualité de conception améliore l’agilité ;

•  la  simplicité  –  l’art  de  maximiser  la  quantité de travail à ne pas faire – est essentielle ;

•  les  meilleures  architectures,  spéci-

fications et conceptions sont issues d’équipes qui s’auto-organisent ; •  à intervalles réguliers, l’équipe réfléchit 

aux moyens de devenir plus efficace, puis accorde et ajuste son comporte- ment dans ce sens.

Pr es ses de l ’ens sib , 2 015 . <  ht tp://www .ens sib .fr /pr es ses/  >

Le nombre d’analystes et de développeurs varie avec l’importance et les moyens du projet. À la BnF, ce principe se traduit surtout par une plus grande participation des développeurs aux échanges avec les utilisateurs alors qu’ils avaient jusque-là tendance à être cantonnés dans une place plus solitaire du back office.

Au côté de cette équipe issue des métiers de l’informatique, la méthode agile préconise la présence quasiment permanente d’un ou plusieurs représentants des utilisateurs – en l’occurrence, un ou plusieurs biblio- thécaires. L’un d’eux a la responsabilité et la légitimité officielle (il est désigné formellement dans cette fonction par son encadrement) de repré- senter les intérêts des utilisateurs (professionnels ou finaux) de l’applica- tion à développer. Cette fonction de « chef de produit »* (product owner) est différente de ce qu’on entend habituellement par « chef de projet ». En effet, tout projet a un début et une fin, tandis qu’une application doit continuer de vivre, d’être maintenue et d’évoluer après la phase initiale de conception et la mise en production des premières versions. Un chef de produit a donc une « durée de vie » plus longue qu’un chef de projet, et dans tous les cas, sa fonction doit perdurer. Compte tenu de la forte impli- cation requise pour ce chef de produit au sein de l’équipe de développe- ment, il importe de ne pas sous-estimer la quotité de travail requise pour le bibliothécaire désigné pour jouer ce rôle. Pour de grosses applications, c’est quasiment un temps plein qu’il faut pouvoir consacrer à cette tâche. À la BnF, on peut considérer que le rôle de chef de produit, généralement occupé par un conservateur, est en passe de devenir un profil de poste à part entière. Cela soulève des questions intéressantes de reformulation des fiches de poste, de positionnement dans l’organigramme, mais aussi de reconnaissance. En effet, cette responsabilité est au croisement des fonctions scientifiques et d’encadrement des conservateurs, mais conduit à les exercer dans un cadre beaucoup plus transverse et évolutif. Le chef de produit porte une lourde responsabilité que l’établissement doit ap- prendre à reconnaître formellement.

Au sein de l’équipe projet, une personne (qui peut être issue aussi bien de la communauté informatique que de la communauté bibliothèque) joue enfin le rôle de pilote ou d’animateur du projet. Sa fonction est de faire respecter les règles du jeu, de s’assurer que les modalités de travail sont

Pr es ses de l ’ens sib , 2 015 . <  ht tp://www .ens sib .fr /pr es ses/  >

conformes au cadre de collaboration défini au lancement du projet : ins- tances, rôles, respect du calendrier, etc. Il est, en quelque sorte, le garant du respect de la méthode.

Les méthodes agiles accordent enfin une place particulière aux « com- manditaires » de l’application, c’est-à-dire aux personnes qui exercent des responsabilités hiérarchiques vis-à-vis de l’équipe opérationnelle chargée de la réalisation du produit. Si l’équipe est encouragée, on l’a vu, à déve- lopper sa propre organisation et à fonctionner de manière aussi autonome que possible, le management n’est pas pour autant exclu de la vie du pro- jet. Les encadrants sont sollicités périodiquement pour résoudre des pro- blèmes de ressources, d’éventuels conflits ou différences d’appréciation quant à la trajectoire, et la prise de risques. De ce fait, ils interviennent avant tout en soutien et en impulsion de l’équipe, davantage que comme un vecteur de contrôle. À la BnF, j’y reviendrai, cette démarche a eu pour effet d’impliquer et de sensibiliser davantage l’encadrement supérieur à l’organisation informatique et à la vie des produits applicatifs et à lui faire prendre davantage conscience des dimensions stratégiques et managé- riales de projets en apparence techniques et donc hors de son champ de vision ou de responsabilité habituel.

La valeur des histoires

En méthode agile, l’unité de mesure du travail de développement s’ap- pelle « l’histoire utilisateur »* (user story). C’est en effet un principe fort de la méthode que de centrer la réalisation des tâches toujours à par- tir de l'expérience utilisateur, que ce soit l'usager final (examen d’une fonctionnalité sur une interface destinée au public, sur le front office) ou professionnel (examen d’une fonctionnalité destinée à l’administration du produit, dans le back office). Les fonctionnalités destinées à être traduites en spécifications et en programme ou code informatique sont ainsi scé- narisées et « incarnées ». Cette approche garantit la permanence du souci de l’utilisateur dans la conduite du projet. Parce qu’elle favorise l’utilisa- tion d’un langage qui parle directement à des cas d’utilisation concrets et quasiment vécus ou à vivre à travers des exemples et des démonstrations, elle facilite l'échange et la compréhension réciproque entre informati- ciens et bibliothécaires, mais aussi avec le management comme avec les

Pr es ses de l ’ens sib , 2 015 . <  ht tp://www .ens sib .fr /pr es ses/  >

communicants qui seront amenés à défendre ou valoriser le projet auprès d’autres instances et d’autres publics. À la BnF, cette approche rend le travail extrêmement tangible. Elle permet aussi de voir les difficultés très vite : une fonctionnalité qu’on n’est pas capable de résumer en histoire est une fonctionnalité mal définie ou dispensable.

Le travail s’organise en itération, des cycles de développement de quelques semaines relativement courts (deux à quatre à la BnF). Au début de chaque itération, l’équipe dresse la liste des histoires à réaliser (le back log*) et répartit les tâches. À la fin de chaque itération, on évalue le réalisé et le reste à faire (et éventuellement les « bonus », conçus en plus) et on prend le temps d’analyser les raisons pour lesquelles les objectifs n’ont pu être atteints. Ce temps permet à l’équipe de réévaluer certaines options, ou de réfléchir aux forces et aux faiblesses de son organisation de travail. La fixation des objectifs comme la réalisation du bilan donnent lieu à une discussion entre informaticiens et bibliothécaires relative au coût et à la valeur de chaque histoire. Chaque histoire projetée se voit ainsi assigner un certain nombre de « points » de valeur, qui servent à apprécier, d’une part, l’importance accordée à sa réalisation d’un point de vue métier, et d’autre part, le coût de cette réalisation. On reviendra plus loin sur cet aspect particulièrement intéressant dans la méthode agile – la discussion de la valeur – qui favorise à la fois la fixation des priorités et la responsa- bilisation de chacun.