Industrialisation du logiciel  Introduction et bonnes pratiques Emmanuel HUGONNET Architecte Technique / Expert Java EE ht...
Critères d’appréciation selon les profils Utile Evolutif Maintenable Exploitable Ergonomique Performant Ouvert Fiable Util...
Lancer un projet <ul><li>Une équipe de taille raisonnable: </li></ul><ul><ul><li>Entre  et  </li></ul></ul><ul><li>Munie d...
Organiser l’équipe <ul><li>Séparer les rôles (dans la mesure du possible) </li></ul><ul><ul><li>D’organisation (Chef de pr...
Protéger l’équipe
Dynamiser l’équipe <ul><li>Privilégier la proximité :  </li></ul><ul><ul><li>un seul lieu de travail spacieux et agréable ...
Pourquoi un changement de mentalité est il nécessaire ?
Agilité <ul><li>Les principes </li></ul><ul><ul><li>Parier sur les hommes et la communication plutôt que sur les processus...
Pratique de l’XP
Le cycle itératif 1 ère   Itération 2 ème   Itération 3 ème   Itération
Le cycle itératif <ul><li>Réduction des risques </li></ul><ul><ul><li>Lancer les items les plus risqués le plus tôt possib...
S’outiller <ul><li>Pour faire vivre le projet </li></ul><ul><ul><li>Communication (forum, mailing list, Jabber …) </li></u...
Intégration Continue Développeur Hudson Intégration   Continue Métriques Anomalies
Définir des actions Qualité <ul><li>Relecture du code (au premier commit par exemple) par un pair. </li></ul><ul><li>Revue...
Bonnes pratiques <ul><li>Reconnaître la qualité de ce qui est fait </li></ul><ul><li>Ne pas oublier l’objectif qui est d’a...
Gérer les exigences <ul><li>Parler aux utilisateurs </li></ul><ul><ul><li>Document de spécifications fonctionnelles </li><...
Tracer les évolutions <ul><li>Pourquoi ? </li></ul><ul><ul><li>Pour cibler les campagnes de tests </li></ul></ul><ul><ul><...
Concevoir et développer <ul><li>Architecture fonctionnelle </li></ul><ul><ul><li>Processus métier </li></ul></ul><ul><ul><...
Découpage <ul><li>Utiliser une architecture simple </li></ul><ul><ul><li>Le 2-tiers suffit souvent </li></ul></ul><ul><ul>...
Qu’est ce qu’une bonne conception ?  <ul><li>Distribuer les données et les traitements </li></ul><ul><ul><li>De manière ho...
Comment faire une bonne conception ? <ul><li>Plusieurs façons </li></ul><ul><ul><li>Par essai / erreur </li></ul></ul><ul>...
Les bonnes pratiques de développement (1/3) <ul><li>Développement par l’exemple </li></ul><ul><ul><li>L’expert construit u...
Les bonnes pratiques de développement (2/3) <ul><li>Solliciter si nécessaire les compétences spécialisées </li></ul><ul><u...
Les bonnes pratiques de développement (3/3) <ul><li>Yagni (You Ain ’t Gonna Need It) </li></ul><ul><ul><li>Ne faire que le...
Documentation <ul><li>Commenter au plus près du code  </li></ul><ul><ul><li>Documentation pérenne (outils de génération au...
Qualité du code objet <ul><li>Un ensemble riche de classes homogènes </li></ul><ul><li>La (non) qualité est généralement c...
Couplage et cohésion <ul><li>Dans un code de qualité le couplage est faible </li></ul><ul><ul><li>Couplage: densité des dé...
Mesurer la qualité du code <ul><li>Des classes de taille raisonnable </li></ul><ul><ul><li>Entre 100 et 1000 lignes hors c...
Protéger par le test automatisé <ul><li>Avantages du test automatisé </li></ul><ul><ul><li>Maitrise des régressions </li><...
Tests automatisés <ul><li>Tests unitaires </li></ul><ul><ul><li>Test en mode boite blanche </li></ul></ul><ul><ul><li>Util...
Coût des bugs http://www.agitar.com/solutions/why_unit_testing.html
Test Driven Development <ul><li>Ecrire le test : il ne compile pas car il manque le code métier </li></ul><ul><li>Ecrire l...
Gestion des patches <ul><li>Un patch est une correction rapide </li></ul><ul><ul><li>Pour répondre à une anomalie urgente ...
Refactoring <ul><li>Modifier un code en profondeur </li></ul><ul><ul><li>Iso fonctionnalités  </li></ul></ul><ul><ul><li>P...
Comment faire ? <ul><li>S’outiller correctement (IDE récent) </li></ul><ul><li>Vérifier grâce aux tests automatisés </li><...
Méthodologies <ul><li>Scrum   :  Gestion de projet itérative et incrémentale (Microsoft, Nokia, Orange, …) . </li></ul><ul...
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 <ul><li>Eliminer les gaspillages. (muda) </li></ul><ul><li>Réduire les stocks. </li></ul><ul><li>Maximise...
Lean – Supprimer les gaspillages (muda) <ul><li>Travail partiellement fait (partially done work)  </li></ul><ul><li>Proces...
Lean et Agile Equilibrer la demande en fonction du flux Supprimer les Gaspillages Amélioration Continue Savoir que le trav...
Agile et CMMI <ul><li>Mark Paulk, l’homme derrière CMM, est positif en ce qui concerne la méthodologie Agile and dit : &qu...
Conclusion <ul><li>Dans un projet la qualité n’est pas une étape c’est un  principe </li></ul><ul><li>La (non) qualité ent...
Questions?
Upcoming SlideShare
Loading in...5
×

Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques

7,793

Published on

Published in: Technology

Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques

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

    Clipping is a handy way to collect important slides you want to go back to later.

×