Stratégie de test, Qualité et Agilité: la Vision qui change tout

Posté par jc-QualityStreet le 11 mars 2009

On dit toujours que l’agilité met l’accent sur la qualité. C’est vrai :

• des pratiques telles que l’intégration continue, les tests unitaires, les tests de recette, le pair programming mais aussi une volonté évidente d’automatisation jouent indéniablement sur la qualité du produit logiciel…
• le client sur site et de courtes itérations, pour plus de collaboration et de feedback permettent de s’assurer que le “bon produit” est développé…
• Avec l’ajout d’un regard Lean et d’une approche ergonomique, le compte est souvent bon…

ET POURTANT dans les faits, stratégie de test et testeurs ont du mal à se retrouver dans les projets Agiles, comme si toute une approche qualité était occultée, menée de manière anarchique, sans ligne directrice…
ça doit changer; ça va changer !

VERS UNE NOUVELLE VISION DES TESTS DANS LES PROJETS AGILES… trois éléments déterminants

Intégrer les testeurs dans l’équipe Agile et enrichir leur rôle (à la fois plus proches et au service de l’équipe mais aussi en soutien fort du Product Owner, du Métier). Cette alerte Agile (Où sont les testeurs) allait dans ce sens, et les résultats sont le plus souvent probants.

Donner un nouvel élan à la stratégie de test dans une dynamique agile. La stratégie de test se doit d’abord d’être envisagée dans une dimension high level en Sprint 0 pour l’ensemble de la version (une version, c’est entre 3 et 6 mois). Ensuite, le challenge du testeur est de l’ajuster en contexte à chaque début de sprint, en fonction du contenu du sprint à venir et de ce qui a été qualifié de Done au sprint précédent. A ce niveau, on va à l’essentiel : la stratégie de test, niveau sprint a la particularité d’être à la fois synthétique et trés précise !

S’appuyer sur le génialissime modéle de Brian Marick (signataire de l’Agile Manifesto et Star de la qualité logiciel) pour formaliser cette stratégie de tests. A chaque sprint, piocher son type de tests dans tel ou tel quadrant. Un modèle, trés visuel, instantanément compréhensible et trés parlant non seulement par le spécialiste QA qui sommeille en vous, mais aussi par toute personne impliquée dans un projet informatique.

4 quadrants qui à eux seuls guideront l’ensemble de votre stratégie:

1. Tests orientés Technologie en soutien de l’équipe (ex : Tests unitaires et approche TDD , le plus automatisé possible)
2. Tests orientés Business en soutien de l’équipe (ex: les tests sur storyboard, les tests fonctionnels pour vérifier les critères d’acceptation du Product Owner: l’approche de conception centrée utilisateurs et l’ergonome y trouvent leu compte)
3. Tests orientés Business pour critiquer le produit (c’est avant tout du manuel, à tout moment ou en End Game pour le systéme complet en test d’acceptation. L’approche ergonomique ressort encore : quand on vous dit qu’il faut faire des Tests Utilisateurs !)
4. Tests orientés Technologie pour critiquer le produit (des tests essentiels qui se doivent d’être outillés et qui peuvent nécessiter la présence de spécialistes, perf / sécurité; souvent en End Game hormis simulations)

ISO 9126, SQuaRE : Qualité, Utilisabilité … et une aubaine pour l’Ergonome

Posté par jc-QualityStreet le 7 novembre 2007

L’ISO 9126 « Software Product Quality » (2001) et l’ISO SQuaRE « Software Product Quality Requirement and Evaluation » (2005) (fusion de 9126 et 14598, son volet évaluation) font partie de ces normes qu’il est bon de connaître quand on travaille dans le développement de logiciels ou plus largement dans la conception de services interactifs.
MàJ du 08/11/2007 : Pour une définition plus précise de l’ergonomie et de l’utilisabilité, jetez-un oeil à ce billet ”Ergonomie = Utilité + Utilisabilit锑

L’essentiel pour moi, Ergonome

• La mise en avant de l’Utilisabilité (facilité d’utilisation) : c’est l’une des 6 caractéristiques du modèle de qualité
• La présence de l’Attractivité en plus de sous caractéristiques plus classiques : c’est la reconnaissance de l’esthétisme, de l’affect, du “beau” au niveau de l’interface… élément qui fait régulièrement débat
• L’introduction (forme révisée) du concept de “Quality in use” avec 4 caractéristiques : Efficacité, Efficience, Sûreté, Satisfaction… mon “Ergonomie en 3 mots” pourrait pourquoi pas, se transformer en une “ergonomie en 4 mots”
• La mise en oeuvre des mesures

En bref
ISO 9126 et ISO SQuaRE fournissent un modèle, fait de caractéristiques et sous-caractéristiques, permettant de lier les qualités externes d’un logiciel à ses qualités internes, et introduisent fort justement (même si on a tendance à l’oublier) le concept de “Quality in use” (« the user’view of the quality of the software product when it is used in a specific environment and a specific context of use ») : une vraie porte ouverte vers les Tests Utilisateurs et l’observation en contexte.

6 caractéristiques de qualité (avec un focus sur l’Utilisabilité)

1. Capacité fonctionnelle
2. Fiabilité
3. UTILISABILITE (en anglais, “usability” qu’on peut traduire aussi par “facilité d’utilisation”, c’est à dire un “Ensemble d’attributs portant sur l’effort nécessaire pour l’utilisation et sur l’évaluation individuelle de cette utilisation par un ensemble défini ou implicite d’utilisateurs”) : Facilité de compréhension, Facilité d’apprentissage, Opérabilité, Attractivité, Conformité aux standards d’ergonomie
4. Rendement
5. Maintenabilité
6. Portabilité

Pourquoi ça m’intéresse ? Qu’est ce que ces normes m’apportent ?

• La qualité des produits est mon leitmotiv, ce vers quoi je tends…
• Ces normes sont à elles seules le symbole de la convergence de plusieurs disciplines de l’ingénierie
• C’est la reconnaissance de ma propre discipline, l’Ergonomie, de mon rôle et de mon expertise (en particulier sur les questions relatives à la facilité d’utilisation), cela peut légitimer mon intervention
• C’est un point d’entrée idéal pour l’ingénierie des exigences (du recueil à la gestion des exigences en passant par l’analyse du besoin): j’utilise ces caractéristiques pour qualifier les exigences fonctionnelles et non fonctionnelles recueillies
• Cela facilite ma collaboration avec les services QA (Quality Assurance) et sur un projet avec un Responsable de test
• Il existe un lien fort avec des domaines de processus CMMI, niveau 2 et 3, je pense notamment à RD “Développement des exigences”, REQM “Gestion des exigences”, VER “Vérification”, VAL “Validation”, TS “Solution technique”, MA “Mesure et Analyse” …

CMMI et Méthodes Agiles : Questions de motivations

Posté par jc-QualityStreet le 16 septembre 2007

Après “Agile CMMI: moi j’y crois” et “CMMI, décidemment nous y sommes“, imaginons maintenant quelles pourraient être les motivations respectives des auteurs ou partisans des deux approches pour un rapprochement (selon moi inévitable) du CMMI (Capability Maturity Model Integration) et des Méthodes Agiles.
Au programme : Convergence … Complémentarité … Popularité … Amélioration continue … Succès.

Convergence
Agilité et CMMI se donnent les mêmes objectifs, notamment niveau Client (satisfaction, rétention, acquisition), niveau Projet (respect côut, délais, qualité) et niveau Collaborateurs (satisfaction, montée en compétence…). Partager le même but peut faciliter les rapprochements…

Complémentarité
CMMI définit le “Quoi” mais a besoin d’éléments pour atteindre les objectifs qu’il se fixe. L’agilité peut donc en partie constituer ces éléments et se charger d’une partie du “comment”, ce qui contribuera au passage à lever les idées reçues concernant les deux approches.
Qui dit Agile ne dit pas absence de discipline, Scott Ambler en parle remarquablement dans ce tout récent article « The discipline of Agile » ; Et, Qui dit CMMI, ne signifie pas pour autant lourdeur excessive.

Popularité
Sans enlever à la notoriété du CMMI, fort populaire dans certains contextes, il est évident que les Méthodes Agiles ont actuellement le vent en poupe. Déjà populaires dans les pays anglo-saxons, elles se démocratisent en France. Ainsi, intégrer plus largement, plus visiblement, plus concrètement, en son sein, des pratiques Agiles (pour chaque but par exemple) pourrait permettre au CMMI d’envisager d’autres cibles.

Amélioration continue
C’est un principe Agile, c’est l’essence même du CMMI … et un facteur motivationnel de 1er ordre pour l’ensemble des acteurs des univers CMMI et Agile, qui pourraient, dans l’agilité ou dans la maturité, trouver les moyens d’améliorer leurs propres pratiques, de combler leurs lacunes et faiblesses….

Succés
Dans le prolongement du point précédent, de récents retours d’expérience nous ont prouvé l’efficacité, que dire, le succès de la combinaison des méthodes Agile et du CMMI. Ensemble on est plus forts, c’est le message que fait passer Jeff Sutherland et dont je suis entièrement convaincu !

Si à votre tour, vous voyez d’autres « motivations », n’hésitez pas à nous les faire partager…

Gestion des risques: mieux vaut être AGILE

Posté par jc-QualityStreet le 10 septembre 2007

Les Méthodes Agiles et  le Processus Unifié ne se contentent pas d’une gestion “classique” des risques; ils approchent les risques d’un projet informatique de manière beaucoup plus offensive, à la fois en termes de considération et de traitement: le projet est entièrement organisé pour lever au plus vite les risques les plus forts, ceux menaçant le plus de compromettre la bonne marche du projet.

Savoir gérer les risques est une bonne pratique de gestion de projet enseignée déjà depuis bien des années … alors pourquoi vous en parler aujourd’hui ?

• Parce que le Processus Unifié surtout et l’Agilité ont redonné au risque une place de choix : les risques pilotent le projet (du moins pour le Processus Unifié), le contenu des itérations, et impactent donc l’activité de chacun d’entre nous (du développeur au testeur, de l’ergonome au Client ….).
• Parce que les bonnes pratiques Agiles, issues de SCRUM ou XP (courtes itérations, livraison incrémentale, daily scrums, reporting visuel, intégration continue, feedback client …) sont des armes redoutables pour faire face aux risques inhérents à tout projet informatique
• Parce que sur terrain, l’analyse des risques doit être conduite dans cette finalité, ce qui nécessite une véritable prise de conscience … Place à l’offensive (c’est là qu’elle prend tout son sens), n’y allons pas à reculons, ou simplement parce que le PMI nous dit de le faire ou que c’est un domaine de processus du CMMI !
• Parce qu’on sous estime (voire néglige) toujours des activités majeurs : Surveiller, Suivre et réajuster, Communiquer, Capitaliser pour les autres projets. Dans mon organisation, le pilotage par les risques (l’un des 6 principes du Processus Unifié) a été perçu comme un point fort; l’analyse a selon les cas été bien menée, servant de base à une priorisation des dév. (après arbitrage), malheureusement la suite n’a pas toujours suivi, sans parler de la base de risques, inexistante !! A nous d’aller jusqu’au bout et de s’en donner les moyens …
• Et parce qu’au final, la gestion des risques s’applique partout : petit ou gros projets, informatique ou non, comme le suggère la définition de l’AFNOR (« Un risque est un événement dont l’apparition n’est pas certaine et dont l’apparition est susceptible d’affecter les objectifs du projet »)

Bon, allons à l’essentiel, et glissons-nous un instant dans la peau de notre Chef de Projet Agile …
La gestion des risques sera partagée par l’équipe mais tout de même sous ma responsabilité… Je vais tout d’abord user et abuser du RISK BOARD tout au long du projet. Pour le rest dans les grandes lignes:

1. Je mène l’analyse des risques de mon projet (sur la base de check-list, celle du SEI par exemple, grilles, critères, brainstorming …), évidemment pas tout seul en m’appuyant sur l’expertise de mes collègues techniques et analystes, sans qui je ne suis rien ! Je m’aide aussi de ces 5 catégories de risque pour y voir plus clair : Client / Organisation du projet / Métier (et fonctionnel) / Technique (et technologique) / Fournisseur (pratique quand on a des sous traitants).
2. Très vite, et grâce au concours de mes collègues experts et de l’équipe, je valorise les risques en termes de Sévérité de l’Impact (délais, coûts, qualité…) et Probabilité d’apparition, ce qui me donne pour chaque risque un indicateur (une note) de criticité. C’est très classique.
3. Je documente ensuite une fiche de risque, disons pour les 8 à 10 risques majeurs ; risques que je suivrai tout particulièrement. C’est à ce moment que je vais consulter mon responsable des tests car sa stratégie de tests sera impactée.
4. Je veille ensuite à ce que les risques ne se transforment pas en problème, organise mon projet pour « lever » au plus vite les risques majeurs (en traitant par ex. en priorité les use cases / user stories contenant les éléments les plus risqués), utilise les bonnes pratiques Agiles les plus appropriées (côté technique, côté test, ou côté gestion de projet) et choisis plus globalement d’appliquer à mes risques l’une des 3 stratégies suivantes : Evitement, Transfert (autres équipes, autres projets ….) ou Acceptation (provisoirement en cherchant à réduire son impact, sa probabilité d’apparition ou définitivement si son impact est faible; le cas échéant, je passe au plan de secours)
5. Je surveille, effectue le suivi et réajuste ma liste de risques … estimation et planification des itérations … arbitrages mais aussi feedback, rétrospective et adaptation ; toutes ces pratiques garderont le risque au coeur des préoccupations de mon équipe.
6. Je mets à jour ma liste des risques et communique (notamment auprés de mon équipe) sur ceux-ci à chaque début et fin d’itération, et chaque jalon important ; communication verbale et écrite … Sans compter mes scrums tous les 2 ou 3 jours où ils sont régulièrement évoqués : en quoi puis-je t’aider ? .
7. Mon projet se termine, je capitalise : la destinée de mes risques fut variable mais je les ai tracés, j’ai récolté de précieux indicateurs … et je commence à me constituer une base de risques disponible pour les projets suivants.

Au final: de l’AGILITE avec anticipation des difficultés et des points bloquants, maîtrise rassurante du projet et de ses évolutions, atteinte des objectifs, mais aussi une démarche disciplinée, définie et maîtrisée telle qu’attendue par le CMMI entre autres dans les domaines de processus suivants (PP, Planification du projet ; PMC, Surveillance et contrôle du projet ; RSKM, Gestion des risques).

AGILE CMMI: moi j’y crois

Posté par jc-QualityStreet le 3 septembre 2007

Plus qu’une simple tendance, le rapprochement des Méthodes Agiles et du CMMI (Capability Maturity Model Integration), ou plus exactement l’usage de pratiques de développement Agiles (qui ont le vent en poupe) dans une dynamique de processus guidée par le CMMI (version1.2 DEV d’aout 2006) est bel et bien réel.

Les exemples concernant XP et SCRUM (voir les études de Mickael Spayd, Mark Paulk, Hillel Glazer ou encore Jeffrey Dutton) se multiplient depuis quelques années.
Dernier exemple en date (trés bien documenté d’ailleurs), celui de Codice Software (un éditeur espagnol), “SCRUM Meets CMMi, Agility and discipline combined“, avec à la clé l’atteinte d’un niveau 2 de maturité et une vision trés pragmatique de la combinaison des deux approches (un vrai travail sur REQM, “Gestion des exigences”, des domaines complètement nouveaux et pas des plus simples dans un contexte Agile: PPQA, “Assurance Qualité Processus et Produit” et MA, “Mesure et Analyse”….).

Dans un contexte plus général, cette démarche de réconciliation Agile CMMI (c’est un bien grand mot !) est soutenue, et c’est trés positif, par des acteurs majeurs des deux “camps”, mais elle implique aussi, selon moi, à notre niveau, l’acceptation de certains prérequis:

• D’abord considèrer le CMMI tel qu’il est, à savoir, un modèle, un guide, et non pas un processus ou une méthode de développement.
• Se souvenir que le CMMI définit seulement le QUOI (par ses objectifs par exemple) et non pas le COMMENT, même si le modèle propose quelques pistes. Et c’est vrai que cette absence de COMMENT a laissé la part belle aux méthodes dites traditionnelles (cascade ou V) toujours bien ancrées.
• Ne pas oublier que seule l’atteinte des objectifs généraux (GG, liés à un niveau de maturité) et spécifiques (SG,liés à un domaine de processus) est requise lors d’une évaluation SCAMPI (méthodes standards d’évaluation). Les pratiques (GP, génériques liées à un niveau et SP, spécifiques liées à un domaine de processus) ne sont quant à elles pas obligatoires, et des alternatives (Agiles notamment) sont envisageables : c’est un bon point d’entrée.
• S’arracher des idées reçues concernant les deux Mondes … (vaste débat), rechercher l’ouverture, et d’un point de vue pratique, au quotidien, s’appuyer sur des leviers organisationnels exploitables.

David Anderson a su trouver les mots justes lors de l’Agile2005:

A key to achieving more agility with the CMMI is to realize that the practices are primarily advisory or indicative only. To meet a CMMI appraisal, an organization must demonstrate that the goals of a process area are being achieved. This is done by identifying evidence of practices. However, the practices need not be the ones described in the CMMI specification. The organization is free to propose alternatives practices and appropriate evidence. The appraisal team must then agree to whether this is appropriate to demonstrate the goal. This provides a process designer with a great deal of freedom.

En conclusion, si vous entendez les mots Agile et CMMI dans la même phrase, ne fuyez pas … soyez curieux … et dites OUI à la convergence.