Le développement
Agile




                                 Un aperçu



© Copyright Pyxis Technologies
Qui suis-je

     !  Dominic Danis
     !  Directeur du produit Urban Turtle à Pyxis
        Technologies, firme spécialis...
Petite mise en garde

     !  Scrum ne donne pas la recette secrète du
       développement logiciel
     !  Scrum fournit...
Quels problèmes rencontrons-nous ?


       Succès: Le projet est réalisé selon le
       budget et les délais convenus. I...
Livrons-nous du logiciel de qualité?




5
5   © Copyright Pyxis Technologies
Nos solutions sont-elles utiles?
      Statistiques de l’industrie




                                     Jim Johnson, S...
Peut-on livrer plus rapidement ?




                                     d'après les travaux d'Hakan
                    ...
Problèmes de communication?

                                     !   Le développement logiciel est
                      ...
Alors pourquoi le développement
    Agile?
    1.  Pour satisfaire rapidement notre client avec des
        solutions logi...
Manifeste Agile
      Nous sommes à découvrir de meilleures façons de
      développer des logiciels en aidant les autres ...
Principes Agiles (1 de 2)

      1.  Notre première priorité est de satisfaire le client en
          livrant tôt et régul...
Principes Agiles (2 de 2)

      6.  Une attention continue à l’excellence technique et à la
          qualité de la conce...
Méthodologies Agiles

      !      Scrum
      !      Extreme Programming (XP)
      !      Adaptive Software Development
...
Pilier 1




                                  Le processus empirique


 © Copyright Pyxis Technologies
Une question de bons sens




15   © Copyright Pyxis Technologies
Processus empirique :
     le squelette de Scrum




                                      Vision



16   © Copyright Pyxi...
Itération : le sprint
            Planification de                                               Démo et
                 ...
Pilier 2




                  La valeur d’affaire en avant plan


 © Copyright Pyxis Technologies
La valeur d’affaires au premier plan
                     Processus en
                                                   ...
Responsable de produit
     (product owner)
     !  Un bon responsable de produit doit :
            •    Connaître la val...
Gestion des exigences :
     le carnet du produit

                                          Chaque itération met en œuvre...
Granularité des exigences
                                          Des détails sont ajoutés au fil du temps




         ...
Pilier 3




La livraison d’incréments de produit terminés


 © Copyright Pyxis Technologies
Comment faire du développement
     incrémental?




24   © Copyright Pyxis Technologies
Processus en cascade


 !   « Ça ne fonctionne jamais! » —
     Brian Marrick
 !   C’est un processus imprévisible,
      ...
Processus Scrum




     !   C'est un processus prévisible, ce qui aide à prendre des décisions éclairées.
     !   La dat...
Définir « terminé »

      !  La définition de « terminé » capture la capacité
         technique actuelle de l'équipe
   ...
Étendre la définition de « terminé »

      !     Conception révisée
      !     Code remanié
      !     Code révisé
    ...
Suivi de l’avancement




     !   La courbe du travail restant à faire permet de déterminer la date
        probable de l...
Pilier 4




                                  L'équipe autogérée


 © Copyright Pyxis Technologies
Équipe Scrum

      !  Une équipe Scrum
         comprend
         uniquement les
         personnes suivantes :
         ...
Caractéristiques d’une équipe
       Scrum
      !  S’auto-organise
      !  Est pluridisciplinaire et ne comporte pas de ...
Le Scrum Master n'est pas un chef de
     projet


                       Imposer        Faire confiance




             ...
Mêlées quotidiennes

      !  Paramètres :
              •    Tous les jours
              •    Durée limitée à 15 minutes...
Questions sur les mêlées quotidiennes

      !  Pourquoi tous les jours?
              •  “Comment un projet peut-il avoir...
Revue du sprint

      !  L’équipe présente ce qui a été réalisé pendant le sprint
      !  La présentation comporte une d...
Rétrospectives du sprint
     !  Dans le but d’améliorer le processus
             •  À la fin de chaque sprint
          ...
La transition




                                  Du traditionnel vers l’agilité



 © Copyright Pyxis Technologies
Erreurs communes

      1.  Faire de l’Agile « pour être dans le vent »
      2.  Faire du développement itératif et non i...
Références – Principes




40   © Copyright Pyxis Technologies
Références – Gestion de projet Agile




41   © Copyright Pyxis Technologies
Références – Collaboration




42   © Copyright Pyxis Technologies
Références – Analyse et modélisation




43   © Copyright Pyxis Technologies
Références – Rapport d’expérience




                             http://www.infoq.com/minibooks/scrum-xp-from-the-trench...
Prochain SlideShare
Chargement dans…5
×

Communaute dot net Montreal juin2010

907 vues

Publié le

Publié dans : Technologie, Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
907
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
15
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Communaute dot net Montreal juin2010

  1. 1. Le développement Agile Un aperçu © Copyright Pyxis Technologies
  2. 2. Qui suis-je !  Dominic Danis !  Directeur du produit Urban Turtle à Pyxis Technologies, firme spécialisée dans le développement, la formation, le coaching ainsi que le développement de produit agile. !  ddanis@pyxis-tech.com 2 © Copyright Pyxis Technologies
  3. 3. Petite mise en garde !  Scrum ne donne pas la recette secrète du développement logiciel !  Scrum fournit simplement les mécanismes permettant de mettre en lumière les problèmes et difficultés que nous rencontrons dans nos projets de développement logiciel afin d’être en mesure de les régler !  Une équipe Scrum apprend à s'améliorer continuellement 3 © Copyright Pyxis Technologies
  4. 4. Quels problèmes rencontrons-nous ? Succès: Le projet est réalisé selon le budget et les délais convenus. Il comporte les fonctions et caractéristiques demandées. Défi: Le projet est en retard, le budget a été dépassé ou il manque certaines fonctions et caractéristiques demandées. Échec: Le projet a été arrêté avant sa fin ou le logiciel développé a été livré CHAOS Report du Standish Group, 2003 mais n’a jamais été utilisé. 4 4 © Copyright Pyxis Technologies
  5. 5. Livrons-nous du logiciel de qualité? 5 5 © Copyright Pyxis Technologies
  6. 6. Nos solutions sont-elles utiles? Statistiques de l’industrie Jim Johnson, Standish Group, XP 2002 6 © Copyright Pyxis Technologies
  7. 7. Peut-on livrer plus rapidement ? d'après les travaux d'Hakan Herdogmus, GUAM 2005 7 © Copyright Pyxis Technologies
  8. 8. Problèmes de communication? !   Le développement logiciel est un jeu coopératif d’invention et de communication. Il est apparenté au développement de produit. !   Les sources de problème dans notre profession sont les gens et les interactions dysfonctionnelles plutôt que les processus et les outils. Comment communiquez-vous? 8 © Copyright Pyxis Technologies
  9. 9. Alors pourquoi le développement Agile? 1.  Pour satisfaire rapidement notre client avec des solutions logicielles utiles 2.  Pour augmenter la qualité 3.  Pour faire face à la complexité 4.  Pour réduire les inefficacités 5.  Pour éviter les longues périodes de stabilisation en fin de projet 6.  Pour maximiser la collaboration 7.  Pour augmenter la motivation et l’engagement des individus 8.  Pour avoir du plaisir au travail  9 © Copyright Pyxis Technologies
  10. 10. Manifeste Agile Nous sommes à découvrir de meilleures façons de développer des logiciels en aidant les autres et en développant nous aussi. Par ce travail, nous en sommes venu à valoriser ce qui suit : !   Personnes et interactions plutôt que processus et outils !   Logiciel fonctionnel plutôt que documentation complète !   Collaboration avec le client plutôt que négociation de contrat !   Réaction au changement plutôt que suivi d’un plan rigide En fait, bien que les éléments de droite soient importants, ceux de gauche le sont encore plus. 10 10 © Copyright Pyxis Technologies
  11. 11. Principes Agiles (1 de 2) 1.  Notre première priorité est de satisfaire le client en livrant tôt et régulièrement du logiciel utile 2.  Le changement est bienvenu, même tardivement dans le développement. Les processus Agiles exploitent le changement comme avantage compétitif pour le client 3.  Le logiciel fonctionnel est la principale façon de mesurer le progrès 4.  Les gens d’affaires et les développeurs doivent collaborer quotidiennement, et ce, tout au long du projet 5.  La méthode la plus efficace de transmettre l’information est une conversation face-à-face 11 11 © Copyright Pyxis Technologies
  12. 12. Principes Agiles (2 de 2) 6.  Une attention continue à l’excellence technique et à la qualité de la conception améliore l’Agilité 7.  La simplicité — l’art de maximiser la quantité de travail à ne pas faire — est essentielle 8.  Les meilleures architectures, spécifications et conceptions émergent d’équipes qui s’auto-organisent 9.  Agile favorise le développement à un rythme normal 10. Régulièrement, l’équipe fait une réflexion sur les façons de devenir plus efficace, s’ajuste et modifie son comportement en conséquence 12 12 © Copyright Pyxis Technologies
  13. 13. Méthodologies Agiles !  Scrum !  Extreme Programming (XP) !  Adaptive Software Development !  Crystal Clear !  Feature Driven Development !  Dynamic Systems Development Method (DSDM) !  MSF for Agile Software Development !  RUP (Agile RUP—AUP) 13 13 © Copyright Pyxis Technologies
  14. 14. Pilier 1 Le processus empirique © Copyright Pyxis Technologies
  15. 15. Une question de bons sens 15 © Copyright Pyxis Technologies
  16. 16. Processus empirique : le squelette de Scrum Vision 16 © Copyright Pyxis Technologies
  17. 17. Itération : le sprint Planification de Démo et Mêlée quotidienne sprint rétrospective (max. 15 min.) (max. 1 jour) (max. 1 jour) 1 2 3 4 5 6 7 n Développement : Conception, code, test, documentation Sprint de 30 jours d’effort soutenu et ciblé (focused) 17 © Copyright Pyxis Technologies
  18. 18. Pilier 2 La valeur d’affaire en avant plan © Copyright Pyxis Technologies
  19. 19. La valeur d’affaires au premier plan Processus en Processus cascade Scrum Exigences Coût Calendrier Contraintes S'appuie sur Contraintes la valeur ou S'appuie vision sur le plan Estimation Coût Calendrier Fonctionnalités Du plan découle De la vision découle les estimations relatives au les estimations relatives coût et au calendrier. aux fonctionnalités. Estimations 19 © Copyright Pyxis Technologies
  20. 20. Responsable de produit (product owner) !  Un bon responsable de produit doit : •  Connaître la valeur commerciale du produit •  Avoir le pouvoir de réunir des intérêts et désirs variés •  Être disponible •  Diriger une équipe de gestion de produit !  Ses responsabilités sont : •  Communiquer la vision •  S’approprier les spécifications •  Évaluer les incréments du produit •  Collaborer avec l’équipe de développement (le plus possible) •  Collaborer avec l’équipe de gestion du produit (le plus possible) 20 20 © Copyright Pyxis Technologies
  21. 21. Gestion des exigences : le carnet du produit Chaque itération met en œuvre les exigences prioritaires. Chaque nouvelle exigence est insérée dans la liste selon sa priorité. Il est possible en tout temps de changer l’ordre de priorité des exigences. Les exigences peuvent être supprimées en tout temps. 21 © Copyright Pyxis Technologies
  22. 22. Granularité des exigences Des détails sont ajoutés au fil du temps Épisodes Scénarios Vision Tâches 6 mois 2-3 mois 1 mois Implantation Horizon de prévisibilité 22 © Copyright Pyxis Technologies
  23. 23. Pilier 3 La livraison d’incréments de produit terminés © Copyright Pyxis Technologies
  24. 24. Comment faire du développement incrémental? 24 © Copyright Pyxis Technologies
  25. 25. Processus en cascade !   « Ça ne fonctionne jamais! » — Brian Marrick !   C’est un processus imprévisible, ce qui cause des surprises, donc de l’insatisfaction. 25 © Copyright Pyxis Technologies
  26. 26. Processus Scrum !   C'est un processus prévisible, ce qui aide à prendre des décisions éclairées. !   La date est fixée. Que doit-on inclure dans le produit ? !   Le produit est en état d'être déployé à la fin de chaque sprint. 26 © Copyright Pyxis Technologies
  27. 27. Définir « terminé » !  La définition de « terminé » capture la capacité technique actuelle de l'équipe !  Avec le temps, la définition de « terminé » devrait s'étendre à toutes les activités nécessaires à la livraison en production !  Le travail qui n'est pas couvert pas la définition de « terminé » (travail « non terminé ») doit être identifié et porté au carnet de produit !  Tout élément qui ne respecte pas la définition de « terminé » n'est pas présenté au directeur de produit en fin de sprint 27 © Copyright Pyxis Technologies
  28. 28. Étendre la définition de « terminé » !  Conception révisée !  Code remanié !  Code révisé !  Tests unitaires !  Tests intégrés !  Tests de recette !  Tests de performance !  Tests d'ergonomie !  Documentation utilisateur !  Déploiement en pré-production !  Acceptation par les utilisateurs 28 © Copyright Pyxis Technologies
  29. 29. Suivi de l’avancement !   La courbe du travail restant à faire permet de déterminer la date probable de livraison 29 © Copyright Pyxis Technologies
  30. 30. Pilier 4 L'équipe autogérée © Copyright Pyxis Technologies
  31. 31. Équipe Scrum !  Une équipe Scrum comprend uniquement les personnes suivantes : •  un responsable de produit •  un ScrumMaster •  des « équipiers » 31 © Copyright Pyxis Technologies
  32. 32. Caractéristiques d’une équipe Scrum !  S’auto-organise !  Est pluridisciplinaire et ne comporte pas de rôles prédéterminés !  Compte 7 membres (+/- 2) !  Est responsable de son engagement !  Possède l’autorité nécessaire pour agir de manière à respecter ses engagements !  Travaille dans des locaux ouverts et avoisinants !  Résout ses propres conflits !  Observe des règles de base de fonctionnement et de comportement 32 © Copyright Pyxis Technologies
  33. 33. Le Scrum Master n'est pas un chef de projet Imposer Faire confiance Contrôler Faciliter Diriger Accompagner 33 © Copyright Pyxis Technologies
  34. 34. Mêlées quotidiennes !  Paramètres : •  Tous les jours •  Durée limitée à 15 minutes •  Tout le monde debout •  Pas de résolution de problèmes !  Trois questions : 1.  Qu’ai-je fait hier? 2.  Quels ont été les obstacles rencontrés? 3.  Qu’est-ce que je compte faire aujourd’hui? !  Les membres d’équipes et personnes externes sont invités •  Permet d’éviter des réunions inutiles !  Seuls les membres d’équipe peuvent s’exprimer 34 © Copyright Pyxis Technologies
  35. 35. Questions sur les mêlées quotidiennes !  Pourquoi tous les jours? •  “Comment un projet peut-il avoir un an de retard?” •  “Un jour à la fois.” –  Fred Brooks, The Mythical Man-Month. !  Est-ce que les mêlées quotidiennes peuvent être remplacées par des rapports d’activité envoyés par courriel? •  Non, non et NON! •  L’équipe entière possède une vision complète actualisée quotidiennement •  Une pression par les pairs incite à faire ce que nous avons dit que nous ferions 35 © Copyright Pyxis Technologies
  36. 36. Revue du sprint !  L’équipe présente ce qui a été réalisé pendant le sprint !  La présentation comporte une démonstration des nouvelles fonctionnalités ou de l’architecture •  Ce qui n’est pas complété n’est pas démontré! !  Revue informelle •  Ne pas dépasser 2 heures de préparation !  Participants •  Propriétaire du produit •  Clients •  Management •  Équipe 36 © Copyright Pyxis Technologies
  37. 37. Rétrospectives du sprint !  Dans le but d’améliorer le processus •  À la fin de chaque sprint •  Le ScrumMaster est facilitateur !  Évaluation de ce qui a bien été et ce qui devrait être amélioré !  Le ScrumMaster établit la priorité des améliorations avec l’aide de l’équipe •  L’équipe conçoit des solutions aux éléments de haute priorité •  2-3 max! •  L’équipe met les solutions en œuvre !  L’équipe s’approprie le processus 37 © Copyright Pyxis Technologies
  38. 38. La transition Du traditionnel vers l’agilité © Copyright Pyxis Technologies
  39. 39. Erreurs communes 1.  Faire de l’Agile « pour être dans le vent » 2.  Faire du développement itératif et non incrémental 3.  Commencer à sprinter seulement lorsque tous les besoins sont recueillis 4.  Effectuer des « mini waterfall » 5.  Laisser les spécialistes travailler en silo 6.  Avoir un responsable de produit qui ne s’implique pas suffisamment 7.  Ne pas partager une vision commune de « terminé » 8.  Ne pas travailler en équipe 39 © Copyright Pyxis Technologies
  40. 40. Références – Principes 40 © Copyright Pyxis Technologies
  41. 41. Références – Gestion de projet Agile 41 © Copyright Pyxis Technologies
  42. 42. Références – Collaboration 42 © Copyright Pyxis Technologies
  43. 43. Références – Analyse et modélisation 43 © Copyright Pyxis Technologies
  44. 44. Références – Rapport d’expérience http://www.infoq.com/minibooks/scrum-xp-from-the-trenches 44 © Copyright Pyxis Technologies

×