Téléchargé 23 fois
Téléchargé parInnobec
Developement logiciel: comment livrer de la qualite ?
Le document traite de l'amélioration de la qualité dans le développement agile, en détaillant l'expérience d'une équipe sur plusieurs livraisons d'applications. Il aborde divers défis, pratiques et résultats tels que la mise en place de l'assurance qualité, le backlog grooming, et la coordination entre développeurs et QA. La conclusion souligne une augmentation de la confiance dans le produit et une réduction des défectuosités après la mise en œuvre de ces pratiques.
Contenu connexe
Developement logiciel: comment livrer de la qualite ?
- 1. DOCUMENT CONFIDENTIEL, TOUSDROITS RÉSERVÉS Comment livrer de la qualité ? JULIEN DESLIÈRES Programmeur-Analyste / Scrum Master
- 2. Objectif Partager notre expérience enAgilité pour inspirer les autres équipes dans la résolution de leurs problèmes
- 3. Client • Chiffre d’affaires: 1,85 millards de dollars US • Employés : 37 000 • Utilisateurs de notre produit : 18 000 • Coût d’un arrêt de l’environement de production : > 100 000 $ par jour
- 4. Projet Première livraison : •Réécriture d’une application mobile roulant sur Windows Mobile 6 • Porter l’application vers Android et iOs • Le temps est important : refaire en 2 ans une application faite sur 10 ans Deuxième livraison : • Réécriture d’une seconde application basée sur la première • Création d’une troisième application • Le temps est important Livraison subséquente : • Ajout de fonctionnalités aux applications
- 5. Démarrage du projet •Tests unitaires automatisés • Tests automatisés des règles d’affaires • Revue de code • Intégration continue • Équipe d’assurance qualité • Tests de charge automatisés
- 6. Défis à surmonter •Équipe(s) en constante évolution • Introduction à la méthodologie Agile : Scrum • Utilisation de nouvelles technologies • Mise en place de l’environnement de développement • Développement multisite
- 7. Première livraison • Distraitpar les problèmes immédiats • Stabilisation longue par rapport au temps de développement • Manque de confiance face au livrable • Livraisons de hotfix suivant la livraison
- 8. Tournant • L’équipe estplus mature • L’environnement de développement est plus mature • Période morte
- 9.
- 10. Backlog Grooming Problèmes : •Préparation des stories incomplètes • Des exit criteria manquants lors de la revue de sprint
- 11. Backlog Grooming Personnes impliquées: • Product Owner • Assurance qualité • Développeur Objectif : • S’assurer que la logique d’affaires est bien comprise par tous • Challenger les stories par différents points de vue • Trouver des cas limites
- 12. Backlog Grooming Résultat : •Les stories mieux préparées • Davantage de cas limites identifiés
- 13. Cycle d’une livraison Spécifications BacklogGrooming Architecture Grooming
- 14. Architecture Grooming Clean Code:Handbook of Agile Software Craftsmanship - What is the ultimate code quality measurement? WFTs/minute :) http://t.co/qj2z3RFtya Problèmes : • Architecture disparate entre les modules • Maitrise des principes architecturaux différents entre les membres de l’équipe
- 15. Architecture Grooming Personnes impliquées: • Architecture Owner • L’équipe de développement Objectifs : • Prendre des décisions architecturales qui feront consensus • Que tous les membres de l’équipe comprennent les choix architecturaux retenus Note: • Les modules les plus importants seront examinés durant la revue du sprint
- 16. Architecture Grooming Résultat : •Architecture plus uniforme • La meilleure architecture à chaque problème • Connaissance transmise à l’équipe Clean Code: Handbook of Agile Software Craftsmanship - What is the ultimate code quality measurement? WFTs/minute :) http://t.co/qj2z3RFtya
- 17. Spécifications Backlog Grooming Architecture Grooming Cycled’une Livraison Planification du sprint Mêlée quotidienne (Daily scrum)
- 18. Cycle d’une story Spécifications& Grooming Ready to Sprint Développement
- 19. Tests automatisés dela logique d’affaires Problèmes : • Les tests de la logique d’affaires mal exploités • Utilisation des tests de logique d’affaires exclusivement par les développeurs • Implémentation très difficile des tests automatisés
- 20. Tests automatisés dela logique d’affaires Solution : • Arrêt de la création des tests automatisés de la logique d’affaires • Rédaction des scénarios de tests • Utilisation d’un outil de suivi des scénarios
- 21. Résultat : • Éliminationd’un irritant • L’équipe s’est approprié les scénarios de tests • Les tests sont devenus des exit criteria • L’utilisation d’un outil de suivi des scénarios de tests a augmenté la Note : • Recherche d’une technologie pour automatiser les scénarios Tests automatisés de la logique d’affaires
- 22. Cycle d’une Story Spécifications& Grooming Ready to Sprint Développement Ready to QA Dev QA Dev
- 23. Assurance qualité parles pairs Problèmes : • L’intégration continue brise fréquemment • L’application ne roule pas sur certains environnements • Manque de membres dédiés à l’assurance qualité
- 24. Assurance qualité parles pairs Objectifs : • S’assurer que la branche de développement compile sur un nouvel environnement • S’assurer que la branche de développement roule sur un nouvel environnement • S’assurer que tous les aspects de la story ont bien été implémentés • Détecter les défectuosités le plus tôt possible
- 25. Assurance qualité parles pairs Résultat : • Moins de compilation brisée • Moins de défectuosités • Moins de modifications après la revue de sprint
- 26. Cycle d’une story Spécifications& Grooming Ready to Sprint Développement Ready to QA Dev QA Dev Ready to QA QA d’une story Ready to Release QA d’une release Ready to Deploy Déploiement
- 27. Cycle d’une livraison Spécifications BacklogGrooming Architecture Grooming Sprint Planning Mêlée quotidienne (Daily scrum) QA War Room
- 28. QA War Room Problèmes: • L’équipe d’assurance qualité décalée par rapport aux développeurs • Plus de défectuosités trouvées pendant les sprints de stabilisation • Défectuosités introduites durant le sprint Bugs Improvements
- 29. QA War Room Objectifs: • Coordination des efforts • Transmission rapide des informations • Fait en fin de sprint, permet de voir l’interaction entre les stories livrées Note : • Se fait plus de 24 h avant la fin du sprint, ce qui permet de régler des défectuosités mineures avant la revue de sprint
- 30. QA War Room Résultat: • Détection des défectuosité plus tôt • Livrable de fin sprint plus stable • Meilleur portrait du livrable
- 31. Cycle d’une livraison Spécifications BacklogGrooming Architecture Grooming Planification de sprint Mêlée quotidienne (Daily Scrum) QA War Room Revue de sprint Rétrospective Produit livrable Livraison
- 32. Méthodologie • Chaque étapeest optionnelle • Une méthodologie en constante évolution • Offrir un environnement efficace et agréable aux développeurs • Rétrospective : une occasion d’identifier les problèmes et de trouver les solutions
- 33. Conclusion • Temps dedéveloppement d’une story plus long • Vélocité sensiblement pareille • Baisse des défectuosités détectées après la livraison d’une feature • Baisse du temps nécessaire à la stabilisation • Réduction du nombre de livraisons de type hotfix • Augmentation de la confiance face au produit • La qualité à un coût, qu’il soit exposé ou non
- 34. DOCUMENT CONFIDENTIEL, TOUSDROITS RÉSERVÉS
- 35. DOCUMENT CONFIDENTIEL, TOUSDROITS RÉSERVÉS Comment livrer de la qualité ? JULIEN DESLIÈRES Programmeur-Analyste / Scrum Master