Posté par jc-QualityStreet le 11 mars 2009
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)
Posté par jc-QualityStreet le 10 avril 2008
Oui mais y-a du boulot car CMMI (Capability Maturity Model Integrated) n’offre pas à l’ergonomie un domaine réservé !
Voici néanmoins quelques pistes dans ce billet sur Ergonomic Garden : “CMMI, Ergonomie: quelle collaboration possible ?” et dans les commentaires associés.
Une 1ère étape pour des bénéfices mutuels…
Un référentiel CMMI évidemment ajusté, léger et dynamique (Esprit Agile et Lean Thinking prennent ici tout leur sens) peut donc s’enrichir et bénéficier ici ou là, des techniques, outils et méthodes de l’ergonomie informatique pour atteindre des objectifs spécifiques bien définis. Outre une meilleure qualité de vos produits, plus d’efficacité, la démarche ergonomique éliminera pas mal de zones de flou et rationalisera vos choix d’interface !
Dans le même temps, la mise ne place de ces bonnes pratiques d’ergonomie, dans un cadre CMMI, va les institutionnaliser et permettre à une organisation de gagner en maturité en terme de Conception Centrée Utilisateurs, et devenir réellement USER FOCUSED.
Vers un TRIO GAGNANT: CMMI, Méthodes Agiles, Ergonomie…
Mais associer ergonomie et CMMI n’est qu’une étape dans des cycles d’amélioration continue. Le vrai challenge, et les GAINS LES PLUS NOTABLES n’interviendront qu’au travers:
Alors, au boulot !
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).
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 ? …
Posté par jc-QualityStreet le 16 février 2008
Le principe de base est qu’un environnement propre et bien rangé contribue à la réalisation d’un travail efficace et de qualité.
Bon, à 35 ans c’est parfois difficile de changer ses habitudes, mais avec un peu d’autodiscipline et de rigueur, croyez-moi on y arrive… et puis, tout ce qui peut éviter de me faire perdre du temps est le bienvenu…
La pratique des 5 S (Seiri, Seiton, Seiso, Seiketsu, Shitsuke) est une méthode d’organisation japonaise précisément du Toyota Production System (TPS), initié par Taiichi Ohno (DG de Toyota); TPS dont Mary et Tom Poppendieck, se sont inspirés dans le cadre du développement logiciel avec leur “Lean Software Development“, que j’ai déjà évoqué dans d’autres billets.
LES 5S:
Seiri (Débarrasser)
Débarrasser son espace de travail de l’inutile, garder l’essentiel : une première étape incontournable. C’est la fin des bureaux encombrés, des armoires pleines, des disques durs engorgés. Pour cela, il suffit de se fier à la fréquence d’utilisation !
Seiton (Mettre en ordre)
Organiser son espace de travail de façon efficace. Une place pour chaque chose et chaque chose à sa place ! Quand on cherche quelque chose, on le trouve vite ! C’est vital pour ses propres dossiers, ça l’est aussi sur un projet ou pour la GESTION des connaissances de l’entreprise.
Seiso (Nettoyer)
Un travail propre se réalise avec des outils propres. Il s’agit donc de nettoyer son poste de travail le plus régulièrement possible.
Seiketsu (Standardiser)
Maintenir l’ordre et la propreté; cela passe par des règles (de rangement, d’indexation notamment) claires, évidentes … et connues de tous si on se place une nouvelle fois au niveau d’un projet ou de l’entreprise.
Shitsuke (Encourager les efforts)
Maintenir ces principes jours après jours, années après années… et même essayer de les améliorer. C’est souvent le plus difficile, et la dessus que j’ai toujours “dérapé” … jusqu’à maintenant !!
Tout cela paraît facile, et ça l’est, alors allons-y. Et pour se motiver davantage, rappelons que ces 5S sont les fondamentaux, le point de départ, vers les autres principes du Toyota Production System et du Lean software Development, des principes qui ont prouvé leur efficience. On pourrait citer par exemple:
- Réduire les stocks (ou plutôt les tâches non réalisées ou en cours de réalisation, les bugs …)
- Éliminer les sources de gaspillage (c’est à dire toutes les activités qui n’apportent pas de valeur au client … anomalies, situations d’attente, fonctionnalités inutiles)
- Favoriser l’apprentissage et adopter une démarche d’amélioration continue…
- Livrer vite mais à un niveau de qualité élevé (cycle de développement courts favorisant le feedback)
- …
D’ailleurs en parlant de Lean, je vous engage tous, à faire sur vos derniers projets, juste pour voir, une petite cartographie des flux de valeurs (la fameuse “Value stream map“) mais là, c’est une autre histoire !
Posté par jc-QualityStreet le 2 février 2008
Mais tout d’abord, une petite question : selon vous, parmi la centaine de posts de ce blog, quel est le “billet le plus consulté” ?
Allez… quelques secondes de réflexion…
Bon fin du suspens (et quel suspens !) … le billet gagnant se trouve être (et de loin) …
“Spécifications, Exigences et Cahier des charges : Quoi, Comment ?”, l’un des billets de mon TOP 14.
Je ne me risquerai pas à émettre des conclusion hâtives sur cette statistique (car les facteurs l’influençant sont nombreux).
Je ne m’aventurerai pas non plus à postuler que le billet en question est celui qui VOUS intéresse le plus, vous les habitués de Qualitystreet, lecteurs assidus qui venez d’horizons souvent différents mais qui vous retrouvez dans ma vision des projets, de la qualité et dans cette convergence vers laquelle je tends.
Alors surpris ? Moi non (mais je triche car je consulte mes stats), et Vous ?…
J’espère que les lecteurs de “ce billet le plus consulté” trouvent déjà dans celui-ci ce qu’ils recherchent… Pour les y aider davantage, voici un petit “best of” de billets Qualitystreet relatifs à l’Ingénierie des exigences (besoins, spécifications, analyse ….), mais rassurez-vous nous en reparlerons, dans des contextes agiles, à partir d’un référentiel CMMI ou même en mixant les deux!
- Spécifications, Exigences et cahier des charges: Quoi, Comment ?
- Spécifications, Exigences et cahier des charges: Qui, Quand
- Modèle de Kano: si précieux pour…
- La voix de l’utilisateur, entre recueil du besoin et gestion de l’incertitude
- Un user proxy mais pas d’utilisateurs
- Une interface conviviale (1/3)
- Une interface conviviale (2/3)
- Une interface conviviale (3/3)
- Use cases, User Stories
- Use cases, User Stories: les différences
- Use Case, UML, oui mais …
- User stories, plus appropriées ?
Si vous avez le courage d’en lire ou en avez lu certains :); dites-moi celui qui vous inspire le plus, sinon plus simplement faites nous partager vos meilleures sources.
