a l i m e n t a t i o n a g r i c u l t u r e e n v i r o n n e m e n t the urgi unit retour...

A L I M E N T A T I O N

A G R I C U L T U R E

E N V I R O N N E M E N TThe URGI unit

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

Hadi Quesneville

Qui sommes nous?Qui sommes nous?

2

Hadi Quesneville

URGI: Unité de Recherche en Génomique-Info

3

Hadi Quesneville

5 teams, 30 people

4

Hadi Quesneville 5

Platform missionsPlatform missions

Hadi Quesneville

ContextesContextes

6

Hadi Quesneville

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

7

Hadi Quesneville

Contraintes• Utilisateurs

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

8

Hadi Quesneville

Difficultés

• Domaine en constante évolution Adaptation rapide aux besoins

• Connaissances multiples Biologie Bioinformatique Informatique

• Turn –over des CDD Maintien des outils développés

9

Binomage

Itérations courtes

Agile

Hadi Quesneville

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

10

Hadi Quesneville

En pratiqueEn pratique

11

Hadi Quesneville

Equipes agiles

• Transversales aux équipes thématiques Ressources génétique, Ressources génomique, Génomique fongique, Dynamique des génomes, Support transversal

• 3 équipes Système d’information Pipelines Data

12

Hadi Quesneville

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)

13

Hadi Quesneville

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 »

14

Hadi Quesneville

Pratiques• Features suivie dans Jira

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

15

Hadi Quesneville

Les réunions• Stand-up tous les jours

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

16

Hadi Quesneville

Le budget• Ressources apportées par chaque projet

% 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

17

Hadi Quesneville

BilanBilan

• 4 ans de mise en place

18

Hadi Quesneville

Points positifs• Satisfaction des développeurs

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

19

Hadi Quesneville

Points négatifs• Personnes hors équipe

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

20

Hadi Quesneville

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

21

Hadi Quesneville

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

22

Hadi Quesneville

Remerciements

23

Gabriel Levan Olivier Inizan

Hadi Quesneville

Remerciements

24