Prenez une grande bouffée d’air agile les 25 et 26 mai 2009 à Vincennes dans un lieu d’exception (Bravo les organisateurs !).
Vous souhaitez découvrir l’agilité ou approfondir avec des spécialistes des sujets plus précis qui vous tiennent à coeur sur SCRUM, LEAN ou XP, venez nous rejoindre (à un tarif préférentiel jusqu’à la fin du mois).
Cette conférence: c’est 2 jours d’intenses échanges au cours desquels se succéderont présentations, ateliers de travail et discussions informelles autour d’un bon café; le tout au vert, à deux pas de PAris.
J’interviendrai pour ma part le 25 après midi pour vous parler de l’intégration de l’ergonomie (Utilisabilité) et de l’Experience Utilisateur dans les projets Agiles avec un gros Focus sur les PERSONAS et le prototypage rapide et collaboratif.
Bref, une modeste contribution au sein d’un programme qui personnellement me fait rêver…
Pour le reste si vous voulez discuter de SCRUM, d’Ergonomie, de Coaching, de pratiques collaboratives ou encore d’Agile CMMI (avec déjà de premiers retours d’expérience sur la question) : je serai là les deux jours !
Le programme:
D’ailleurs, et si on prenait le temps de faire un ROTI à chaque session ?
Mais toujours avec de la préparation (beaucoup de découpage) et plutôt en petits groupes, c’est en effet beaucoup plus riche et beaucoup plus sympa !
A l’heure ou d’autres cherchent encore et toujours l’outil magique qui révolutionnera l’ère du prototypage ou de la conception ergonomique de Wireframes, le prototypage papier met délibérément l’accent sur l’humain, la collaboration et la proximité … des valeurs trés agiles.
Car selon moi, la vraie force du format Wireframe (livrable essentiel de conception) réside avant tout dans sa capacité à :
se faire dans un mode collaboratif,
susciter le feedback,
communiquer la vision ergonomique
soutenir les activités à la fois des acteurs métier / MOA et des acteurs Développement & Test.
Le tout en restant dans le JUSTE CE QU’IL FAUT …
Et le prototypage papier va bien dans ce sens… Les possibilités de mise en oeuvre sont nombreuses et les bénéfices de ce format en workshop conception sont très réels. Voilà ce que j’ai pu observer dans quelques séances de groupes:
C’est ultra collaboratif, ça suscite les échanges et ça permet d’obtenir une vision commune, y compris avec des équipes pluri disciplinaires ou qui n’ont pas forcément les mêmes objectifs (des groupes hétérogènes c’est encore mieux !)
Cela réduit les problèmes de communication: on est en direct !
C’est plus ouvert et ça nous libère de pas mal de contraintes en donnant l’impression que rien n’est figé, qu’on peut modifier les choses aisément sans gros impact
C’est source de créativité (faites confiance à l’intelligence collective)
C’est interactif, c’est de la manipulation directe, c’est ludique et en rupture avec la passivité des réunions classiques
C’est adaptatif et évolutif avec multiples modes d’intervention et d’animation selon les contextes
Pour conclure, une petire illustration en images d’une séance Prototypage Papier:
Devant pourtant une forte affluence : 130 personnes au Novotel de La défense.
19:15 Bonne intro de Luc Legardeur pour restituer la genèse du SUG France:
” Le SUG a pour mission de promouvoir les pratiques agiles de SCRUM sur le territoire français en tant que composante fondamentale des méthodes agiles”.
Sur le papier, tout se présentait donc bien …
20h30 et deux présentations plus tard (Jeff Sutherland et Dietmar Strasser ), je trouvais déjà ça beaucoup moins rigolo, voire carrément ennuyeux. Pas de panique ça s’est arrangé par la suite… avec en prime un bon buffet.
EN BREF:
Même si SCRUM était la star de la soirée, Jeff Sutherland (co-inventeur de SCRUM) en était l’attraction. Ses pilules bleues et surtout rouges font toujours autant d’effet, à lui et à son auditoire. Pour le reste, je retiendrai aussi et surtout l’esprit d’ouverture dont il fait preuve.
Ouverture vers CMMI, symbolisée par un futur papier pour Agile 2009 (”Scrum and CMMI : going from good to great”), ouverture trés remarquée vers CMMI et PMI (Project Management Institute), et là c’est pas gagné, lors du dernier SCRUM GAthering d’Orlando avec la présence de Mark Paulk (CMMI) et Greg Balestrero (PMI). Alors, esprit Business ou sincères motivations ? sans doute un peu des deux, mais le message est fort et c’est bien. AgileCMMI on en reparlera…
Mon ROTI : 3 (” Présentation juste Moyenne. Je n’ai pas perdu mon temps, sans plus”" !), un 3 pour l’ouverture et pour avoir vu Jeff en vrai :)
Seconde présentation : Dietmar Strasser avec le cas d’école de la transition vers l’agilité de la R&D Borland. Trop d’évidences, et un discours trés monotone… alors d’abord on a mis un Product Owner, ensuite on a mis du QA dans l’équipe, puis la doc … ensuite on a splitté …
Je suis un peu sèvère mais ces questions QA et Tests, les activités du Product Owner m’intéressant énormément, j’ai regretté que tout cela ne soit que survolé.
Mon ROTI: 1 (”Inutile. Je n’ai rien gagné, rien appris”)
Claude Aubry, mon ami bloggeur, enchaîna aprés une courte pause en tentant de redynamiser les débats. Au programme: Scrum en France, et notamment sa folle croissance depuis les prémisses en 2005 jusqu’au succès en 2009. Puis les spécificités françaises au travers d’un sujet qui lui est cher : l’agilité en situation (ou contexte).
Mon ROTI : 3 (” Présentation juste Moyenne. Je n’ai pas perdu mon temps, sans plus”); j’en connaissais une grosse partie…
Dernière présentation: Guillaume Bodet, alias l’Heureuse Surprise. Une présentation pêchue, un discours très intéressant autour des Kits de vente (ou plutôt des kits pour convaincre) et quelques messages clés:
sortir d’une logique défensive (Kit Logique et Kit Preuves)
vendre avant tout du changement (on revient aux fondements de l’agilité)
vendre clairement la réalité
S’appuyer essentiellement sur deux kits : Analyse de Gain et Analyse de risques (préalable à tout démarche de coaching ceci dit…) toujours à adapter selon vos interlocuteurs cibles
Bref un discours qui m’a fait réfléchir, et m’a plu hormis sur la partie changement sur laquelle je l’ai trouvé moins convaincant.
Mon ROTI : 5 (” Excellente présentation. Ça valait bien plus que le temps que j’y ai passé”)
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 (initiés par Brian Marick, repris par Lisa Crispin & Janet Gregory dans l’excellent ouvrage Agile Testing) qui à eux seuls guideront l’ensemble de votre stratégie:
Tests orientés Technologie en soutien de l’équipe (ex : Tests unitaires et approche TDD , le plus automatisé possible)
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)
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 !)
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)
Vous devrez vous IMPLIQUER
Vous devrez privilégier la COLLABORATION Vous devrez comuniquer la Vision du produit à concevoir
Vous devrez fixer des priorités
Vous devrez expliquer ce que vous attendez
Vous devrez répondre aux questions
Vous devrez donner vos critères d’acceptation
Vous devrez passer du temps avec les équipes
Vous devrez changer votre façon de spécifier
Vous devrez changer votre façon de recetter
Vous devrez STATUER en fin d’itération sur ce qui est DONE et ce qui ne l’est pas !
Quand une équipe fait appel à moi pour une mission de coaching Agile ou que je m’engage dans un séminaire interactif consacré à l’agilité, mes interlocuteurs sont toujours surpris et curieux de me voir aborder ces questions là …
Vous êtes le premier à nous en parler…
Je n’avais pas vu le Sprint Zéro sous cet angle…
Ça me rassure, j’y vois plus clair…
Attendez mais c’est donc compatible avec notre process de déploiement…
Sans pour autant fixer des règles ultra figées qui n’auraient guère de sens dans un contexte Agile, j’ai pourtant des messages forts à délivrer et quelques repères à proposer :
Oui, dans un projet Agile, il y a un Sprint 0 au démarrage, un sprint vraiment différent des autres, même si sa durée selon les contextes est variable (de quelques jours à 3 semaines) en fonction de la maturité de l’Equipe sur certaines questions…
Oui dans un projet Agile, il y a souvent un “End Game”, un sprint un peu particulier en fin de version…
Et puisqu’un schéma vaut mieux qu’un long discours, voilà un exemple de cycle de vie (agile) :
SPRINT 0
Le Sprint Zéro n’est pas un vrai sprint (agile) au sens où il ne se termine pas forcément par la livraison d’un produit qui marche, et que sa durée est variable (de quelques jours à 3 ou 4 semaines). Ce sprint est pourtant essentiel pour mettre le projet sur de bons rails et permettre à l’équipe d’apprendre à travailler ensemble.
C’est un moment privilégié pour construire sa collaboration et prendre ses marques.
Quelles sont les activités typiques menées en Sprint 0 ?
Partager une VISION claire du produit
Analyser les risques
Déterminer un plan de release (version)
Produire un Backlog de produit estimé et priorisé
Préparer l’environnement de développement (y compris quelques docs)
Définir la posture ergonomique de l’interface et identifier les cibles (Personas)
“End Game” mais pas vraiment une fin dans le sens où dans les faits ce sprint apparaît davantage comme une transition. Ce sprint, c’est le moment où l’équipe met la touche finale à la version et travaille de concert avec ceux qui vont déployer et exploiter au quotidien la future application.
Attention : CE N’EST PAS UNE PHASE DE TEST, même si certains types de test y trouveront une place privilégiée (tests d’acceptation, performance globale, alpha ou beta testing).
La durée du End Game est aussi variable (selon les activités menées au préalable), il peut être très court même courir sur deux sprints…
Quelles sont les activités typiques pouvant être menées en End Game ?
Test final de la version dans un environnement similaire à la Prod
Tests d’acceptation et tests utilisateurs sur l’ensemble de la version (même si des tests ont été réalisés au fur et à mesure)
Tests d’install
Possibles tests d’intégration de parties tierces non disponibles jusqu’alors
