Agilité, Tests Et Industrialisation

6 635 vues

Publié le

Présentation donnée en septembre 2009 à un acteur informatique à Bordeaux. J'explique ma vision de l'agilité, des tests et de l'industrialisation au travers de l'exemple PHP.

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

Aucun téléchargement
Vues
Nombre de vues
6 635
Sur SlideShare
0
Issues des intégrations
0
Intégrations
537
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
18
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Agilité, Tests Et Industrialisation

  1. 1. Agilité, Tests et industrialisationoù comment maîtriser votre business<br />Olivier Hoareau – PHPPRO<br />23 Septembre 2009<br />www.phppro.fr<br />
  2. 2. A FAIRE<br />EN COURS<br />FINI<br />Tour de<br />Table<br />Intro<br />5’<br />10’<br />Equipe<br />Agile<br />UdD<br />30’<br />40’<br />What’s<br />Next ?<br />?<br />5’<br />30’<br />
  3. 3. A FAIRE<br />EN COURS<br />FINI<br />Tour de<br />Table<br />Intro<br />5’<br />10’<br />Equipe<br />Agile<br />UdD<br />30’<br />40’<br />What’s<br />Next ?<br />?<br />5’<br />30’<br />
  4. 4. Qui suis-je ?<br />Animateur Méthodologies Agiles<br />Animateur Equipes Technique<br />Expert Certifié PHP 5<br />Consultant Indépendant (PHPPRO)<br />10 ans de développement Web/PHP/OSS<br />5 ans de projets Grands Comptes<br />2 ans de Coaching Agile<br />1 an de vie sur Bordeaux (Paris, Brussels…)<br />Bloggeur / AFUP / Conférencier<br />
  5. 5. qui êtes-vous ?<br />
  6. 6. A FAIRE<br />EN COURS<br />FINI<br />Tour de<br />Table<br />Intro<br />5’<br />10’<br />Equipe<br />Agile<br />UdD<br />30’<br />40’<br />What’s<br />Next ?<br />?<br />5’<br />30’<br />
  7. 7. Vous, aujourd’hui…<br />
  8. 8. Vous êtes plutôt…« On s’en sort déjà, ca marche »<br />Vous vendez (des applications)<br />Vous savez répondre à la plupart des besoins de vos clients<br />Vous avez créé vos processus (développement, livraison)<br />Vous avez un catalogue produits<br />Vous avez des compétences internes<br />…<br />Chez nous, ça marche !<br />
  9. 9. ou alors…« On sait que l’on peut mieux faire »<br />Vous vendez (trop) cher<br />Vous ne gagnez pas tous les appels d’offres<br />Vous perdez de l’énergie<br />Vous perdez ou manquez de compétences<br />Vous avez des applications « legacy » et/ou « zombies »<br />Le mot « manuel » fait encore partie de votre quotidien<br />…<br />Oui, il y a peut être un peu de ça ?<br />
  10. 10. Dans tous les cas…« La dure réalité de notre quotidien »<br />Les besoins du client changent<br />Les délais sont toujours trop court<br />Les développeurs n’en font toujours qu’à leur tête<br />Les acteurs projets ne parlent pas le même langage<br />Il faut prévoir une phase de recette dans le planning<br />Nécessité de faire des compromis pour gagner de l’argent<br />On perd du temps dans la rédaction / lecture des documents<br />…<br />C’est notre quotidien !<br />
  11. 11. Prise de conscience:« Il faut améliorer nos pratiques pour maîtrisernos coûts, nos délais et la satisfaction client »<br />Pour ne paslivrer en retard<br />Pour ne pasperdre du temps en maintenance<br />Pour ne pasredévelopper toute l’appli<br />Pour cadrer nos développeurs<br />Pour faire et maintenir notre marge<br />Pour pouvoir planifier<br />Pour être compétitif<br />Oui !<br />
  12. 12. Barrières:« Maîtriser, oui mais… »<br />Comment libérer l’innovation / l’imagination ?<br />Comment prendre en compte les compétences de chacun ?<br />Comment ne pas imposer ?<br />Comment contrôler ?<br />Comment éviter de perdre du temps ?<br />Comment ne pas tout remettre en question ?<br />Par où commencer ?<br />Comment ?<br />
  13. 13. A FAIRE<br />EN COURS<br />FINI<br />Tour de<br />Table<br />Intro<br />5’<br />10’<br />Equipe<br />Agile<br />UdD<br />30’<br />40’<br />What’s<br />Next ?<br />?<br />5’<br />30’<br />
  14. 14. Il était une fois une équipe …<br />
  15. 15. qui acquis des valeurs fondamentales<br />Equipe<br />Application / Logiciel<br />Collaboration<br />Acceptation du changement<br />Source : Wikipédia, http://fr.wikipedia.org/wiki/M%C3%A9thode_agile<br />
  16. 16. qui adhéra à la philosophie « agile »<br />Servir avant tout la satisfaction client<br />Livrer une application qui fonctionne / est utile<br />Travailler ensemble<br />Privilégiez les interactions entre les personnes<br />Collaborer plutôt que contractualiser<br />S’adapter constamment plutôt que suivre un plan<br />Livrer régulièrement, un logiciel n’est jamais fini<br />Faire (toujours le plus) simple<br />S’améliorer constamment (feedback)<br />Cultiver la motivation<br />Source : Agile Manifesto, http://agilemanifesto.org/<br />
  17. 17. qui utilisa le vocabulaire « agile »<br />Itération / Sprint<br />Scrum / XP<br />Vélocité / Valeur<br />Backlog<br />Post-it<br />User Story<br />Planning game<br />Bilan / Retrospective<br />Stand Up Meeting / Daily Scrum<br />P.O : Product Owner/ S.M : Scrum Master<br />Utilisateur(s) / Client<br />Développeur(s)<br />
  18. 18. qui mis en place une organisation « agile »<br />Les UTILISATEURS<br />Les DEVELOPPEURS<br />Le PRODUCT OWNER<br />Le SCRUM MASTER<br />Images empreintées à http://borisgloger.com<br />
  19. 19. qui organisa son tempsen itérations fixes (ex: 2 semaines)<br />J0<br />Préparation contenu itération / Tableau des Posts-its<br />J1 … J10<br />Production des posts-its<br />J10<br />Démo<br />Bilan / Retrospective / Feedback<br />Pendant l’itération (planifié par post-it si possible)<br />Livraison / Déploiement de l’itération précédente<br />Atelier de conception improvisé<br />Traitements des bugs de prod (mode imprévu)<br />
  20. 20. qui mis en œuvre des pratiques agiles*<br />Stand Up Meeting (10min: quotidien, même heure, debout)<br />Engagement / Responsabilisation<br />TDD : Test DrivenDevelopment<br />Pair Programming<br />« Commits » sur barre verte<br />Refactoring<br />Intégration Continue<br />Design Patterns<br />TDR : Test DrivenRequirements<br />LEAN : Amélioration des Processus<br />Dojo<br />…<br />* Pas forcément toutes les pratiques, et progressivement<br />
  21. 21. qui s’auto-contrôla<br />Contrôles régulier des pratiques<br />BurndownChart Planning<br />Mise en place de règles Bilan  feedback  nouvelles règles<br />Couverture de Tests  Robustesse<br />Vérification du respect des conventions  Maintenabilité<br />Dojo et Revue de code  Evolutivité / Modularité / Réutilisabilité (Archi.)<br />…<br />Contrôles automatisés de l’application<br />Taille du code / répartition du code<br />Tests Unitaires<br />Tests fonctionnels<br />Tests de non-régressions<br />Tests d’intégrations<br />Tests d’IHM<br />…<br />Métriques<br />
  22. 22. Source : ScrumAlliance, http://www.frenchsug.org<br />… avec des BurndownCharts<br />
  23. 23. Source : http://www.typeoneerror.com<br />… en mesurant sa couverture de code<br />
  24. 24. … en réalisant ses Bilans / Rétrospectives<br />Pointspositifs<br />Problèmesrencontrés<br />Actionsbénéfiques<br />à renouveler<br />Idéesà tester<br />
  25. 25. qui s’outilla<br />Capitalisation Wiki (ex: Confluence)<br />Environnement de développement (ex: Zend Studio)<br />Gestion de sources (ex: Subversion)<br />Réutilisation / Framework (ex: Zend Framework)<br />Tests Unitaires (ex: PHPUnit)<br />Packaging / Automatisation (ex: Phing / PEAR)<br />Intégration Continue (ex: Hudson)<br />Tests Fonctionnels Exécutables (ex: Fitnesse)<br />Tests Graphiques (ex: Selenium)<br />Mesure du code (ex: PHPLoc, PHPCpd…)<br />Suivi évolutions / bugs (ex: JIRA)<br />…<br />
  26. 26. qui améliora son architecture<br />Programmation Objet<br />Couche Services<br />Multi-contextes (web, batch, tests, …)<br />Design Patterns<br />Web services & REST<br />Découpage en modules<br />Testabilité (« Bouchonnabilité »)<br />Multi-base de données / BdDNon Relationnelles<br />Librairie technique interne<br />Librairie fonctionnelle interne<br />…<br />
  27. 27. qui fit émerger etrespecta ses conventions<br />Sociales<br />Horaires<br />Engagements<br />Fichiers / Classes / Méthodes<br />Nommage<br />Encodage / Taille<br />Architecture<br />Grands Principes<br />Couches<br />Tests<br />…<br />« L’excellence attire l’excellence »<br />
  28. 28. qui livra régulièrement des évolutions<br />T0<br />T0+1mois<br />T0+2mois<br />T0+3mois<br />T0+4mois<br />Livraison<br />Livraison<br />Livraison<br />Livraison<br />It.#1<br />It.#2<br />It.#5<br />It.#8<br />It.#0<br />It.#3<br />It.#4<br />It.#6<br />It.#7<br />
  29. 29. inspiré d’une histoireSvraieS :<br />6<br />
  30. 30. Ils « vivent » l’« agile »<br />1 Grand Compte Service Public – Projet de 25 dév. / 50 pers.<br />1 Acteur 1% Logement –Projet de 15 dév. / 30 pers.<br />1 Grand Compte Telecom – Projet de 4 dév. / 8 pers.<br />1 Startup Tchat Virtuel – Projet de 3 dév. / 6 pers.<br />1 Grand Compte Service Public – Projet de 4 dév. / 7 pers.<br />1 SSII Suisse – Projet de 1 dév. / 2 pers.<br />et vous ?<br />
  31. 31. A FAIRE<br />EN COURS<br />FINI<br />Tour de<br />Table<br />Intro<br />5’<br />10’<br />Equipe<br />Agile<br />UdD<br />30’<br />40’<br />What’s<br />Next ?<br />?<br />5’<br />30’<br />
  32. 32. Usine de Développement :Industrialisation PHP<br />
  33. 33. Ma définition de l’industrialisation<br />INDUSTRIALISATION<br />MONO<br />MULTI<br />MA PRATIQUE<br />OUTILS<br />TECHNIQUES<br />PRATIQUES<br />
  34. 34. Une vraie usine professionnelle<br />Capitalisation Wiki  Confluence<br />Environnement de développement  Eclipse,Zend Studio<br />Gestion de sources Subversion, Git<br />Réutilisation / Framework  Zend Framework, Symfony<br />Tests Unitaires PHPUnit<br />Packaging / Automatisation  Phing/ PEAR<br />Intégration Continue  Hudson, PHPUnderControl<br />Tests Fonctionnels Exécutables  Fitnesse<br />Tests Graphiques  Selenium<br />Mesure du code  PHPLoc, PHPCpd, Pdepend, CodeSniffer<br />Suivi évolutions / bugs  JIRA<br />…<br />
  35. 35. Paramètres<br />T.U<br />Ce qui teste<br />LOGIQUE<br />Ce qui est testé<br />ENV / SYS<br />Ce qui interagie<br />Retours<br />Exceptions<br />Qu’est-ce qu’un test unitaire ?<br />Vérifie que l’envoie de<br />la liste des lettres<br />en recommandé<br />Electronique d’hier par<br />email fonctionne<br />Demande la liste des lettres<br />Recommandé à la BDD,<br />Construit et déclenche /<br /> commande l’envoie d’email<br />Envoie des emails via le réseau<br />Exécute une requête sur la BDD<br />Lit / Ecrit dans des fichiers<br />…<br />
  36. 36. TDD : Test DrivenDevelopment<br />« Test First » : coder le test avant le code<br />Construire / Designer le code « au fil de l’eau »<br />TDD : 3 fois plus de temps à développer, 10 fois moins de problème à l’arrivée.<br />Automatisation des T.U : base de l’usine de développement<br />
  37. 37. Pourquoi TDD ?<br />Tests oublié si à la fin<br />Fort impact positif sur le Design (Architecture)<br />M’oblige à développer le strict nécessaire<br />Plus robuste<br />Tests automatisables  intégration continue<br />M’oblige à être modulaire pour bouchonner<br />« Je n’ai plus peur de toucher le code »<br />« Je n’ai plus peur de supprimer du code »<br />…<br />
  38. 38. Exemple TDD / PHPUnit<br />« Développer une méthode de récupération de la liste des commandes d’une date par webservice »<br />
  39. 39. Je développe le test du cas simple…<br />
  40. 40. …ensuite, le code pour faire passer le test<br />
  41. 41. Je développe le test du cas d’erreur…<br />Test<br />… je refactore et développe le code<br />Code<br />
  42. 42. TDD : une approche systématique<br />Test du cas nominal<br />Code du cas nominal<br />Test du cas d’erreur<br />Code du cas d’erreur<br />Test du / des cas aux limites<br />Code du / des cas aux limites<br />= Robustesse, Bouchon, Simplicité et Modularité<br />
  43. 43. Testabilité du code PHP<br />Natif<br />PHP<br />Support<br />PHP<br />Web<br />
  44. 44. Qu’est-ce qu’un test fonctionnel ?<br />Un test écrit dans un vocabulaire fonctionnel<br />Un test écrit de préférence par un fonctionnel<br />Un test décrivant une fonctionnalité<br />Un test non contraint, en apparence, par la technique<br />Un test lisible sans connaissances techniques<br />Un test de non regréssion des fonctionnalités<br />outils T.D.R = Test DRIVEN REQUIREMENTS<br />
  45. 45. T.D.R : Quels avantages ?<br />Simple + Efficace : Wiki<br />Remplacement possible du CdC (Word  Wiki)<br />Visibilité temps réel sur l’accompli / non accompli<br />Tests de non régression temps réel / à la demande<br />Vecteur de formalisation des évolutions<br />Outil de démo / bilan de fin d’itération<br />Vocabulaire universel, i.e. « compris par tous »<br />Outil pour tester le comportement de l’application<br />OUTIL de PREDILECTION DE LA « MOA AGILE »<br />
  46. 46. T.D.R : Les outils du marché<br />Fitnesse Open Source / Free<br />GreenPepper  Open Source / Commercial<br />Voir, en BehaviourDrivenDevelopment (dérivé) :<br />Jbehave<br />RobotFramework<br />…<br />
  47. 47. DEV<br />BUILD<br />DEPLOY<br />INTEG<br />S.I.<br />Une usine de développement typique<br />© OCTO Technology - Université du Système d’Information<br />47<br />1<br />3<br />2<br />integ.myapp.com<br />*/2 * * * *<br />SVN<br />dev.myapp.com<br />TDD<br />on-demand<br />on-commit<br />RUN<br />PROJECT<br />T.U<br />6<br />nightly<br />Tracker+Backlog<br />on-demand<br />TDR<br />Qualité<br />1,5,7<br />nightly<br />(pre-)prod.myapp.com<br />REPORT <br />4<br />
  48. 48. Construire sa Librairie commune<br />« à n’utiliser qu’en cas de besoin »<br />Librairie de composants techniques et/ou fonctionnels<br />Surcouche du framework choisi (ex: ZF)<br />Cache la complexité / Paradigme « convention over configuration »<br />Minimal, évolutif, réactif, en constante amélioration<br />Rationalisation arborescence fichiers<br />Gérer le tranverse : boostraps, conf, bdd…<br />Capitalisation / Factorisation<br />Si pas présent dans la lib, les équipes le développent<br />Contribuez à la lib via le SVN<br />Maintenu / Modéré<br />Conventions et critères qualité pour donner l’exemple<br />
  49. 49. Les 10 commandements du développeur<br />Faire simple ET propre<br />Développer en TDD : le test d’abord, le code ensuite<br />Committer si tous les tests de l’application sont en succès<br />Respecter des conventions de codage connus en dehors de l&apos;entreprise<br />Développer 1 fois, Réutiliser plusieurs fois<br />Tester unitairement toutes les fonctionnalités du coeur de l&apos;application<br />Utiliser les comparaisons de valeurs ET de types (===, !==)<br />Réaliser systématiquement des implémentation mocks (bouchons)<br />Ne pas dépasser plus de 80 lignes aérées et commentées pour une fonction/méthode<br />Banir « l’écran noir » de mon quotidien<br />Bonus: Always have fun !<br />
  50. 50. des questions ?<br />
  51. 51. A FAIRE<br />EN COURS<br />FINI<br />Tour de<br />Table<br />Intro<br />5’<br />10’<br />Equipe<br />Agile<br />UdD<br />30’<br />40’<br />What’s<br />Next ?<br />?<br />5’<br />30’<br />
  52. 52. Vos perspectives…<br />Boss<br />Geek<br />Alignement<br />Réactivité<br />Flexibilité<br />Adaptabilité<br />Réutilisabilité<br />Visibilité<br />Automatisation<br />Collaboratif<br />Mono / Multi<br />…<br />Maîtrise du déploiement<br />Dév. Procédurale  Objet*<br />Capitalisation interne<br />Bouchons / Testabilité<br />Intégration Continue<br />Modernité<br />Modularité<br />Evolutivité<br />Maintenabilité<br />…<br />* optimisée / efficace<br />
  53. 53. Par où commencer<br />Se faire coacher (méthodo / technique)<br />Pour être pris en main / conseillé<br />Pour ne pas perdre du temps<br />Pour passer les obstacles en étant conscient<br />Pour choisir et mettre en place les bons outils<br />Pour faire par vous-même dès le début<br />Choisir un projet-test (1ère implémentation)<br />Pour appréhender / se roder<br />Pour avoir un succès à raconter / un exemple à suivre<br />
  54. 54. Pour démarrer, vous pensez à…<br />un projet ?<br />une équipe ?<br />une mission ?<br />un client ?<br />une période ?<br />
  55. 55. A FAIRE<br />EN COURS<br />FINI<br />Tour de<br />Table<br />Intro<br />5’<br />10’<br />Equipe<br />Agile<br />UdD<br />30’<br />40’<br />What’s<br />Next ?<br />?<br />5’<br />30’<br />
  56. 56. des questions ?<br />
  57. 57. Merci !<br />olivier@phppro.fr<br />06.31.20.74.79<br />http://blog.phppro.fr<br />http://www.phppro.fr<br />

×