Posté par jc-QualityStreet le 28 août 2007
Agilité rime souvent avec Absence de documentation : voilà une idée reçue bien nuisible qui doit être combattue avec force … car mener un projet en utilisant les méthodes Agile (Agile UP, xxUP, XP, SCRUM…), n’a jamais signifié « ne produire aucune documentation ».
A l’origine de cette confusion ? Peut être une mauvaise interprétation de l’Agile Manifesto et de l’une de ses 4 valeurs « un logiciel fonctionnel plutôt qu’une documentation complète », ou plus simplement la facilité, un manque de volonté voire de compétences de certaines équipes de développement souvent soumises à un timing toujours plus serré …
Soyons clairs, privilégier l’application (ou un prototype) qui marche, plutôt que la documentation, à la fois pour mesurer l’avancement d’un projet et valider ce qu’on fait est un principe agile de base, indispensable et dont je suis entièrement convaincu (la documentation ne doit jamais servir d’indicateur de productivité). Mais aujourd’hui, peu de projets peuvent se passer d’une documentation (au sens large) précise et adaptée.
Ma position tient donc en quelques mots … « JUSTE CE QU’IL FAUT », en réfléchissant attentivement :
- A la Valeur du doc (ou de l’artefact) par rapport à l’Effort pour le produire et surtout le maintenir, sans perdre de vue que notre but, notre métier, c’est faire du soft, c’est concevoir des applications informatiques, ce n’est pas produire du papier !
- En termes de réponse à un besoin, de bénéfice pour le projet, de feedback …
- Et toujours en fonction de destinataires potentiels
Car être agile c’est avant tout penser communication, feedback, réactivité et adaptation plutôt que lourdeur, lenteur et bureaucratie, et croyez-moi une telle approche nécessite même une grande discipline ! Etre agile, c’est donc documenter de façon intelligente, appropriée et précise son projet en s’appuyant sur ce dont on a réellement besoin et ce qui est attendu pour éviter un gaspillage de temps et d’argent.
L’expérience me montre que l’utilisation d’un certain nombre de documents est quasi obligatoire sur la plupart des projets (la Vision par exemple, et d’autres pour la gestion de projet, les spécifications, …), et que certains contextes nécessitent plus naturellement (sans imposer) un certain formalisme (je pense à l’Offshore ou encore au CMMI, Capability Maturity Model Integration …). D’ailleurs, à l’autre extrême (autre idée reçue), se référer aux bonnes pratiques du modèle CMMI ne signifie pas pour autant, excès de bureaucratie et documentation à outrance.
Tout est donc affaire de mesure … SCRUM (la méthode Agile la plus populaire du moment) ou encore la conduite efficace de projets agiles vont dans ce sens.
Le Processus Unifié (dans une version customisée et adaptée à l’entreprise) peut assurer un très bon compromis, en permettant de constituer rapidement un excellent référentiel de doc. et bonnes pratiques que le chef de projet devra de nouveau ajuster à chaque projet (par l’intermédiaire du Plan de projet, élément incontournable d’UP qu’on retrouve aussi dans les pratiques du processus PP (« Planification du Projet »), l’un des 7 processus de niveau 2 du CMMI 1.2).
Pour le reste, les qualités de l’auteur de la documentation feront la différence pour la rendre correcte, précise et pertinente mais aussi lisible, légère et acceptable : en effet rédiger des cas d’utilisation ou même des user stories ne s’improvise pas, tout comme décrire des « personas », faire des diagrammes UML, des grilles fonctionnelles, rédiger un guide utilisateur, définir un plan de projet ou encore maintenir un plan d’itération …
Posté par jc-QualityStreet le 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…)
Posté par jc-QualityStreet le 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é.
Posté par jc-QualityStreet le 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 ?
Posté par jc-QualityStreet le 12 janvier 2007
Dans l’autre sens cette fois.
La recherche de la qualité du logiciel et de la qualité des processus est mon leitmotiv depuis quelques années et sera à l’honneur sur QualityStreet. Si vous êtes devant ce blog c’est que vous percevez déjà la nécessité de tester ce que vous produisez et que le chiffre de 30% de test dans la charge globale d’un projet ne vous fera pas bondir !!
Ce que j’apprécie beaucoup dans le Processus Unifié c’est qu’il met le focus sur cette discipline et permet d’introduire facilement les concepts de validation, de vérification. Il me permet même de faire le lien avec mon activité initiale d’ergonome, que ce soit au niveau de:
- la vérification (le produit est-il bien fait ?) : cela peut être par rapport à une charte d’ergonomie, de standards…
- ou de la validation (est ce le bon produit ?) par des utilisateurs (tests utilisateurs pour les ergos.; tests d’acceptation pour les ingenieurs qualité).
Vous me voyez venir…
oui, le test peut être un point d’entrée idéal vers une démarche ergonomique. Si en plus mon équipe développe en mode UP, dans une démarche itérative, et bien je peux même faire mes tests plus tôt et avoir accés à mes utilisateurs. Voilà la boucle est bouclée, avec un peu d’efforts je m’approche sans en avoir l’air de l’ISO 13407 (conception centrée utilisateur).
OK, ça fait beaucoup de raccourcis…mais je vous promets de déveloper tout cela par la suite.
