Posted by jc-QualityStreet on 5 septembre 2007
Hier encore, je vous disais que des acteurs majeurs, côté Agile et côté CMMI, se prononcent désormais pour un rapprochement des deux approches … sans doute le signal que Jeff Sutherland (oui oui le co-auteur de SCRUM) attendait pour publier sur son blog, son article, Scrum and CMMI Level 5: A Magic Potion for Code Warriors … Encore merci Jeff ! 
Plus sérieusement, ses conclusions sont plutôt explicites:
“Our recommendation to the Agile community is to use the CMMI generic practices from CMMI Level 3 to amplify the benefits from Agile methods. Our recommendation to the CMMI community is that Agile methods can fit into your CMMI framework and will provide exciting improvements to your organization.”
Quant à la démarche préconisée, précisément pour les organisations opérant déjà dans un contexte CMMI:
diagnostic avec Lean pour identifier là où ça fait mal, puis application de pratiques Agiles ajustées pour soigner tout cela (tiens tiens ça ne vous rappelle pas UP et une dose de SCRUM ?). Pour les organisations en mode Agile, s’appuyer sur les pratiques génériques CMMI, niveau 2 et 3 (sans oublier les objectifs à atteindre, génériques et spécifiques, qui eux sont obligatoires lors des évaluations).
Posted by jc-QualityStreet on 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.
Posted by jc-QualityStreet on 16 mai 2007
Plusieurs typologies de tests (le plus souvent complémentaires) coexistent ; la première d’entre elle, la plus simple, distingue les tests « Boite blanche » des tests « Boite noire » (différence en terme d’accès au fonctionnement interne de l’application). Une autre insistera davantage sur les aspects Statiques ou Dynamiques. On pourrait aussi catégoriser les tests selon le type d’activité à mener (l’IEEE 1012), Vérification (est-ce un produit bien fait ?) ou Validation (avons-nous fait le bon produit ?).
Je vous présente aujourd’hui la classification que j’utilise et qui mixe quant à elle, niveaux de test et caractéristiques de test. Cette classification répond à mes problématiques de ces dernières années et s’adapte à de nombreux contextes:
Avantages :
- C’est un bon support de communication : on va à l’essentiel (simplicité et signifiance)
- Elle s’inscrit complètement dans une démarche itérative, incrémentale et pilotée par les risques (Processus Unifié)
- Elle place les tests au cœur du projet
- Elle favorise la mise en place, dés le début du projet, d’une stratégie de test en fonction des risques identifiés et des exigences à tester
- Elle permet d’appréhender toute forme d’exigences : fonctionnelles (ce que le système doit faire), non fonctionnelles (qualité des services attendus, cf. ISO 9126)
- Elle permet de tracer ces exigences : toute exigence doit être couverte par au moins un type de test en fonction des risques
- Elle permet d’associer facilement des rôles et des ressources à un type de test (par exemple, les Tests d’Utilisabilité planifiés et réalisés par l’Ergonome; les Tests Unitaires réalisés par les Développeurs…)
Posted by jc-QualityStreet on 4 mai 2007
Le CFTL (Comité français du Test Logiciel) organise le 20 juin prochain un examen pour l’obtention du certificat Fondation (Testeur Certifié).
Cet examen se fonde sur le syllabus (de qualité d’ailleurs) réalisé par le CFTL et l’ISTQB (International Software Testing Qualification Board), document qui a pour ambition de devenir le socle des formations proposées dans le domaine du test par des organismes accrédités. Justement ma formation en cours du soir au CNAM (”Test & Validation du logiciel“) prépare à cet examen (cours, TD, exam. blanc).
L’examen est payant et s’adresse aux testeurs, responsables des tests, concepteurs de test ….; reste à savoir ce qu’il vaut et représente pour les entreprises ainsi que les benéfices que l’on peut attendre de cette certification…
Posted by jc-QualityStreet on 12 février 2007
Actualiser ses connaissances, envisager d’autres points de vue, me paraît primordial. Aujourd’hui marquait le début de deux formations que je vais suivre : Stratégie des Tests (sur 3 jours) et Test & Validation du logiciel (l’UE du CNAM en cours du soir jusqu’au mois de juin).
Dans les deux cas, je n’échapperai pas à des choses connues, déjà vues et revues: ce fut le cas pour l’essentiel de cette première “grande” journée (11 heures de formation au total!); même s’il n’est pas toujours inintéressant de se voir présenter les choses sous un angle différent.
Toutefois la suite s’annonce meilleure… Pour le première formation, focus sur l’intégration du test dans le processus itératif avec études de cas (qui répondront peut être à certaines questions que je me pose) et retours d’expèrience sur les problématiques offshore. Pour la seconde, celle du CNAM, l’étude plus détaillée des techniques de test et des aspects propres au développement : tests unitaires, intégration, automatisation.
Bref, une belle complémentarité.
Posted by jc-QualityStreet on 1 février 2007
Développé, livré et testé dans une même itération : ce n’est pas forcément naturel ; c’est même souvent une vraie difficulté pour les projets utilisant les les méthodes Agile: Processus Unifié (UP), SCRUM ou XP.
Le TimeBoxing (fixer les dates d’iteration quitte à faire évoluer le contenu de celle-ci) et les livraisons intermediaires sont bien acceptés. Reste à s’entendre sur ce qu’on livre …
Vérifier continuellement la qualité de l’application est principe fondateur du Processus Unifié. Le processus Unifié (”Unified Process” en anglais ou plus simplement “UP”) met l’accent sur la qualité des processus, sur la qualité du produit : des points déterminants dans notre choix de la méthode.
Une discipline est même formalisée, des rôles (”worker”) identifiés.
Quand vous présentez ce principe aux hautes instances de votre organisation, cette dernière est enthousiaste …il en est de même pour les équipes de développement.
Puis c’est le moment de concrétiser tout cela avec vos nouveaux projets: “ce sera environ 25% (parfois plus) de charge pour la discipline Test sur l’ensemble du projet”. Mettre le focus sur la qualité, ça a un prix : “Ah bon, vous êtes sur ?”
Mais jusque là tout va bien.
Enfin c’est le moment de mettre en application notre principe sur une itération, et c’est là que se présentent les premiers dérapages :
- “tester, désolé on a plus le temps” …
- “au fait qui va tester ?” …
- “on a pas les ressources” …
- “vous avez pris du retard les testeurs ne sont plus dispo”
- “les cas de test ne sont pas prêts”
- “ah pour vos tests on a pas l’environnement”
- “attendez !! on a livré c’est déjà bien non ?”
Et bien non, ce n’est pas suffisant: ce qu’on livre on l’a testé. On ne peut se contenter de tester dans l’iteration suivante ce qu’on vient de produire dans notre itération. Une stratégie, non, plutôt un constat d’echec et surtout davantage de risques pour l’avenir.
Ce problème est donc récurrent; malheureusement il n’y a pas de recette miracle.
Encore une fois, une prise de conscience doit avoir lieu.
L’itération entière doit être tournée vers la recherche de la qualité. Les tests doivent être planifiés, anticipés, toute l’équipe doit se mobiliser et la QA team impliquée au plus tôt dans une approche collaborative (QA n’est pas mon ennemi !!) …
Bon, un vrai travail d’optimisation des ressources est à mener mais je pense de plus en plus à intégrer les SCRUM dans ma gestion de projet (scrum signifie mêlée), ou plus exactement intègrer le “scrum daily meeting”, (une courte réunion quotidienne, sauf que pour moi ce serait plutôt tous les 2/3 jours, d’environ 15 minutes, rassemblant les membres de l’équipe, où chacun décrit entre autres ce qu’il a fait la veille et va faire aujourd’hui).
Ces points intermédiaires seraient par exemple l’occasion pour les développeurs et les QA de faire un point sur leurs tests respectifs, et de rester en alerte sur cette question.
Et vous, comment faites-vous ?
