• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Chouette! Encore un bug! Agile Tour 2012
 

Chouette! Encore un bug! Agile Tour 2012

on

  • 1,001 views

A bug can be a learning opportunity

A bug can be a learning opportunity

Statistics

Views

Total Views
1,001
Views on SlideShare
992
Embed Views
9

Actions

Likes
4
Downloads
0
Comments
0

1 Embed 9

https://twitter.com 9

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Portia and Pascal introduce themselves by sharing a bit about their background.
  • Portia and Pascal introduce themselves by sharing a bit about their background.

Chouette! Encore un bug! Agile Tour 2012 Chouette! Encore un bug! Agile Tour 2012 Presentation Transcript

  • Chouette! Encore un bug! Pascal Van Cauwenberghe
  • Bonjour Donne des conseils Programme Gère des projets Crée des Jeux Organise des ConférencesNAYIMAWe make play workwww.nayima.beblog.nayima.be
  • CLAUSE DE NON-RESPONSABILITÉ
  • Clause de non-responsabilité• Cette présentation contient du code – Sans garantie que ça compile• Cette présentation contient des insectes – A éviter pour les entomophobes
  • Based on true stories• In different countries• In different projects• With different teams• Using different (programming) languages
  • Chouette! Encore un bug!Comment passer toute la journée à corriger un tout petit bug
  • Maman....D’où viennent les bugs?
  • Euh....Il était une fois un projet...
  • Contexte• Société globale• Grande application web• Mission critical, 24/7• Majeure source de revenue• Premier projet Agile de l’équipe• Je les accompagne comme coach• Nous devons modifier et étendre une petite partie de l’application
  • Le ProjetL’applicationNOUS
  • Scene 1:Un développeur découvre un bug
  • Que faites vous quand on vous dit “J’ai trouvé un bug...” ?
  • MERCI! MERCI !
  • Algoritme du code parfait1. TROUVER UN BUG2. DIRE “MERCI !”3. ......11. ...
  • MERCI! MERCI !
  • Scene 2:Qu’est-ce qu’on fait ?
  • CECI N’EST PAS UN BUG
  • CECI EST UNE OPPORTUNITE
  • ASTUCES• Sans blâme• Personne n’est coupable• Attention au langage: – “Excercice”, “Experiment”, “Apprendre”, “Améliorer” – “Nous”, “Notre code”, “Notre problème”• Approche “Solution Focus”
  • Scene 3: L’équipe fait uneRoot Cause Analysis (RCA)5 développeurs + architecte
  • “Le client a droit à unremboursement jusqu’au moment de la livraison”
  • Qui voit le problème?boolean refundAllowed(Product product) { Datetime delivery = Datetime.parse("yyyy-MM-dd“, product.deliveryAt()); Datetime now = Datetime.now; return now <= delivery ;}
  • MERCI! MERCI !
  • On teste l’application• Livraison le 23/11/2012 à 16:00• Il est maintenant 22/11/2012 17:45• 22/11/2012 17:45 <= 23/11/2012 00:00 ?
  • Let’s test the application• Livraison le 23/11/2012 à 16:00• Il est maintenant 22/11/2012 17:45• 22/11/2012 17:45 <= 23/11/2012 00:00 ? Remboursement? OUI
  • On teste l’application• Livraison le 22/11/2012 à 20:00• Il est maintenant 22/11/2012 17:45• 22/11/2012 17:45 <= 22/11/2012 00:00 ?
  • Let’s test the application• Livraison le 22/11/2012 à 20:00• Il est maintenant 22/11/2012 17:45• 22/11/2012 17:45 <= 22/11/2012 00:00 ? Remboursement? NON
  • Algoritme du code parfait1. TROUVER UN BUG2. DIRE “MERCI !”3. REPRODUIRE LE PROBLEME4. ...
  • Est-ce qu’on peut corriger le code ? C’est tout simple !
  • Algoritme du code parfait1. TROUVER UN BUG2. DIRE “MERCI !”3. REPRODUIRE LE PROBLEME4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE5. ...
  • Un nouveau testvoid testRefundGivenWhenDeliveryLaterToday() {Datetime now = DateTime.now ;String endofDay = now.strftime(“yyyy-MM-dd") + " 23:59" ;Product product = ...product.deliveryAt(endOfDay) ;BusinessRule businessRule = ...bool refund = businessRule.refundAllowed(product);assertTrue(refund,“Refund allowed until delivery, even on the day of delivery") ;}
  • Un nouveau testvoid testRefundGivenWhenDeliveryLaterToday() {Datetime now = DateTime.now ;String endofDay = now.strftime(“yyyy-MM-dd") + " 23:59" ;Product product = ...product.deliveryAt(endOfDay) ;BusinessRule businessRule = ...bool refund = businessRule.refundAllowed(product);assertTrue(refund,“Refund allowed until delivery, even on the day of delivery") ;}
  • Est-ce qu’on peut corriger le code ? C’est tout simple !
  • Enfin, on corrige le bugboolean refundAllowed(Product product) { Datetime delivery = Datetime.parse( "yyyy-MM-dd HH:MM“,product.deliveryAt()); Datetime now = Datetime.now; return now <= delivery ;}
  • On relance le testvoid testRefundGivenWhenDeliveryLaterToday() {Datetime now = DateTime.now ;String endofDay = now.strftime(“yyyy-MM-dd") + " 23:59" ;Product product = ...product.deliveryAt(endOfDay) ;BusinessRule businessRule = ...bool refund = businessRule.refundAllowed(product);assertTrue(refund,“Refund allowed until delivery, even on the day of delivery") ;}
  • Algoritme du code parfait1. TROUVER UN BUG2. DIRE “MERCI !”3. REPRODUIRE LE PROBLEME4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE5. CORRIGER LE PROBLEME6. TOUS LES TESTS PASSENT7. ...
  • “Ce truc agile prendra beaucoup de tempssi on va faire ça pour tous les bugs !”“Oui, mais on a plus de confiance qu’on abien corrigé le bug et qu’on n’a pas casséautre chose.”
  • “On a vraiment suivi notre principe‘qualité sans compromis’.”
  • “On devrait contacter l’équipe responsablepour leur dire qu’on a corrigé le bug.”“Il y a peut-être déjà des réclamations parnos clients. On devrait informer les servicesupport client”
  • Astuce• Définir et afficher les valeurs de l’équipe• Maintenez un liste visible des actions issues de la Root Cause Analysis (RCA)• Langage: – “On devrait ...” => “On va ...”
  • ON VA...• Contacter l’équipe dev responsable• Informer le service support client
  • Algoritme du code parfait1. TROUVER UN BUG2. DIRE “MERCI !”3. REPRODUIRE LE PROBLEME4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE5. CORRIGER LE PROBLEME6. TOUS LES TESTS PASSENT7. EXECUTER LES ACTIONS ISSUES DU RCA8. ...
  • “Bon travail, les gars.”“Retournons au boulot!”
  • THE ENDEt ils vécurent heureux à tout jamais ...
  • C’est pas encore fini!
  • Scene 4: Après la correctionLe testeur rejoint les développeurs et l’architecte
  • Algoritme du code parfait1. TROUVER UN BUG2. DIRE “MERCI !”3. REPRODUIRE LE PROBLEME4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE5. CORRIGER LE PROBLEME6. TOUS LES TESTS PASSENT7. EXECUTER LES ACTIONS ISSUES DU RCA8. AMELIORER LES TESTS9. ...
  • Comment améliorer nos tests? Nous aurions dû trouver ce bug plus tôt
  • Comment améliorer nos tests? Nous aurions dû allons trouver ce genre de bug plus tôt
  • Comment améliorer nos tests? Nous allons trouver ce genre de bug plus tôt
  • Contexte (2)• L’application a presque 80% de couverture de code avec des tests automatiques• Ce module a une couverture de 100%• Mais contient (au moins) un bug• Pourquoi ?• Regardons les tests ...
  • Qui voit le problème ?void testRefundGiven() { Product product = ... product.deliveryAt(“2050-12-31 19:00”) ; BusinessRule businessRule = ... bool allowed = businessRule.refundAllowed(product)}
  • MERCI! MERCI !
  • Comment améliorer nos tests?• Il n’y a pas d’ ASSERT ! – Facile d’avoir 100% de couverture• Pourquoi 2050? – Qu’est-ce qui se passe le 1er janvier 2051?• Il faut au moins 4 tests – Livraison avant aujourd’hui – Livraison aujourd’hui avant maintenant – Livraison aujourd’hui après maintenant – Livraison après aujourd’hui
  • Pourquoi?• Développeurs ne savent pas comment tester du code avec des dates (et des zones horaires) – Beaucoup de tests avec des dates en 2050• Peu de développeurs avec de l’experience en tests unitaires• Coaching Agile dans le passé ne contenait pas de formation technique
  • On va...• Contacter l’équipe de dev responsable• Informer le service support client• Ajouter des tests pour les dates, qui peuvent servir comme exemple• Montrer nos exemples aux autres équipes
  • Développeurs: “On a encore beaucoup àapprendre”Architecte: “J’ai toujours eu des doutes ausujet des tests. Maintenant je saispourquoi.”
  • Testeur: “Si vous voulez, je peux vousaider à écrire des tests”
  • Creusons un peu ... Pourquoi des tests sans ASSERT?• But: “augmenter la couverture par les tests automatiques” au lieu de “augmenter la qualit锕 Pression pour livrer des fonctionnalités• Peu d’experience en testing• TEST LAST au lieu de TEST FIRST• Pas de formation ou coaching sur les aspects techniques Agile• Peu de coaches avec de l’experience technique
  • On va...• Contacter l’équipe de dev responsable• Informer le service support client• Ajouter des tests pour les dates, qui peuvent servir comme exemple• Montrer nos exemples aux autres équipes• Appliquer le TDD en binôme avec le coach et le testeur• Ajouter « Manque de coaching technique » à la liste des risques du coach meeting
  • Systems Thinking
  • Algoritme du code parfait1. TROUVER UN BUG2. DIRE “MERCI !”3. REPRODUIRE LE PROBLEME4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE5. CORRIGER LE PROBLEME6. TOUS LES TESTS PASSENT7. EXECUTER LES ACTIONS ISSUES DU RCA8. AMELIORER LES TESTS9. AMELIORER LA FACON D’ECRIRE LES TESTS10. ...
  • The EndEt ils vécurent heureux à tout jamais.. “On a beaucoup à apprendre”
  • I’m BACK !
  • Scene 5: Après les testsUn bug n’arrive jamais seul...
  • Est-ce que ce bug est arrivé seul?
  • Cherchons dans le code...• 10 cas où on parse cette date – 5 fois avec “yyyy-MM-dd HH:MM” – 5 fois avec “yyyy-MM-dd”• Chaque développeur analyse un cas• Résultat: deux bugs en plus
  • Qu’est-ce que vous dites ?
  • MERCI! MERCI !
  • Encore une fois...
  • MERCI! MERCI !
  • Algoritme du code parfait1. TROUVER UN BUG2. DIRE “MERCI !”3. REPRODUIRE LE PROBLEME4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE5. CORRIGER LE PROBLEME6. TOUS LES TESTS PASSENT7. EXECUTER LES ACTIONS ISSUES DU RCA8. AMELIORER LES TESTS9. AMELIORER LA FACON D’ECRIRE LES TESTS10. RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 211. ...
  • “Qualité sans compromis”. Facile à dire,difficile à faire“Ecrire les tests et corriger lesproblèmes devient de plus en plus de laroutine. Ca va de plus en plus vite.”
  • Enfin, La Fin?Est-ce qu’on peut vivre heureux à tout jamais, maintenant ?
  • C’est pas encore fini!
  • Est-ce que vous voyez encore un problème?
  • MERCI! MERCI !
  • Creusons un peu... Pourquoi est-ce qu’on a écrit ce bug?• On ne se rend pas compte qu’il y a une date + temps• On a 10x le même code de parsing• => 10 opportunités pour des erreurs• Enlevons la duplication
  • Améliorons Productclass Product {... // Deprecated: Remove when obsolete String deliveryAt() ; // New: gradually refactor all clients DateTime deliveryAtDateTime() ;...}From “stringly typed” to “strongly typed”
  • Algoritme du code parfait1. TROUVER UN BUG2. DIRE “MERCI !”3. REPRODUIRE LE PROBLEME4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE5. CORRIGER LE PROBLEME6. TOUS LES TESTS PASSENT7. EXECUTER LES ACTIONS ISSUES DU RCA8. AMELIORER LES TESTS9. AMELIORER LA FACON D’ECRIRE LES TESTS10. RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 211. RENDRE IMPOSSIBLE DE REFAIRE LA MEME ERREUR
  • Maman....D’ou viennent les strings?
  • L’application ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO System AABCDEFGHIJKLMNO ABCDEFGHIJKLMNO Application ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO System B
  • L’application (vision) ABCDEFGHIJKLMNO System AL’application ABCDEFGHIJKLMNO System B
  • On va...• Contacter l’équipe de dev responsable• Informer le service support client• Ajouter des tests pour les dates, qui peuvent servir comme exemple• Montrer nos exemples aux autres équipes• Appliquer le TDD en binôme avec le coach et le testeur• Ajouter « Manque de coaching technique » à la liste des risques du coach meeting• Encapsuler les données qui viennent de l’exterieur
  • GRAND REFACTORING
  • Proposition A3
  • Proposition A3 Description du problèmeAVANT APRESSTEPS: Visualisation1. .jdlkjds2. Kmlkdmlkd3. Dkqjdlkjds4. Sqkjlkdlksqmk5. BEER !
  • ASTUCE• La proposition A3 reste visible pendant toute la durée• Affichez l’A3 où on ne peut pas la manquer• Limitez le nombre de propositions A3
  • Scene 6:Acte Final
  • Qu’est-ce qui s’est passé?1. 7 membres de l’équipe + un coach ont passé tout l’après-midi à corriger un bug de 6 caractères. Est-ce raisonable?2. On a trouvé beaucoup moins de bugs que dans les projets “normaux”? Y a-t-il un lien?3. Le projet a été livré en 5 mois au lieu de 8. Comment peut-on finir plus vite en allant plus lentement?
  • Theory of Constraints in a nutshell
  • Combien est-ce qu’ils livrent? Test &Analysis: Dev: 20 10 Deploy: 15 ???
  • Combien est-ce qu’ils livrent? Test &Analysis: Dev: 20 10 Deploy: 15 <= 10
  • Combien est-ce qu’ils livrent? Test & Analysis: Dev: 20 10 Deploy: 15 ???Analysis: Dev: 10 12
  • Combien est-ce qu’ils livrent? Test & Analysis: Dev: 20 10 Deploy: 15 <= 15Analysis: Dev: 10 12
  • Si on développe plus vite? Test & Analysis: Dev: 20 20 Deploy: 15 ???Analysis: Dev: 10 12
  • Aucun changement? Test & Analysis: Dev: 20 20 Deploy: 15 <= 15Analysis: Dev: 10 12
  • Le backlog se remplit! Test & Analysis: Dev: 20 20 Deploy: 15 < 15Analysis: Dev: 10 12
  • Est-ce qu’on peut faire mieux? Test & Analysis: Dev: 20 10 Deploy: 15 <= 15Analysis: Dev: 10 12
  • Et si on allait plus lentement? Test & Analysis: Dev: 20 8 Deploy: 15 <= 15Analysis: Dev: 10 12
  • Et si on allait plus lentement? Test & Analysis: Dev: 20 8 Deploy: 17 <= 17Analysis: Dev: 10 12
  • Pourquoi écrire tant de stories? Test & Analysis: Dev: 20 8 Deploy: 17 <= 17Analysis: Dev: 10 12
  • On fait moins On livre plus Test & Dev: <= 17 Analysis: 10 Deploy: 8 17Analysis: Dev: 10 12
  • The Bottleneck Game
  • Pour en savoir plus
  • Combien coûte la qualité?
  • PUB• Quand il n’y a plus de bugs... Appliquez IDD™ Irritation Driven Development®Contact me if you want to become a Certifiable Irritating Person
  • ASTUCES• Binomez avec le goulot d’étranglement• Marchez dans leurs souliers• Observez et notez les irritations – Eliminez les irritations, sans fanfare• Exemple: installation dev-ops
  • En Résumé
  • Algoritme du code parfait1. TROUVER UN BUG2. DIRE “MERCI !”3. REPRODUIRE LE PROBLEME4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE5. CORRIGER LE PROBLEME6. TOUS LES TESTS PASSENT7. EXECUTER LES ACTIONS ISSUES DU RCA8. AMELIORER LES TESTS9. AMELIORER LA FACON D’ECRIRE LES TESTS10. RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 211. RENDRE IMPOSSIBLE DE REFAIRE LA MEME ERREUR
  • PARLONSRESPONSABILITÉ
  • Qu’allez vous faire demain pour augmenter la qualité? “Quality is Free” Philip Crosby
  • Mais le plus important ...
  • MERCI! MERCI !
  • LA FINEt ils vécurent heureux à tout jamais
  • SESSION FEEDBACK
  • Merci, Dank u, Thank you, Danke, Tak,Kiitos, Gracias, Grazie, Tack, Obrigado, Arigatou Gozaimasu Donne des conseils Programme Gère des projets Crée des Jeux Organise des conférences NAYIMA We make play work http://www.nayima.be http://www.agilecoach.net