3 questions de Dragos Dreptate, Responsable R&D Logiciel

Dragos, Responsable R&D Logiciel, envisage le passage aux Méthodes Agiles et à se titre se renseigne et se documente sur la question. Je lui ai proposé de partager mon expérience en répondant à quelques-unes de ses interrogations car être Agile, c'est aussi savoir partager sa connaissance. Dragos a accepté la démarche alors que nous ne nous connaissions pas! C'est un signe de confiance "à priori" que je salut; c'est une valeur très importante.

Voici le contenu de nos premiers échanges:

[Dragos]

Ma première question va dans la direction du recrutement. Il est clair, la qualité des membres de l’équipe est primordiale, bonne communication, team player et excellence technique s’imposent. La question : Comment faire pour être sur que la personne qu’on recrute est « agile » ?

[Luc]

Chez nous, voici les étapes que nous mettons en oeuvre pour recruter:

- Rédaction d'une annonce qui souligne les points essentiels sur le contexte de notre entreprise et les valeurs que nous recherchons chez notre futur collaborateur.

- Nous organisons une session de tests avec une douzaine de candidats où nous décrivons plus précisément notre entreprise. Puis il y a deux heures de tests écris sur des points techniques, logiques, d'Anglais. Ces tests ne sont pas très difficiles et nous permettent de faire un premier filtre.

- Les 3-4 candidats que nous estimons les meilleurs sont reçus en entretien individuel pour apprendre à mieux les connaître et découvrir leurs motivations et aspirations.

- Puis nous avons expérimenté une mise en situation dans une équipe sur une "journée accélérée" afin de mieux évaluer les aptitudes des candidats à travailler en équipe. Ce fut assez intéressant pour tester la capacité d'adaptation des candidats!

Quelques pistes:

http://www.cio.com/article/print/478106

http://www.agilex.fr/2009/01/recrutement-agile/

[Dragos]

La deuxième question s’attaque aux problèmes de test. L’activité de test est intégrée au sprint. Les méthodes agiles essaient de diminuer le temps alloué a cette activité en accordant plus d’attention a la qualité du design et du codage, en gros a tout ce que tienne de l’ingénierie logiciel, pour produire un meilleur code avec moins défauts. C’est bien, mais parfois pas suffisant. Nos clients, des grands laboratoires pharmaceutiques, utilisent notre application scientifique en phase de recherche de nouveaux médicaments. Une étape très sensible et coûteuse. Nous sommes soumis à des réglementations strictes concernant la qualité logicielle et sommes certifiés ISO9001. Mais au delà des certifications, la qualité du livrable est un engagement très fort que nous avons envers nos clients. Actuellement la phase de test a lieu après la fin du développement et consiste dans de plans de test « statiques », quasiment manuels, de tests qui s’appuient sur de spécifications détaillés écrites après la fin du codage. Très peu de tests unitaires. Et enfin la question : Connaisez-vous des outils de test "agiles", permettant de créer des tests automatisés adaptés aux logiciels avec beaucoup d’IHM et beaucoup d’intervention de l’utilisateur dans les scenarios d’usage ?

[Luc]

Avant de répondre à la question j'aimerais revenir sur la notion de test dans un contexte Agile. Tout d'abord, pour fixer le périmètre de mes propos, je vais m'appuyer sur deux méthodes Agiles complémentaires : SCRUM pour la gestion du projet et XP (ExtrêmeProgramming) pour les pratiques de développement. Dans ces méthodes, tout est itératif et incrémental car on recherche le feedback en permanence. Plus tôt est le retour sur les problèmes tels que les défauts où incompréhensions des besoins utilisateurs, moins cher coûtera la correction ou l'adaptation. De ce fait, les tests sont quotidiennement nécessaires à mesure que le développement évolue. Ces méthodes ne diminuent pas le temps alloué aux tests mais au contraire l'augmente. Le principe, c'est de ne pas dire qu'une fonctionnalité est terminée tant qu'elle n'est pas testée et le but recherché est de terminer des fonctionnalités dans les sprints (2-3 semaines). En d'autres termes, on ne repousse pas la phase de tests à la traditionnel Release Candidate pour y trouver des défauts qui prendront plusieurs semaines à corriger. A chaque fin d'itération, on doit avoir un incrément de produit potentiellement livrable au client donc entièrement validé et de qualité irréprochable. Alors évidement, on ne plus se permettre de dérouler des plans de tests pendant des jours entiers alors il faut changer les pratiques de test.

Il y a plusieurs types de tests à considérer:

- Les tests unitaires sont écris pendant le développement et se situes au niveau des classes. Idéalement il faut pratiquer le TDD (Test Driven Development) où on écrit toujours un test unitaire avant d'ajouter du code pour une fonctionnalité. De cette façon, on ne développe que ce qui est nécessaire (pas de provision ni de code mort) et ceci permet de faire émerger un design qui soit testable avec peu de couplage, etc. Je vous propose de lire le Tutoriel de Bruno.

- Les tests d'intégration sont également écris par les développeurs pour s'assurer que les classes fonctionnent bien ensemble.

- Les tests fonctionnels testent les critères d'acceptation de la fonctionnalité. Il est largement préférable de les automatiser car plus les projets grossissent, plus dérouler l'ensemble des tests fonctionnels en fin d'itération devient long et pénible. Sur des petits projets, il peut être acceptable de garder ces tests manuels.

Au final, il n'est pas anormal de passer les 2/3 du temps de développement à écrire des tests. Pour que le feedback soit rapide, il faut respecter la pyramide pour la répartition des tests. Les tests unitaires doivent être nombreux et couvrir un maximum de cas possibles. Ils doivent également être très rapides pour pouvoir être exécutés par tous les développeurs, tout le temps, pour vérifier que rien n'a été cassé. Il est très important de comprendre qu'automatiser ces tests permettra d'avoir des tests joués tous les jours. En effet, toutes les nuits, un système d'intégration continue doit construire l'application de A à Z (compilation, setup, etc) et exécuter tous les tests (unitaires, intégrations, fonctionnels). Ainsi, chaque matin, les équipes ont une vue claire sur l'état du projet. Si un test n'est pas passé, la priorité sera de le réparer.

Quand on travail sur une base de code non couverte par des tests, il faut apprendre à ajouter de la fonctionnalité en ajoutant des tests. Cela peut-être difficile mais plein de techniques existes pour isoler et modulariser la base de code. A ce sujet, je vous recommande la bible en la matière : Working Effectively With Legacy Code

Concernant les tests d'IHM, la pratique nous a montré que les tests manipulant les IHM sont souvent fragiles. En découplant bien la présentation des données, il est plus efficace de tester la couche juste en dessous. Ceci dit, nous utilisons pour nos projets en C# le framework de tests NUnit avec NUnitForms. Pour les applications Web, il y a Selenium (que je ne connais pas). Je vous propose de lire le billet suivant : http://blog.octo.com/demarches-de-tests-fonctionnels/

Les tests d'IHM coûtent cher par rapport à des tests plus bas niveau donc nous nous en servons pour vérifier qu'il n'y a pas de bug mais nous comptons principalement sur des tests plus bas niveau pour couvrir l'application et traiter le maximum de cas.

Il faut aussi donner de l'importance aux tests exploratoires. Ils permettent de challenger le logiciel sur toutes les couches et ne sont pas automatisables. Ce sont des tests structurés mais pas prédéfinis.

[Dragos]

J’ai pu trouver pas mal d’informations sur les points forts et les bénéfices que les méthodes agiles apportent mais il me manque une meilleure vue sur les risques engendrés par l’adoption de ces méthodes et sur leurs points faibles en général. Pouvez-vous m’en dire plus à ce sujet ?

[Luc]

Voici quelques points à considérer lors d'un passage à Scrum/XP:

- Scrum, de part sa nature itérative et empirique, ne permet pas de s'engager sur les trois points suivant en même temps

-> Contenu du produit

-> Qualité du produit.

-> Délais

Le plus souvent, c'est le contenu qui est adaptable car chacun sait qu'une grosse partie des fonctionnalités d'un logiciel ne sont jamais ou très peu utilisé. Donc c'est le jeu, le Product Owner doit faire des choix de priorité en permanence.

- Les chefs de projets et les représentants de la QA doivent changer de rôle pour laisser les équipes s'auto-organiser. Ils peuvent devenir ScumMaster (facilitateur), Product Owner si ils connaissent bien le métier, expert-technique ou ne pas trouver leur nouvelle place.

- Les Testeurs ne peuvent plus travailler comme avant. Je vous recommande le livre "Agile Testing: A Practical Guide for Testers and Agile Teams". Ceci dit, personne en ma connaissance ne regrette l'époque cycle en V avec des campagnes de tests de plusieurs semaines.

- Les équipes, avant de devenir productives, vont traverser plusieurs étapes donc il ne faut pas changer ces équipes trop souvent car le processus peut prendre plusieurs années.

-> Forming (création de l'équipe)

-> Storming (turbulence)

-> Norming (harmonisation)

-> Performing (performance)

- Il n'est pas toujours évident d'insérer les contraintes non fonctionnelles telles que l'Architecture et les Performances aux Product BackLog. Les ProductOwners ne sont pas toujours les personnes adaptées pour fournir des critères sur ces points. Le danger, c'est de considérer certains points trop tardivement.

Chers lecteurs, si vous avez des compléments d'information à partager, n'hésitez pas! Si un échange sur un point particulier vous intéresse, contactez-moi!