Avec la disparition du ScrumDay, Agile France est le gros évènement agile parisien du premier semestre : plus de 280 participants (d'après les organisateurs), et près de la moitié de primo-participants (ma perception).
Agile France 2016 s'est tenu les 16 et 17 juin au Chalet de la Porte Jaune à Vincennes. Le programme de l'année était riche avec pas moins de six tracks en parallèle, sans keynote, couvrant tout le spectre des pratiques agiles, du design au développement, en passant par le test et le déploiement. Le panel des speakers est similaire, avec des nouveaux, des très expérimentés et des extra-terrestres. Morceaux choisis d'agilité sur les deux jours autour du test, du dév, de la programmation fonctionnelle, etc.
Utilisateur, fais-moi mal
Emilie-Anne Guerch et Nicolas Moreau proposent un retour d'expérience sur la refonte d'un site institutionnel d'assurance, en se concentrant sur la partie test utilisateurs. L'équipe est importante avec 1 Po, 1 coach, 4 dev, 3 designers, venant de plusieurs pays distincts. Il est toujours possible de faire simple, et il semble que dans les grandes entreprises françaises, ce concept soit peu appliqué.
Les deux speakers reviennent sur les basiques : aujourd'hui, les licornes (Kickstarter, Spotify, AirBnB) sont des entreprises fondées par des designers, avec un fort pool de R&D orienté design. A l'inverse, en traçant un trend google, il semble y avoir peu de corrélation entre les recherches sur l'UX et le user testing. En partant d'un reality-check, ils posent et reprennent une étude expliquant que :
Les vrais gens 1) sont malins, 2) n'ont pas le temps, 3) sont influencés par l'extérieur, 4) sont agnostiques, 5) sont bienveillants.
A partir de cette vision, Nicolas découpe les tests utilisateurs en deux catégories :
- Les tests utilisateurs qui correspondent à des conditions réelles ou simulées, avec un dispositif. Ceci implique un coût, une forte préparation, un brief, un facilitateur (hors équipe projet), etc.
- Les usability test qui sont plus rapides, simples, se font avec n'importe qui et n'importe où. Ils narrent d'ailleurs descendre régulièrement à la cantine ou dans les halls d'attente pour mettre fin aux discussions entre développeurs et designeurs sur de l'iconographie.
Un bon takeaway si vous travaillez sur ce genre de projet : allez là où la nourriture est ! Testez en condition le plus proche du réel. Vous avez bien lu. La cantine est sans doute le meilleur endroit pour rencontrer de vrais utilisateurs.
L'important dans un processus itératif est de tester tout le temps (démarche assez proche du Lean Startup), en :
- Parlant avec des utilisateurs pour remonter leurs difficultés
- Evitant les features de trop
- Augmentant le niveau de sécurité des solutions pour éviter le braconnage et détournement (qui n'a pas hacké des urls ou fait des renvois de sessions pour éviter de venir au bureau le week-end ?)
- Hackant l'organisation pour tester vos produits (trouver les dates de conventions, les réunions clés, les salons)
Les speakers finissent avec leurs conseils et leurs "à éviter".
Conseils :
- Choisir l'endroit qui correspond à votre test
- Poser des questions ouvertes
- Rajouter toujours une question "pouvez-vous me montrer ? pourquoi ? où ?"
- Attention au non verbal
- Laissez votre ego à la porte
A éviter :
- N'invitez pas le boss du testeur (effet HiPPO garanti)
- Le PO n'est pas le facilitateur
- Ne prenez pas toujours des experts : la perle rare existe en interne
- Le test, c'est pas trop cher
- V et tests ne sont pas incompatibles
- Recoupez les retours !
La foire aux micro-services
Yannick François et Emmanuel Gaillot ont proposé une expérience sociale de développement improbable autour de la résolution du kata puissance 4 (que je n'ai pas vu dans le catalogue des kata) en mode micro-service auto-organisé. L'idée semble provenir d'une session vue et utilisée par des connaissances nordiques.
Pour décrire cette expérience, imaginez une bande d'une trentaine de personnes ne se connaissant pas (trop). Les deux commencent donc par un peu d'ice breaking autour d'une répartition des présents sur la sensibilité agile, le TDD, les différents langages. Ceci permet de former des groupes/pairs et de se lancer. Objectif : faire marcher un puissance 4 avec uniquement des micro-services, trois tableaux et un réseau wifi personnel, en moins d'une heure. Pour les autres, un rôle d'observateur est aménagé.
De manière étonnante, la partie la plus compliquée est le lancement d'un "hello world" : quelques informaticiens et peu ayant des stacks de développement complètes (c'est Agile France, pas les XP days), et il me faut presque trente minutes pour avoir une salutation de flask. En levant les yeux, j'aperçois un annuaire de micro-service (sans IP), des fonctionnalités sur un tableau, avec des noms en face, mais aucune idée d'où se trouvent ces personnes. C'est donc l'heure de faire l'abeille, et de voler à la chasse à l'information.
Le temps de retourner à notre place et de commencer à coder, la liste des fonctionnalités n'est plus à jour, 4 ou 5 personnes sont parties ou ont décidé d'organiser le travail. Et comme tout le monde s'en moque, et bien ça continue comme avant. L'heure est vite passée, le niveau d'énergie est vraiment bon, et c'est avec un petit pincement au coeur que nous levons les mains, avec un Puissance 4 qui ne marche pas :(
Un bon debrief permet aux observateurs d'exposer un certain niveau d'incompréhension sur le fonctionnement, et un étonnement sur le manque de communication intra-groupe. Ma conclusion est plutôt simple : l'auto-organisation ne se fait pas en 1 heure avec des groupes qui ne se connaissent pas et qui n'ont pas l'habitude de travailler ensemble.
Mob, Mob, Mob Programming
Le second jour commence fort avec un atelier très, très bizarre. Présenté par Jonathan Perret et Raphael Pierquin, le principe n'a rien à voir avec le mob programming tel que nous avons pu en parler (ou alors c'est très capilotracté). C'est plutôt un concept autour de la programmation de Mob pour Minecraft (les mobs spawners) autour d'une API JavaScript écrite par les présentateurs.
En un peu plus d'une heure et demi de démonstration en environnement Minecraft réel, les deux compères reviennent sur la genèse du projet. Quand vous voulez apprendre la programmation à des enfants entre six et huit ans, Scratch c'est plutôt bien. Après, "Scratch c'est pour les bébés", alors que "Minecraft c'est bien". Pour rester dans une logique d'offre et de demande (et d'appétence du client), il reste donc à écrire des éléments pour programmer Minecraft.
Voilà, c'est aussi simple que cela.
La démonstration présentait l'API sur des cas réels, et l'apparition de blocks et autres personnages. Elle a vite tourné en une "expérience scientifique" pour vérifier qui du bébé zombie ou de sa version adulte infligeaient le plus de dégats à des paysans (parce qu'un bébé zombie ça va plus vite !). Vous me répondrez "mais c'est bien sûr", et vous avez raison. Néanmoins, ce n'est pas tant la question qui ici est pertinente que l'option qu'ouvre Minecraft et sa programmation à une population d'enfants pour leur faire passer le goût du code (et même un morceau de l'esprit scientifique).
Un concept à partager avec vos enfants si vous trouvez qu'ils jouent trop et oublient leurs devoirs.
Faciliter la collaboration sur les tests
La session suivante retombe dans le pragmatisme du test et la manière de les opérer en "mode guerilla". Un peu comme pour la première session, le terme est un peu "buzzword", avec des concepts encore une fois proches du Lean Startup en pratique sur l'incubateur des startups gouvernementales (en lien avec l'interview de Pierre Pezziardi pour le Lean-IT Summit de l'année dernière).
Les deux présentateurs reviennent sur le principe de startup d'Etat, qui reste un format de startup avec pratiques agiles et du Lean Startup sur le développement d'un produit. Dans ce contexte, les tests utilisateurs impliquent la compréhension du domaine de l'utilisateur final. C'est donc le premier conseil proposé : "aller voir les utilisateurs finaux pour accroitre l'empathie de l'équipe".
Ce qu'ils définissent comme mode guerilla est un mix d'agile et de lean. Les projets étant à enveloppe fixe et périmètre fixe, le principe d'un test utilisateur "standard", planifié un an à l'avance avec un calendrier prévisionnel a peu de sens et engendre des surcoûts non raisonnables.
L'équipe part donc trois jours sur site pour interviewer et tester le produit directement avec les potentiels utilisateurs finaux, remonter les frictions et difficultés qu'ils éprouvent, etc. Après la collecte, il reste à formaliser les éléments à développer. Les présentateurs décrivent deux formats :
La personne | quand elle essaie | rencontre le problème | c'est pour cela qu'elle a absolument besoin de ... | elle a fini par | elle raconte aussi que
La personne | a essayé de | n'a pas pu | avait besoin de | alors que aujourd'hui | et aussi
Avec une base de travail construite avec la pratique du dessus, l'équipe parvient à mapper les besoins et solutions, puis à "clusterer" les difficultés et résolutions posibles. Ceci permet de construire des scénarios et des propositions de valeurs, qui servent au développement du produit.
Kata-Elm : le jeu de la vie
Laurent Bossavit propose pour la fin de la journée un kata "le jeu de la vie" en Elm. Le concept du kata est sans doute l'un des plus compliqués et abscons, mais permet bien de mettre en avant l'intérêt d'un langage purement fonctionnel comme Elm.
En partant sur une base de TDD, Laurent construit les étapes du jeu de la vie les unes après les autres. Là encore, les questions techniques finissent par être celles consommant le plus de temps (notamment la stabilité du wifi).
Si la maîtrise est certaine, l'intérêt d'un tel Kata est surtout de présenter le langage et les concepts de base. Si l'architecture du langage repose sur une base de MVC, les modèles et vues paraissent plus proches d'un no MVC avec un modèle de souscription à des événements et une programmation réactive.
Conclusion
Agile France est la bonne occasion pour la communauté agile de se croiser, de faire des connaissances, d'apprendre et de partager. Les niveaux restent très hétérogènes, avec des questions et des sessions pour que tout agiliste y trouve son compte.