L’agilité depuis près de 20 ans a largement démontré au travers de nombreux rapports statistiques tels que ceux du Standish Group (Chaos Report) l’efficacité de la qualité vis-à-vis de la réussite des projets.
Le cycle de vie dans le cadre d’un développement en mode Agile et plus spécifiquement SCRUM se présente comme suit : 
L’équipe va garantir en
s’appuyant sur une approche incrémentale, itérative et des cycles courts, une
convergence avec le besoin métier et également un haut niveau de qualité, étant
donné une activité soutenue de tests et la livraison d’un incrément
potentiellement livrable en production à chaque fin d’itération. Ce processus,
pouvant aller de 1 à 4 semaines maximum, implique une inspection des
fonctionnalités produites afin de vérifier la conformité aux critères
d’acceptance, ainsi que de la qualité desdits livrables aux travers des tests
et du contrôle de qualité de code. Si un des points n’est pas satisfait, le
livrable est rejeté et replacé dans le Product Backlog pour finalisation au
Sprint suivant. Ceci est décidé au cours de la session de Sprint Review, lors
de laquelle, l’équipe va présenter au Product Owner et aux parties prenantes du
projet, les fonctionnalités développées lors du Sprint. Le critère de passage
pour rappel est la conformité avec la « Definition of Done » ainsi
que la validation du Product Owner.
L’activité de tests est donc bien évidemment au centre d’une stratégie
qualité, qui en fait englobe un plus large panel d’activités dont la plupart viennent
du monde agile. Nous allons donc dans un
premier temps définir quels sont les concepts clés à prendre en compte dans une
stratégie qualité et nous mapperons le concept avec le ou les outils proposé
par Visual Studio 2013
La DOD : Definition of Done
L’état Terminé se définit comme l’état ou la fonctionnalité d’un incrément
logiciel devient potentiellement candidat à une mise en production. La Définition
of Done (DOD) est une simple check-list auditable définie par l’équipe de
développement et qui peut être influencée par les standards de l’organisation
du projet (standard d’architecture, normes qualités etc.). La DOD est un des
éléments qui va permettre de valider comme terminé le développement d’un PBI.
Ci-dessous un exemple de DOD :
·
Code complété, compile et archivé dans le contrôle
de code source
·
Tous les tests passent (Tests unitaires, acceptance,
non régression)
·
Les critères d’acceptance du Product Owner sont validés
·
Nombre de Bugs critiques ouverts : 0
·
La couverture de code est >= 70%
·
Le nombre de warnings FXCop<=20
Coté Visual Studio 2013, la DOD fera appel au Contrôle de Code Source
TFS, les tests unitaires, le calcul de couverture de code, les builds automatisés,
le module de gestion de projet Agile avec Web Access, le système de suivi des
bugs, et Microsoft Test Manager
La gestion de la dette
technique
La dette technique est une
métaphore inventée par Ward Cunningham dans les années 90. Il compare le
concept existant de dette dans le domaine financier et l'applique au domaine du
développement logiciel.
Par définition, la dette
technique est un ensemble d’accumulation d’imperfections techniques liées à un
projet dans sa globalité, le plus souvent non visible par l’utilisateur. A
l’instar d’une dette financière, Ward Cunningham parle du point de non-retour,
à partir duquel nous ne serons plus capables de rembourser la dette technique.
Les causes principales sont généralement une mauvaise qualité du code, un
manque de tests et / ou d’automatisation des tests, l’absence de validation à
fréquence régulière en se basant sur une liste DOD par exemple. Un processus de
contrôle qualité et des cycles courts Agiles avec le respect d’une Definition
of Done seront très efficaces pour gérer cette dette et ou l’endiguer. D’autres
pratiques d’ingénierie Agile tel que le refactoring, le Pair Programming, la
mise en œuvre d’analyse de code statique et dynamique ainsi que des tests de
performance participeront également au contrôle de cette dette et éviter le
point de non retour.
Visual Studio 2013 fournit
l’ensemble des métriques permettant de piloter une dette technique et permet au
travers de la plate forme de reporting de produire les rapports adhoc
Les points de contrôle et de Reporting
La mise en place de tableaux de bord ou rapport de
statut permettant de fournir les
métriques qui seront vérifiées à
chaque fin d’itération. Cette pratique est parfaitement en conformité avec
Scrum dont les trois piliers sont la transparence, l’inspection et l’adaptation
avec notamment l’opportunité à chaque fin de Sprint d’inspecter le niveau de
qualité de l’incrément et potentiellement l’adapter pour être conformes aux
niveau exigé par le projet avec par exemple, le niveau de Warning FXCop, le
nombre de tests unitaires ainsi que la couverture de code associée, l’état de
la Build tout au long du Sprint, et un rapport sur la couverture et les
résultats des tests fonctionnels.
Visual Studio 2013 fournit
une plate forme de reporting et également un cube OLAP qui permettra de suivre
les métriques du plan qualité et de les présenter dans un rapport de statut
Le
Refactoring : cette pratique d’amélioration du code et de son
design consiste à changer la structure interne du code sans en affecter le
comportement externe, en d’autres mots, améliorer le code sans casser les tests
unitaires, le refactoring ne doit être fait que pour minimiser la dette
technique, ajouter de la valeur métier ou atteindre la « Definition of Done »
de l’équipe
L’IDE Visual Studio fournit
un outil de refactoring intégré et permet également d’intégrer sous forme de
plugin des outils tiers tel que Resharper par exemple
Le
Pair Programming :
Lors de cette pratique, deux développeurs vont travailler sur une tache de
développement et alterner à fréquence constante. Pour cela, les développeurs
pourront utiliser la méthode Pomodoro par exemple. Souvent controversée, cette
méthode apporte pourtant de nombreux avantages tels qu’une meilleure qualité
due à une inspection er revue du code continue, on notera également une
augmentation des compétences et le partage des connaissances avec également une
meilleure cohésion dans l’équipe. Généralement le code produit est plus
rapidement conforme à la Definition of Done.
Le couplage des tests
unitaires et du refactoring font que Visual Studio 2013 est un outil
parfaitement adapté à une approche TDD
Analyse
de code statique : cette
fonction va relever la présence de défauts dans le code et lever des warnings ou des erreurs lors de la compilation. Le
principe est de confronter le code écrit aux 200 règles et bonnes pratiques
édictées par Microsoft couvrant les domaines suivants : Design, globalisation,
interopérabilité, maintenabilité, conventions de nommage, performance,
stabilité, sécurité, et usage de code. L’analyse statique de code doit être
utilisée dans le cadre du processus d’intégration continue, mais également dans
le cas de développement externalisés ou encore dans le cadre d’audits.
Avec le module d’analyse de
code statique, il est possible dans Visual Studio ainsi que dans le processus
de Build d’intégrer une politique qualité personnalisable basée sur des
templates :
Sprint
Reviews : Le Sprint Review est un
évènement qui clôture un Sprint et qui a pour vocation l’inspection des
fonctionnalités délivrées afin de valider si l’incrément sera accepté ou
replacé dans le Product Backlog. Cet évènement fait partie de la stratégie qualité,
car c’est à ce moment que le Product Owner inspecte en présence des parties
prenantes les fonctionnalités livrées pour validation ou non.
Intégration
continue (CI) : Cette
pratique implique que les développements intégrés dans le contrôle de code
source doivent faire l’objet à fréquence fixe ou lors d’évènements tel que le
check in d’un développeur d’une compilation globale avec un jeu complet des
tests unitaires ainsi que d’un processus d’analyse de code statique.
Dans Visual Studio 2013, le
support de l’intégration continue repose sur le service de Build, permettant de
créer des builds des solutions composant un projet avec le jeu des tests
unitaires et le contrôle de l’analyse statique du code. Une fonctionnalité
particulièrement intéressante avec Visual Studio est le Gated Check in. Sur le
principe, dès qu’un développeur va soumettre son code pour archivage,
l’archivage ne sera accepté qu’à la condition ou le code fusionne et compile
avec succès avec le code coté serveur. Techniquement, TFS crée un Shelve coté
serveur, fusionne le code proposé par le développeur puis le compile. En cas
d’échec, l’archivage est rejeté, dans le
cas contraire, le code est intégré au contrôle de code source. Ci-dessous la
configuration d’un build avec l’analyse de code et le jeu des tests
unitaires :
Déploiement
Continu (CD) : Ce
concept va permettre à l’issue d’un build
de déployer automatiquement l’ application afin que les testeurs aient en
permanence la dernière version à tester. Le déploiement continu constitue une
automatisation à très haute valeur ajoutée qui de plus va engendrer des
économies importantes de temps à l’équipe car il s’agit très souvent d’une tache fastidieuse et
répétitive.
Visual Studio 2013 va
proposer cette fonctionnalité de déploiement continu en se basant sur la brique
Lab Management via les workflows BDT (Build Deploy Test). Dans ce cas la
solution est compilée, testée unitairement puis déployée sur un environnement
cible puis des tests automatisés ou manuels pourront être joués sur ces
environnement. Ci-dessous un lab avec un serveur d’application et un client
provisionné dans Lab Center :
Ci-dessous un template de
Build en mode édition montrant le designer XAML permettant la modification du
workflow de build avec l’ajout de séquences de déploiement (la technologie
sous-jacente est Workflow Foundation 4.0)
Automatisation
des Tests : Cette pratique va
consister simplement à intégrer le jeu des tests de non régression au processus
d’intégration continue. L’automatisation pourra également inclure des tests
automatisés d’interfaces utilisateurs.
Visual Studio avec la
plateforme de build et la mise en œuvre de scenario BDT avec Lab Management
vient outiller ce scenario de bout en bout.
Gestion
des Bugs : Quand bien même,
en Agile, la devise pour les bugs
est : "Just Fix them, don't manage them!" (Fixez les, ne les gérez pas !), un système de
gestion d’anomalies est au centre d’une stratégie qualité, ceci
particulièrement lorsque l’application est utilisée par des équipes autres que
l’équipe de développement, ou encore lorsque certains bugs ne pourront pas être
gérés dans le Sprint en cours, à ce moment-là , ils pourront être tracés dans
le système de suivi d’anomalies. Un des pointé intéressant du suivi des bugs
est aussi le suivi de la volumétrie des bugs et également celui des bugs
critiques qui potentiellement peuvent être bloquant pour la validation d’un
Sprint, avec par exemple l’inclusion dans la Definition of Done de la clause 0
bugs critiques.
Avec Visual Studio 2013, deux
outils permettront la création et la gestion des bugs : pour les testeurs,
il s’agit de Test Runner, qui va permettre la création de bugs riches grâce au
collecteur intégré, pour toutes les autres parties prenantes, la plateforme Web
Access va permettre la création et le suivi des bugs au travers du tableau de
bord du portail Web Access et aussi des requêtes de work items.
Coté développeur, Visual Studio 2013 apportent de nombreuses
fonctionnalités qui vont permettre un
meilleur contrôle de la qualité du code avec :
Code
Lens : Cet outil confère un
affichage de type tableau de bord dans l’IDE au niveau fonction mais aussi au
niveau du type permettant au développeur de disposer d’informations
contextuelles, de manière configurable via le menu options, avec :
·
Statut des
Tests unitaires
·
Testé par
·
Références
·
Auteur
·
Changements
·
Work items
/ bugs
·
Code
Reviews
Le développeur peut non
seulement consulter les informations mais aussi accéder à ces informations en
cliquant sur les hyperliens tel que montré ci-dessous :
Code
maps : cette fonctionnalité permet de
retranscrire des portions de code en format Visuel et analyser efficacement les
dépendances du code .Il permet d’appréhender la complexité par le visuel et de mieux gérer la structure du code pour mener
à bien une tache de refactoring par exemple.
En conclusion, la richesse fonctionnelle de
la plate forme Visual Studio 2013 va permettre d’intégrer ses équipes dans une
réelle approche Dev-Tests au travers d’outils performant centré sur la qualité,
l’agilité, l’automatisation et la productivité. L’outillage des méthodes et
pratiques explicitées dans cet article avec Visual Studio 2013 permettra d’optimiser la probabilité de réussite de tout
projet informatique.
Aucun commentaire:
Enregistrer un commentaire