pratiques de développement pour équipes agile
DESCRIPTION
Présentation de David Beaumier d'Élapse Technologies lors de l'Agile Tour 2009 Québec.TRANSCRIPT
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
1. Valeurs positives -> vérifier résultat = largeur x longueur2. Valeurs de 0 -> résultat = 03. Valeurs négatives -> retourne erreur4. Combinaisons des conditions précédentes
Supposons la fonction (simple)CalculerAire(largeur, longueur) As Double
larg
eu
r
longueur
Combien de tests sont nécessaires?
• « Ç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
le testProgrammer
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
Compilation
Exécution des tests
Référentiel de sources
OUPS ! On corrige
Logiciel 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
Temps
Co
ût
de
dév
elo
pp
eme
nt
Hors contrôle
Mis
e a
u r
anca
rt
Du
rée
de
vie
pré
vue
Perte $$$Élevés
Bas
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
Recette1. 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)