SlideShare une entreprise Scribd logo
1  sur  32
Télécharger pour lire hors ligne
David Beaumier
• Pourquoi parler de pratiques
• Les pratiques
• Cas vécu: résultats
• Répondre à vos questions
• Dans le domaine des TI depuis 1994
• Pratique le développement Agile depuis 2003
• Conseiller chez Elapse Technologies
• MCAD + Certified ScrumMaster
• Accompagne les équipes dans la mise en
 place des bonnes pratiques de
 développement durant les projets
• L’état actuel de notre industrie
 • Malheureusement encore « artisanal »
 • Niveau de maturité inégal
• Qualité logicielle encore déficiente
 • Selon le Standish Group:
   • Ratio de 3:1 des bogues logiciels vs matériel
   • Cause de 55% des pannes de systèmes
   • 300 milliards de pertes annuellement
• Échecs de projets Agile
 • Scrum en particulier
• Avoir des normes et conventions communes
• Pourquoi c’est important
 • Assurer une uniformité dans le code
 • Permettre à tous de le lire et le comprendre
 • Faciliter l’arrivée de nouvelles personnes
• Comment s’y prendre
 • Choisir et respecter une convention
 • S’assurer du respect de cette convention
« Paul est absent, on devra attendre
      son retour pour finir le correctif »

• Permettre à tous de modifier le code
• Répartir la connaissances dans toute l’équipe
• Moyens
 • Effectuer une rotation des les assignations
 • Revue de code et discussions
 • Travailler en équipe à la résolution des problèmes
• 2 personnes 1 ordi (1 clavier, 1 souris)
• Alternance entre rôle stratégique et tactique
• Pourquoi faire?
 • 2 têtes valent mieux qu’une: conception améliorée
 • Revue instantanée de tout le code écrit
• Ça demeure un pratique controversée
 • Payer deux personnes pour le même travail?
   • “Ce qui est complexe en programmation ce n’est pas de
     taper le code”
 • Changement des habitudes de travail
• Suggestion: appliquer l’esprit et non la lettre
• Aussi souvent que possible
 • Lors de la conception, de refactorisation
 • Lorsque vous êtes bloqué -> immédiatement!
 • Mais laissez-vous souffler un peu!
• Essentiel: franchise et respect
• État de la situation
 • Une bonne pratique de génie logiciel
 • Encore peu systématisé dans les équipes
 • Souvent escamoté

• Qu’est-ce qu’un test unitaire?
 • Tester une petite partie de code
   indépendamment des autres
 • S’assurer de la conformité des résultats en toutes
   circonstances
longueur




                                                                 largeur
Supposons la fonction (simple)
 CalculerAire(largeur, longueur) As Double

Combien de tests sont nécessaires?
1. Valeurs positives -> vérifier résultat = largeur x longueur
2. Valeurs de 0 -> résultat = 0
3. Valeurs négatives -> retourne erreur
4. Combinaisons des conditions précédentes
• « Ça marche seulement pour les cas
  simples! »
• « C’est vrai… »
• Justement… On recherche des
  implémentations simples!!!

  Solution = ensemble de simplicités
• TDD: « Test-Driven Development »
 • En français: Développement piloté par les tests

• TDD est un cadre de travail
 • Emphase sur la conception
 • Comprendre ce qu’on doit faire avant de coder
 • Valorise le travail de qualité

• Conception pilotée par les tests
Réflexion




            Programmer     Programmer
               le test   l’implémentation
• Meilleure conception
 • Couplage faible
 • Cohésion élevée
• Documentation toujours à jour
• Patrimoine de cas d’essais important
 • Maintenance et évolution facilitées
 • Filet de sureté essentiel pour l’équipe
 • Réduit les anomalies de régression
• Qu’est-ce que l’intégration?
 • C’est le processus par lequel un ensemble de
   modifications au code est mise en commun
• Pourquoi continuellement?
 • Vérifier l’impact de chaque modification au code
   source
 • S’assurer de ne pas produire de régression
 • Feedback immédiat en cas de problème
 • Facilité d’identifier ce qui cause le problème
Référentiel
                           de sources

                         Compilation




 OUPS !      Exécution
             des tests             Logiciel
On corrige                       fonctionnel
La chose la plus simple qui marche!
• Objectifs
 • Une solution simple qui répond au besoin
 • Code facile à comprendre et à maintenir
• Moyens
 • Éliminer le réflexe du BDUF
 • Faire ce qui est nécessaire maintenant
 • Réfléchir, consulter, discuter
     C’est beaucoup plus difficile qu’il n’y paraît!
• Éviter les « tant qu’à y être » (YAGNI)
• S’en tenir aux choses simples (KISS)
• Éviter la duplication (DRY)
• Code doit être explicite et clair
 • Oublions les commentaires
 • Le code lui-même doit être clair
• Vous appliquez toutes ces pratiques
• Que va-t-il arriver au code?
• Quelle sera la productivité de l’équipe?
• Constat: le code a besoin
  de soins
• Sinon: dette technique
Coût de développement




 Bas
                                     Élevés




Temps
                                          Hors contrôle




                 Mise au rancart
                                          Perte $$$




               Durée de vie prévue
Gain de
productivité
• Aussi appelé «Refactoring »
• Qu’est-ce que c’est?
 • Modifier la structure du code (conception) sans
   altérer le fonctionnement du système
• Pourquoi?
 • Ne pas sacrifier l’excellence technique à
   l’évolution
 • Parfaire constamment le code
Recette
 1. Identifier le(s) changement(s) à réaliser
 2. Faire une modification ciblée
 3. Rouler les tests unitaires
   •   Identifier et corriger les problèmes
 4. Appliquer la modification, si elle fonctionne
 5. Recommencer
En faire souvent pour devenir à l’aise
• Changement ≠ amelioration
• Comment s’assurer que l’on s’en va à la
  bonne place?
• Mesurer, mais quoi?
• Exemples
 • Évaluer le respect des standards et conventions
 • Analyser la complexité du code
 • Résultats des essais (unitaires, acceptation)
• Intégrer au processus de build
Contexte de l’intervention
 • Difficulté à livrer de la valeur d’affaires
 • Produit livrée de faible qualité
Situation
 • Code patrimonial hérité de projets antérieurs
 • Effort d’architecture plus récent, mais sans
   modifier les pratiques
 • Initiative de revoir les pratiques et mesurer
   l’impact
Concepts simples, mais rigueur requise!
Plan de match
• Identifiez vos leaders positifs (champions)
• Introduisez les pratiques successivement
• Allouez du temps à l’équipe pour apprendre
• Mesurez les impacts des changements
Défi: compétences en conception OO
N’hésitez pas à aller chercher de l’aide
Scrum Developer Training (Scrum.org)
Pratiques de développement pour équipes Agile

Contenu connexe

Tendances

La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !
Lucian Precup
 
De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?
Goood!
 
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisationAgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
Agile Toulouse
 
De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?
Goood!
 

Tendances (20)

Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeaux
 
La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
 
Formation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratifFormation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratif
 
Et si on jouait au tdd 20131017
Et si on jouait au tdd 20131017Et si on jouait au tdd 20131017
Et si on jouait au tdd 20131017
 
Y sont pas cher mes tests
Y sont pas cher mes testsY sont pas cher mes tests
Y sont pas cher mes tests
 
Method XP
Method XP Method XP
Method XP
 
De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?
 
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisationAgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
 
Les Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileLes Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/Agile
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
 
Coding dojo en entreprise
Coding dojo en entrepriseCoding dojo en entreprise
Coding dojo en entreprise
 
De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?
 
Futur tunis
Futur tunisFutur tunis
Futur tunis
 
Université du soir - TDD
Université du soir - TDDUniversité du soir - TDD
Université du soir - TDD
 
Xtreme Programming
Xtreme ProgrammingXtreme Programming
Xtreme Programming
 
[Agile Testing Day] Test Driven Development (TDD)
[Agile Testing Day] Test Driven Development (TDD)[Agile Testing Day] Test Driven Development (TDD)
[Agile Testing Day] Test Driven Development (TDD)
 
La relecture de code : avant tout des pratiques
La relecture de code : avant tout des pratiquesLa relecture de code : avant tout des pratiques
La relecture de code : avant tout des pratiques
 
Genielogiciel
GenielogicielGenielogiciel
Genielogiciel
 
AT2010 Principes Integration Continue
AT2010 Principes Integration ContinueAT2010 Principes Integration Continue
AT2010 Principes Integration Continue
 

Similaire à Pratiques de développement pour équipes Agile

TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
French Scrum User Group
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
Clement Bouillier
 
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
Cyrille Grandval
 

Similaire à Pratiques de développement pour équipes Agile (20)

TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
 
L'Agilité chez GEE Montréal
L'Agilité chez GEE MontréalL'Agilité chez GEE Montréal
L'Agilité chez GEE Montréal
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testable
 
Vincent Biret Societic devops Sherbrooke
Vincent Biret Societic devops SherbrookeVincent Biret Societic devops Sherbrooke
Vincent Biret Societic devops Sherbrooke
 
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDDWebinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
 
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
 
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
 
Usine Logicielle 2013
Usine Logicielle 2013Usine Logicielle 2013
Usine Logicielle 2013
 
C'est quoi, du bon code ?
C'est quoi, du bon code ?C'est quoi, du bon code ?
C'est quoi, du bon code ?
 
L'integration continue pour tous
L'integration continue pour tousL'integration continue pour tous
L'integration continue pour tous
 
Lunch learn 5 sep2013
Lunch learn 5 sep2013Lunch learn 5 sep2013
Lunch learn 5 sep2013
 
Le pilotage par les tests
Le pilotage par les testsLe pilotage par les tests
Le pilotage par les tests
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
 
Agile Data Warehousing - 7 pillars - Procima Experts
Agile Data Warehousing - 7 pillars - Procima ExpertsAgile Data Warehousing - 7 pillars - Procima Experts
Agile Data Warehousing - 7 pillars - Procima Experts
 
Mockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice Duteil
 
Processus d’intégration continue et outils
Processus d’intégration continue et outilsProcessus d’intégration continue et outils
Processus d’intégration continue et outils
 
4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel
 

Plus de Agile Tour 2009 Québec

Plus de Agile Tour 2009 Québec (9)

Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
 
Introduction au Kanban et expérience pratique chez IBM Bromont
Introduction au Kanban et expérience pratique chez IBM BromontIntroduction au Kanban et expérience pratique chez IBM Bromont
Introduction au Kanban et expérience pratique chez IBM Bromont
 
L’agilité dans des projets d’envergure
L’agilité dans des projets d’envergureL’agilité dans des projets d’envergure
L’agilité dans des projets d’envergure
 
Waste and Trashing
Waste and TrashingWaste and Trashing
Waste and Trashing
 
La technique Pomodoro
La technique PomodoroLa technique Pomodoro
La technique Pomodoro
 
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
 
Intégration d'Agile dans un domaine multidisciplinaire
Intégration d'Agile dans un domaine multidisciplinaire Intégration d'Agile dans un domaine multidisciplinaire
Intégration d'Agile dans un domaine multidisciplinaire
 
Open Space
Open SpaceOpen Space
Open Space
 
Exemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUMExemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUM
 

Pratiques de développement pour équipes Agile

  • 2. • Pourquoi parler de pratiques • Les pratiques • Cas vécu: résultats • Répondre à vos questions
  • 3. • Dans le domaine des TI depuis 1994 • Pratique le développement Agile depuis 2003 • Conseiller chez Elapse Technologies • MCAD + Certified ScrumMaster • Accompagne les équipes dans la mise en place des bonnes pratiques de développement durant les projets
  • 4.
  • 5. • L’état actuel de notre industrie • Malheureusement encore « artisanal » • Niveau de maturité inégal • Qualité logicielle encore déficiente • Selon le Standish Group: • Ratio de 3:1 des bogues logiciels vs matériel • Cause de 55% des pannes de systèmes • 300 milliards de pertes annuellement • Échecs de projets Agile • Scrum en particulier
  • 6.
  • 7. • Avoir des normes et conventions communes • Pourquoi c’est important • Assurer une uniformité dans le code • Permettre à tous de le lire et le comprendre • Faciliter l’arrivée de nouvelles personnes • Comment s’y prendre • Choisir et respecter une convention • S’assurer du respect de cette convention
  • 8. « Paul est absent, on devra attendre son retour pour finir le correctif » • Permettre à tous de modifier le code • Répartir la connaissances dans toute l’équipe • Moyens • Effectuer une rotation des les assignations • Revue de code et discussions • Travailler en équipe à la résolution des problèmes
  • 9. • 2 personnes 1 ordi (1 clavier, 1 souris) • Alternance entre rôle stratégique et tactique • Pourquoi faire? • 2 têtes valent mieux qu’une: conception améliorée • Revue instantanée de tout le code écrit • Ça demeure un pratique controversée • Payer deux personnes pour le même travail? • “Ce qui est complexe en programmation ce n’est pas de taper le code” • Changement des habitudes de travail
  • 10. • Suggestion: appliquer l’esprit et non la lettre • Aussi souvent que possible • Lors de la conception, de refactorisation • Lorsque vous êtes bloqué -> immédiatement! • Mais laissez-vous souffler un peu! • Essentiel: franchise et respect
  • 11. • État de la situation • Une bonne pratique de génie logiciel • Encore peu systématisé dans les équipes • Souvent escamoté • Qu’est-ce qu’un test unitaire? • Tester une petite partie de code indépendamment des autres • S’assurer de la conformité des résultats en toutes circonstances
  • 12. longueur largeur Supposons la fonction (simple) CalculerAire(largeur, longueur) As Double Combien de tests sont nécessaires? 1. Valeurs positives -> vérifier résultat = largeur x longueur 2. Valeurs de 0 -> résultat = 0 3. Valeurs négatives -> retourne erreur 4. Combinaisons des conditions précédentes
  • 13. • « Ça marche seulement pour les cas simples! » • « C’est vrai… » • Justement… On recherche des implémentations simples!!! Solution = ensemble de simplicités
  • 14. • TDD: « Test-Driven Development » • En français: Développement piloté par les tests • TDD est un cadre de travail • Emphase sur la conception • Comprendre ce qu’on doit faire avant de coder • Valorise le travail de qualité • Conception pilotée par les tests
  • 15. Réflexion Programmer Programmer le test l’implémentation
  • 16. • Meilleure conception • Couplage faible • Cohésion élevée • Documentation toujours à jour • Patrimoine de cas d’essais important • Maintenance et évolution facilitées • Filet de sureté essentiel pour l’équipe • Réduit les anomalies de régression
  • 17. • Qu’est-ce que l’intégration? • C’est le processus par lequel un ensemble de modifications au code est mise en commun • Pourquoi continuellement? • Vérifier l’impact de chaque modification au code source • S’assurer de ne pas produire de régression • Feedback immédiat en cas de problème • Facilité d’identifier ce qui cause le problème
  • 18. Référentiel de sources Compilation OUPS ! Exécution des tests Logiciel On corrige fonctionnel
  • 19. La chose la plus simple qui marche! • Objectifs • Une solution simple qui répond au besoin • Code facile à comprendre et à maintenir • Moyens • Éliminer le réflexe du BDUF • Faire ce qui est nécessaire maintenant • Réfléchir, consulter, discuter C’est beaucoup plus difficile qu’il n’y paraît!
  • 20. • Éviter les « tant qu’à y être » (YAGNI) • S’en tenir aux choses simples (KISS) • Éviter la duplication (DRY) • Code doit être explicite et clair • Oublions les commentaires • Le code lui-même doit être clair
  • 21. • Vous appliquez toutes ces pratiques • Que va-t-il arriver au code? • Quelle sera la productivité de l’équipe? • Constat: le code a besoin de soins • Sinon: dette technique
  • 22. Coût de développement Bas Élevés Temps Hors contrôle Mise au rancart Perte $$$ Durée de vie prévue
  • 24. • Aussi appelé «Refactoring » • Qu’est-ce que c’est? • Modifier la structure du code (conception) sans altérer le fonctionnement du système • Pourquoi? • Ne pas sacrifier l’excellence technique à l’évolution • Parfaire constamment le code
  • 25. Recette 1. Identifier le(s) changement(s) à réaliser 2. Faire une modification ciblée 3. Rouler les tests unitaires • Identifier et corriger les problèmes 4. Appliquer la modification, si elle fonctionne 5. Recommencer En faire souvent pour devenir à l’aise
  • 26. • Changement ≠ amelioration • Comment s’assurer que l’on s’en va à la bonne place? • Mesurer, mais quoi? • Exemples • Évaluer le respect des standards et conventions • Analyser la complexité du code • Résultats des essais (unitaires, acceptation) • Intégrer au processus de build
  • 27.
  • 28. Contexte de l’intervention • Difficulté à livrer de la valeur d’affaires • Produit livrée de faible qualité Situation • Code patrimonial hérité de projets antérieurs • Effort d’architecture plus récent, mais sans modifier les pratiques • Initiative de revoir les pratiques et mesurer l’impact
  • 29.
  • 30. Concepts simples, mais rigueur requise! Plan de match • Identifiez vos leaders positifs (champions) • Introduisez les pratiques successivement • Allouez du temps à l’équipe pour apprendre • Mesurez les impacts des changements Défi: compétences en conception OO N’hésitez pas à aller chercher de l’aide