Retour d’expérience de la mise en place de l’Agile à l’URGI

Présentation au sujet: "Retour d’expérience de la mise en place de l’Agile à l’URGI"— Transcription de la présentation:

1 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

2 Qui sommes nous?

3 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

4 5 teams, 30 people

5 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

6 Contextes

7 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

8 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

9 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

10 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

11 En pratique

12 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

13 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 ( )

14 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 »

15 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

16 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

17 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

18 Bilan 4 ans de mise en place

19 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

20 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

21 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

22 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 !!

23 Remerciements Gabriel Levan Olivier Inizan

24 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)