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.

1. Agilité, Tests et industrialisationoù comment maîtriser votre business Olivier Hoareau – PHPPRO 23 Septembre 2009 www.phppro.fr

2. A FAIRE EN COURS FINI Tour de Table Intro 5’ 10’ Equipe Agile UdD 30’ 40’ What’s Next ? ? 5’ 30’

3. A FAIRE EN COURS FINI Tour de Table Intro 5’ 10’ Equipe Agile UdD 30’ 40’ What’s Next ? ? 5’ 30’

4. Qui suis-je ? Animateur Méthodologies Agiles Animateur Equipes Technique Expert Certifié PHP 5 Consultant Indépendant (PHPPRO) 10 ans de développement Web/PHP/OSS 5 ans de projets Grands Comptes 2 ans de Coaching Agile 1 an de vie sur Bordeaux (Paris, Brussels…) Bloggeur / AFUP / Conférencier

5. qui êtes-vous ?

6. A FAIRE EN COURS FINI Tour de Table Intro 5’ 10’ Equipe Agile UdD 30’ 40’ What’s Next ? ? 5’ 30’

7. Vous, aujourd’hui…

8. Vous êtes plutôt…« On s’en sort déjà, ca marche » Vous vendez (des applications) Vous savez répondre à la plupart des besoins de vos clients Vous avez créé vos processus (développement, livraison) Vous avez un catalogue produits Vous avez des compétences internes … Chez nous, ça marche !

9. ou alors…« On sait que l’on peut mieux faire » Vous vendez (trop) cher Vous ne gagnez pas tous les appels d’offres Vous perdez de l’énergie Vous perdez ou manquez de compétences Vous avez des applications « legacy » et/ou « zombies » Le mot « manuel » fait encore partie de votre quotidien … Oui, il y a peut être un peu de ça ?

10. Dans tous les cas…« La dure réalité de notre quotidien » Les besoins du client changent Les délais sont toujours trop court Les développeurs n’en font toujours qu’à leur tête Les acteurs projets ne parlent pas le même langage Il faut prévoir une phase de recette dans le planning Nécessité de faire des compromis pour gagner de l’argent On perd du temps dans la rédaction / lecture des documents … C’est notre quotidien !

11. Prise de conscience:« Il faut améliorer nos pratiques pour maîtrisernos coûts, nos délais et la satisfaction client » Pour ne paslivrer en retard Pour ne pasperdre du temps en maintenance Pour ne pasredévelopper toute l’appli Pour cadrer nos développeurs Pour faire et maintenir notre marge Pour pouvoir planifier Pour être compétitif Oui !

12. Barrières:« Maîtriser, oui mais… » Comment libérer l’innovation / l’imagination ? Comment prendre en compte les compétences de chacun ? Comment ne pas imposer ? Comment contrôler ? Comment éviter de perdre du temps ? Comment ne pas tout remettre en question ? Par où commencer ? Comment ?

13. A FAIRE EN COURS FINI Tour de Table Intro 5’ 10’ Equipe Agile UdD 30’ 40’ What’s Next ? ? 5’ 30’

14. Il était une fois une équipe …

15. qui acquis des valeurs fondamentales Equipe Application / Logiciel Collaboration Acceptation du changement Source : Wikipédia, http://fr.wikipedia.org/wiki/M%C3%A9thode_agile

16. qui adhéra à la philosophie « agile » Servir avant tout la satisfaction client Livrer une application qui fonctionne / est utile Travailler ensemble Privilégiez les interactions entre les personnes Collaborer plutôt que contractualiser S’adapter constamment plutôt que suivre un plan Livrer régulièrement, un logiciel n’est jamais fini Faire (toujours le plus) simple S’améliorer constamment (feedback) Cultiver la motivation Source : Agile Manifesto, http://agilemanifesto.org/

17. qui utilisa le vocabulaire « agile » Itération / Sprint Scrum / XP Vélocité / Valeur Backlog Post-it User Story Planning game Bilan / Retrospective Stand Up Meeting / Daily Scrum P.O : Product Owner/ S.M : Scrum Master Utilisateur(s) / Client Développeur(s)

18. qui mis en place une organisation « agile » Les UTILISATEURS Les DEVELOPPEURS Le PRODUCT OWNER Le SCRUM MASTER Images empreintées à http://borisgloger.com

19. qui organisa son tempsen itérations fixes (ex: 2 semaines) J0 Préparation contenu itération / Tableau des Posts-its J1 … J10 Production des posts-its J10 Démo Bilan / Retrospective / Feedback Pendant l’itération (planifié par post-it si possible) Livraison / Déploiement de l’itération précédente Atelier de conception improvisé Traitements des bugs de prod (mode imprévu)

20. qui mis en œuvre des pratiques agiles* Stand Up Meeting (10min: quotidien, même heure, debout) Engagement / Responsabilisation TDD : Test DrivenDevelopment Pair Programming « Commits » sur barre verte Refactoring Intégration Continue Design Patterns TDR : Test DrivenRequirements LEAN : Amélioration des Processus Dojo … * Pas forcément toutes les pratiques, et progressivement

21. qui s’auto-contrôla Contrôles régulier des pratiques BurndownChart Planning Mise en place de règles Bilan  feedback  nouvelles règles Couverture de Tests  Robustesse Vérification du respect des conventions  Maintenabilité Dojo et Revue de code  Evolutivité / Modularité / Réutilisabilité (Archi.) … Contrôles automatisés de l’application Taille du code / répartition du code Tests Unitaires Tests fonctionnels Tests de non-régressions Tests d’intégrations Tests d’IHM … Métriques

22. Source : ScrumAlliance, http://www.frenchsug.org … avec des BurndownCharts

23. Source : http://www.typeoneerror.com … en mesurant sa couverture de code

24. … en réalisant ses Bilans / Rétrospectives Pointspositifs Problèmesrencontrés Actionsbénéfiques à renouveler Idéesà tester

25. qui s’outilla Capitalisation Wiki (ex: Confluence) Environnement de développement (ex: Zend Studio) Gestion de sources (ex: Subversion) Réutilisation / Framework (ex: Zend Framework) Tests Unitaires (ex: PHPUnit) Packaging / Automatisation (ex: Phing / PEAR) Intégration Continue (ex: Hudson) Tests Fonctionnels Exécutables (ex: Fitnesse) Tests Graphiques (ex: Selenium) Mesure du code (ex: PHPLoc, PHPCpd…) Suivi évolutions / bugs (ex: JIRA) …

26. qui améliora son architecture Programmation Objet Couche Services Multi-contextes (web, batch, tests, …) Design Patterns Web services & REST Découpage en modules Testabilité (« Bouchonnabilité ») Multi-base de données / BdDNon Relationnelles Librairie technique interne Librairie fonctionnelle interne …

27. qui fit émerger etrespecta ses conventions Sociales Horaires Engagements Fichiers / Classes / Méthodes Nommage Encodage / Taille Architecture Grands Principes Couches Tests … « L’excellence attire l’excellence »

28. qui livra régulièrement des évolutions T0 T0+1mois T0+2mois T0+3mois T0+4mois Livraison Livraison Livraison Livraison It.#1 It.#2 It.#5 It.#8 It.#0 It.#3 It.#4 It.#6 It.#7

29. inspiré d’une histoireSvraieS : 6

30. Ils « vivent » l’« agile » 1 Grand Compte Service Public – Projet de 25 dév. / 50 pers. 1 Acteur 1% Logement –Projet de 15 dév. / 30 pers. 1 Grand Compte Telecom – Projet de 4 dév. / 8 pers. 1 Startup Tchat Virtuel – Projet de 3 dév. / 6 pers. 1 Grand Compte Service Public – Projet de 4 dév. / 7 pers. 1 SSII Suisse – Projet de 1 dév. / 2 pers. et vous ?

31. A FAIRE EN COURS FINI Tour de Table Intro 5’ 10’ Equipe Agile UdD 30’ 40’ What’s Next ? ? 5’ 30’

32. Usine de Développement :Industrialisation PHP

33. Ma définition de l’industrialisation INDUSTRIALISATION MONO MULTI MA PRATIQUE OUTILS TECHNIQUES PRATIQUES

34. Une vraie usine professionnelle Capitalisation Wiki  Confluence Environnement de développement  Eclipse,Zend Studio Gestion de sources Subversion, Git Réutilisation / Framework  Zend Framework, Symfony Tests Unitaires PHPUnit Packaging / Automatisation  Phing/ PEAR Intégration Continue  Hudson, PHPUnderControl Tests Fonctionnels Exécutables  Fitnesse Tests Graphiques  Selenium Mesure du code  PHPLoc, PHPCpd, Pdepend, CodeSniffer Suivi évolutions / bugs  JIRA …

35. Paramètres T.U Ce qui teste LOGIQUE Ce qui est testé ENV / SYS Ce qui interagie Retours Exceptions Qu’est-ce qu’un test unitaire ? Vérifie que l’envoie de la liste des lettres en recommandé Electronique d’hier par email fonctionne Demande la liste des lettres Recommandé à la BDD, Construit et déclenche / commande l’envoie d’email Envoie des emails via le réseau Exécute une requête sur la BDD Lit / Ecrit dans des fichiers …

36. TDD : Test DrivenDevelopment « Test First » : coder le test avant le code Construire / Designer le code « au fil de l’eau » TDD : 3 fois plus de temps à développer, 10 fois moins de problème à l’arrivée. Automatisation des T.U : base de l’usine de développement

37. Pourquoi TDD ? Tests oublié si à la fin Fort impact positif sur le Design (Architecture) M’oblige à développer le strict nécessaire Plus robuste Tests automatisables  intégration continue M’oblige à être modulaire pour bouchonner « Je n’ai plus peur de toucher le code » « Je n’ai plus peur de supprimer du code » …

38. Exemple TDD / PHPUnit « Développer une méthode de récupération de la liste des commandes d’une date par webservice »

39. Je développe le test du cas simple…

40. …ensuite, le code pour faire passer le test

41. Je développe le test du cas d’erreur… Test … je refactore et développe le code Code

42. TDD : une approche systématique Test du cas nominal Code du cas nominal Test du cas d’erreur Code du cas d’erreur Test du / des cas aux limites Code du / des cas aux limites = Robustesse, Bouchon, Simplicité et Modularité

43. Testabilité du code PHP Natif PHP Support PHP Web

44. Qu’est-ce qu’un test fonctionnel ? Un test écrit dans un vocabulaire fonctionnel Un test écrit de préférence par un fonctionnel Un test décrivant une fonctionnalité Un test non contraint, en apparence, par la technique Un test lisible sans connaissances techniques Un test de non regréssion des fonctionnalités outils T.D.R = Test DRIVEN REQUIREMENTS

45. T.D.R : Quels avantages ? Simple + Efficace : Wiki Remplacement possible du CdC (Word  Wiki) Visibilité temps réel sur l’accompli / non accompli Tests de non régression temps réel / à la demande Vecteur de formalisation des évolutions Outil de démo / bilan de fin d’itération Vocabulaire universel, i.e. « compris par tous » Outil pour tester le comportement de l’application OUTIL de PREDILECTION DE LA « MOA AGILE »

46. T.D.R : Les outils du marché Fitnesse Open Source / Free GreenPepper  Open Source / Commercial Voir, en BehaviourDrivenDevelopment (dérivé) : Jbehave RobotFramework …

47. DEV BUILD DEPLOY INTEG S.I. Une usine de développement typique © OCTO Technology - Université du Système d’Information 47 1 3 2 integ.myapp.com */2 * * * * SVN dev.myapp.com TDD on-demand on-commit RUN PROJECT T.U 6 nightly Tracker+Backlog on-demand TDR Qualité 1,5,7 nightly (pre-)prod.myapp.com REPORT 4

48. Construire sa Librairie commune « à n’utiliser qu’en cas de besoin » Librairie de composants techniques et/ou fonctionnels Surcouche du framework choisi (ex: ZF) Cache la complexité / Paradigme « convention over configuration » Minimal, évolutif, réactif, en constante amélioration Rationalisation arborescence fichiers Gérer le tranverse : boostraps, conf, bdd… Capitalisation / Factorisation Si pas présent dans la lib, les équipes le développent Contribuez à la lib via le SVN Maintenu / Modéré Conventions et critères qualité pour donner l’exemple

49. Les 10 commandements du développeur Faire simple ET propre Développer en TDD : le test d’abord, le code ensuite Committer si tous les tests de l’application sont en succès Respecter des conventions de codage connus en dehors de l'entreprise Développer 1 fois, Réutiliser plusieurs fois Tester unitairement toutes les fonctionnalités du coeur de l'application Utiliser les comparaisons de valeurs ET de types (===, !==) Réaliser systématiquement des implémentation mocks (bouchons) Ne pas dépasser plus de 80 lignes aérées et commentées pour une fonction/méthode Banir « l’écran noir » de mon quotidien Bonus: Always have fun !

50. des questions ?

51. A FAIRE EN COURS FINI Tour de Table Intro 5’ 10’ Equipe Agile UdD 30’ 40’ What’s Next ? ? 5’ 30’

52. Vos perspectives… Boss Geek Alignement Réactivité Flexibilité Adaptabilité Réutilisabilité Visibilité Automatisation Collaboratif Mono / Multi … Maîtrise du déploiement Dév. Procédurale  Objet* Capitalisation interne Bouchons / Testabilité Intégration Continue Modernité Modularité Evolutivité Maintenabilité … * optimisée / efficace

53. Par où commencer Se faire coacher (méthodo / technique) Pour être pris en main / conseillé Pour ne pas perdre du temps Pour passer les obstacles en étant conscient Pour choisir et mettre en place les bons outils Pour faire par vous-même dès le début Choisir un projet-test (1ère implémentation) Pour appréhender / se roder Pour avoir un succès à raconter / un exemple à suivre

54. Pour démarrer, vous pensez à… un projet ? une équipe ? une mission ? un client ? une période ?

55. A FAIRE EN COURS FINI Tour de Table Intro 5’ 10’ Equipe Agile UdD 30’ 40’ What’s Next ? ? 5’ 30’

56. des questions ?

57. Merci ! olivier@phppro.fr 06.31.20.74.79 http://blog.phppro.fr http://www.phppro.fr