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

by Agile Tour 2009 Québec on Nov 02, 2009

Accessibility

Categories

Upload Details

Usage Rights

Statistics

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