0

• Monde médical => documentationo Traditionnellement Waterfallo Traditionnellement Waterfallo 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 produito Implication de l'équipe de développement tôt dans le processus

• Analyse/Architecture haut niveauo 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 multidisciplinaireo Temps QA inclus dans les estiméso Donne à la haute direction une idée de grandeur du projet

• Mur "Roadmap"o Étalage des "user stories" dans le temps

P i f ti l t t t i b idé d à io Pour information seulement; pas un contrat, mais une bonne idée de ce à quoi s'attendre

o Prends en compte:Attentes du clientRéalités de Dev&QAStory Points estimés

o Affiche aussi les milestones importants (présentations officielles, intégrations équipes externes, ...)

• Sprint '0'

15

• Sprint 0o Essais et tests technologiqueso Préparation de l'environnemento En parallel avec la fin de l'analyse haut niveau

• Points d’entrée:"Backlog" (XPlanner)o "Backlog" (XPlanner)

o Liste de bugs• Choix de l’équipe

o Représentant cliento Développeurso QA

• Estimation informée (raffiner les estimations haut niveaux)E t d l’é i• Engagement de l’équipe

• Contrat à durée fixeo Habituellement 3 semaines

• Partage des tâcheso Différentes mentalités

AssignationCollégien ("Pige dans le lac")

2 d f ti t éfé C llé io 2 modes fonctionnent; préférence Collégieno Mixte des 2 très difficile à gérer

• Post-mortem du sprint précédento Amélioration continue

• Utilisation du buffer vs évaluation initiale

16

• Réunion rapide, 15 minutes, à tous les joursj• Tous les membres de l’équipe sont présents

o Représentant cliento Devso QA

• Permet une priorisation plus fine des p pfonctionnalités

• Centré sur le tableau de statuto Distinction "Done" vs "Done Done"

• À tous les jourso Ajustements à la planificationo Nouveaux risques levés

17

• Intégration continue• « Builds » automatisés

o « Build » effectués automatiquement à toutes les demi-heuresSeulement si quelque chose a changé

o Possibilité de lancement manuelo Avertissement automatique des intervenants si « build » ne réussit pas

Toutes personne ayant commis du code + demandeur du « build » + SCMRapport des changements depuis le dernier build

C i t b i l b ildo Ce qui peut briser le buildErreurs à la compilationErreurs dans les testsErreurs dans les règles d’analyse du code

o Outil utilisé: QuickBuild• Déploiement automatisés

o 6 environnements1 environnement entièrement automatisé

« Nightly Build », intégré2 environnements Dev2 environnements pour tests d’intégration2 environnements pour tests d intégration1 environnement pour démo

Version figée, fins de sprints, …Environnements protégés par des droits

o Quelques autres environnementsVérification et ValidationÉquipes externes

…o Tous les composants sont répliqués

Base de données:Scripts de baseScripts de testsNon roulés sur les environnements de validation

o Tests unitairesRoulés

o Tests intégrésBD générée pour les tests; détruite ensuite.

• Rapports automatiséso Résultats des tests unitaireso Couverture des testso Analyse du code compilé (« fxCop »)

Analyse des sources ( StyleCop )o Analyse des sources (« StyleCop »)o Métriques de base (ex.: complexité cyclomatique, NCSS)o Ressources

Pour faciliter la traductionRapports et application

• Autres outils d’automatisationo Automatisation de tests contre les Web Serviceso Automatisation de tests Silverlight

Technologie pas facilement testable lorsqu’on a commencé le projetAutomatisation des tests était importante pour nous

18

Automatisation des tests était importante pour nousCré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.

• Implication du représentant cliento Meeting fréquents avec le cliento Client voit l’évolution à intervals courts

• QA présentso Lors de meeting entre Dev et représentant cliento 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 dossiersPrototypage peut servir pour validero Prototypage peut servir pour valider

• Fonctionnalités testées durant le sprinto Avant: 1 semaine à la fin des sprints pour tester/debugger/documenter/fermero 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éveloppementBugs non entrés dans le système => réduction de coûtsCode frais à la mémoire:Analyse d’impact plus facilePlus facile à corriger

Bugs non corrigés: entrés dans le systèmeComme un test (!!)Comme un test (!!)Comme un bug

o Régression manuelle seulement à des milestones important• « Peer Review »

o Révision du codeEffectués au jour le jour (collégial)Initiales dans nos commentaires de « check-in »

o Révision des testsTests révisés entre QA et Dev

• Tests unitaireso Écrits au besoin, durant le sprint

Éo Écrits lors de la détection de bugo Basé sur retour sur investissemento 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âchesQA + Analyse

Ajoutent un autre œil à la résolution de problèmesPosent souvent de bonnes questions qu’il aurait fallu entendre « au début »

Dev + TestsDéveloppeurs doivent aider les tests

19

Développeurs doivent aider les testsPréfèrent automatiser que refaire des tests manuels sur leur propre codeCréent/améliorent outils pour QARenforcés par le fait qu’une fonctionnalité n’est pas livrée si elle n’est pas testée.

• Documentation très importante dans le domaine médicalo FDA

• Spécifications: documenter comment le système doit fonctionner• Spécifications: documenter comment le système doit 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 tempso Intervenants n’y trouvent pas de valeur ajoutéeo Sentiment que la documentation n’est pas lueo Différentes compréhension entre Représentant client, Dev et QA

RequisSpé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érifiero Un maillon faible de moins: interprétation entre les specs et les tests.o Spécifications écrites sous forme de testso Tests révisés par Dev & QA; Spécifications révisés par QA & Dev…o Effets observés:

Couverture de specs amélioréeCouverture de tests améliorée

A t ti ti• Automatisation:o Commencé à automatiser les tests

Documents vieillissent rarement comme du bon vin...Deviennent vite désuet ET/OUNe disent plus la vérité

Tests == specs, => automatisation des specsS’assure que les specs sont toujours à jour avec l’application

o Futur:Atteindre une meilleure couverture

• Specs-Tests ne couvrent pas TOUS les casSpecs Tests ne couvrent pas TOUS les caso Outil CASE

WorkflowsDiagramme d’activité, appuyé par diagramme d’état au besoinHaut niveau faits au début du projetAmélioration durant les sprintsSert de base pour la compréhension communeMoins important lorsqu’un module est prototypé, mais demeure nécessaire pour nous

Traçabilité des requisPassé: validation à tous les sprintsMaintenant: validation à certains points dans le temps.

Outil utilisé: Enterprise Architect par Sparx Systemso Bugs

Lorsque réglés rapidement, sont parfois entré comme tests (régression)o Tests unitaires

Passé: tests unitaires écrits par et pour les devsPré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 AutrePhotographies du tableau lors de séances d’analyse et de design

20

Photographies du tableau lors de séances d’analyse et de designFutur: pousser plus ce concept (enregistrement audio/vidéo?)

• Note: Merci à Georges Saad pour l'image

• Durant un sprint, analyse de "user stories" à faire p yprochainement

• Choix des fonctionnalités les plus "probables"o PAS un contrato 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/programmationanalyse/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