Les mécanismes d'assurance et de contrôle de la qualité dans un projet Agile Séminaire du génie logiciel LATECE 10 avril 2013 Qui sommes- nous? Mathieu Boisvert Coach Agile Chargé de cours à L ESG (UQAM) Co- auteur d un livre avec Sylvie Sylvie Trudel Professeure en informalque (UQAM) Coach Agile Co- auteur d un livre avec Mathieu Doctorat de l ETS Prix AFISI du meilleur livre informalque 2012 1
Agenda IntroducLon Assurance et contrôle de qualité (ACQ) dans les projets tradilonnels Survol de l agilité PraLques d ACQ dans les projets agiles PraLques organisalonnelles au- delà des projets V&V, normes et modèles INTRODUCTION 2
Hypothèse de ce[e présentalon Les équipes de développement appliquent les meilleures pralques, peu importe qu elles travaillent en mode tradilonnel ou agile à Les défis et difficultés liés au non- respect de ces meilleures pralques seront traités à la fin Normes et modèles liés à l ACQ Modèle de bonnes pra=ques, dont les domaines de processus Assurance qualité processus et produit (niv.2) VérificaLon (niv.3) ValidaLon (niv.3) CMMI ISO 12207 IEEE Std 730 Processus du cycle de vie du logiciel GesLon de la qualité Tests de qualificalon Assurance qualité VérificaLon ValidaLon Revues Audits Plan d assurance qualité logiciel (SQAP) GesLon et documentalon Normes, pralques, convenlons et indicateurs Revues, tests, oulls, 3
ObjecLfs de l AQ via sa définilon Quality assurance (=rée ISO 12207) all the planned and systemalc aclviles implemented within the quality system, and demonstrated as needed, to provide adequate confidence that an enlty will fulfill requirements for quality a) Internal quality assurance: within an organizalon, quality assurance provides confidence to management; b) External quality assurance: in contractual situalons, quality assurance provides confidence to the customer or others. VérificaLon et validalon Vérifica=on: a- t- on bien fait le livrable? Valida=on: a- t- on fait le bon produit? à 2 formes de contrôle de qualité 4
Qui parlcipe aux aclvités d ACQ? Testeurs et autres membres de l équipe de développement Représentant du client Parfois le même Groupe d assurance qualité AcLvités et jalons de la qualité ASSURANCE ET CONTRÔLE DE QUALITÉ DANS LES PROJETS TRADITIONNELS 5
ACQ dans le cycle de développement GesLon de projet Architecture Analyse Design ProgrammaLon Test AcLvité d assurance qualité AcLvité de contrôle de qualité Déploiement Les 4 valeurs, les 12 principes, itéralons et incréments, Scrum SURVOL DE L AGILITÉ 6
Les 4 valeurs de l agilité L agilité valorise: davantage que: 1. Les individus et les interaclons 2. Les logiciels fonclonnels 3. La collaboralon avec le client 4. La réponse au changement les processus et les oulls une documentalon exhauslve la négocialon de contrat le suivi d'un plan ULles, nécessaires, mais moins importants que Les 12 principes de l agilité 1. Notre première priorité est de salsfaire le client en livrant tôt et régulièrement des logiciels u=les 2. Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compé==f pour le client 3. Livrer fréquemment une applica=on fonc=onnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte 4. Les experts méler et les développeurs doivent collaborer quo=diennement au projet 5. Bâ=ssez le projet autour de personnes mo=vées. Donnez- leur l'environnement et le soulen dont elles ont besoin, et croyez en leur capacité à faire le travail 6. La méthode la plus efficace pour transme[re l'informalon est une conversa=on en face à face 7. Un logiciel fonc=onnel est la meilleure unité de mesure de la progression du projet 8. Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et ullisateurs devraient pouvoir maintenir le rythme indéfiniment 9. Une a[enlon conlnue à l'excellence technique et à la qualité de la conceplon améliore l'agilité 10. La simplicité - l'art de maximiser la quanlté de travail à ne pas faire - est essenlelle 11. Les meilleures architectures, spécificalons et conceplons sont issues d'équipes qui s'auto- organisent 12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens 7
L approche Scrum: un survol ScrumMaster Équipe Scrum Utilisateurs Vision Product Owner Les aclvités menant à la qualité PRATIQUES D ACQ DANS LES PROJETS AGILES 8
Principes et orientalons de l ACQ 1. La qualité est l'affaire de tous à rôles et responsabilités 2. Chaque pralque et livrables du processus doit être conforme avec ses critères de qualité, soit ses objeclfs à a[eindre à pra=ques agiles d inspec=on à pra=que du carnet de produit 3. «Qualité» de nos applicalons et de nos processus en tant que critère non négociable à défini=on de terminé 4. L équipe applique les principes d amélioralon conlnue à Rétrospec=ves 1. Rôles et responsabilités imputable d un carnet de qualité, du ROI et de l acceptalon du produit Scrum Master surveille l applicalon du processus agile Responsable de produit L équipe responsable des eslmalons, de prendre des engagements et de livrer des résultats 9
2a. PraLques agiles d inspeclon Mêlée quotidienne pour assurer le bon déroulement de l itération Rétrospective pour vérifier et améliorer le processus de l équipe Revue d itération pour valider le dernier incrément de logiciel Tests automatisés pour valider la qualité du produit à chaque mouvement de code PraLques adaptées au cycle de VerificaLon, ValidaLon, Revue, et Audit 2b. PraLque du carnet de produit Chaque itération met en œuvre les exigences prioritaires Il est possible en tout temps de changer l ordre de priorité des exigences Chaque nouvelle exigence est insérée dans la liste selon sa priorité Les exigences peuvent être supprimées en tout temps 10
Le carnet de produit (suite) Chaque item est un «contrat» entre l équipe et le client Chaque item est un projet en soit: Requiert toutes les disciplines, de l analyse jusqu au tests Définit un test d acceptalon Répond à la définilon de terminé Adapté aux tests automalsés: unitaires et fonclonnels Ne peut pas être parlellement livré à qualité «produclon» Un item du carnet (exemple) En tant que Responsable de la tarifica4on Je veux effectuer l'analyse et l'ajustement des baux et de l espace occupé Afin d ajuster le loyer des clients pour les 3 prochaines années Avec le formalisme des Stories, les items sont écrits sous la forme d un besoin de l ullisateur plutôt que sous la forme d une descriplon de fonclonnalité 11
la descriplon de l item (exemple) Pour ce faire, je veux obtenir les données: Par immeuble et par bail à espace et taux Pour les baux ayant le type d'aclon bail = ajustements préétablis et un statut = en a[ente je veux les dates effeclves de ces ajustements et les taux prévus des ces ajustements. [ ] et les condilons de succès!!! Dans la sous- seclon ANALYSE DES SUPERFICIES, les «types d'espaces» présents au bail sont affichés Pour chaque type d'espace, je peux voir à l'écran la «superficie réelle du Parc», la «superficie du bail» et «l'écart réel vs bail» Pour chaque «type d'espace», je clique sur un bouton d'édilon qui m'ouvre une fenêtre dans laquelle je peux faire des «ajustements» de superficie au bail [ ] Une Story c est tout ça: - Un besoin d affaires - Une descriplon - Et les condilons de succès 12
3. DéfiniLon de terminé Entente sur les pralques de qualité entre le client et l équipe La définilon de «terminé» devrait s'étendre à toutes les ac=vités nécessaires à la livraison en produclon Le travail qui n'est pas couvert pas la définilon de «terminé» (travail «non terminé») doit être iden=fié et porté au carnet de produit Tout élément qui ne respecte pas la définilon de «terminé» n'est pas présenté à la revue d itéra=on DéfiniLon de terminé (exemple) Période Défini=on de terminé Story Devis fonclonnel rédigé Code intégré au geslonnaire de code source IntégraLon conlnue réussie Tests unitaires écrits et réussis à 100% Remodelage effectué Code revu par un pair Respect des normes IUG Aucun averlssement lors de la compilalon ItéraLon Mêmes éléments que pour la story, plus: Bilan d itéralon publié sur le Wiki Livraison Déployé sur l'espace de pré- produclon Répond au plan de Tests de stabilisalon (à préciser) Procédure de déploiement fonclonnelle et documentée Guide ullisateur rédigé au niveau du dernier incrément Phase Déployé sur l'espace de produclon Équivalente au plan qualité logiciel (SQAP) en grande parle! 13
Un produit de qualité produclon à chaque itéralon! De[e technique 14
Stop the line! Il est risqué, voire dangereux, de continuer si un problème est connu mais ignoré 29 4. RétrospecLve La rétrospec=ve fait suite à la revue d itéralon Permet à l'équipe de prendre du recul sur l'itéralon terminée et le processus de travail L'équipe s'auto- évalue sur ce qui a bien fonclonné, ce qu'on doit faire autrement, et les axes d'amélioralon L équipe définit des ac=ons pour s'améliorer dès la prochaine itéralon 15
Ce qui n est pas couvert par les méthodes agiles PRATIQUES ORGANISATIONNELLES AU- DELÀ DES PROJETS PraLques du CMMI couvertes en parle PPQA VER Produit logiciel Processus du projet Établir les enregistrements L ensemble des pralques VER, sauf Analyser les données des revues par les pairs VAL 16
PraLques du CMMI non couvertes À peu près tout ce qui conlent le mot «organisa=onnel» à Typiquement en dehors de la portée des méthodes agiles DéfiniLon du processus organisalonnel FocalisaLon sur le processus organisalonnel Assurance qualité sur des aclvités organisalonnelles (ex. bureau de projet) Parce que les méthodes agiles sont peu prescriplves, une organisalon a toute la laltude pour entourer et soutenir ses équipes Le carnet de produit (Processus qualité) Objec=fs Qui (Rôles) Durée Quand Condi=ons d arrêt Engagement de l équipe Définir le but de l itéralon Découpage en tâches Responsable de produit Analystes fonclonnels Développeurs Scrum Master 2 à 4 heures Au début de l itéralon Livrables en entrée Carnet de produit Livrables en sor=e L équipe est en mesure de s engager sur le travail à faire pour l itéralon courante Carnet d itéralon Carnet de produit mis à jour Plan de livraison 17
Revue d itéralon (Processus qualité) Qui valide? Fréquence Critères Traitement ajendu des non- conformités Délai de résolu=on ajendu des non- conformité Escalade des non- conformités (dernier recours) Responsable de produit À la fin de chaque itéralon DéfiniLon de terminé Scénario de démonstralon est préparé à l avance par l équipe. Seulement les stories «terminées» sont présentées à la démonstralon Toutes les stories démontrées sont soumises à l acceptalon du responsable de produit Au besoin, accompagner l équipe de projet à compléter son scénario de démonstralon Ramener à l ordre l auditoire lors du déroulement du scénario Accompagner le responsable de produit à me[re à jour le carnet de produit pour les stories démontrées mais non acceptées Pendant la démonstralon idéalement. Sinon, avant la planificalon de la prochaine itéralon. Résoudre les non- conformités avec le responsable de produit et l équipe de projet. Doit- on craindre une non- qualité avec les méthodes agiles? CONCLUSION ET DISCUSSION 18
Discussion Défis et difficultés liés au non- respect des meilleures pralques au regard de la qualité, quels sont- ils? à Similaires, peu importe que l équipe soit agile ou pas: Processus non suivi à AQ déficiente PraLques bâclées de contrôle de la qualité Conclusion Le principe directeur Agile est de livrer LE BON PRODUIT fonclonnel, de qualité produclon, ce qui est en ligne avec les objeclfs de l ACQ L ACQ est l affaire de TOUS LES INTERVENANTS, pas seulement les responsables du contrôle de la qualité Les pralques agiles offrent de mul=ples points d inspec=on pour combler les besoins liés à l ACQ 19
Vos questions? Données supplémentaires ANNEXES 20