Pratiques de développement pour équipes Agile

538 views
493 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
538
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
30
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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)

×