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