Your SlideShare is downloading. ×
Agilité, Tests Et Industrialisation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Agilité, Tests Et Industrialisation

5,009
views

Published on

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.

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.

Published in: Technology

0 Comments
19 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,009
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
19
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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