Posté par jc-QualityStreet le 29 novembre 2007
Quelques « tips » proposés par Declan Whelan, sous la forme d’une présentation et de 7 min de video.
Au programme, diffusion de l’expérience utilisateur dans l’équipe, défense des utilisateurs (notamment grâce aux personas, mis en avant dans l’information radiator par exemple), guidelines ergonomiques, utilisation d’outils légers (cartes, tableau blanc ….), juste ce qu’il faut de modélisation (pour démarrer) …
Bref, tout cela est en phase avec mon Manifeste pour une ergonomie Agile, manifeste qui décrit comment l’Ergonome (spécialiste User Expérience, Interaction Design et Usability) peut intervenir et collaborer efficacement dans des projets s’inspirant des méthodes Agile (XP, SCRUM, UP…), et qui propose aussi quelques éléments quant aux spécificités du profil de cet Ergonome “Agile”.
Posté par jc-QualityStreet le 26 novembre 2007
Définitivement OUI !
Je vous parlais dans un précédent billet de la mise en place d’une War Room, environnement de travail collaboratif dédié à l’équipe projet ; et bien l’un de ses principaux composants est l’Information radiator (« Radiateur d’informations » en français). Et même si Laurent Bossavit en parle régulièrement (Agile 2006 notamment), je trouve qu’on a tendance à sous estimer son importance.
L’Information Radiator rassemble en un seul lieu, accessible et visible de tous, les informations clés du projet et présente en temps réel ses principaux indicateurs d’avancement (Risques, Performance de l’équipe, Qualité …)
Selon moi, l’Information Radiator est à la fois le symbole de cet Esprit Agile que j’évoque régulièrement et sa représentation la plus concrète.
Il donne de la visibilité à tous les acteurs en mettant le focus sur l’essentiel (on sait exactement où on en est et ce qu’on fait). Il suscite l’intérêt et les échanges.
Il est COLLABORATIF, INTERACTIF ; ENGAGEANT et EN MOUVEMENT (jetez plutôt un œil à ce qui se passe autour du Taskboard), et suscitera la REACTION de votre hiérarchie.
Son contenu reste évidemment contextuel, mais je vois quelques incontournables :
- un Taskboard (représentation par stories des tâches A faire, En cours, A vérifier et Terminées, pour une itération) facilement manipulable
- un Burndown chart (vue graphique du reste à faire sur une itération)
- une liste des obstacles
- des métriques qualité, de risques
- le calendrier des livraisons, une vue sur les jalons
J’y ajouterais pour ma part les posters de mes Personas (c’est promis la prochaine fois je m’y colle) : voilà pour qui on développe (même si le Client ou des utilisateurs peuvent se déplacer chez nous), quel est leur but et comment notre outil sera utilisé : ce fil rouge est précieux.
Alors messieurs, dégagez vos murs car les équipes Agiles débarquent pour les envahir !
Posté par jc-QualityStreet le 20 novembre 2007
Le coaching agile est une activité qui a le vent en poupe, mais quand on parle d’agilité, de quoi parle-t-on exactement?
Méthodes Agiles: une belle définition
Celle de Veronique Messager Rota, dans Gestion de projet : Vers les méthodes agiles 
:
“Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients”
Voilà qui est clair, précis et tout à fait fidèle aux 4 valeurs et 12 principes de l’Agile Manifesto, ce signal fort lancé en 2001 par 17 personnalités de l’industrie logicielle (Beck, Cockburn, Fowler, Jeffries, Marick, Schwaber, Sutherland …) en réponse à un malaise et aux insuffisances et difficultés liées aux méthodes de développement traditionnelles :
Agilité: une définition
Aujourd’hui le développement Agile transforme le business ; la France semble enfin s’en apercevoir, et l‘agilité :
“ capacité d’une organisation à créer de la valeur et à ravir son client, tout en favorisant et en s’adaptant -à temps- aux changements de son environnement (Grosjean, 2011)
pénètre toutes les couches de l’Entreprise:
Scrum est devenu incontestablement la méthode la plus populaire. C’est aussi la méthode Agile que je porte dans mes missions de Coaching Agile tant ce framework est pertinent pour initier le process agile de l’organisation, symbole d’une agilité qui ne peut fonctionner qu’en contexte. L’agilité modifie donc notre façon de concevoir des produits, et d’envisager un Projet Informatique (notamment en termes d’estimation, de planification et de suivi)… un choc culturel pour beaucoup de personnes, d’équipes ou d’organisations. Mais les Méthodes Agiles vont impacter également la notion de contrat et bouleversent surtout la façon d’exercer nos propres métiers…
Le jeu en vaut-il la chandelle ? Je réponds OUI, sans hésitation; les bénéfices sont en effet bien réels (comme le montre cette dernière étude ou ma propre capitalisation):
- Visibilité
- Vélocité
- Adaptabilité et réactivité (dimensions clés du Time to market)
- Réduction des risques
- Qualité
- Efficacité
Beaucoup chercheront à comparer les différentes méthodes Agiles (XP, SCRUM, DSDM, ASD, AUP …), c’est intéressant, certes… Mais, plus que de méthodes, je parlerais davantage de techniques, de pratiques à piocher ici ou là, dans XP, dans SCRUM, dans Lean, à essayer, à adapter, à intégrer sur un socle stabilisé mais souple propre à chaque organisation, en respectant quelques principes fondamentaux (discipline nécessaire):
- Itératif (courtes)
- Incrémental (avec en plus des livraisons de fonctionnalités opértationnelles à chaque itération)
- Collaboratif
- Timeboxing
- Focus sur les Tests, à chaque itération
- Feedback Client et Utilisateurs
Toutes ces pratiques intégrables et ajustables ainsi que la remise au premier plan du FACTEUR HUMAIN sont la vraie RICHESSE des Méthodes Agiles.
Des Méthodes qui véhiculent malheureusement encore pas mal d’idées reçues : du point de vue de la documentation, de la planification, de l’offshore, du CMMI ou même de l’Ergonomie et de l’Expérience Utilisateur …
Posté par jc-QualityStreet le 17 novembre 2007
Photography:Laurence Cohen
Mais comme David Anderson dans son dernier billet, je me demande dans quelle mesure c’est efficace…
de mon côté, un scrum c’est plutôt entre 7 et 10 personnes !
Pour en savoir plus sur le déroulement et les objectifs d’un scrum (« mêlée »), réunion d’équipe projet de maximum 15 min, je vous renvoie à mes deux billets: En quoi puis-je t’aider ? ou De l’art d’être un facilitateur…
Posté par jc-QualityStreet le 14 novembre 2007
Sortons quelques instants de l’Agilité dans les projets informatiques, pour parler de l’agilité motrice, gestuelle 
Fred Cavazza pointait du doigt lors du dernier Usability Day l’insuffisance des périphériques actuels proposés sur la marché (claviers, souris, manette de jeu) pour naviguer et agir avec efficacité et efficience dans les univers 3D.
L’Expansion vient de publier une interview plutôt alléchante de Taizo Yasutake, l’inventeur de la technologie 3D de Sandio.
Sandio propose, si cela vous intéresse, une démo en français de son nouveau périphérique sur son site.
Fred, c’est toi l’expert, qu’en penses-tu ? Quelqu’un a-t-il déjà testé ce produit ?
Posté par jc-QualityStreet le
Le Timeboxing au final c’est super mais ce n’est pas si facile
… tel est en substance ce qui ressort des équipes qui appliquent ce principe fondamental de l’Agilité.
Le Timeboxing consiste à découper un projet en tranches de temps de durée fixe ; celles-ci constitueront les itérations (ou sprints), sorte de mini-projets « à taille humaine » au cours desquels les activités d’ingénierie (exigences, ergonomie, conception, développement, test…) vont se dérouler (on parle alors de développement itératif…).
Le principe est simple : la DATE FIXEE NE BOUGE PAS, le contenu de l’itération est la variable ajustable (on peut par exemple retirer les fonctionnalités à réaliser dans l’itération n et les passer en n+1). Du fait de sa simplicité, le Timeboxing est souvent présenté rapidement sans que soit réellement mesuré son impact, énorme, sur le Projet, l’Equipe et le Client. Contraignant au départ, il suppose en effet :
- d’envisager les projets vraiment différemment car la tendance est aisée de faire ou laisser glisser …
- d’avoir une discipline et de responsabiliser les équipes, vers un seul but … la livraison de fin d’itération (sans cela c’est mort !)
- d’effectuer un vrai travail d’estimation et de planification, au préalable pour le projet ou la release, et régulièrement à chaque itération pour envisager le contenu de l’itération suivante (feedback, adaptation, estimation)
- d’être à la fois souple et rigoureux sur la politique de tests pour une itération
Mais les bénéfices sont bel et bien réels … le Timeboxing est un élément très apprécié par les équipes de dév. (Processus Unifié : capitalisation) :
- Il oblige à hiérarchiser les objectifs
- Il donne une cadence à l’équipe mais aussi des repères, des deadlines claires : c’est stimulant
- Il procure un sentiment d’avancement et de satisfaction puisque chaque fin d’itération est marquée par une livraison
- Il rassure tout le monde, Clients et Instances dirigeantes, en donnant de la visibilité. Fini l’effet Tunnel : on sait exactement où on en est !
- Il vous donne une bonne monnaie d’échanges ; vous ne fournissez pas de planning ultra détaillé au début, OK, en contrepartie vous vous engagés pour un périmètre et sur des jalons précis
- Il est trés précieux dans un contexte Offshore
- Pour moi Ergonome, c’est l’occasion d’envisager des Tests Utilisateurs de manière précoce et régulière
Et les dérapages ? s’il y a dérapages, ils doivent être minimes… S’ils se répètent ou si vous ne parvenez pas à livrer régulièrement : révisez vos estimations, réfléchissez à la vélocité de votre équipe, bref recherchez les causes (même si les rétrospectives de fin d’itération, ce n’est pas uniquement en cas de dérapage) et agissez, quitte à tout arrêter pour repartir sur des bases enrichies et plus fiables. Les jalons du Processus Unifié peuvent aussi servir à ça !
