• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Méthodes agiles
 

Méthodes agiles

on

  • 1,888 views

Une présentation sur les méthodes agiles

Une présentation sur les méthodes agiles

Statistics

Views

Total Views
1,888
Views on SlideShare
1,780
Embed Views
108

Actions

Likes
3
Downloads
1
Comments
0

3 Embeds 108

http://www.mostefaiamine.com 98
http://www.linkedin.com 6
http://mostefaiamine.com 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Méthodes agiles Méthodes agiles Presentation Transcript

    • Méthodes Agiles
      Un parcours des méthodes agiles
      1
    • Introduction
      2
      Nos echecs
    • Introduction
      3
      Taux de réussite des projets
    • Introduction
      4
      Critères de réussite
    • Introduction
      5
      Autres industries : Renault Zoé (2012)
    • Introduction
      6
      Autres industries : Batman 3 (Juillet 2012)
    • Introduction
      7
      Succès d’un projet
    • Introduction
      Et notre industrie ? Quelques désastres
      • Duke Nukem n’est jamais sorti 
      • Satellite perdu de la NASA : deux modules n’utilisaient pas les mêmes unités de mesure (125 M$)
      • Panama : 8 personnes atteintes du cancer sont mortes à cause d’une erreur de calcul du dosage des radiations
      8
    • Introduction
      9
    • Introduction
      10
      Facteurs d’échec
    • Introduction
      11
      Conduite classique d’un projet
    • Introduction
      12
      Implications
    • Principes Agiles
      13
      Principes agiles
    • Principes agiles
      Manifesto agile 2001
      • 17 chefs de projets se sont réunis à l’Utah (USA)
      • Lassés par la lourdeurs des processus classiques
      • Ils ont formé l’alliance agile
      14
    • Les principes agiles
      15
    • Les principes agiles
      Individus et interactions au lieu de processus et outils
      • Les collaborateurs sont la clé du succès
      • Les « seniors » échoueront s’ils ne collaborent pas en tant qu’équipe
      • Un bon collaborateur n’est pas un forcément un bon programmeur. C’est quelqu’un qui travaille bien en équipe
      • Une surabondance d’outils est aussi mauvaise que le manque d’outils
      • Démarrer petit et investir peu au démarrage
      • Construire l’équipe c’est plus important que construire l’environnement
      16
    • Les principes agiles
      Logiciel fonctionnel au lieu de documentation massive
      • Un code sans documentation est un désastre
      • Trop de documents est pire que pas de documents
      • Difficulté à produire et à synchroniser avec le code
      • Souvent les documents sont des mensonges formels
      • Le code ne ment jamais sur lui-même
      • Produire toujours des documents aussi courts que possible
      17
    • Les principes agiles
      Collaboration du client au lieu de la négociation de contrats
      • Très difficile de décrire la totalité du logiciel depuis le début
      • Les projets réussis impliquent les clients d’une manière fréquente et régulière
      • Le client doit avoir un contact direct avec l’équipe de développement
      18
    • Les principes agiles
      Réagir aux changements au lieu de suivre un plan
      • Un logiciel ne peut pas être planifié très loin dans le futur
      • Tout change : technologie, environnement et surtout les besoins
      • Les chefs de projets classiques fonctionnent sur la base de GANTT, PERT et le système de tâches
      • Avec le temps, les diagrammes se dégradent car des tâches s’ajoutent et d’autres deviennent non nécessaires
      • Une meilleure stratégie est de planifier très court (02 semaines à 01 mois)
      • Plannings détaillés pour la semaine à venir, rigoureux pour les trois mois et très vagues au-delà
      19
    • Les principes agiles
      Les 12 principes agiles
      Toujours satisfaire le client à travers des livraisons rapides et continues
      Bien accueillir tous les changements même les tardifs
      Livrer fréquemment un système fonctionnel
      Les clients et les développeurs doivent collaborer
      Conduire le projet autour d’équipes motivées
      La meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateurs
      La première mesure d’avancement c’est un logiciel fonctionnel
      Le développement doit être durable et à un rythme constant
      La bonne conception et l’excellence technique augmentent l’agilité
      Simplifier au maximum
      Les meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles-mêmes
      L’équipe s’améliore d’une manière autonome et régulière
      20
    • Méthodologie XP
      21
      Méthodologie xp
    • La méthodologie XP
      22
    • Planification Agile
      23
      Planification agile
    • Planification Agile
      Planification
      • Les développeurs et le client discutent du système (identifier les fonctions)
      • Ne pas chercher à avoir une liste exhaustive des fonctions
      • Chaque fonction est traduite en user stories
      • Les user stories sont écrites sur des cartes (ou équivalent)
      • Les développeurs collaborent à estimer les user stories
      • L’estimation ne se fait pas en temps mais en points
      • Une user stories de 8 points durera logiquement deux fois plus qu’une user stories de 1 point
      • Les user stories trop longues sont réparties en plusieurs user stories
      • Une user story trop petite est fusionnée avec une autre
      • La fusion et la division n’est pas une science exacte en terme de points
      24
    • Planification Agile
      Planification
      • Chaque itération un ensemble de user stories sont terminées
      • La vélocité est le nombre de points finalisés durant la semaine ou l’itération
      • Après 03 ou 04 semaines, l’équipe a une idée de sa vélocité
      • Au début, la vélocité est très imprécise puis se stabilise dans le temps
      • Après la stabilisation de la vélocité, on peut déduire la durée d’un release en terme d’itérations
      • Une user story n’est finalisée que si elle passe tous ses tests d’acceptation
      25
    • Planification Agile
      Planification
      • Les développeurs divisent les user stories en tâches
      • Les tâches sont créées et enregistrée
      • Chaque développeur s’inscrit à une ou plusieurs tâches durant l’itération
      • Chaque développeur connaît le nombre de points de son itération précédente
      • Il prend des tâches jusqu’à atteindre ce nombre de points
      • Si des tâches restent, les développeurs négocient pour prendre le reste
      26
    • Planification Agile
      Planification
      • Au milieu d’une itération, une réunion entre développeurs est organisée
      • Théoriquement, la moitié des user stories devraient êtres terminées
      • Dans le cas contraire, l’équipe se réorganise pour assurer une bonne terminaison de l’itération
      27
    • Planification Agile
      Planification
      • A chaque fin d’itération le produit est montré et évalué par le client
      • Le client suit de près l’évolution du produit
      28
    • Planification Agile
      Planification
      • Le suivi par des outils informatiques
      • Project ou Excel sont des exemples d’outils de suivi
      • TFS est un excellent support de suivi
      29
    • Introduction
      30
    • Planification Agile
      31
      Conception agile
    • Conception agile
      Qu’est-ce que la conception agile ?
      • L’analyse concerne le « quoi », la conception concerne le « comment »
      • Les diagrammes UML n’est pas la conception mais une partie de la conception
      • La conception est un concept abstrait
      • Le code EST la conception
      • La conception agile est l’application continue des principes agiles
      32
    • Conception agile
      Pourquoi une bonne conception
      • Livrer plus rapidement
      • Etre prêt au changement
      • Gérer la complexité
      33
    • Introduction
      34
    • Conception agile
      Symptômes d’une mauvaise conception
      35
    • Conception agile
      Rigidité
      • Difficile à faire évoluer même avec de petits changements
      • Difficile de se retrouver dans une structure complexe
      • Difficile voire impossible d’estimer les changements
      • L’impact du changement est imprévisible
      36
    • Conception agile
      Fragilité
      • Plusieurs modules tombent alors qu’un seul a été modifié
      • Régler un problème engendre la création d’autres problèmes
      37
    • Conception agile
      Immobilité
      • Une conception est immobile si elle contient des parties réutilisables mais l’isolement de ces parties est à la fois difficile et risqué
      38
    • Conception agile
      Viscosité
      • Viscosité du logiciel :lorsque les changements impliquant le changement de la conception sont plus facile à faire que ceux qui ne l’impliquent pas
      • Viscosité de l’environnement : compilation lente, check-in fastidieux,….
      39
    • Conception agile
      Complexité inutile
      • Souvent causée par l’anticipation
      • L’anticipation conduit souvent à l’effet inverse
      40
    • Conception agile
      Répétition inutile
      • Abuser du copier-coller
      • Même code mais sous différentes formes
      41
    • Conception agile
      Opacité
      • Code et structure difficile à comprendre
      • Les développeurs doivent se mettre à la place des lecteurs
      42
    • Conception agile
      Causes d’une mauvaise conception
      • Dépendance incorrecte entre les modules
      • Manque de vision
      43
    • Conception agile
      Causes d’une bonne conception
      • Haute cohésion
      • Couplage moindre
      44
    • Conception agile
      Principes de conception agile
      45
    • SRP
      Single-ResponsibilityPrinciple
      • Cohésion des fonctions
      • Chaque responsabilité est un axe de changement
      46
    • SRP
      Exemple de violation de SRP
      47
    • SRP
      Amélioration pour prendre en considération le SRP
      48
    • SRP
      Exemple de violation de SRP
      49
    • SRP
      Amélioration SRP
      50
    • SRP
      Single-ResponsibilityPrinciple
      • Il faut apprendre à faire la balance entre SRP et la complexité du système
      • Ajouter la persistance dans les entités métier est une violation du SRP
      51
    • OCP
      Open – ClosedPrinciple
      • Les entités logicielles doivent être fermées à la modification, ouvertes à l’extension
      • Un changement sur un système mal conçu conduit à une cascade d’effets sur des modules dépendants
      52
    • OCP
      Open – ClosedPrinciple
      • Comment fermer la modification et ouvrir l’extension  abstraction
      • Abstraction  classes abstraites et / ou interfaces
      53
    • OCP
      Exemple
      54
    • OCP
      Exemple
      55
    • OCP
      Exemple
      56
    • LCP
      LCP – The Liskov Substitution Principle
      • L’héritage est une solution à OCP mais comment réguler l’héritage ?
      • Principe : Les sous-types doivent être des substituts pour leur ancêtres
      57
    • LCP
      Exemple
      58
    • LCP
      Exemple – Problème LCP
      59
    • LCP
      LCP – Remèdes
      • Eviter une vision isolatrice des entités
      • Avoir une vision plus globale et plus anticipative
      60
    • DIP
      Dependency Inversion Principle
      • Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau
      • Les abstractions ne doivent pas dépendre des détails, Les détails doivent dépendre des abstractions
      61
    • DIP
      DIP - Exemple
      62
    • Conception Agile
      63
    • ISP
      Interface SegregationPrinciple
      • Les clients ne doivent pas être forcées à dépendre de méthodes qu’elles n’utilisent pas
      64
    • ISP
      ISP- Exemple
      65
    • ISP
      ISP- Exemple
      66
    • Refactoring
      67
      refactoring
    • Refactoring
      Refactoring
      Le refactoring est le processus d’améliorer la structure interne du code sans en altérer le fonctionnement
      68
    • Refactoring
      Refactoring
      Un module de code a les fonctions suivantes :
      • Assurer la fonction pour laquelle il a été créé
      • Permettre l’évolution
      • Communiquer avec ses lecteurs / utilisateurs
      69
    • Refactoring
      Refactoring avec VS2010
      70
    • Refactoring
      71
    • TDD
      72
      Test-drivendevelopment
    • TDD
      Qu’est-ce que le TDD
      Conduire tous nos développements par les tests. Le test doit être le vecteur de la conception.
      TDD fait partie des meilleures pratiques agiles car la qualité d’une itération sous-entend le passage de tous les tests unitaires et les tests d’acceptation
      73
    • TDD
      Etapes du TDD
      74
    • TDD
      Intérêts
      • Ecrire le test avant le programme permet une meilleure visibilité sur le résultat
      • Anticipe la conception
      • Augmente la confiance en soi
      • Estimer l’état d’avancement
      75
    • TDD
      76
    • TDD
      Problème avec les grands systèmes
      • Des modules peuvent dépendre d’autres systèmes non encore implémentés
      • Solution Mock
      77
    • TDD
      MockObjects
      • Les objets mock miment le comportement de vrais objets
      • Exemple : tests de crash de voitiure (faux conducteur)
      78
    • TDD
      MockObjects - Utilisation
      Les mocks sont utilisés dans les cas suivants :
      • Les objets renvoient des résultats non déterministes
      • Des états difficiles à reproduire (par exemple panne réseau)
      • Des objets pour des tests uniquement
      • Des objets qui n’existent pas encore ou qui doivent évoluer
      79
    • TDD
      80