• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4
 

Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4

on

  • 2,416 views

Présentation Générale sur l'agilité et les bonnes pratiques

Présentation Générale sur l'agilité et les bonnes pratiques

Statistics

Views

Total Views
2,416
Views on SlideShare
2,416
Embed Views
0

Actions

Likes
2
Downloads
93
Comments
0

0 Embeds 0

No embeds

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

Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4 Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4 Presentation Transcript

  • Industrialisation du logiciel Introduction et bonnes pratiques Emmanuel HUGONNET Architecte Technique / Expert Java EE http://www.ehsavoie.com e [email_address] +334 76 24 86 58 17 novembre 2008
    • Support en version 1.4
  • Critères d’appréciation selon les profils Utile Evolutif Maintenable Exploitable Ergonomique Performant Ouvert Fiable Utilisateur Développeur Marketing Exploitation Perception des critères de qualité
  • Lancer un projet
    • Une équipe de taille raisonnable:
      • Entre et
    • Munie des compétences adaptées
      • Spectre nécessaire couvert
      • Formations prévues en amont
    • Stable et disponible
      • Peu de mouvement
      • Pas à 50% sur autre chose
    • Suffisamment expérimentée
      • 50% avec une expérience >= 3 ans (et encore mieux si 1 personne avec 6 – 7 ans d’expérience)
  • Organiser l’équipe
    • Séparer les rôles (dans la mesure du possible)
      • D’organisation (Chef de projet)
      • Technique(Architecte, Expert)
      • Fonctionnel (Utilisateur, Expert)
    • Privilégier les tâches de support
      • L’encadrement doit être disponible
      • Il est d’abord là pour répondre aux questions
    • Favoriser le travail d’équipe:
      • Implication
      • Communication
      • Appropriation
  • Protéger l’équipe
  • Dynamiser l’équipe
    • Privilégier la proximité :
      • un seul lieu de travail spacieux et agréable
    • Impliquer les utilisateurs :
      • Travailler près d’eux.
    • Formaliser la mise en commun :
      • Réunion ‘debout’ d’un quart d’heure quotidienne
      • Réunion d’avancement hebdomadaire
      • Réunion d’itération (mensuelle)
  • Pourquoi un changement de mentalité est il nécessaire ?
  • Agilité
    • Les principes
      • Parier sur les hommes et la communication plutôt que sur les processus et l’outillage.
      • Ecrire du logiciel qui fonctionne
      • Collaborer avec l’utilisateur plutôt que d’avoir une relation contractuelle
      • Réagir et d’adapter plutôt que de suivre un plan prédéfini
      • Un code professionnel
    • Les bonnes pratiques
      • Cycle itératif et incrémental
      • Proximité avec l’utilisateur
      • Intégration continue
      • Tests exhaustifs et systématiques
      • Gestion continue des évolutions
  • Pratique de l’XP
  • Le cycle itératif 1 ère Itération 2 ème Itération 3 ème Itération
  • Le cycle itératif
    • Réduction des risques
      • Lancer les items les plus risqués le plus tôt possible
      • Mettre en œuvre le plus rapidement possible
    • S’adapter aux changements
      • Être réactif par rapport aux demandes des utilisateurs
    • Eviter l’effet tunnel
      • Valider qu’utilisateurs et développeurs ont la même vision
      • Démo de fin d’itération qui force à avoir un logiciel qui fonctionne et qui permet de prendre du recul pour l’itération suivante
  • S’outiller
    • Pour faire vivre le projet
      • Communication (forum, mailing list, Jabber …)
      • Documentation (wiki, Maven site, ….)
      • Gestion des anomalies (Trac, Bugzilla, …)
      • Gestion des tâches
    • Pour développer
      • Environnement de développement (IDE et plugins)
      • Outil de build (Maven, Ant, …)
      • Plate-forme d’intégration Continue (Hudson, Continuum, …)
      • Plate-forme de validation
  • Intégration Continue Développeur Hudson Intégration Continue Métriques Anomalies
  • Définir des actions Qualité
    • Relecture du code (au premier commit par exemple) par un pair.
    • Revue de code régulière au cours des itérations par le responsable qualité.
    • Audit(au hasard) par une personne extérieure au projet
  • Bonnes pratiques
    • Reconnaître la qualité de ce qui est fait
    • Ne pas oublier l’objectif qui est d’améliorer, de trouver une solution et non de critiquer.
    • Ne pas s’acharner à trouver la faute et à critiquer les individus
    • Ne pas alourdir les méthodes de travail
  • Gérer les exigences
    • Parler aux utilisateurs
      • Document de spécifications fonctionnelles
      • Maquette
      • Story board
      • Prototype technique
      • Prototype fonctionnel
      • Portail projet
  • Tracer les évolutions
    • Pourquoi ?
      • Pour cibler les campagnes de tests
      • Pour rechercher les éventuelles régressions
      • Pour ne pas ré implémenter les anciennes anomalies
    • Quand ?
      • Au cours des itérations
      • Pendant la maintenance
    • Comment ?
      • Outil de gestion des exigences
      • Outils de gestion des sources
      • Outils de gestion des anomalies
      • Release notes
  • Concevoir et développer
    • Architecture fonctionnelle
      • Processus métier
      • Découpage en modules fonctionnels
    • Architecture technique
      • Découpage en couches
      • Typologie des composants
      • Choix des technologies
    • L’architecture permet
      • De structurer et d’organiser
      • D’affronter rapidement le risque
      • De fournir un exemple à suivre
      • De prouver la faisabilité
  • Découpage
    • Utiliser une architecture simple
      • Le 2-tiers suffit souvent
      • Bien penser l’usage de frameworks ‘maison’
    • Découper l’application en modules
      • Par couche
      • Par sous système fonctionnel
    • Gérer les dépendances entre modules (JDepend)
      • Pas de dépendances circulaires
      • Réduire au maximum les dépendances
      • Utiliser l’IoC
      • Utiliser des interfaces
  • Qu’est ce qu’une bonne conception ?
    • Distribuer les données et les traitements
      • De manière homogène (éviter les objets sans mémoire et sans intelligence: modèle anémique)
      • Cohérente : données et leurs traitements doivent être regroupés
    • Cela permet
      • Une bonne encapsulation
      • De remplacer un élément
      • De réduire l’impact d’une modification
  • Comment faire une bonne conception ?
    • Plusieurs façons
      • Par essai / erreur
      • Au contact d’experts
      • En formalisant l’expertise (design pattern)
    • Qu’est ce qu’un design pattern?
      • Une paire problème / solution
      • Réunis en catalogue (Gof, …)
      • Un vocabulaire
  • Les bonnes pratiques de développement (1/3)
    • Développement par l’exemple
      • L’expert construit un exemple complet que les développeurs reprennent
    • Pair programming
      • Deux développeurs : l’un qui guide et l’autre qui exécute ce qui permet une revue de code automatique (très pratique en cas de nouvelle technologie)
    • Support de proximité
      • L’expert travaille au sein du groupe
  • Les bonnes pratiques de développement (2/3)
    • Solliciter si nécessaire les compétences spécialisées
      • Un ergonome pour l’ihm
      • Un designer pour la chartre graphique
      • Un pédagogue pour la documentation
    • Echanger les sujets entre développeurs ainsi le code devient la propriété de tous
    • Utiliser une convention de codage
  • Les bonnes pratiques de développement (3/3)
    • Yagni (You Ain ’t Gonna Need It)
      • Ne faire que le besoin
      • Eviter de prévoir des fonctionnalités à l’avance
    • Kiss (Keep It Simple Stupid)
      • Faire au plus simple
      • Optimiser après et seulement si c’est nécessaire
    • DRY (Don’t Repeat Yourself)
      • Automatiser au maximum les taches
      • Ne pas copier/ coller de code
  • Documentation
    • Commenter au plus près du code
      • Documentation pérenne (outils de génération automatique)
      • Commenter les en-têtes de classe et de méthode (éviter les commentaires au sein des méthodes)
      • Eviter les commentaires inutiles (getter / setter)
    • Rédiger des tutoriels cours (3-8 pages) regroupés dans un wiki
  • Qualité du code objet
    • Un ensemble riche de classes homogènes
    • La (non) qualité est généralement constatée quelque soit le critère : taille, couplage, complexité
    Loc/classe Nb classes Classes décrivant une structure Classes complexes avec toute l’intelligence Loc/classe Nb classes
  • Couplage et cohésion
    • Dans un code de qualité le couplage est faible
      • Couplage: densité des dépendances entre les classes
    • Et la cohésion est importante
      • Peu de responsabilité par classe
      • Peu de classes impliquées dans une responsabilité
    • Généralement les deux indices sont couplés :
      • Moins un logiciel est couplé et plus il et cohérent
  • Mesurer la qualité du code
    • Des classes de taille raisonnable
      • Entre 100 et 1000 lignes hors commentaires
      • 250 en moyenne
    • Un nombre limité de méthodes par classe
      • Entre 3 et 20 (hors getter / setter)
    • Des méthodes de taille réduite
      • Entre 1 et 100 lignes (10 lignes en moyenne)
      • Moins de 10 paramètres (2 en moyenne)
      • Complexité faible (indice cyclomatique <= 10 dans 90% des cas)
    • Arbre d’héritage de faible hauteur (4 niveaux au maximum, 1 en moyenne)
  • Protéger par le test automatisé
    • Avantages du test automatisé
      • Maitrise des régressions
      • Documentation
      • Vérifie l’intégration
    • Conséquences
      • Exécuter un test ne coute rien
      • Le développeur se sent protégé
    • La couverture du code
      • Plus de 95% des lignes de code doivent être traversées par les tests
      • Mesure la qualité des tests
  • Tests automatisés
    • Tests unitaires
      • Test en mode boite blanche
      • Utilisation d’un framework type XUnit
      • D’abord obtenir la couverture de code ( > 95%)
      • Reproduire chaque anomalie avec un test
    • Tests fonctionnels
      • Test en mode boite noire
      • Pré-enregistrement d’un ensemble d’opérations utilisateur
      • Réaliser un ensemble de scénarii des spécifications fonctionnelles
    • Tests de performance
      • Test en mode boite noire
      • Sur quelques scénarii représentatifs
      • Déclenché dans une simulation de l’environnement réel
  • Coût des bugs http://www.agitar.com/solutions/why_unit_testing.html
  • Test Driven Development
    • Ecrire le test : il ne compile pas car il manque le code métier
    • Ecrire le code métier nécessaire à la compilation du test: le test est en échec
    • Écrire le code métier suffisant pour que le test s’exécute correctement
    • On transforme (refactoring) le code pour le rendre plus lisible et de meilleure qualité
    • Le test doit toujours s’exécuter correctement
    • On recommence …..
  • Gestion des patches
    • Un patch est une correction rapide
      • Pour répondre à une anomalie urgente
      • Pour tenir compte de la spécificité d’une plate-forme
      • Pour s’adapter à un composant extérieur
    • Les patches sont inévitables
      • Ils mettent en danger la qualité car ils sont mal testés et peu cohérents
    • Il faut gérer les patches
      • Les tracer (wiki, tracker, …)
      • Les documenter
      • Prévoir le refactoring
  • Refactoring
    • Modifier un code en profondeur
      • Iso fonctionnalités
      • Procéder par petites étapes et vérifier le bon fonctionnement à chaque étape
    • Pourquoi ?
      • Optimiser le code existant
      • Préparer de nouvelles fonctionnalités
      • Eviter les redondances
      • Rendre le code plus cohérent et plus lisible
  • Comment faire ?
    • S’outiller correctement (IDE récent)
    • Vérifier grâce aux tests automatisés
      • Plus la couverture de tests est importante et plus c’est efficace
    • Connaître les patterns de refactoring (Martin Fowler)
  • Méthodologies
    • Scrum : Gestion de projet itérative et incrémentale (Microsoft, Nokia, Orange, …) .
    • Lean : Adaptation du système Toyota ( http://www.poppendieck.com/ )
    • Crystal Clear : Méthodologie agile adaptée à une équipe de moins de 10 personnes. ( Alistair Cockburn )
    • Dynamic Systems Development Method
    • eXtrem Programming
  • Scrum
  • Scrum
  • Scrum – backlog
  • Scrum – Sprint backlog
  • Scrum - Mêlée quotidienne
  • Scrum – burndown chart
  • Scrum – Sprint review and retrospective
  • Lean - Waste
  • Lean – 10 Points
    • Eliminer les gaspillages. (muda)
    • Réduire les stocks.
    • Maximiser le flux (itérations brèves).
    • Faire selon la demande (décider le plus tard possible).
    • Donner du pouvoir à l’équipe (décider au plus près possible).
    • Répondre aux exigences des clients.
    • Faites le bien la première fois (intégrer les retours).
    • Abolir l’optimisation locale.
    • S’associer avec ses fournisseurs.
    • Créer une Culture de l’Amélioration Continue.
  • Lean – Supprimer les gaspillages (muda)
    • Travail partiellement fait (partially done work)
    • Processus inutiles (extra processes)
    • Développements ou fonctionnalités inutiles (extra features)
    • Passer d'un projet à l'autre (task switching)
    • Attentes (waiting) : supprimer les queues
    • Déplacements (motion)
    • Défauts, retouches (defects) : Do It Right the First Time
    Gaspillages dans les projets SI selon Poppendieck* :
  • Lean et Agile Equilibrer la demande en fonction du flux Supprimer les Gaspillages Amélioration Continue Savoir que le travail est périssable LEAN http://www.agilemanagement.net/Articles/Weblog/FutureDirectionsforAgile.html La perfection est l’ennemi du bien Confiance, Capital Humain Culture Hautement Collaborative Agile
  • Agile et CMMI
    • Mark Paulk, l’homme derrière CMM, est positif en ce qui concerne la méthodologie Agile and dit : &quot; Agile Methods address many CMM level 2 and 3 practices &quot;.
      • XP, for example, addresses most level 2 and 3 practices, but not level 4 and 5.
    • Scrum correctement implémenté permet d’atteindre seul CMMI niveau 3.
      • Jeff Sutherland : &quot; I think the cost of going to CMMI Level 5 starting with Scrum could be reduced by 50-80%. ... The process overhead of CMMI Level 5 with Scrum is 4%.&quot;
  • Conclusion
    • Dans un projet la qualité n’est pas une étape c’est un principe
    • La (non) qualité entraine la (non) qualité
      • Un mauvais code est de moins en moins respecté
      • Les corrections sont plus difficiles
    • Faire simple
      • Faire ce qui est nécessaire et suffisant
      • Utiliser les technologies adaptées
      • Bâtir autour d’une architecture simple et raisonnable
    • Etre concret
      • Etablir une stratégie de développement
      • Procéder par l’exemple
  • Questions?