IUT Lyon 1 - 20 Juin 2012



   Retours d'expériences


                             Introduction
                               à l'agilité
@Agnes_Crepet
@Morendil
@AlfredAlmendra
Idées reçues, constats classiques
Trop cher
 ● admettons à court terme, mais beaucoup plus rentable
   (investissement)
 ● non à moyen/long terme, suivi du ROI régulièrement (pour
   s’arrêter à temps)


“Scrum (ou l'agilité) ne fonctionne pas ou n’a pas fonctionné
dans mon contexte”
  ● la méthode est-il bien utilisée ? dur au départ, mais ensuite
    on s'améliore
Idées reçues, constats classiques
Exemples d’indicateurs :
 ● est-ce que PO et CP parlent de leurs problèmes aux stand
   up ?
 ● est-ce que l’estimation du RAF est collégiale ?
 ● est-ce que les rétrospectives identifient des actions d’
   amélioration pour d’autres personnes que les développeurs
   ?

Ex-DSI Boiron qui témoigne :
  Comment faire sans l’agilité ?
  Est-ce qu’il y a mieux ?
http://clacote.free.fr/ vidéo d'Agnès Crépet et Cyril Lacôte
30 minutes
Exemple de mise en oeuvre

Introduit en 2007 les méthodes agiles - DSI des laboratoires Boiron

 ● Pour les projets de refonte du Système d’information sur la base d’
   architectures contemporaines (JEE, ESB, MDM, etc.)

 ● Intérêts :
     ○ introduire des demandes d’évolutions en cours de projet
     ○ faciliter l’acceptation des nouvelles solutions informatiques par
       les utilisateurs finaux

 ● Premier « vrai » déploiement sur un projets critique (10000 jours)

 ● Agilité chez BOIRON ?
    ○ Un mix d’UP, XP et de Scrum / Kanba
Pratiques et outillages "agiles"

Processus itératif et incrémental
Recette Utilisateur à chaque fin d’itération
Stand-up quotidien / Tableau post-it
Gestion des exigences
Développement par les tests (JUNIT, DBUNIT, Mockito)
Refactoring régulier (par les patterns)
Bug Tracker (JIRA)
Intégration Continue (Maven, Jenkins, Nexus)
Agilité et UML
Comment documenter / modéliser un besoin ?

2 approches semblent opposées :

 ● l'approche Model-Driven (OMG)
      ○ modélisation UML très poussée
      ○ génération automatique de code

 ● l'approche agile
      ○ production rapide de code opérationnel (mieux que la
        doc)
      ○ minimiser la modélisation en amont
Agilité et UML
La modélisation agile peut-elle exister ?

L'agilité se passe de plus en plus d'UML

Mais Boiron a décidé néanmoins de garder UML :
 ● Traçabilité des exigences
 ● Analyse d'impact d’un changement
 ● Contrainte de validation pharmaceutique
 ● Communication inter et intra équipe

Stratégie Boiron pour pour la modélisation:
  ● Pas trop de doc
  ● Un peu d'UML

Voir :
http://www.slideshare.net/agnes_crepet/modelisation-agile-03122011
Exemple de mise en oeuvre
Des itérations d’un mois calendaire

      Mais cela peut varier en fonction des phases du projet
       Un sprint est à durée fixe en Scrum

      Kanban


Des recettes utilisateurs
à chaque fin d’itération

En période pré-production :
recette toutes les 2 / 3 semaines

Photo : Recette Utilisateur
Boiron Janvier 2010
Une itération
Backlog de produit

Les exigences, les activités
 ● En UP : Use Case (Boiron)
 ● En XP : User stories

Une entrée du backlog de produit est un Use Case UML
(inspiré d’UP)
  ● Un Use Case peut se dérouler sur 1 ou 2 itérations
            en Scrum          en Kanban

Leurs priorités sont revues à chaque itération
 ● Définies par le Product Owner
 ● Mais également par le reste de l’équipe (différent de Scrum)
Exemple de backlog Boiron
A chaque Use Case sont associées deux attributs :
  ● Une estimation en points arbitraires (on ne parle pas encore de jours)
  ● Et une priorité (métier, risque technique identifié)


La liste peut évoluer au cours
du projet, suite aux recettes
utilisateur en fin d’itération
Exemple de mise en oeuvre
Comment planifier une itération ?
Exemple de mise en oeuvre
Vie du backlog de l’itération

L'estimation du reste à faire est ajustée tous les
jours (Stand-up / JIRA)

  ● Mise à jour du travail restant quand il est mieux
    connu

N'importe qui peut ajouter, supprimer, changer la liste des tâches en stand-up

Si un travail n'est pas clair, définir une tâche avec plus de temps et la
décomposer après

                 Changement en cours d’itérations           Estimation du reste à faire
   Scrum                                            Utilisation de Burndown Charts
                                                    avec mise à jour quotidienne

   Boiron
                        (comme Kanban)              Utilisation de JIRA (quotidien)

#11 rex

  • 1.
    IUT Lyon 1- 20 Juin 2012 Retours d'expériences Introduction à l'agilité @Agnes_Crepet @Morendil @AlfredAlmendra
  • 2.
    Idées reçues, constatsclassiques Trop cher ● admettons à court terme, mais beaucoup plus rentable (investissement) ● non à moyen/long terme, suivi du ROI régulièrement (pour s’arrêter à temps) “Scrum (ou l'agilité) ne fonctionne pas ou n’a pas fonctionné dans mon contexte” ● la méthode est-il bien utilisée ? dur au départ, mais ensuite on s'améliore
  • 3.
    Idées reçues, constatsclassiques Exemples d’indicateurs : ● est-ce que PO et CP parlent de leurs problèmes aux stand up ? ● est-ce que l’estimation du RAF est collégiale ? ● est-ce que les rétrospectives identifient des actions d’ amélioration pour d’autres personnes que les développeurs ? Ex-DSI Boiron qui témoigne : Comment faire sans l’agilité ? Est-ce qu’il y a mieux ?
  • 4.
    http://clacote.free.fr/ vidéo d'AgnèsCrépet et Cyril Lacôte 30 minutes
  • 5.
    Exemple de miseen oeuvre Introduit en 2007 les méthodes agiles - DSI des laboratoires Boiron ● Pour les projets de refonte du Système d’information sur la base d’ architectures contemporaines (JEE, ESB, MDM, etc.) ● Intérêts : ○ introduire des demandes d’évolutions en cours de projet ○ faciliter l’acceptation des nouvelles solutions informatiques par les utilisateurs finaux ● Premier « vrai » déploiement sur un projets critique (10000 jours) ● Agilité chez BOIRON ? ○ Un mix d’UP, XP et de Scrum / Kanba
  • 6.
    Pratiques et outillages"agiles" Processus itératif et incrémental Recette Utilisateur à chaque fin d’itération Stand-up quotidien / Tableau post-it Gestion des exigences Développement par les tests (JUNIT, DBUNIT, Mockito) Refactoring régulier (par les patterns) Bug Tracker (JIRA) Intégration Continue (Maven, Jenkins, Nexus)
  • 7.
    Agilité et UML Commentdocumenter / modéliser un besoin ? 2 approches semblent opposées : ● l'approche Model-Driven (OMG) ○ modélisation UML très poussée ○ génération automatique de code ● l'approche agile ○ production rapide de code opérationnel (mieux que la doc) ○ minimiser la modélisation en amont
  • 8.
    Agilité et UML Lamodélisation agile peut-elle exister ? L'agilité se passe de plus en plus d'UML Mais Boiron a décidé néanmoins de garder UML : ● Traçabilité des exigences ● Analyse d'impact d’un changement ● Contrainte de validation pharmaceutique ● Communication inter et intra équipe Stratégie Boiron pour pour la modélisation: ● Pas trop de doc ● Un peu d'UML Voir : http://www.slideshare.net/agnes_crepet/modelisation-agile-03122011
  • 9.
    Exemple de miseen oeuvre Des itérations d’un mois calendaire Mais cela peut varier en fonction des phases du projet Un sprint est à durée fixe en Scrum Kanban Des recettes utilisateurs à chaque fin d’itération En période pré-production : recette toutes les 2 / 3 semaines Photo : Recette Utilisateur Boiron Janvier 2010
  • 10.
  • 11.
    Backlog de produit Lesexigences, les activités ● En UP : Use Case (Boiron) ● En XP : User stories Une entrée du backlog de produit est un Use Case UML (inspiré d’UP) ● Un Use Case peut se dérouler sur 1 ou 2 itérations en Scrum en Kanban Leurs priorités sont revues à chaque itération ● Définies par le Product Owner ● Mais également par le reste de l’équipe (différent de Scrum)
  • 12.
    Exemple de backlogBoiron A chaque Use Case sont associées deux attributs : ● Une estimation en points arbitraires (on ne parle pas encore de jours) ● Et une priorité (métier, risque technique identifié) La liste peut évoluer au cours du projet, suite aux recettes utilisateur en fin d’itération
  • 13.
    Exemple de miseen oeuvre Comment planifier une itération ?
  • 14.
    Exemple de miseen oeuvre Vie du backlog de l’itération L'estimation du reste à faire est ajustée tous les jours (Stand-up / JIRA) ● Mise à jour du travail restant quand il est mieux connu N'importe qui peut ajouter, supprimer, changer la liste des tâches en stand-up Si un travail n'est pas clair, définir une tâche avec plus de temps et la décomposer après Changement en cours d’itérations Estimation du reste à faire Scrum Utilisation de Burndown Charts avec mise à jour quotidienne Boiron (comme Kanban) Utilisation de JIRA (quotidien)