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 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 7 novembre 2007
L’ISO 9126 « Software Product Quality » (2001) et l’ISO SQuaRE « Software Product Quality Requirement and Evaluation » (2005) (fusion de 9126 et 14598, son volet évaluation) font partie de ces normes qu’il est bon de connaître quand on travaille dans le développement de logiciels ou plus largement dans la conception de services interactifs.
MàJ du 08/11/2007 : Pour une définition plus précise de l’ergonomie et de l’utilisabilité, jetez-un oeil à ce billet ”Ergonomie = Utilité + Utilisabilit锑
L’essentiel pour moi, Ergonome
- La mise en avant de l’Utilisabilité (facilité d’utilisation) : c’est l’une des 6 caractéristiques du modèle de qualité
- La présence de l’Attractivité en plus de sous caractéristiques plus classiques : c’est la reconnaissance de l’esthétisme, de l’affect, du “beau” au niveau de l’interface… élément qui fait régulièrement débat
- L’introduction (forme révisée) du concept de “Quality in use” avec 4 caractéristiques : Efficacité, Efficience, Sûreté, Satisfaction… mon “Ergonomie en 3 mots” pourrait pourquoi pas, se transformer en une “ergonomie en 4 mots”
- La mise en oeuvre des mesures
En bref
ISO 9126 et ISO SQuaRE fournissent un modèle, fait de caractéristiques et sous-caractéristiques, permettant de lier les qualités externes d’un logiciel à ses qualités internes, et introduisent fort justement (même si on a tendance à l’oublier) le concept de “Quality in use” (« the user’view of the quality of the software product when it is used in a specific environment and a specific context of use ») : une vraie porte ouverte vers les Tests Utilisateurs et l’observation en contexte.
6 caractéristiques de qualité (avec un focus sur l’Utilisabilité)
- Capacité fonctionnelle
- Fiabilité
- UTILISABILITE (en anglais, “usability” qu’on peut traduire aussi par “facilité d’utilisation”, c’est à dire un “Ensemble d’attributs portant sur l’effort nécessaire pour l’utilisation et sur l’évaluation individuelle de cette utilisation par un ensemble défini ou implicite d’utilisateurs”) : Facilité de compréhension, Facilité d’apprentissage, Opérabilité, Attractivité, Conformité aux standards d’ergonomie
- Rendement
- Maintenabilité
- Portabilité
Pourquoi ça m’intéresse ? Qu’est ce que ces normes m’apportent ?
- La qualité des produits est mon leitmotiv, ce vers quoi je tends…
- Ces normes sont à elles seules le symbole de la convergence de plusieurs disciplines de l’ingénierie
- C’est la reconnaissance de ma propre discipline, l’Ergonomie, de mon rôle et de mon expertise (en particulier sur les questions relatives à la facilité d’utilisation), cela peut légitimer mon intervention
- C’est un point d’entrée idéal pour l’ingénierie des exigences (du recueil à la gestion des exigences en passant par l’analyse du besoin): j’utilise ces caractéristiques pour qualifier les exigences fonctionnelles et non fonctionnelles recueillies
- Cela facilite ma collaboration avec les services QA (Quality Assurance) et sur un projet avec un Responsable de test
- Il existe un lien fort avec des domaines de processus CMMI, niveau 2 et 3, je pense notamment à RD “Développement des exigences”, REQM “Gestion des exigences”, VER “Vérification”, VAL “Validation”, TS “Solution technique”, MA “Mesure et Analyse” …
Posté par jc-QualityStreet le 16 septembre 2007
Après “Agile CMMI: moi j’y crois” et “CMMI, décidemment nous y sommes“, imaginons maintenant quelles pourraient être les motivations respectives des auteurs ou partisans des deux approches pour un rapprochement (selon moi inévitable) du CMMI (Capability Maturity Model Integration) et des Méthodes Agiles.
Au programme : Convergence … Complémentarité … Popularité … Amélioration continue … Succès.
Convergence
Agilité et CMMI se donnent les mêmes objectifs, notamment niveau Client (satisfaction, rétention, acquisition), niveau Projet (respect côut, délais, qualité) et niveau Collaborateurs (satisfaction, montée en compétence…). Partager le même but peut faciliter les rapprochements…
Complémentarité
CMMI définit le “Quoi” mais a besoin d’éléments pour atteindre les objectifs qu’il se fixe. L’agilité peut donc en partie constituer ces éléments et se charger d’une partie du “comment”, ce qui contribuera au passage à lever les idées reçues concernant les deux approches.
Qui dit Agile ne dit pas absence de discipline, Scott Ambler en parle remarquablement dans ce tout récent article « The discipline of Agile » ; Et, Qui dit CMMI, ne signifie pas pour autant lourdeur excessive.
Popularité
Sans enlever à la notoriété du CMMI, fort populaire dans certains contextes, il est évident que les Méthodes Agiles ont actuellement le vent en poupe. Déjà populaires dans les pays anglo-saxons, elles se démocratisent en France. Ainsi, intégrer plus largement, plus visiblement, plus concrètement, en son sein, des pratiques Agiles (pour chaque but par exemple) pourrait permettre au CMMI d’envisager d’autres cibles.
Amélioration continue
C’est un principe Agile, c’est l’essence même du CMMI … et un facteur motivationnel de 1er ordre pour l’ensemble des acteurs des univers CMMI et Agile, qui pourraient, dans l’agilité ou dans la maturité, trouver les moyens d’améliorer leurs propres pratiques, de combler leurs lacunes et faiblesses….
Succés
Dans le prolongement du point précédent, de récents retours d’expérience nous ont prouvé l’efficacité, que dire, le succès de la combinaison des méthodes Agile et du CMMI. Ensemble on est plus forts, c’est le message que fait passer Jeff Sutherland et dont je suis entièrement convaincu !
Si à votre tour, vous voyez d’autres « motivations », n’hésitez pas à nous les faire partager…
Posté par jc-QualityStreet le 3 septembre 2007
Plus qu’une simple tendance, le rapprochement des Méthodes Agiles et du CMMI (Capability Maturity Model Integration), ou plus exactement l’usage de pratiques de développement Agiles (qui ont le vent en poupe) dans une dynamique de processus guidée par le CMMI (version1.2 DEV d’aout 2006) est bel et bien réel.
Les exemples concernant XP et SCRUM (voir les études de Mickael Spayd, Mark Paulk, Hillel Glazer ou encore Jeffrey Dutton) se multiplient depuis quelques années.
Dernier exemple en date (trés bien documenté d’ailleurs), celui de Codice Software (un éditeur espagnol), “SCRUM Meets CMMi, Agility and discipline combined“, avec à la clé l’atteinte d’un niveau 2 de maturité et une vision trés pragmatique de la combinaison des deux approches (un vrai travail sur REQM, “Gestion des exigences”, des domaines complètement nouveaux et pas des plus simples dans un contexte Agile: PPQA, “Assurance Qualité Processus et Produit” et MA, “Mesure et Analyse”….).
Dans un contexte plus général, cette démarche de réconciliation Agile CMMI (c’est un bien grand mot !) est soutenue, et c’est trés positif, par des acteurs majeurs des deux “camps”, mais elle implique aussi, selon moi, à notre niveau, l’acceptation de certains prérequis:
- D’abord considèrer le CMMI tel qu’il est, à savoir, un modèle, un guide, et non pas un processus ou une méthode de développement.
- Se souvenir que le CMMI définit seulement le QUOI (par ses objectifs par exemple) et non pas le COMMENT, même si le modèle propose quelques pistes. Et c’est vrai que cette absence de COMMENT a laissé la part belle aux méthodes dites traditionnelles (cascade ou V) toujours bien ancrées.
- Ne pas oublier que seule l’atteinte des objectifs généraux (GG, liés à un niveau de maturité) et spécifiques (SG,liés à un domaine de processus) est requise lors d’une évaluation SCAMPI (méthodes standards d’évaluation). Les pratiques (GP, génériques liées à un niveau et SP, spécifiques liées à un domaine de processus) ne sont quant à elles pas obligatoires, et des alternatives (Agiles notamment) sont envisageables : c’est un bon point d’entrée.
- S’arracher des idées reçues concernant les deux Mondes … (vaste débat), rechercher l’ouverture, et d’un point de vue pratique, au quotidien, s’appuyer sur des leviers organisationnels exploitables.
David Anderson a su trouver les mots justes lors de l’Agile2005:
A key to achieving more agility with the CMMI is to realize that the practices are primarily advisory or indicative only. To meet a CMMI appraisal, an organization must demonstrate that the goals of a process area are being achieved. This is done by identifying evidence of practices. However, the practices need not be the ones described in the CMMI specification. The organization is free to propose alternatives practices and appropriate evidence. The appraisal team must then agree to whether this is appropriate to demonstrate the goal. This provides a process designer with a great deal of freedom.
En conclusion, si vous entendez les mots Agile et CMMI dans la même phrase, ne fuyez pas … soyez curieux … et dites OUI à la convergence.
