SlideShare uma empresa Scribd logo
1 de 28
Baixar para ler offline
0
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
•   Monde médical => documentation
      o      Traditionnellement Waterfall
      o      Gestion par requis "systèmes" (Le système doit faire xyz...)
•   Quand même possible de se créer un environnement "agile"
      o      Nécessite l'aide du gestionnaire de produit
      o      Implication de l'équipe de développement tôt dans le processus
•   Analyse/Architecture haut niveau
      o      Transposition requis & "use cases" en "user stories"
                      Plus facile à gérer pour les membres de l'équipe de dev (Dev, QA ET le
                      représentant client)
                        p                  )
                      Outil utilisé pour les "user stories": XPlanner (gratuit, mais mieux adapté
                      a eXtreme Programming)
                      Système de "story point" de base; à améliorer avec le temps
•   Estimation effectuée par équipe multidisciplinaire
      o      Temps QA inclus dans les estimés
      o      Donne à la haute direction une idée de grandeur du projet
•   Mur "Roadmap"
      o      Étalage des "user stories" dans le temps
      o      Pour information seulement; pas un contrat, mais une bonne idée d ce à quoi
             P     i f      ti       l       t            t t    i      b       idé de         i
             s'attendre
      o      Prends en compte:
                      Attentes du client
                      Réalités de Dev&QA
                      Story Points estimés
      o      Affiche aussi les milestones importants (présentations officielles, intégrations
             équipes externes, ...)
•   Sprint '0'
            0
      o      Essais et tests technologiques
      o      Préparation de l'environnement
      o      En parallel avec la fin de l'analyse haut niveau



                                                         15
•   Points d’entrée:
      o     "Backlog" (XPlanner)
      o     Liste de bugs
•   Choix de l’équipe
      o     Représentant client
      o     Développeurs
      o     QA
•   Estimation informée (raffiner les estimations haut niveaux)
•   Engagement de l’é i
    E             t d l’équipe
•   Contrat à durée fixe
      o     Habituellement 3 semaines
•   Partage des tâches
      o     Différentes mentalités
                   Assignation
                   Collégien ("Pige dans le lac")
      o     2 modes f
                  d fonctionnent; préférence C llé i
                          ti       t éfé         Collégien
      o     Mixte des 2 très difficile à gérer
•   Post-mortem du sprint précédent
      o     Amélioration continue
•   Utilisation du buffer vs évaluation initiale




                                              16
•   Réunion rapide, 15 minutes, à tous les jours
                                           j
•   Tous les membres de l’équipe sont présents
      o Représentant client
      o Devs
      o QA
•   Permet une priorisation p
                 p          plus fine des
    fonctionnalités

•   Centré sur le tableau de statut
     o Distinction "Done" vs "Done Done"

•   À tous les jours
     o Ajustements à la planification
     o Nouveaux risques levés




                                 17
•   Intégration continue
•   « Builds » automatisés
        o     « Build » effectués automatiquement à toutes les demi-heures
                          Seulement si quelque chose a changé
        o     Possibilité de lancement manuel
        o     Avertissement automatique des intervenants si « build » ne réussit pas
                          Toutes personne ayant commis du code + demandeur du « build » + SCM
                          Rapport des changements depuis le dernier build
        o     Ce i
              C qui peut b it briser l b ild
                                     le build
                          Erreurs à la compilation
                          Erreurs dans les tests
                          Erreurs dans les règles d’analyse du code
        o     Outil utilisé: QuickBuild
•   Déploiement automatisés
        o     6 environnements
                          1 environnement entièrement automatisé
                                       « Nightly Build », intégré
                          2 environnements Dev
                          2 environnements pour tests d’intégration
                                                           d intégration
                          1 environnement pour démo
                                       Version figée, fins de sprints, …
                          Environnements protégés par des droits
        o     Quelques autres environnements
                          Vérification et Validation
                           Équipes externes
                          …
        o     Tous les composants sont répliqués
                          Base de données:
                                       Scripts de base
                                       Scripts de tests
                                       Non roulés sur les environnements de validation
        o     Tests unitaires
                          Roulés
        o     Tests intégrés
                          BD générée pour les tests; détruite ensuite.
•   Rapports automatisés
        o     Résultats des tests unitaires
        o     Couverture des tests
        o     Analyse du code compilé (« fxCop »)
        o     Analyse des sources ( StyleCop »)
                                        («             )
        o     Métriques de base (ex.: complexité cyclomatique, NCSS)
        o     Ressources
                          Pour faciliter la traduction
                          Rapports et application

•   Autres outils d’automatisation
       o     Automatisation de tests contre les Web Services
       o     Automatisation de tests Silverlight
                        Technologie pas facilement testable lorsqu’on a commencé le projet
                        Automatisation des tests était importante pour nous
                        Création d’un outil interne pour automatiser les tests utilisateurs
•   Retrospective: Intégration continue et automatisation à faire tôt dans le projet

•   *** Parler du retard causé par build machine down
•   *** Parler du fait que CI + Tests unitaires == à faire dans les premières étapes d’un prochain projet.



                                                                    18
•   Implication du représentant client
       o      Meeting fréquents avec le client
       o      Client voit l’évolution à intervals courts
•   QA présents
       o      Lors de meeting entre Dev et représentant client
       o      Lors de meeting entre Devs (!)
•   Réduction importante des délais de « feedback »
•   Réduction importante de la génération de documents « intermédiaires »
       o      « Design napkins » + photos tableau + entente entre 3 intervenants deviennent suffisant pour
              beaucoup de dossiers
       o      Prototypage peut servir pour valider
•   Fonctionnalités testées durant le sprint
       o      Avant: 1 semaine à la fin des sprints pour tester/debugger/documenter/fermer
       o      Maintenant: dès qu’elles sont complétées, avec l’aide des environnements d’intégration continue
                         Bugs trouvés tout de suite après le développement
                                     Bugs non entrés dans le système => réduction de coûts
                                     Code frais à la mémoire:
                                     Analyse d’impact plus facile
                                     Plus facile à corriger
                         Bugs non corrigés: entrés dans le système
                                     Comme un test (!!)
                                     Comme un bug
       o      Régression manuelle seulement à des milestones important
•   « Peer Review »
       o      Révision du code
                         Effectués au jour le jour (collégial)
                         Initiales dans nos commentaires de « check-in »
       o      Révision des tests
                         Tests révisés entre QA et Dev
•   Tests unitaires
       o      Écrits au besoin, durant le sprint
       o      Écrits lors de la détection de bug
              É
       o      Basé sur retour sur investissement
       o      Testabilité fait partie des considération d’architecture
                         Découplage pour permettre les tests de logiques d’affaires
•   Équipe multidisciplinaire
       o      Différentes expertisent aident pour les différentes tâches
                         QA + Analyse
                                     Ajoutent un autre œil à la résolution de problèmes
                                     Posent souvent de bonnes questions qu’il aurait fallu entendre « au début »
                         Dev + Tests
                                     Développeurs doivent aider les tests
                                     Préfèrent automatiser que refaire des tests manuels sur leur propre code
                                     Créent/améliorent outils pour QA
                                     Renforcés par le fait qu’une fonctionnalité n’est pas livrée si elle n’est pas
                                     testée.




                                                                    19
•   Documentation très importante dans le domaine médical
      o    FDA

•   Spécifications: documenter comment le système doit fonctionner
                                                           fonctionner.
•   Tests: Vérifier si le système fonctionne tel que documenté dans les spécifications et les requis.
•   Processus de documentation habituel est lourd
       o      Demande du temps
       o      Intervenants n’y trouvent pas de valeur ajoutée
       o      Sentiment que la documentation n’est pas lue
       o      Différentes compréhension entre Représentant client, Dev et QA
                          Requis
                          Spécifications
                          -> Exactement pourquoi on implante des pratiques agiles (communication >
                          documentation) )
•   Bugs surviennent souvent dans le code, dans la documentation MAIS AUSSI dans les tests
•   Notre solution: Specs-Tests
       o      But: documenter comment le système fonctionne, et comment le vérifier
       o      Un maillon faible de moins: interprétation entre les specs et les tests.
       o      Spécifications écrites sous forme de tests
       o      Tests révisés par Dev & QA; Spécifications révisés par QA & Dev…
       o      Effets observés:
                          Couverture de specs améliorée
                          Couverture de tests améliorée

•   Automatisation:
    A t   ti ti
       o     Commencé à automatiser les tests
                    Documents vieillissent rarement comme du bon vin...
                               Deviennent vite désuet ET/OU
                               Ne disent plus la vérité
                    Tests == specs, => automatisation des specs
                    S’assure que les specs sont toujours à jour avec l’application
       o     Futur:
                    Atteindre une meilleure couverture

•   Specs Tests
    Specs-Tests ne couvrent pas TOUS les cas
      o     Outil CASE
                     Workflows
                                  Diagramme d’activité, appuyé par diagramme d’état au besoin
                                  Haut niveau faits au début du projet
                                  Amélioration durant les sprints
                                  Sert de base pour la compréhension commune
                                  Moins important lorsqu’un module est prototypé, mais demeure nécessaire
                                  pour nous
                     Traçabilité des requis
                                  Passé: validation à tous les sprints
                                  Maintenant: validation à certains points dans le temps.
                     Outil utilisé: Enterprise Architect par Sparx Systems
      o     Bugs
                     Lorsque réglés rapidement, sont parfois entré comme tests (régression)
      o     Tests unitaires
                     Passé: tests unitaires écrits par et pour les devs
                     Présent: tests unitaires écrits par et pour les devs, MAIS
                                  Nomenclature des tests permet de comprendre ce qui est testé
                                  Pris en compte par QA pour ne pas refaire tout en double
      o     Autre
                     Photographies du tableau lors de séances d’analyse et de design
                                  Futur: pousser plus ce concept (enregistrement audio/vidéo?)

•   Note: Merci à Georges Saad pour l'image




                                                                   20
•   Durant un sprint, analyse de "user stories" à faire
                p          y
    prochainement
•   Choix des fonctionnalités les plus "probables"
     o PAS un contrat
     o Choix final à faire durant le "Planning Game"
         suivant
•   Permet de soulever les embûches plus tôt
     o Découpage possible en plusieurs stories
•   Permet à l'équipe d'avoir de la "viande" plus tôt
•   Meilleure répartition du temps
    analyse/programmation
•   Rafinement des analyses haut niveau
     o ex.: workflows
•   Avant: dernière semaine du sprint
•   Maintenant: tâche comme une autre




                                  21
•   Discussions courantes avec le représentant client
•   Prototypage
•   Demo
     o Enregistrement de démos de fin de sprint




                                22
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès

Mais conteúdo relacionado

Mais procurados

Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2Christophe Rochefolle
 
Intégration continue
Intégration continueIntégration continue
Intégration continueKlee Group
 
L’intégration continue chez AXA France
L’intégration continue chez AXA FranceL’intégration continue chez AXA France
L’intégration continue chez AXA FranceMicrosoft
 
20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_all20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_allCARA_Lyon
 
AT2010 Principes Integration Continue
AT2010 Principes Integration ContinueAT2010 Principes Integration Continue
AT2010 Principes Integration ContinueNormandy JUG
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxNicolas Fédou
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement MicrosoftChristophe HERAL
 
Rappels Modularisation application C/C++
Rappels Modularisation application C/C++Rappels Modularisation application C/C++
Rappels Modularisation application C/C++Sylvain Leroy
 
Concept de l’Intégration Continue
Concept de l’Intégration ContinueConcept de l’Intégration Continue
Concept de l’Intégration ContinueFrédéric Sagez
 
AT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillagesAT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillagesJérôme Avoustin
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logicielJean-Paul CARMONA
 
Formation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratifFormation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratifkemenaran
 
AgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFSAgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFSAgile Toulouse
 
4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciellauraty3204
 
Avis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsAvis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsCloudNetCare
 
La qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
La qualité logicielle et l'intégration continue - Cas concret du projet CytomineLa qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
La qualité logicielle et l'intégration continue - Cas concret du projet CytomineGeeks Anonymes
 

Mais procurados (20)

Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
 
ATDD Visuel
ATDD VisuelATDD Visuel
ATDD Visuel
 
Intégration continue
Intégration continueIntégration continue
Intégration continue
 
Les usines à logiciels
Les usines à logicielsLes usines à logiciels
Les usines à logiciels
 
L’intégration continue chez AXA France
L’intégration continue chez AXA FranceL’intégration continue chez AXA France
L’intégration continue chez AXA France
 
20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_all20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_all
 
AT2010 Principes Integration Continue
AT2010 Principes Integration ContinueAT2010 Principes Integration Continue
AT2010 Principes Integration Continue
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeaux
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
 
Rappels Modularisation application C/C++
Rappels Modularisation application C/C++Rappels Modularisation application C/C++
Rappels Modularisation application C/C++
 
Concept de l’Intégration Continue
Concept de l’Intégration ContinueConcept de l’Intégration Continue
Concept de l’Intégration Continue
 
AT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillagesAT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillages
 
Futur tunis
Futur tunisFutur tunis
Futur tunis
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logiciel
 
Formation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratifFormation Extreme Programming, Tests unitaires, travail collaboratif
Formation Extreme Programming, Tests unitaires, travail collaboratif
 
Method XP
Method XP Method XP
Method XP
 
AgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFSAgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFS
 
4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel4-Cours de Géniel Logiciel
4-Cours de Géniel Logiciel
 
Avis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsAvis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests Logiciels
 
La qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
La qualité logicielle et l'intégration continue - Cas concret du projet CytomineLa qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
La qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
 

Semelhante a Deux ans de développement Agile, erreurs et succès

Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileLaurent Deséchalliers
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileNormandy JUG
 
Developement logiciel: comment livrer de la qualite ?
Developement logiciel: comment livrer  de la qualite ?Developement logiciel: comment livrer  de la qualite ?
Developement logiciel: comment livrer de la qualite ?Innobec
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelAgile Montréal
 
Azure DevOps Tests Plan
Azure DevOps Tests PlanAzure DevOps Tests Plan
Azure DevOps Tests PlanDenis Voituron
 
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continueOmnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continueXavier Callens
 
Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Ippon
 
La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !Lucian Precup
 
What's Next Replay - IC / Jenkins
What's Next Replay - IC / JenkinsWhat's Next Replay - IC / Jenkins
What's Next Replay - IC / JenkinsZenikaOuest
 
10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptxGuillaume Saint Etienne
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logicielRabia AZIZA
 
La revue de code : facile !
La revue de code : facile !La revue de code : facile !
La revue de code : facile !Lucian Precup
 
Altran soirée du test logiciel - assez des c 05-10-17
Altran   soirée du test logiciel - assez des c 05-10-17Altran   soirée du test logiciel - assez des c 05-10-17
Altran soirée du test logiciel - assez des c 05-10-17Marc Hage Chahine
 
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...TelecomValley
 
L'integration continue pour tous
L'integration continue pour tousL'integration continue pour tous
L'integration continue pour tousAurelien Navarre
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgileAgile Tour 2009 Québec
 

Semelhante a Deux ans de développement Agile, erreurs et succès (20)

Dev opsday case study
Dev opsday   case studyDev opsday   case study
Dev opsday case study
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agile
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet Agile
 
Maven
MavenMaven
Maven
 
Developement logiciel: comment livrer de la qualite ?
Developement logiciel: comment livrer  de la qualite ?Developement logiciel: comment livrer  de la qualite ?
Developement logiciel: comment livrer de la qualite ?
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
 
Azure DevOps Tests Plan
Azure DevOps Tests PlanAzure DevOps Tests Plan
Azure DevOps Tests Plan
 
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continueOmnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
 
Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Présentation Rex GWT 2.0
Présentation Rex GWT 2.0
 
Lunch learn 5 sep2013
Lunch learn 5 sep2013Lunch learn 5 sep2013
Lunch learn 5 sep2013
 
La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !
 
What's Next Replay - IC / Jenkins
What's Next Replay - IC / JenkinsWhat's Next Replay - IC / Jenkins
What's Next Replay - IC / Jenkins
 
10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
 
La revue de code : facile !
La revue de code : facile !La revue de code : facile !
La revue de code : facile !
 
Altran soirée du test logiciel - assez des c 05-10-17
Altran   soirée du test logiciel - assez des c 05-10-17Altran   soirée du test logiciel - assez des c 05-10-17
Altran soirée du test logiciel - assez des c 05-10-17
 
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
 
L'integration continue pour tous
L'integration continue pour tousL'integration continue pour tous
L'integration continue pour tous
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
 
Methodologie projet
Methodologie projet Methodologie projet
Methodologie projet
 

Mais de Agile Tour 2009 Québec

Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...Agile Tour 2009 Québec
 
Introduction au Kanban et expérience pratique chez IBM Bromont
Introduction au Kanban et expérience pratique chez IBM BromontIntroduction au Kanban et expérience pratique chez IBM Bromont
Introduction au Kanban et expérience pratique chez IBM BromontAgile Tour 2009 Québec
 
L’agilité dans des projets d’envergure
L’agilité dans des projets d’envergureL’agilité dans des projets d’envergure
L’agilité dans des projets d’envergureAgile Tour 2009 Québec
 
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...Agile Tour 2009 Québec
 
Intégration d'Agile dans un domaine multidisciplinaire
Intégration d'Agile dans un domaine multidisciplinaire Intégration d'Agile dans un domaine multidisciplinaire
Intégration d'Agile dans un domaine multidisciplinaire Agile Tour 2009 Québec
 
Exemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUMExemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUMAgile Tour 2009 Québec
 
Processus d’intégration continue et outils
Processus d’intégration continue et outilsProcessus d’intégration continue et outils
Processus d’intégration continue et outilsAgile Tour 2009 Québec
 

Mais de Agile Tour 2009 Québec (10)

Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
 
Introduction au Kanban et expérience pratique chez IBM Bromont
Introduction au Kanban et expérience pratique chez IBM BromontIntroduction au Kanban et expérience pratique chez IBM Bromont
Introduction au Kanban et expérience pratique chez IBM Bromont
 
L’agilité dans des projets d’envergure
L’agilité dans des projets d’envergureL’agilité dans des projets d’envergure
L’agilité dans des projets d’envergure
 
Waste and Trashing
Waste and TrashingWaste and Trashing
Waste and Trashing
 
La technique Pomodoro
La technique PomodoroLa technique Pomodoro
La technique Pomodoro
 
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
 
Intégration d'Agile dans un domaine multidisciplinaire
Intégration d'Agile dans un domaine multidisciplinaire Intégration d'Agile dans un domaine multidisciplinaire
Intégration d'Agile dans un domaine multidisciplinaire
 
Open Space
Open SpaceOpen Space
Open Space
 
Exemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUMExemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUM
 
Processus d’intégration continue et outils
Processus d’intégration continue et outilsProcessus d’intégration continue et outils
Processus d’intégration continue et outils
 

Deux ans de développement Agile, erreurs et succès

  • 1. 0
  • 16. Monde médical => documentation o Traditionnellement Waterfall o Gestion par requis "systèmes" (Le système doit faire xyz...) • Quand même possible de se créer un environnement "agile" o Nécessite l'aide du gestionnaire de produit o Implication de l'équipe de développement tôt dans le processus • Analyse/Architecture haut niveau o Transposition requis & "use cases" en "user stories" Plus facile à gérer pour les membres de l'équipe de dev (Dev, QA ET le représentant client) p ) Outil utilisé pour les "user stories": XPlanner (gratuit, mais mieux adapté a eXtreme Programming) Système de "story point" de base; à améliorer avec le temps • Estimation effectuée par équipe multidisciplinaire o Temps QA inclus dans les estimés o Donne à la haute direction une idée de grandeur du projet • Mur "Roadmap" o Étalage des "user stories" dans le temps o Pour information seulement; pas un contrat, mais une bonne idée d ce à quoi P i f ti l t t t i b idé de i s'attendre o Prends en compte: Attentes du client Réalités de Dev&QA Story Points estimés o Affiche aussi les milestones importants (présentations officielles, intégrations équipes externes, ...) • Sprint '0' 0 o Essais et tests technologiques o Préparation de l'environnement o En parallel avec la fin de l'analyse haut niveau 15
  • 17. Points d’entrée: o "Backlog" (XPlanner) o Liste de bugs • Choix de l’équipe o Représentant client o Développeurs o QA • Estimation informée (raffiner les estimations haut niveaux) • Engagement de l’é i E t d l’équipe • Contrat à durée fixe o Habituellement 3 semaines • Partage des tâches o Différentes mentalités Assignation Collégien ("Pige dans le lac") o 2 modes f d fonctionnent; préférence C llé i ti t éfé Collégien o Mixte des 2 très difficile à gérer • Post-mortem du sprint précédent o Amélioration continue • Utilisation du buffer vs évaluation initiale 16
  • 18. Réunion rapide, 15 minutes, à tous les jours j • Tous les membres de l’équipe sont présents o Représentant client o Devs o QA • Permet une priorisation p p plus fine des fonctionnalités • Centré sur le tableau de statut o Distinction "Done" vs "Done Done" • À tous les jours o Ajustements à la planification o Nouveaux risques levés 17
  • 19. Intégration continue • « Builds » automatisés o « Build » effectués automatiquement à toutes les demi-heures Seulement si quelque chose a changé o Possibilité de lancement manuel o Avertissement automatique des intervenants si « build » ne réussit pas Toutes personne ayant commis du code + demandeur du « build » + SCM Rapport des changements depuis le dernier build o Ce i C qui peut b it briser l b ild le build Erreurs à la compilation Erreurs dans les tests Erreurs dans les règles d’analyse du code o Outil utilisé: QuickBuild • Déploiement automatisés o 6 environnements 1 environnement entièrement automatisé « Nightly Build », intégré 2 environnements Dev 2 environnements pour tests d’intégration d intégration 1 environnement pour démo Version figée, fins de sprints, … Environnements protégés par des droits o Quelques autres environnements Vérification et Validation Équipes externes … o Tous les composants sont répliqués Base de données: Scripts de base Scripts de tests Non roulés sur les environnements de validation o Tests unitaires Roulés o Tests intégrés BD générée pour les tests; détruite ensuite. • Rapports automatisés o Résultats des tests unitaires o Couverture des tests o Analyse du code compilé (« fxCop ») o Analyse des sources ( StyleCop ») (« ) o Métriques de base (ex.: complexité cyclomatique, NCSS) o Ressources Pour faciliter la traduction Rapports et application • Autres outils d’automatisation o Automatisation de tests contre les Web Services o Automatisation de tests Silverlight Technologie pas facilement testable lorsqu’on a commencé le projet Automatisation des tests était importante pour nous Création d’un outil interne pour automatiser les tests utilisateurs • Retrospective: Intégration continue et automatisation à faire tôt dans le projet • *** Parler du retard causé par build machine down • *** Parler du fait que CI + Tests unitaires == à faire dans les premières étapes d’un prochain projet. 18
  • 20. Implication du représentant client o Meeting fréquents avec le client o Client voit l’évolution à intervals courts • QA présents o Lors de meeting entre Dev et représentant client o Lors de meeting entre Devs (!) • Réduction importante des délais de « feedback » • Réduction importante de la génération de documents « intermédiaires » o « Design napkins » + photos tableau + entente entre 3 intervenants deviennent suffisant pour beaucoup de dossiers o Prototypage peut servir pour valider • Fonctionnalités testées durant le sprint o Avant: 1 semaine à la fin des sprints pour tester/debugger/documenter/fermer o Maintenant: dès qu’elles sont complétées, avec l’aide des environnements d’intégration continue Bugs trouvés tout de suite après le développement Bugs non entrés dans le système => réduction de coûts Code frais à la mémoire: Analyse d’impact plus facile Plus facile à corriger Bugs non corrigés: entrés dans le système Comme un test (!!) Comme un bug o Régression manuelle seulement à des milestones important • « Peer Review » o Révision du code Effectués au jour le jour (collégial) Initiales dans nos commentaires de « check-in » o Révision des tests Tests révisés entre QA et Dev • Tests unitaires o Écrits au besoin, durant le sprint o Écrits lors de la détection de bug É o Basé sur retour sur investissement o Testabilité fait partie des considération d’architecture Découplage pour permettre les tests de logiques d’affaires • Équipe multidisciplinaire o Différentes expertisent aident pour les différentes tâches QA + Analyse Ajoutent un autre œil à la résolution de problèmes Posent souvent de bonnes questions qu’il aurait fallu entendre « au début » Dev + Tests Développeurs doivent aider les tests Préfèrent automatiser que refaire des tests manuels sur leur propre code Créent/améliorent outils pour QA Renforcés par le fait qu’une fonctionnalité n’est pas livrée si elle n’est pas testée. 19
  • 21. Documentation très importante dans le domaine médical o FDA • Spécifications: documenter comment le système doit fonctionner fonctionner. • Tests: Vérifier si le système fonctionne tel que documenté dans les spécifications et les requis. • Processus de documentation habituel est lourd o Demande du temps o Intervenants n’y trouvent pas de valeur ajoutée o Sentiment que la documentation n’est pas lue o Différentes compréhension entre Représentant client, Dev et QA Requis Spécifications -> Exactement pourquoi on implante des pratiques agiles (communication > documentation) ) • Bugs surviennent souvent dans le code, dans la documentation MAIS AUSSI dans les tests • Notre solution: Specs-Tests o But: documenter comment le système fonctionne, et comment le vérifier o Un maillon faible de moins: interprétation entre les specs et les tests. o Spécifications écrites sous forme de tests o Tests révisés par Dev & QA; Spécifications révisés par QA & Dev… o Effets observés: Couverture de specs améliorée Couverture de tests améliorée • Automatisation: A t ti ti o Commencé à automatiser les tests Documents vieillissent rarement comme du bon vin... Deviennent vite désuet ET/OU Ne disent plus la vérité Tests == specs, => automatisation des specs S’assure que les specs sont toujours à jour avec l’application o Futur: Atteindre une meilleure couverture • Specs Tests Specs-Tests ne couvrent pas TOUS les cas o Outil CASE Workflows Diagramme d’activité, appuyé par diagramme d’état au besoin Haut niveau faits au début du projet Amélioration durant les sprints Sert de base pour la compréhension commune Moins important lorsqu’un module est prototypé, mais demeure nécessaire pour nous Traçabilité des requis Passé: validation à tous les sprints Maintenant: validation à certains points dans le temps. Outil utilisé: Enterprise Architect par Sparx Systems o Bugs Lorsque réglés rapidement, sont parfois entré comme tests (régression) o Tests unitaires Passé: tests unitaires écrits par et pour les devs Présent: tests unitaires écrits par et pour les devs, MAIS Nomenclature des tests permet de comprendre ce qui est testé Pris en compte par QA pour ne pas refaire tout en double o Autre Photographies du tableau lors de séances d’analyse et de design Futur: pousser plus ce concept (enregistrement audio/vidéo?) • Note: Merci à Georges Saad pour l'image 20
  • 22. Durant un sprint, analyse de "user stories" à faire p y prochainement • Choix des fonctionnalités les plus "probables" o PAS un contrat o Choix final à faire durant le "Planning Game" suivant • Permet de soulever les embûches plus tôt o Découpage possible en plusieurs stories • Permet à l'équipe d'avoir de la "viande" plus tôt • Meilleure répartition du temps analyse/programmation • Rafinement des analyses haut niveau o ex.: workflows • Avant: dernière semaine du sprint • Maintenant: tâche comme une autre 21
  • 23. Discussions courantes avec le représentant client • Prototypage • Demo o Enregistrement de démos de fin de sprint 22