14
Introduction à l'agilité IUT Lyon 1 - 20 Juin 2012 @Agnes_Crepet @Morendil @AlfredAlmendra Retours d'expériences

#11 rex

Embed Size (px)

Citation preview

Page 1: #11 rex

Introduction à l'agilité

IUT Lyon 1 - 20 Juin 2012

@Agnes_Crepet@Morendil @AlfredAlmendra

Retours d'expériences

Page 2: #11 rex

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

Page 3: #11 rex

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 ?

Page 4: #11 rex

http://clacote.free.fr/ vidéo d'Agnès Crépet et Cyril Lacôte30 minutes

Page 5: #11 rex

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

Page 6: #11 rex

Pratiques et outillages "agiles"

Processus itératif et incrémentalRecette Utilisateur à chaque fin d’itérationStand-up quotidien / Tableau post-itGestion des exigencesDéveloppement par les tests (JUNIT, DBUNIT, Mockito)Refactoring régulier (par les patterns)Bug Tracker (JIRA)Intégration Continue (Maven, Jenkins, Nexus)

Page 7: #11 rex

Agilité et UMLComment 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

Page 8: #11 rex

Agilité et UMLLa 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

Page 9: #11 rex

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 UtilisateurBoiron Janvier 2010

Page 10: #11 rex

Une itération

Page 11: #11 rex

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)

Page 12: #11 rex

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 coursdu projet, suite aux recettesutilisateur en fin d’itération

Page 13: #11 rex

Exemple de mise en oeuvreComment planifier une itération ?

Page 14: #11 rex

Exemple de mise en oeuvreVie 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 Chartsavec mise à jour quotidienne

Boiron(comme Kanban)

Utilisation de JIRA (quotidien)