Posté par jc-Qualitystreet le 28 septembre 2009
Agilité et standards : certains n’y croient toujours pas … et pourtant…
Travailler dans une équipe Agile, c’est accepter de travailler avec les standards. Des standards non pas pour contraindre, mais pour challenger, changer et s ’améliorer. Des standards non pas centralisés, mais construits, partagés, intégrés par les équipes.
Les enjeux sont énormes car la standardisation est un vrai facilitateur de travail source de productivité, de qualité, de confort et de satisfaction. Les standards réduisent la complexité. Ils sont aussi et surtout la première brique de toute démarche d’amélioration continue … De l’humain, pas du documentaire !
Bon je le répète une dernière fois : « TRAVAILLER AVEC » et ne pas subir !
Le poids de la culture d’entreprise est important sur cette question, et selon les organisations c’est toute la philosophie autour de ceux -ci qui est à revoir, tant au niveau de la définition des standards que de leur exploitation.
Le taylorisme a laissé des traces… la conception des standards est bien souvent laissé à des experts loin, bien loin des préoccupations et des réalités du terrain des projets. De l’autre côté, on peste, on râle, on se soumet, parfois on ne cherche même pas à challenger, et on bride tout son potentiel créatif …
Ce qui plait dans les projets agiles, c’est que l’équipe se met autour de la table est discute ensemble avec ou sans le soutien du coach, de ces bonnes pratiques, de ces standards…
Le sprint 0 est bien souvent le moment idéal pour les initier ! Chaque fin de sprint est quant à elle, le moment idéal pour les challenger et les améliorer !
J’ai tendance à dire que le premier de ces standards est le process de développement lui même.
Scrum par exemple est un excellent cadre de travail pour les projets IT. Le process Scrum, c’est cette difficile balance entre les règles que l’on peut doit respecter et l’adaptation au contexte. Beaucoup d’éléments relèvent du Shu (« Suivre les règles ») ; j’aide donc l’équipe à s’approprier ces règles de base. Dans cette posture, et en toute transparence, je facilite l’adaptation au contexte avec le ScrumMaster, l’équipe, le Product Owner, et différentes parties-prenantes.
Toutefois, le message est clair :
- Ne considérer jamais ces standards comme acquis
- Envisager ces standards comme soutien de votre activité
- Faites évoluer ces standards dés que vous en éprouvez le besoin avec comme objectif de les améliorer, pour vous améliorer
Une règle d’or :
INFOMER, IMPLIQUER puis FORMER sans contraindre, quel que soit le standard !
Ensemble, on doit construire notre process Scrum standard, notre façon de bosser ensemble. Ensemble, on doit définir ce que revêt le FINI (c’est le fameux : « definition of done » !), la clés de voute du sprint et de la collaboration Product Owner / Développeurs / Testeurs. Ensemble avec le concours d’un ergonome ou spécialiste de l’expérience utilisateur, on définit progressivement les standards d’interface ou on s’appuie sur les standards d’accessibilité…
Pour certains (praticiens eXtreme Progeramming), la question des standards fait partie des habitudes. Une pratique forte existe, celle des normes de codage. Il s’agit de standards de développement que l’équipe doit fixer pour le projet,. C’est aussi un préalable à d’autre pratiques XP : la propriété collective du code et le pair programming. Le travail en équipe n’est en effet possible qu’à condition d’utiliser des règles communes de conception technique et de développement.
Sur quoi s’appuyer pour construire ses standards ?
En premier lieu sur l’équipe et sa connaissance du contexte de travail, mais aussi sur toute communauté qui se met en place pour travailler telle ou telle question. Check-lists, revues de code sont précieux. On peut s’appuyer également aussi sur un coach maitrisant l’agilité et capable de bien analyser la situation de travail, le projet et le contexte organisationnel.
La rétrospective de fin de sprint est décisive. C’est un moment fort, très concret. La pensée Lean est enfin une vraie source d’inspiration. Son influence est sur ce sujet très forte :
- Les standards appartiennent à l’Histoire du TPS (Toyoya Production Ssytem) depuis 50 ans; Taiichi Ohno son inventeur, y était très attaché
- «Standardiser les tâches et processus»est l’un des 14 principes du Lean Management (base de l’amélioration continue et de la respnsabilisation des employés …
- Des outils du TPS très connus, comme les 5S poussent dans ce sens. L’un des 5 S est «Seiketsu qui signifie Standardiser.
Bref, ne craignez pas les Standards, servez-vous en et faites les évoluer !
Posté par jc-QualityStreet le 29 août 2008
C’est la première valeur de l’Agile Manifesto, c’est aussi, en substance, le message que souhaite faire passer aux chefs de projet, Bertrand Duperrin dans un récent billet.
Un premier pas, certes … mais les chefs de projet ne font qu’appliquer des process qui ont généralement été pensé par d’autres et utilisent bien souvent des outils qu’on leur impose ! …
WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 28 août 2008
Oh que oui !
et pourtant les rétrospectives sont parfois négligées voire absentes… or s’il y a bien une réunion indispensable, notamment dans les contextes Agiles (SCRUM, XP) et dans les autres, c’est bien celle là. Voyons en quoi cela consiste ..
WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 6 mars 2008
J’introduisais dans mon précédent billet la nécessité pour une organisation de travailler sur ses processus de développement, ses processus organisationnels, pour une intégration et une diffusion naturelle de la Conception centrée Utilisateurs et de l’Ergonomie.
Bref, je posais la nécessité d’améliorer ses processus pour plus de bénéfices et pour répondre aux exigences d’un environnement toujours plus compétitif.
Amélioration des processus ?
Attendez, mais,
“nous sommes Agiles…” diront certains,
“nous sommes CMMI niveau 3…” ajouteront d’autres,
Très bien, vous avancez … mais vous vous rendez bien compte que ce n’est pas suffisant, qu’il y a des trous, des zones de flou, des gaspillages … que l’utilisabilité de vos produits n’est pas toujours à la hauteur… quant à vos Utilisateurs…
Ce que je vous propose c’est de DEVENIR réellement USER FOCUSED, de mettre en pratique les techniques et méthodes de Conception Centrée Utilisateurs, dans un esprit Kaizen, tout en vous appuyant sur vos pépites, ces bonnes pratiques de développement que vous avez su mettre en place avec votre expérience, en vous servant de l’Agilité (c’est un excellent point de départ) ou sur la base du référentiel CMMI.
Et concrètement ?
J’apprécie beaucoup, pour sa simplicité, son accessibilité et son réalisme, l’échelle de maturité en Ergonomie (littéralement utilisabilité) de Jakob Nielsen (2006) (je la présente en détail à la fin de ce billet).
En 30 secondes, ce petit indicateur permet à votre Organisation de se situer sur une échelle de 1 à 8 niveaux, et me permet de vous montrer rapidement et facilement vers quoi nous allons tendre.
Bref, c’est un bon point de repère même si derrière TOUT RESTE A FAIRE !
En fonction de votre existant, de vos objectifs, notre stratégie d’amélioration continue pourra donc nous conduire dans un premier temps vers:
- le niveau 4 (”Budget Ergonomie dédié“),
- le niveau 5 (”Ergonomie disciplinée“),
- le niveau 6 (” Démarche ergonomique systématique“),
- le niveau 7 (”Conception Centrée Utilisateurs“)
- OU le niveau 8 (”Organisation Centrée Utilisateurs, total user focused“)
de cette échelle, avant de capitaliser et d’aller plus loin par la suite…
Voici pour conclure les 8 niveaux de maturité d’une organisation en matière d’ergonomie.
ET VOUS, OU VOUS SITUEZ-VOUS ?
Niveau 1: Hostilité à l’égard de l’ergonomie
En résumé, “A good user is a dead user”, l’ergonomie, on ne connaît pas et on ne veut pas connaître. Heureusement c’est de plus en plus rare.
Niveau 2: Ergonomie Centrée Développeur
Les décisions se fondent avant tout sur l’intuition. On échange, on réfléchit mais cela reste très technique. C’est fait par des développeurs pour des développeurs …
Niveau 3: Parcelles d’ergonomie
Pas de reconnaissance de l’ergonomie, pas de budget dédié mais quelques actions menées ici ou là. Il peut arriver que l’organisation fasse appel à un ergonome extérieur.
Niveau 4 : Budget Ergonomie dédié
Un budget est alloué (mais peut facilement se réduire du jour au lendemain); ce budget peut par exemple couvrir tout ou partie de l’activité d’un collaborateur. L’ergonomie reste encore perçue comme une sorte de potion magique qui rendra l’interface plus sexy; elle intervient encore tardivement. D’ailleurs, on ne sait pas trop ce que fait un Ergonome !
Niveau 5 : Ergonomie disciplinée
Un groupe, un pôle ergonomie est officiellement crée. Son leader fixera les orientations au sein de l’organisation et sur les projets. Une base de connaissances ergonomie est constituée et maintenue. La cause de l’ergonomie avance… même si les conditions d’intervention sont loin d’être idéales.
Niveau 6 : Démarche ergonomique systématique
L’ergonomie est instituée sur les projets. Les techniques et méthodes de conception centrée utilisateurs sont des pratiques considérées au démarrage de tous les projets avec un degré d’intervention variable selon la nature et l’importance du projet. Cela devient très intéressant !
Niveau 7 Conception Centrée Utilisateurs
L’ergonomie est l’affaire de tous. Des recherches Utilisateurs sont menées régulièrement: elles alimentent les projets. La qualité ergonomique du produit est mise au 1er plan : elle est vérifiée, mesurée, des objectifs sont fixés.
Niveau 8 : Organisation Centrée Utilisateurs (total user focused)
Les données recueillies dans les recherche utilisateurs vont alimenter la stratégie produit et la stratégie d’entreprise. L’expérience Utilisateurs est étendue à tous les canaux, à toutes les formes d’interaction avec les clients.
L’original: http://www.useit.com/alertbox/maturity.html
Posté par jc-QualityStreet le 5 mars 2008
Êtes vous User Focused ? Vous sentez-vous User Focused ?
Appliquez-vous les principes de Conception Centrée Utilisateurs ?
Comment vous améliorer ?
Vaste sujet puisqu’il est transversal puisqu’il touche à vos processus organisationnels … mais un sujet qui va devenir central dans les années à venir tant la prise en compte des utilisateurs et la qualité ergonomique des produits et services informatiques vont impacter votre business.
Quand une organisation se met à s’interroger sur les problématiques ergonomiques concernant ses produits (c’est le “WAKE UP CALL“, le fameux déclic), nous avons plusieurs façons de la conseiller, plusieurs possibilités d’intervention :
- Aider à la conception du produit
- Evaluer les interfaces
- Mesurer l’effet du produit en contexte
- Lancer des recherches utilisateurs ponctuelles
Des classiques me direz-vous … des interventions, certes utiles, qui vont répondre à des besoins immédiats dans une vision à court et moyen terme.
Pourtant là n’est pas le vrai challenge …
pour progresser, amplifier ses gains, pour se démarquer, il faut aller plus en profondeur !
Il faut travailler sur ses processus de développement, ses processus organisationnels, et faire en sorte que Conception centrée Utilisateurs et Ergonomie soient intégrés et se diffusent naturellement dans l’organisation.
C’est donc là que j’interviens !
On voit où vous en êtes sur toutes ces questions.
On fait un point précis sur vos process.
On met en place une stratégie d’amélioration AJUSTEE à vos contextes de développement, à vos cycles produit.
On ne cesse de s’améliorer.
Simple Non ? …
