Accueil > Méthodes Agiles > Le JUG de Lyon est agile !

Le JUG de Lyon est agile !

JUG AgilityAprès avoir rappelé les défauts d’une gestion avec un cycle en V, une courte introduction théorique à l’agilité nous a été dispensée par Agnès Crépet (Laboratoires Boiron), Laurent Caron (Interfaces Solutions) et Cyril Lacôte (Objet Direct.)

La soirée était basée sur le retour d’expérience de près de deux ans de travail avec le mélange des différentes déclinaisons de l’agilité : UP, XP, Kanban et Scrum, en particulier au sein des Laboratoires Boiron.

Je ne vais pas me lancer dans les descriptions détaillées des principes de l’agilité, de ses 12 piliers, de ses avantages,… mais plutôt détailler les ressentis de chacun autour des différents sujets qui nous ont été présentés.

La présentation commence par la description des grandes étapes de la conduite de projet agile.

Toute conduite du changement doit passer par la formation, l’adaptation à la nouvelle vision.

Avec l’exemple détaillé au cours de la soirée, les meilleures pratiques, les plus adaptées, ont été extraites des méthodes précédemment citées.

Un projet se découpe en 4 étapes :

  1. le référencement des requirements,
  2. leur découpage en cas d’utilisation,
  3. leur réalisation,
  4. leur livraison.

L’agilité peut donc être appliquée au forfait.

Les requirements et les uses cases sont alors mappés dans une matrice de traçabilité qui permet de s’assurer que tous les requirements seront couverts.

Ceci ressemble beaucoup à un cycle en V, non ! La différence réside dans les niveaux de détails des requirements, et dans la gestion de leur implémentation. En effet, l’agilité s’exprime à cette étape.

L’étape focus de la soirée, l’étape de réalisation, va être découpée en itérations.

Une itération commence par la constitution du backlog. Il s’agit d’une liste de cas d’utilisation qui seront implémentés au cours de l’itération. Ces cas d’utilisation sont choisis en collaboration avec le client (en particulier avec leur représentant).

Une itération doit être la plus courte possible. Scrum préconise des itérations à durée fixe mais on s’autorise chez Boiron des variations de quelques jours, suivant les nécessités du projet.

Autre écart chez Boiron avec le strict respect de Scrum, le backlog peut évoluer au cours du lancement même de l’itération dans la mesure où juste un macro chiffrage a été réalisé à cette étape. Introduire un use case au backlog consiste à l’analyser, à mesurer les impacts sur l’existant, en faire une macro-conception, et le découper en tâches. Ces tâches peuvent alors être référencées dans l’outil de bug tracking (et de gestion de la planification) et être affectées.

La vélocité réelle de l’équipe (tenant compte des absences) est calculée à chaque itération, et chaque développeur est considéré opérationnel à 80%. Les 20% restant permettent de planifier les stands up quotidien (15min) et surtout le refactoring du code produit.

Chaque développeur est responsabilisé. Il peut intervenir dans le chiffrage, revoir le reste à faire de ses tâches, éventuellement redistribuer ses propres tâches. L’équipe agile est pratiquement en auto gestion.

Une fois le backlog construit, le périmètre de l’itération est fixé et les développements peuvent commencer.

Les développements sont sécurisés grâce à l’approche TDD (Test Driven Development). Elle consiste à écrire les tests avant d’écrire la moindre ligne de code. La mise en place de ces tests peut se faire en collaboration avec le métier; cette étape permet de bien valider que le fonctionnement de l’application est en adéquation avec les requirements client. Ceci évite des livraisons mal ou peu testées et améliorent la relation client.

L’approche TDD aide également le refactoring de sources qui peut être réalisé de manière sécurisée. Le refactoring contribue à l’amélioration des performances de l’application, à la lisibilité du code et surtout à sa maintenance.

Ces tests font partie intégrante du projet, ils sont unitaires, automatisées et un environnement d’exécution leur est dédié. Beaucoup de frameworks sont disponibles pour faciliter la réalisation de ces tests (EasyMock en particulier, qui a été mis en œuvre au cours d’une démonstration, est très intéressant pour bouchonner toutes les dépendances d’une classe.)

L’utilisation de l’outil de construction Maven a également été décrite. Maven récupère les sources du gestionnaire de configuration SVN, télécharge les dépendances, compile, peut déployer sur des environnements différents, et exécute régulièrement les tests unitaires de manière automatisée. Il peut être couplé à des outils d’audit de code (PMD, CheckStyle, FindBugs) et d’audit de couverture de test (Cobertura,…). Il communique également sur le résultat de l’exécution des tests suites.

Avec l’approche TDD, une fois le test en échec, l’implémentation peut commencer. Le test passe alors au vert et la phase de refactoring peut commencer.

L’itération se termine, lorsqu’il ne reste plus de cas d’utilisation à implémenter. L’application est alors recettée par un groupe d’utilisateurs finaux. Des bugs remontent, sont saisis et entrent dans le workflow de l’outil de bug tracking. Leur correction peut être chiffrée et intégrée au planning de la prochaine itération.

L’utilisateur s’approprie au fur et à mesure la nouvelle version de l’application, il peut adapter ses méthodes de travail avec ce nouvel outil qui répond au mieux à ses besoins. En étant intégré à l’étape de réalisation, on ne l’enferme pas dans un tunnel pour ensuite le débarquer sur une application qui correspond mal à ces besoins.L’agilité permet de fournir ni plus ni moins que les besoins exprimés par l’utilisateur. De nouveaux besoins peuvent apparaitre, ils sont alors pondérés (par les utilisateurs) par rapport au reste des uses cases à réaliser. Le changement est assuré en douceur et dans le respect. Une fois la recette validée, l’itération se termine. La prochaine peut être lancée.

La présentation s’est terminé par des interviews filmées des différents intervenants d’un projet informatique: la DSI, les architectes, les représentants métier, les chefs de projet, les développeurs autour de l’agilité.

Chacun est pleinement satisfait de la mise en œuvre de ces méthodes pour la refonte d’une partie des applications Boiron et ne souhaite pas retourner au cycle en V.

Avec l’agilité et quelques outils on améliore grandement la satisfaction client, le travail des différentes équipes informatiques (et ainsi leur motivation), on maitrise mieux le planning et les risques.

Le DSI Boiron conclue le film, sur la réponse à la question « Êtes vous satisfait de l’agilité ? » par « Avez-vous encore mieux à nous présenter ? »

Et vous ? Qu’attendez-vous ?

  1. 21/01/2010 à 16:44 | #1

    Superbe article ! Très intéressant et bien rédigé 😉

  2. Cyril Lacote
    21/01/2010 à 18:30 | #2

    Merci Pierrette pour ce compte-rendu!
    Le film devrait être en ligne dans les jours prochains, je posterai le lien par ici.

  3. Ludovic
    23/01/2010 à 22:09 | #3

    Ouai j’attends le film avec impatience (non pas de lol ici, c’est un blog sérieux quoi!).

  4. Cyril
    26/01/2010 à 23:41 | #4

    Pierrette, encore en vacances, n’est pas là pour éditer l’article et donner le lien pour le film récemment mis en ligne, alors le voilà : http://clacote.free.fr/agilite.html

  5. Mathieu Petitdant
    11/02/2010 à 14:42 | #5

    Bel article, y aurait-il des informations chiffrées où non du gain de productivité apporté par ces méthodes ?

    Sinon attention à la terminologie! Scrum réinvente la terminologie que l’on connait(ssait) non pas pour se faire « mousser » mais bien pour marquer le changement. Ce ne sont donc pas des « use cases » qui doivent être utilisés mais des « user stories », élément beaucoup plus light en terme de fonctionnalité et surtout en quantité de doc associée.

    Merci pour le retour en tous cas !

  1. Pas encore de trackbacks