SlideShare uma empresa Scribd logo
1 de 124
Chouette! Encore un bug!




     Pascal Van Cauwenberghe
Bonjour


              Donne des conseils
              Programme
              Gère des projets
              Crée des Jeux
              Organise des Conférences



NAYIMA
We make play work

www.nayima.be
blog.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 Projet




L’application

NOUS
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 parfait
1. TROUVER UN BUG
2. 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 une
Root Cause Analysis (RCA)

5 développeurs + architecte
“Le client a droit à un
remboursement 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 parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI !”
3.   REPRODUIRE LE PROBLEME
4.   ...
Est-ce qu’on peut corriger le
           code ?

     C’est tout simple !
Algoritme du code parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI !”
3.   REPRODUIRE LE PROBLEME
4.   AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.   ...
Un nouveau test
void 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 test
void 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 bug
boolean refundAllowed(Product product) {
 Datetime delivery = Datetime.parse(
 "yyyy-MM-dd   HH:MM“,product.deliveryAt());

 Datetime now = Datetime.now;

 return now <= delivery ;}
On relance le test
void 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 parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI !”
3.   REPRODUIRE LE PROBLEME
4.   AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.   CORRIGER LE PROBLEME
6.   TOUS LES TESTS PASSENT
7.   ...
“Ce truc agile prendra beaucoup de temps
si on va faire ça pour tous les bugs !”
“Oui, mais on a plus de confiance qu’on a
bien 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 responsable
pour leur dire qu’on a corrigé le bug.”

“Il y a peut-être déjà des réclamations par
nos clients. On devrait informer les service
support 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 parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI !”
3.   REPRODUIRE LE PROBLEME
4.   AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.   CORRIGER LE PROBLEME
6.   TOUS LES TESTS PASSENT
7.   EXECUTER LES ACTIONS ISSUES DU RCA
8.   ...
“Bon travail, les gars.”

“Retournons au boulot!”
THE END
Et ils vécurent heureux à tout jamais ...
Chouette! Encore un bug! Agile Tour 2012
C’est pas encore fini!
Scene 4:
     Après la correction

Le testeur rejoint les développeurs
           et l’architecte
Algoritme du code parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI !”
3.   REPRODUIRE LE PROBLEME
4.   AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.   CORRIGER LE PROBLEME
6.   TOUS LES TESTS PASSENT
7.   EXECUTER LES ACTIONS ISSUES DU RCA
8.   AMELIORER LES TESTS
9.   ...
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 au
sujet des tests. Maintenant je sais
pourquoi.”
Testeur: “Si vous voulez, je peux vous
aider à é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 parfait
1. TROUVER UN BUG
2. DIRE “MERCI !”
3. REPRODUIRE LE PROBLEME
4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5. CORRIGER LE PROBLEME
6. TOUS LES TESTS PASSENT
7. EXECUTER LES ACTIONS ISSUES DU RCA
8. AMELIORER LES TESTS
9. AMELIORER LA FACON D’ECRIRE LES TESTS
10. ...
Chouette! Encore un bug! Agile Tour 2012
The End
Et ils vécurent heureux à tout jamais..

   “On a beaucoup à apprendre”
Chouette! Encore un bug! Agile Tour 2012
I’m BACK !
Scene 5:
     Après les tests

Un 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 parfait
1.    TROUVER UN BUG
2.    DIRE “MERCI !”
3.    REPRODUIRE LE PROBLEME
4.    AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.    CORRIGER LE PROBLEME
6.    TOUS LES TESTS PASSENT
7.    EXECUTER LES ACTIONS ISSUES DU RCA
8.    AMELIORER LES TESTS
9.    AMELIORER LA FACON D’ECRIRE LES TESTS
10.   RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2
11.   ...
“Qualité sans compromis”. Facile à dire,
difficile à faire
“Ecrire les tests et corriger les
problèmes devient de plus en plus de la
routine. 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 Product
class Product {
...
  // Deprecated: Remove when obsolete
  String deliveryAt() ;
  // New: gradually refactor all clients
  DateTime deliveryAtDateTime() ;
...
}

From “stringly typed” to “strongly typed”
Algoritme du code parfait
1.    TROUVER UN BUG
2.    DIRE “MERCI !”
3.    REPRODUIRE LE PROBLEME
4.    AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.    CORRIGER LE PROBLEME
6.    TOUS LES TESTS PASSENT
7.    EXECUTER LES ACTIONS ISSUES DU RCA
8.    AMELIORER LES TESTS
9.    AMELIORER LA FACON D’ECRIRE LES TESTS
10.   RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2
11.   RENDRE IMPOSSIBLE DE REFAIRE LA MEME ERREUR
Maman....

D’ou viennent les strings?
L’application
                                    ABCDEFGHIJKLMNO


   ABCDEFGHIJKLMNO
                                                      System A

ABCDEFGHIJKLMNO
                  ABCDEFGHIJKLMNO


 Application
            ABCDEFGHIJKLMNO
   ABCDEFGHIJKLMNO
        ABCDEFGHIJKLMNO             ABCDEFGHIJKLMNO

                                                       System B
Chouette! Encore un bug! Agile Tour 2012
L’application (vision)
                ABCDEFGHIJKLMNO

                                    System A




L’application
                  ABCDEFGHIJKLMNO


                                     System B
Chouette! Encore un bug! Agile Tour 2012
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
Chouette! Encore un bug! Agile Tour 2012
Proposition A3
Proposition A3
          Description du problème
AVANT                     APRES




STEPS:                    Visualisation
1. .jdlkjds
2. Kmlkdmlkd
3. Dkqjdlkjds
4. Sqkjlkdlksqmk
5. 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
                                <= 15


Analysis:    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
                                   <= 15


Analysis:         Dev:
  10               12
Le backlog se remplit!

                            Test &
 Analysis:         Dev:
   20               20
                            Deploy:
                              15
                                      < 15


Analysis:           Dev:
  10                 12
Est-ce qu’on peut faire mieux?

                     Test &
 Analysis:   Dev:
   20         10
                     Deploy:
                       15
                               <= 15


Analysis:    Dev:
  10          12
Et si on allait plus lentement?

                       Test &
 Analysis:    Dev:
   20          8
                       Deploy:
                         15
                                 <= 15


Analysis:     Dev:
  10           12
Et si on allait plus lentement?

                       Test &
 Analysis:    Dev:
   20          8
                       Deploy:
                         17
                                 <= 17


Analysis:     Dev:
  10           12
Pourquoi écrire tant de stories?

                    Test &
 Analysis:   Dev:
   20         8
                    Deploy:
                      17
                              <= 17


Analysis:    Dev:
  10          12
On fait moins
             On livre plus

                        Test &
              Dev:
                                  <= 17
 Analysis:
   10                   Deploy:
               8
                          17




Analysis:     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 parfait
1.    TROUVER UN BUG
2.    DIRE “MERCI !”
3.    REPRODUIRE LE PROBLEME
4.    AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.    CORRIGER LE PROBLEME
6.    TOUS LES TESTS PASSENT
7.    EXECUTER LES ACTIONS ISSUES DU RCA
8.    AMELIORER LES TESTS
9.    AMELIORER LA FACON D’ECRIRE LES TESTS
10.   RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2
11.   RENDRE IMPOSSIBLE DE REFAIRE LA MEME ERREUR
PARLONS
RESPONSABILITÉ
Qu’allez vous faire demain pour
    augmenter la qualité?
         “Quality is Free”
          Philip Crosby
Mais le plus important ...
MERCI!




    MERCI !
LA FIN
Et 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
Chouette! Encore un bug! Agile Tour 2012

Mais conteúdo relacionado

Mais procurados

Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?CGI Québec Formation
 
Rappels Modularisation application C/C++
Rappels Modularisation application C/C++Rappels Modularisation application C/C++
Rappels Modularisation application C/C++Sylvain Leroy
 
Industrialisation des développements logiciels
Industrialisation des développements logicielsIndustrialisation des développements logiciels
Industrialisation des développements logicielsSylvain Leroy
 
Recherche lead technique désespérément
Recherche lead technique désespérémentRecherche lead technique désespérément
Recherche lead technique désespérémentAgile Montréal
 
Kanban, un outil simple de gestion de la production.
Kanban, un outil simple de gestion de la production.Kanban, un outil simple de gestion de la production.
Kanban, un outil simple de gestion de la production.Blackbird
 
Integration continue et déploiement automatisé
Integration continue et déploiement automatiséIntegration continue et déploiement automatisé
Integration continue et déploiement automatiséJérémie Campari
 
Techniques accélération des pages web #kiwiparty
Techniques accélération des pages web #kiwipartyTechniques accélération des pages web #kiwiparty
Techniques accélération des pages web #kiwipartyJean-Pierre Vincent
 
Qu'est ce qu'un logiciel de qualité
Qu'est ce qu'un logiciel de qualitéQu'est ce qu'un logiciel de qualité
Qu'est ce qu'un logiciel de qualitéSylvain Leroy
 
BBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - PuppetBBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - PuppetOlivier BAZOUD
 
Cleancode / Tocea / Introduction
Cleancode / Tocea / IntroductionCleancode / Tocea / Introduction
Cleancode / Tocea / IntroductionSylvain Leroy
 
Contractualisation agile : Saison 2 (atm)
Contractualisation agile :  Saison 2 (atm)Contractualisation agile :  Saison 2 (atm)
Contractualisation agile : Saison 2 (atm)Michel Lejeune
 
Presentation Rex Methodes Agiles
Presentation Rex Methodes AgilesPresentation Rex Methodes Agiles
Presentation Rex Methodes AgilesIppon
 
Recrutement et si vous laissiez l'équipe faire ?
Recrutement et si vous laissiez l'équipe faire ?Recrutement et si vous laissiez l'équipe faire ?
Recrutement et si vous laissiez l'équipe faire ?Manuel Vacelet
 
A la poursuite du bug perdu - 2019 - THEAULT - DI GIORGIO - ACPQUALIFE
A la poursuite du bug perdu - 2019 - THEAULT - DI GIORGIO - ACPQUALIFEA la poursuite du bug perdu - 2019 - THEAULT - DI GIORGIO - ACPQUALIFE
A la poursuite du bug perdu - 2019 - THEAULT - DI GIORGIO - ACPQUALIFETelecomValley
 
Intégration Continue (Agile Nantes)
Intégration Continue (Agile Nantes)Intégration Continue (Agile Nantes)
Intégration Continue (Agile Nantes)Fabian Piau
 
Architecture express pour petits projets
Architecture express pour petits projetsArchitecture express pour petits projets
Architecture express pour petits projetsCGI Québec Formation
 
Accélérer les tests d’acceptation avec un DSL et du refactoring
Accélérer les tests d’acceptation avec un DSL et du refactoringAccélérer les tests d’acceptation avec un DSL et du refactoring
Accélérer les tests d’acceptation avec un DSL et du refactoringLaurent PY
 

Mais procurados (18)

Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?
 
Rappels Modularisation application C/C++
Rappels Modularisation application C/C++Rappels Modularisation application C/C++
Rappels Modularisation application C/C++
 
Industrialisation des développements logiciels
Industrialisation des développements logicielsIndustrialisation des développements logiciels
Industrialisation des développements logiciels
 
Recherche lead technique désespérément
Recherche lead technique désespérémentRecherche lead technique désespérément
Recherche lead technique désespérément
 
Atelier Lean Feedback
Atelier Lean FeedbackAtelier Lean Feedback
Atelier Lean Feedback
 
Kanban, un outil simple de gestion de la production.
Kanban, un outil simple de gestion de la production.Kanban, un outil simple de gestion de la production.
Kanban, un outil simple de gestion de la production.
 
Integration continue et déploiement automatisé
Integration continue et déploiement automatiséIntegration continue et déploiement automatisé
Integration continue et déploiement automatisé
 
Techniques accélération des pages web #kiwiparty
Techniques accélération des pages web #kiwipartyTechniques accélération des pages web #kiwiparty
Techniques accélération des pages web #kiwiparty
 
Qu'est ce qu'un logiciel de qualité
Qu'est ce qu'un logiciel de qualitéQu'est ce qu'un logiciel de qualité
Qu'est ce qu'un logiciel de qualité
 
BBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - PuppetBBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - Puppet
 
Cleancode / Tocea / Introduction
Cleancode / Tocea / IntroductionCleancode / Tocea / Introduction
Cleancode / Tocea / Introduction
 
Contractualisation agile : Saison 2 (atm)
Contractualisation agile :  Saison 2 (atm)Contractualisation agile :  Saison 2 (atm)
Contractualisation agile : Saison 2 (atm)
 
Presentation Rex Methodes Agiles
Presentation Rex Methodes AgilesPresentation Rex Methodes Agiles
Presentation Rex Methodes Agiles
 
Recrutement et si vous laissiez l'équipe faire ?
Recrutement et si vous laissiez l'équipe faire ?Recrutement et si vous laissiez l'équipe faire ?
Recrutement et si vous laissiez l'équipe faire ?
 
A la poursuite du bug perdu - 2019 - THEAULT - DI GIORGIO - ACPQUALIFE
A la poursuite du bug perdu - 2019 - THEAULT - DI GIORGIO - ACPQUALIFEA la poursuite du bug perdu - 2019 - THEAULT - DI GIORGIO - ACPQUALIFE
A la poursuite du bug perdu - 2019 - THEAULT - DI GIORGIO - ACPQUALIFE
 
Intégration Continue (Agile Nantes)
Intégration Continue (Agile Nantes)Intégration Continue (Agile Nantes)
Intégration Continue (Agile Nantes)
 
Architecture express pour petits projets
Architecture express pour petits projetsArchitecture express pour petits projets
Architecture express pour petits projets
 
Accélérer les tests d’acceptation avec un DSL et du refactoring
Accélérer les tests d’acceptation avec un DSL et du refactoringAccélérer les tests d’acceptation avec un DSL et du refactoring
Accélérer les tests d’acceptation avec un DSL et du refactoring
 

Destaque

Keynote agile grenoble 2013
Keynote agile grenoble 2013Keynote agile grenoble 2013
Keynote agile grenoble 2013AgileCoach.net
 
Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013AgileCoach.net
 
Agreeing on business value
Agreeing on business valueAgreeing on business value
Agreeing on business valueAgileCoach.net
 
Vous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestionVous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestionAgileCoach.net
 
Journée Agilité à Ei.Cesi (17 avril 2013)
Journée Agilité à Ei.Cesi (17 avril 2013)Journée Agilité à Ei.Cesi (17 avril 2013)
Journée Agilité à Ei.Cesi (17 avril 2013)Fabrice Aimetti
 
Roses, orties et fraises - jardin-paysan de production pédagogique
Roses, orties et fraises - jardin-paysan de production pédagogique Roses, orties et fraises - jardin-paysan de production pédagogique
Roses, orties et fraises - jardin-paysan de production pédagogique Mike Durable
 
Synodiance > SEO et Contenu - 5 points clés qui changent - Ecommerce-Live - 2...
Synodiance > SEO et Contenu - 5 points clés qui changent - Ecommerce-Live - 2...Synodiance > SEO et Contenu - 5 points clés qui changent - Ecommerce-Live - 2...
Synodiance > SEO et Contenu - 5 points clés qui changent - Ecommerce-Live - 2...Search Foresight
 
Equipement techonologique en france - ARCEP - Décembre 2011
Equipement techonologique en france - ARCEP - Décembre 2011Equipement techonologique en france - ARCEP - Décembre 2011
Equipement techonologique en france - ARCEP - Décembre 2011Romain Fonnier
 
4 ir be-dimensionnement_interface_radio_2012_v3
4 ir be-dimensionnement_interface_radio_2012_v34 ir be-dimensionnement_interface_radio_2012_v3
4 ir be-dimensionnement_interface_radio_2012_v3Gilles Samba
 
Search Engine Marketing (SEO, SEA, SSO, LSO, MSO)
Search Engine Marketing (SEO, SEA, SSO, LSO, MSO)Search Engine Marketing (SEO, SEA, SSO, LSO, MSO)
Search Engine Marketing (SEO, SEA, SSO, LSO, MSO)Softeam agency
 
HUB REPORT - L'indispensable à savoir sur la Data & le CRM
HUB REPORT - L'indispensable à savoir sur la Data & le CRM HUB REPORT - L'indispensable à savoir sur la Data & le CRM
HUB REPORT - L'indispensable à savoir sur la Data & le CRM HUB INSTITUTE
 
Real Options - Agile France 2013
Real Options - Agile France 2013Real Options - Agile France 2013
Real Options - Agile France 2013AgileCoach.net
 
Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013AgileCoach.net
 
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisionsDevoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisionsAgileCoach.net
 
Agile 2010 Estimation Games
Agile 2010 Estimation  GamesAgile 2010 Estimation  Games
Agile 2010 Estimation GamesAgileCoach.net
 
Dear NSA, let me take care of your slides.
Dear NSA, let me take care of your slides.Dear NSA, let me take care of your slides.
Dear NSA, let me take care of your slides.Emiland
 
Business value by systems thinking
Business value by systems thinkingBusiness value by systems thinking
Business value by systems thinkingAgileCoach.net
 
Masters of SlideShare
Masters of SlideShareMasters of SlideShare
Masters of SlideShareKapost
 

Destaque (20)

Keynote agile grenoble 2013
Keynote agile grenoble 2013Keynote agile grenoble 2013
Keynote agile grenoble 2013
 
Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013
 
Agreeing on business value
Agreeing on business valueAgreeing on business value
Agreeing on business value
 
Vous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestionVous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestion
 
Journée Agilité à Ei.Cesi (17 avril 2013)
Journée Agilité à Ei.Cesi (17 avril 2013)Journée Agilité à Ei.Cesi (17 avril 2013)
Journée Agilité à Ei.Cesi (17 avril 2013)
 
Roses, orties et fraises - jardin-paysan de production pédagogique
Roses, orties et fraises - jardin-paysan de production pédagogique Roses, orties et fraises - jardin-paysan de production pédagogique
Roses, orties et fraises - jardin-paysan de production pédagogique
 
Synodiance > SEO et Contenu - 5 points clés qui changent - Ecommerce-Live - 2...
Synodiance > SEO et Contenu - 5 points clés qui changent - Ecommerce-Live - 2...Synodiance > SEO et Contenu - 5 points clés qui changent - Ecommerce-Live - 2...
Synodiance > SEO et Contenu - 5 points clés qui changent - Ecommerce-Live - 2...
 
Equipement techonologique en france - ARCEP - Décembre 2011
Equipement techonologique en france - ARCEP - Décembre 2011Equipement techonologique en france - ARCEP - Décembre 2011
Equipement techonologique en france - ARCEP - Décembre 2011
 
Venecia Inolvidable
Venecia InolvidableVenecia Inolvidable
Venecia Inolvidable
 
4 ir be-dimensionnement_interface_radio_2012_v3
4 ir be-dimensionnement_interface_radio_2012_v34 ir be-dimensionnement_interface_radio_2012_v3
4 ir be-dimensionnement_interface_radio_2012_v3
 
Search Engine Marketing (SEO, SEA, SSO, LSO, MSO)
Search Engine Marketing (SEO, SEA, SSO, LSO, MSO)Search Engine Marketing (SEO, SEA, SSO, LSO, MSO)
Search Engine Marketing (SEO, SEA, SSO, LSO, MSO)
 
HUB REPORT - L'indispensable à savoir sur la Data & le CRM
HUB REPORT - L'indispensable à savoir sur la Data & le CRM HUB REPORT - L'indispensable à savoir sur la Data & le CRM
HUB REPORT - L'indispensable à savoir sur la Data & le CRM
 
Real Options - Agile France 2013
Real Options - Agile France 2013Real Options - Agile France 2013
Real Options - Agile France 2013
 
J2 me
J2 meJ2 me
J2 me
 
Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013
 
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisionsDevoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
 
Agile 2010 Estimation Games
Agile 2010 Estimation  GamesAgile 2010 Estimation  Games
Agile 2010 Estimation Games
 
Dear NSA, let me take care of your slides.
Dear NSA, let me take care of your slides.Dear NSA, let me take care of your slides.
Dear NSA, let me take care of your slides.
 
Business value by systems thinking
Business value by systems thinkingBusiness value by systems thinking
Business value by systems thinking
 
Masters of SlideShare
Masters of SlideShareMasters of SlideShare
Masters of SlideShare
 

Semelhante a Chouette! Encore un bug! Agile Tour 2012

La qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitairesLa qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitairesGauthier Delamarre
 
Techdays 2013 : ALM et eCommerce, des challenges en continu
Techdays 2013 : ALM et eCommerce, des challenges en continuTechdays 2013 : ALM et eCommerce, des challenges en continu
Techdays 2013 : ALM et eCommerce, des challenges en continuvlabatut
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1Christophe Rochefolle
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsThierry Gayet
 
Usine logicielle à Orange Labs
Usine logicielle à Orange LabsUsine logicielle à Orange Labs
Usine logicielle à Orange LabsEmmanuel Hugonnet
 
AT2010 Principes Integration Continue
AT2010 Principes Integration ContinueAT2010 Principes Integration Continue
AT2010 Principes Integration ContinueNormandy JUG
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agilelaurent bristiel
 
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
 
Azure DevOps Tests Plan
Azure DevOps Tests PlanAzure DevOps Tests Plan
Azure DevOps Tests PlanDenis Voituron
 
CocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - EpitezCocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - EpitezCocoaHeads France
 
Présentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésPrésentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésDjamel Zouaoui
 
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
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingGeeks Anonymes
 
Agile tour 2015 alliés contre les défauts
Agile tour 2015   alliés contre les défautsAgile tour 2015   alliés contre les défauts
Agile tour 2015 alliés contre les défautsJulien Jakubowski
 

Semelhante a Chouette! Encore un bug! Agile Tour 2012 (20)

La qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitairesLa qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitaires
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
 
Techdays 2013 : ALM et eCommerce, des challenges en continu
Techdays 2013 : ALM et eCommerce, des challenges en continuTechdays 2013 : ALM et eCommerce, des challenges en continu
Techdays 2013 : ALM et eCommerce, des challenges en continu
 
Valider par des tests - Blend
Valider par des tests - BlendValider par des tests - Blend
Valider par des tests - Blend
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teams
 
Usine logicielle à Orange Labs
Usine logicielle à Orange LabsUsine logicielle à Orange Labs
Usine logicielle à Orange Labs
 
AT2010 Principes Integration Continue
AT2010 Principes Integration ContinueAT2010 Principes Integration Continue
AT2010 Principes Integration Continue
 
The DevOps Wonder @ PHPTour Lyon 2014
The DevOps Wonder @ PHPTour Lyon 2014The DevOps Wonder @ PHPTour Lyon 2014
The DevOps Wonder @ PHPTour Lyon 2014
 
Hands on Sonar
Hands on SonarHands on Sonar
Hands on Sonar
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agile
 
Paris Chaos Engineering Meetup #5
Paris Chaos Engineering Meetup #5Paris Chaos Engineering Meetup #5
Paris Chaos Engineering Meetup #5
 
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)
 
Azure DevOps Tests Plan
Azure DevOps Tests PlanAzure DevOps Tests Plan
Azure DevOps Tests Plan
 
CocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - EpitezCocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - Epitez
 
Présentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésPrésentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisés
 
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...
 
Scrum@epitech
Scrum@epitechScrum@epitech
Scrum@epitech
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testing
 
Agile tour 2015 alliés contre les défauts
Agile tour 2015   alliés contre les défautsAgile tour 2015   alliés contre les défauts
Agile tour 2015 alliés contre les défauts
 

Mais de AgileCoach.net

Real Options: How and When (not) to take Decisions
Real Options: How and When (not) to take DecisionsReal Options: How and When (not) to take Decisions
Real Options: How and When (not) to take DecisionsAgileCoach.net
 
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/AgileAgileCoach.net
 
Conflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchConflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchAgileCoach.net
 
Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010AgileCoach.net
 
Conflict resolution diagram tutorial
Conflict resolution diagram tutorialConflict resolution diagram tutorial
Conflict resolution diagram tutorialAgileCoach.net
 

Mais de AgileCoach.net (6)

Real Options: How and When (not) to take Decisions
Real Options: How and When (not) to take DecisionsReal Options: How and When (not) to take Decisions
Real Options: How and When (not) to take Decisions
 
Great! another bug
Great! another bugGreat! another bug
Great! another bug
 
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
 
Conflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchConflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - French
 
Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010
 
Conflict resolution diagram tutorial
Conflict resolution diagram tutorialConflict resolution diagram tutorial
Conflict resolution diagram tutorial
 

Último

Workshop l'IA au service de l'industrie - Présentation générale - Extra 14...
Workshop l'IA au service de l'industrie - Présentation générale - Extra 14...Workshop l'IA au service de l'industrie - Présentation générale - Extra 14...
Workshop l'IA au service de l'industrie - Présentation générale - Extra 14...Infopole1
 
Mes succès sur Microsoft LEARN et examens
Mes succès sur Microsoft LEARN et examensMes succès sur Microsoft LEARN et examens
Mes succès sur Microsoft LEARN et examensErol GIRAUDY
 
KIT-COPILOT and more Article du 20240311
KIT-COPILOT and more Article du 20240311KIT-COPILOT and more Article du 20240311
KIT-COPILOT and more Article du 20240311Erol GIRAUDY
 
Installation de Sylius 2.0 et découverte du nouveau backoffice en Bootstrap
Installation de Sylius 2.0 et découverte du nouveau backoffice en BootstrapInstallation de Sylius 2.0 et découverte du nouveau backoffice en Bootstrap
Installation de Sylius 2.0 et découverte du nouveau backoffice en BootstrapMaxime Huran 🌈
 
The Importance of Indoor Air Quality (French)
The Importance of Indoor Air Quality (French)The Importance of Indoor Air Quality (French)
The Importance of Indoor Air Quality (French)IES VE
 
Les Metiers de l'Intelligence Artificielle
Les Metiers de l'Intelligence ArtificielleLes Metiers de l'Intelligence Artificielle
Les Metiers de l'Intelligence ArtificielleErol GIRAUDY
 

Último (6)

Workshop l'IA au service de l'industrie - Présentation générale - Extra 14...
Workshop l'IA au service de l'industrie - Présentation générale - Extra 14...Workshop l'IA au service de l'industrie - Présentation générale - Extra 14...
Workshop l'IA au service de l'industrie - Présentation générale - Extra 14...
 
Mes succès sur Microsoft LEARN et examens
Mes succès sur Microsoft LEARN et examensMes succès sur Microsoft LEARN et examens
Mes succès sur Microsoft LEARN et examens
 
KIT-COPILOT and more Article du 20240311
KIT-COPILOT and more Article du 20240311KIT-COPILOT and more Article du 20240311
KIT-COPILOT and more Article du 20240311
 
Installation de Sylius 2.0 et découverte du nouveau backoffice en Bootstrap
Installation de Sylius 2.0 et découverte du nouveau backoffice en BootstrapInstallation de Sylius 2.0 et découverte du nouveau backoffice en Bootstrap
Installation de Sylius 2.0 et découverte du nouveau backoffice en Bootstrap
 
The Importance of Indoor Air Quality (French)
The Importance of Indoor Air Quality (French)The Importance of Indoor Air Quality (French)
The Importance of Indoor Air Quality (French)
 
Les Metiers de l'Intelligence Artificielle
Les Metiers de l'Intelligence ArtificielleLes Metiers de l'Intelligence Artificielle
Les Metiers de l'Intelligence Artificielle
 

Chouette! Encore un bug! Agile Tour 2012

  • 1. Chouette! Encore un bug! Pascal Van Cauwenberghe
  • 2. Bonjour Donne des conseils Programme Gère des projets Crée des Jeux Organise des Conférences NAYIMA We make play work www.nayima.be blog.nayima.be
  • 4. 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
  • 5. Based on true stories • In different countries • In different projects • With different teams • Using different (programming) languages
  • 6. Chouette! Encore un bug! Comment passer toute la journée à corriger un tout petit bug
  • 8. Euh.... Il était une fois un projet...
  • 9. 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
  • 11. Scene 1: Un développeur découvre un bug
  • 12. Que faites vous quand on vous dit “J’ai trouvé un bug...” ?
  • 13. MERCI! MERCI !
  • 14. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI !” 3. ... ... 11. ...
  • 15. MERCI! MERCI !
  • 18. CECI EST UNE OPPORTUNITE
  • 19. 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”
  • 20. Scene 3: L’équipe fait une Root Cause Analysis (RCA) 5 développeurs + architecte
  • 21. “Le client a droit à un remboursement jusqu’au moment de la livraison”
  • 22. 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 ; }
  • 23. MERCI! MERCI !
  • 24. 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 ?
  • 25. 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
  • 26. 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 ?
  • 27. 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
  • 28. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI !” 3. REPRODUIRE LE PROBLEME 4. ...
  • 29. Est-ce qu’on peut corriger le code ? C’est tout simple !
  • 30. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI !” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. ...
  • 31. Un nouveau test void 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") ; }
  • 32. Un nouveau test void 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") ; }
  • 33. Est-ce qu’on peut corriger le code ? C’est tout simple !
  • 34. Enfin, on corrige le bug boolean refundAllowed(Product product) { Datetime delivery = Datetime.parse( "yyyy-MM-dd HH:MM“,product.deliveryAt()); Datetime now = Datetime.now; return now <= delivery ;}
  • 35. On relance le test void 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") ; }
  • 36. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI !” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS PASSENT 7. ...
  • 37. “Ce truc agile prendra beaucoup de temps si on va faire ça pour tous les bugs !” “Oui, mais on a plus de confiance qu’on a bien corrigé le bug et qu’on n’a pas cassé autre chose.”
  • 38. “On a vraiment suivi notre principe ‘qualité sans compromis’.”
  • 39. “On devrait contacter l’équipe responsable pour leur dire qu’on a corrigé le bug.” “Il y a peut-être déjà des réclamations par nos clients. On devrait informer les service support client”
  • 40. 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 ...”
  • 41. ON VA... • Contacter l’équipe dev responsable • Informer le service support client
  • 42. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI !” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS PASSENT 7. EXECUTER LES ACTIONS ISSUES DU RCA 8. ...
  • 43. “Bon travail, les gars.” “Retournons au boulot!”
  • 44. THE END Et ils vécurent heureux à tout jamais ...
  • 47. Scene 4: Après la correction Le testeur rejoint les développeurs et l’architecte
  • 48. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI !” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS PASSENT 7. EXECUTER LES ACTIONS ISSUES DU RCA 8. AMELIORER LES TESTS 9. ...
  • 49. Comment améliorer nos tests? Nous aurions dû trouver ce bug plus tôt
  • 50. Comment améliorer nos tests? Nous aurions dû allons trouver ce genre de bug plus tôt
  • 51. Comment améliorer nos tests? Nous allons trouver ce genre de bug plus tôt
  • 52. 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 ...
  • 53. Qui voit le problème ? void testRefundGiven() { Product product = ... product.deliveryAt(“2050-12-31 19:00”) ; BusinessRule businessRule = ... bool allowed = businessRule.refundAllowed(product) }
  • 54. MERCI! MERCI !
  • 55. 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
  • 56. 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
  • 57. 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
  • 58. Développeurs: “On a encore beaucoup à apprendre” Architecte: “J’ai toujours eu des doutes au sujet des tests. Maintenant je sais pourquoi.”
  • 59. Testeur: “Si vous voulez, je peux vous aider à écrire des tests”
  • 60. 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
  • 61. 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
  • 63. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI !” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS PASSENT 7. EXECUTER LES ACTIONS ISSUES DU RCA 8. AMELIORER LES TESTS 9. AMELIORER LA FACON D’ECRIRE LES TESTS 10. ...
  • 65. The End Et ils vécurent heureux à tout jamais.. “On a beaucoup à apprendre”
  • 68. Scene 5: Après les tests Un bug n’arrive jamais seul...
  • 69. Est-ce que ce bug est arrivé seul?
  • 70. 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
  • 72. MERCI! MERCI !
  • 74. MERCI! MERCI !
  • 75. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI !” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS PASSENT 7. EXECUTER LES ACTIONS ISSUES DU RCA 8. AMELIORER LES TESTS 9. AMELIORER LA FACON D’ECRIRE LES TESTS 10. RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2 11. ...
  • 76. “Qualité sans compromis”. Facile à dire, difficile à faire “Ecrire les tests et corriger les problèmes devient de plus en plus de la routine. Ca va de plus en plus vite.”
  • 77. Enfin, La Fin? Est-ce qu’on peut vivre heureux à tout jamais, maintenant ?
  • 79. Est-ce que vous voyez encore un problème?
  • 80. MERCI! MERCI !
  • 81. 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
  • 82. Améliorons Product class Product { ... // Deprecated: Remove when obsolete String deliveryAt() ; // New: gradually refactor all clients DateTime deliveryAtDateTime() ; ... } From “stringly typed” to “strongly typed”
  • 83. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI !” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS PASSENT 7. EXECUTER LES ACTIONS ISSUES DU RCA 8. AMELIORER LES TESTS 9. AMELIORER LA FACON D’ECRIRE LES TESTS 10. RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2 11. RENDRE IMPOSSIBLE DE REFAIRE LA MEME ERREUR
  • 85. L’application ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO System A ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO Application ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO System B
  • 87. L’application (vision) ABCDEFGHIJKLMNO System A L’application ABCDEFGHIJKLMNO System B
  • 89. 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
  • 93. Proposition A3 Description du problème AVANT APRES STEPS: Visualisation 1. .jdlkjds 2. Kmlkdmlkd 3. Dkqjdlkjds 4. Sqkjlkdlksqmk 5. BEER !
  • 94. 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
  • 96. 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?
  • 97. Theory of Constraints in a nutshell
  • 98. Combien est-ce qu’ils livrent? Test & Analysis: Dev: 20 10 Deploy: 15 ???
  • 99. Combien est-ce qu’ils livrent? Test & Analysis: Dev: 20 10 Deploy: 15 <= 10
  • 100. Combien est-ce qu’ils livrent? Test & Analysis: Dev: 20 10 Deploy: 15 ??? Analysis: Dev: 10 12
  • 101. Combien est-ce qu’ils livrent? Test & Analysis: Dev: 20 10 Deploy: 15 <= 15 Analysis: Dev: 10 12
  • 102. Si on développe plus vite? Test & Analysis: Dev: 20 20 Deploy: 15 ??? Analysis: Dev: 10 12
  • 103. Aucun changement? Test & Analysis: Dev: 20 20 Deploy: 15 <= 15 Analysis: Dev: 10 12
  • 104. Le backlog se remplit! Test & Analysis: Dev: 20 20 Deploy: 15 < 15 Analysis: Dev: 10 12
  • 105. Est-ce qu’on peut faire mieux? Test & Analysis: Dev: 20 10 Deploy: 15 <= 15 Analysis: Dev: 10 12
  • 106. Et si on allait plus lentement? Test & Analysis: Dev: 20 8 Deploy: 15 <= 15 Analysis: Dev: 10 12
  • 107. Et si on allait plus lentement? Test & Analysis: Dev: 20 8 Deploy: 17 <= 17 Analysis: Dev: 10 12
  • 108. Pourquoi écrire tant de stories? Test & Analysis: Dev: 20 8 Deploy: 17 <= 17 Analysis: Dev: 10 12
  • 109. On fait moins On livre plus Test & Dev: <= 17 Analysis: 10 Deploy: 8 17 Analysis: Dev: 10 12
  • 111. Pour en savoir plus
  • 112. Combien coûte la qualité?
  • 113. 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
  • 114. 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
  • 116. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI !” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS PASSENT 7. EXECUTER LES ACTIONS ISSUES DU RCA 8. AMELIORER LES TESTS 9. AMELIORER LA FACON D’ECRIRE LES TESTS 10. RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2 11. RENDRE IMPOSSIBLE DE REFAIRE LA MEME ERREUR
  • 118. Qu’allez vous faire demain pour augmenter la qualité? “Quality is Free” Philip Crosby
  • 119. Mais le plus important ...
  • 120. MERCI! MERCI !
  • 121. LA FIN Et ils vécurent heureux à tout jamais
  • 123. 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

Notas do Editor

  1. Portia and Pascal introduce themselves by sharing a bit about their background.
  2. Portia and Pascal introduce themselves by sharing a bit about their background.