Retour d’expérience de la mise en place de l’Agile à l’URGI Le point de vu du Directeur d’Unité PEPI-IDL 6th December 2011 Hadi Quesneville The URGI unit

Qui sommes nous?

URGI: Unité de Recherche en Génomique-Info Research Unit INRA unit (French National Institute for Agricultural Research) Plant breeding and Genetics Department Strong connexions with other plant INRA departments Bioinformatic platform IBISA Grade Member of the French National Network of Bioinformatic Platforms (ReNaBi) Research Data integration Genome structure and dynamics

5 teams, 30 people

Platform missions Databases design Annotation pipelines Develop an Information System Databases design Annotation pipelines Data mining tools Manage data for large collaborative projects INRA projects ANR projects EU-FP7 projects Maintain a repository for plant and pest genomic and genetic data Grapevine (IGGP), Wheat (IWGSC) National research programs (Genoplante) INRA research programs

Contextes

Contexte Sollicitation à travers des projets scientifiques Durée courte (~3 ans) Financement orienté sur la question scientifique et pas l’outil Les besoins sont de répondre à la question scientifique, et rarement de développer un outil. Ressources: 1 CDD Evolution des besoins en cours de projet Changement des technologies Questions initiales ne deviennent plus d’actualité Nouvelles questions

Contraintes Utilisateurs Développeurs Biologistes non-informaticiens Souvent externes à l’unité Développeurs Développement en interne Robustesse/qualité des développements Besoin de maintenir et de faire évoluer les outils existant

Difficultés Domaine en constante évolution Connaissances multiples Agile Domaine en constante évolution Adaptation rapide aux besoins Connaissances multiples Biologie Bioinformatique Informatique Turn –over des CDD Maintien des outils développés Itérations courtes Binomage

Constituer une masse critique Création d’une équipe de développement Mise en commun des développeurs Rotation des binômes sur les développements Partages des connaissances et des compétences Equilibre ressources/projet Mise en place d’un budget de projet

En pratique

Equipes agiles Transversales aux équipes thématiques 3 équipes Ressources génétique, Ressources génomique, Génomique fongique, Dynamique des génomes, Support transversal 3 équipes Système d’information Pipelines Data

Gestion du temps « agiles » Affectation aux équipes Appartenance à 2 équipes maximum Pas plus de 80% du temps en équipe agile % variant de 20% à 80% Les agents donnent leurs disponibilités pour le mois Le « off » Une journée par semaine ( réunions, …) 2h par jours (email)

La notion de « feature » Spécification légère d’une user-story Ecrite (pas toujours!) par l’équipe Arbitrage à chaque itération (1 mois) Une feature a un coût et une durée maximal d’un mois Feature leader Responsable de la spécification « Celui qui comprend ce qu’il y a à faire »

Pratiques Features suivie dans Jira Développement Spécifications Date de livraison Temps passé Développement Pair-programming CVS, Eclipse Java, Hibernate, Struts/Spring, GWT, Python Code over documentation Test Driven Developments (tests unitaires, test fonctionnels) Intégration continu

Les réunions Stand-up tous les jours Réunion d’itération Concerne que l’équipe de dev. Point sur les réalisations d’hier Ce qui est prévu aujourd’hui Réunion d’itération Concerne l’équipe de dev. + chefs de projets + direction Présentation des « features » réalisées Quelques démos Présentation des futures « features » (exemple) Arbitrage Retrospectives, formations, jamborees

Le budget Ressources apportées par chaque projet Le projet « common » % de temps de chaque développeur apporté à chaque projet Le projet « common » Features transversales, maintenance applicative, évolution des outils sans projets. 20% de chaque développeur Burn down (exemple) Consommation des ressources sur 3 mois (3 itérations) Possibilité de faire des avances Remise à 0 au bout de 3 mois

Bilan 4 ans de mise en place

Points positifs Satisfaction des développeurs Meilleurs développements Esprit d’équipe Partage des compétences Meilleurs développements Plus fiables Mieux maintenus Meilleur suivi de l’avancement des projets Ré-orientation rapide (mauvaise compréhension, changement d’objectifs, …) Plus de visibilité sur les difficultés rencontrées Meilleure gestion des ressources

Points négatifs Personnes hors équipe Visibilité du projet Exclusion Rythme imposé accru  Charge de travail accrue Visibilité du projet Myopie Pas de temps pour s’accaparer le projet Réunion d’itération Peu de temps pour les démos Peu de discussion en profondeur

Roadmap Construite pour 3 mois avec le budget Constitution d’une équipe Construction entre le chef de projet et les développeurs Définition des objectifs  périmètre du produit Arbitrage des features Réunion d’itération à 15j Démos Réorientation rapide Discussion plus approfondie

Recommandations Adapter la méthode à ses besoins Identifier le but recherché Les principes plus importants que les pratiques Pas de dogme Mettre en place progressivement Résultat de 4 ans de travail Faire évoluer la méthodologie Construire la confiance Autonomie, auto-organisation des équipes Déléguer les responsabilités (animateur, équipe) Ne pas remettre en cause les chiffrages !!

Remerciements Gabriel Levan Olivier Inizan

Remerciements URGI A-F. Adam-Blondon N. Mohellibi, M. Alaux, F. Alfama, J. Amselem, N. Choisne, S. Durand, O. Inizan, V. Jamilloux, A. Keliet, E. Kimmel, N. Lapalu, I. Luyten, N. Mohellibi, M. Moissette C. Pommier, H. Quesneville, S. Reboux, D. Steinbach, M. Zytnicki S. Arnoux (CDD), M. Bras (CDD), B. Brault (CDD), L. Brigitte (CDD), T. Chaumier (CDD) R. Flores (CDD), T. Flutre (PhD), C. Hoede (CDD), Y. Luo (CDD) F. Maumus(Post-doc), C. Michotey (CDD) D. Verdelet (CDD), D.Valdenaire (CDD)