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
•...
• L’état actuel de notre industrie
 • Malheureusement encore « artisanal »
 • Niveau de maturité inégal
• Qualité logiciel...
• Avoir des normes et conventions communes
• Pourquoi c’est important
 • Assurer une uniformité dans le code
 • Permettre ...
« Paul est absent, on devra attendre
      son retour pour finir le correctif »

• Permettre à tous de modifier le code
• ...
• 2 personnes 1 ordi (1 clavier, 1 souris)
• Alternance entre rôle stratégique et tactique
• Pourquoi faire?
 • 2 têtes va...
• Suggestion: appliquer l’esprit et non la lettre
• Aussi souvent que possible
 • Lors de la conception, de refactorisatio...
• État de la situation
 • Une bonne pratique de génie logiciel
 • Encore peu systématisé dans les équipes
 • Souvent escam...
longueur




                                                                 largeur
Supposons la fonction (simple)
 Calc...
• « Ça marche seulement pour les cas
  simples! »
• « C’est vrai… »
• Justement… On recherche des
  implémentations simple...
• TDD: « Test-Driven Development »
 • En français: Développement piloté par les tests

• TDD est un cadre de travail
 • Em...
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 ...
• Qu’est-ce que l’intégration?
 • C’est le processus par lequel un ensemble de
   modifications au code est mise en commun...
Référentiel
                           de sources

                         Compilation




 OUPS !      Exécution
       ...
La chose la plus simple qui marche!
• Objectifs
 • Une solution simple qui répond au besoin
 • Code facile à comprendre et...
• Éviter les « tant qu’à y être » (YAGNI)
• S’en tenir aux choses simples (KISS)
• Éviter la duplication (DRY)
• Code doit...
• Vous appliquez toutes ces pratiques
• Que va-t-il arriver au code?
• Quelle sera la productivité de l’équipe?
• Constat:...
Coût de développement




 Bas
                                     Élevés




Temps
                                     ...
Gain de
productivité
• Aussi appelé «Refactoring »
• Qu’est-ce que c’est?
 • Modifier la structure du code (conception) sans
   altérer le fonc...
Recette
 1. Identifier le(s) changement(s) à réaliser
 2. Faire une modification ciblée
 3. Rouler les tests unitaires
   ...
• Changement ≠ amelioration
• Comment s’assurer que l’on s’en va à la
  bonne place?
• Mesurer, mais quoi?
• Exemples
 • É...
Contexte de l’intervention
 • Difficulté à livrer de la valeur d’affaires
 • Produit livrée de faible qualité
Situation
 •...
Concepts simples, mais rigueur requise!
Plan de match
• Identifiez vos leaders positifs (champions)
• Introduisez les prat...
Scrum Developer Training (Scrum.org)
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
Prochain SlideShare
Chargement dans…5
×

Pratiques de développement pour équipes Agile

637 vues

Publié le

Présentation de David Beaumier d'Élapse Technologies lors de l'Agile Tour 2009 Québec.

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

Aucun téléchargement
Vues
Nombre de vues
637
Sur SlideShare
0
Issues des intégrations
0
Intégrations
7
Actions
Partages
0
Téléchargements
31
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Pratiques de développement pour équipes Agile

  1. 1. David Beaumier
  2. 2. • Pourquoi parler de pratiques • Les pratiques • Cas vécu: résultats • Répondre à vos questions
  3. 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. 4. • 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
  5. 5. • 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
  6. 6. « 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
  7. 7. • 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
  8. 8. • 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
  9. 9. • É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
  10. 10. 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
  11. 11. • « Ça marche seulement pour les cas simples! » • « C’est vrai… » • Justement… On recherche des implémentations simples!!! Solution = ensemble de simplicités
  12. 12. • 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
  13. 13. Réflexion Programmer Programmer le test l’implémentation
  14. 14. • 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
  15. 15. • 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
  16. 16. Référentiel de sources Compilation OUPS ! Exécution des tests Logiciel On corrige fonctionnel
  17. 17. 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!
  18. 18. • É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
  19. 19. • 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
  20. 20. Coût de développement Bas Élevés Temps Hors contrôle Mise au rancart Perte $$$ Durée de vie prévue
  21. 21. Gain de productivité
  22. 22. • 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
  23. 23. 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
  24. 24. • 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
  25. 25. 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
  26. 26. 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
  27. 27. Scrum Developer Training (Scrum.org)

×