Une interface conviviale (1/3)

Posté par jc-QualityStreet le 28 février 2007

“Faites-moi une interface conviviale !”

… qui n’a pas été confronté

Concevoir un produit facile à utiliser (Livre)

Posté par jc-QualityStreet le 21 février 2007

« Concevoir un produit facile à utiliser » : voilà un livre méconnu, je dirais malheureusement … car selon moi, cet ouvrage devrait être lu par toutes les personnes impliquées dans la conception de Produits.
Précis, il est vraiment facile à lire : style simple et incisif, encadrés, fiche résumée pour chaque chapitre.
Ce livre propose en outre de tres bonnes illustrations et de bons exemples avec la volonté continue de se donner une orientation « produit », « usage » et pas seulement I.H.M. En ce sens c’est l’un des meilleurs que j’ai lus.
La vision d’Eric Brangier et Javier Barcenilla (par ailleurs, mes professeurs il y a quelques années) est pragmatique, fondée sur l’action et issue d’une bonne expérience du terrain.
L’ouvrage est complet dans son traitement de la conception et de l’évaluation des interfaces.
Les normes, notamment 9241 et 13407 sont également rappelées ; la définition de l’ergonomie et de ses composantes est juste, claire et bien illustrée.
Une lecture que vous ne regretterez pas !

Retrouvez d’autres références sur l’Ergonomie, le Processus Unifié et le Test Logiciel dans la rubrique “Quelques livres“.

Ergonomie du logiciel et Design Web (Livre)

Posté par jc-QualityStreet le 16 février 2007

« Ergonomie du logiciel et Design Web » est un livre de référence qui ne s’adresse pas seulement aux ergonomes mais qui peut intéresser au final, toutes les personnes impliquées dans des projets de développement logiciel ou web.
D’ailleurs, c’est le livre que je prête le plus autour de moi ! notamment à mes collègues développeurs quand ceux-ci me demandent un livre sur l’ergonomie web: leur retour est plutôt positif.
« Ergonomie du logiciel et Design Web » est complet, plutôt bien écrit; Jean-François Nogier propose pas mal de repères et décrit remarquablement la démarche ergonomique. De plus, cet ouvrage a le gros avantage d’être en français.
Le livre propose un ensemble de recommandations, argumentées et valables aussi bien dans l’univers web que logiciel. Les annexes introduisent quelques concepts de psychologie cognitive et fournissent des checklists intéressantes pour la conception et l’évaluation d’interfaces utilisateur.
Bref un livre du domaine Ergonomie que je vous recommande vivement.

Retrouvez d’autres références sur l’Ergonomie, et bien d’autres domaines dans la rubrique “Quelques livres“.

Formations Test Logiciel

Posté par jc-QualityStreet le 12 février 2007

Actualiser ses connaissances, envisager d’autres points de vue, me paraît primordial. Aujourd’hui marquait le début de deux formations que je vais suivre : Stratégie des Tests (sur 3 jours) et Test & Validation du logiciel (l’UE du CNAM en cours du soir jusqu’au mois de juin).
Dans les deux cas, je n’échapperai pas à des choses connues, déjà vues et revues: ce fut le cas pour l’essentiel de cette première “grande” journée (11 heures de formation au total!); même s’il n’est pas toujours inintéressant de se voir présenter les choses sous un angle différent.
Toutefois la suite s’annonce meilleure… Pour le première formation, focus sur l’intégration du test dans le processus itératif avec études de cas (qui répondront peut être à certaines questions que je me pose) et retours d’expèrience sur les problématiques offshore. Pour la seconde, celle du CNAM, l’étude plus détaillée des techniques de test et des aspects propres au développement : tests unitaires, intégration, automatisation.
Bref, une belle complémentarité.

UP et une dose de SCRUM

Posté par jc-QualityStreet le 8 février 2007

Le Processus Unifié (UP) et SCRUM partagent une même démarche: itérative, incrémentale, pilotée par les risques, cadencée par le time boxing et par des livraisons fréquentes. Il s’agit de deux Méthodes Agiles, même si pour certaines instanciations d’UP il y a souvent débat et même si SCRUM possède incontestablement plus de légèreté et de dynamisme. Et c’est ce côté dynamique qui me semble trés pertinent.

On retrouve déjà dans le Processus Unifié pas mal d’éléments de SCRUM, mais dans une terminologie différente:

• Backlog produit = “Liste des exigences”, fonctionnelles ou non (ergonomiques, performance, sécurité …) (UP)
• Backlog de Sprint = “Plan d’itération” (UP)
• Produit partiel utilisable = “Prototype” en début de projet (phase d’Elaboration par exemple), ; “Produit” ensuite, (UP)
• Revue de Sprint = “Réunion de fin d’itération” (UP)

Au sein de nos équipes, le pilotage par les risques est très apprécié mais le concept d’itération est ce qui est le mieux perçu (malgré certaines difficultés dans la pratique), tout comme les livraisons intermédiaires. Toutefois l’itération en elle-même me semble manquer de pêche (ça démarre fort, ça se termine pas mal, mais au milieu il y a comme un peu de flottement…)

Le remède ? pourquoi pas ces techniques issues de SCRUM que le chef de projet (un chef de projet agile et pas un ScrumMaster) s’approprierait:

• Le scrum daily meeting (réunion d’équipe de 15 minutes maximum où chacun décrit où il en est…)
• Le burndown chart (graphique d’avancement, non figé, permettant de constater trés facilement le “reste à faire” sur un sprint)
• Les aides visuelles du SCRUM (par exemple, un grand tableau ou un mur distinguant les tâches en cours, celles non initiées et celles terminées, et des cartes pour chaque tâche à réaliser ; des cartes, un mur des choses que nous connaissons en Ergonomie des sites ou applications web)
• La communication sur certaines valeurs (esprit d’équipe, engagement, courage …)

J’attends de mettre ça en pratique sur mes prochains projets.
Pour le reste, le Processus Unifié correspond davantage à nos besoins notamment au niveau de la description et de l’enchainement des disciplines et activités, de la définition des rôles (trop succincte à mon goût dans SCRUM) et du focus sur la qualité.

Le Processus Unifié en bref

Posté par jc-QualityStreet le 3 février 2007

“Le processus unifié est un processus de développement logiciel, c’est-à-dire qu’il regroupe les activités à mener pour transformer les besoins d’un utilisateur en système logiciel” (Jacobson, Booch, Rumbaugh 1999)

Il est le fruit des meilleures pratiques de l’ingénierie logicielle: des approches éprouvées pour développer et maintenir des logiciels de qualité.

Pourquoi passer au Processus Unifié ?
Le processus Unifié est en mesure de répondre directement ou indirectement à à ces problématiques, n’hésitez donc pas à en lire un peu plus !

• Vous explosez vos budgets
• Vous dérapez sur les délais ce qui retarde la mise en marché de vos produits
• Vos clients ne sont pas satisfaits de la qualité de vos produits
• Vos produits ne font pas, au final, ce qu’il sont censés faire, sans compter les bugs !
• Vous ne parvenez pas à gèrer le moindre changement demandé en cours de projet
• Vous manquez de visibilité sur vos projets, d’ailleurs vous avez commencé du développement Offshore et c’est encore pire!
• Vos équipes de développement ne savent pas ce qu’elles ont à faire ou ne semblent guère motivées
• Vous perdez du temps à refaire sans cesse les mêmes choses
• Vous n’avez rien à communiquer à vos clients, dailleurs vos clients vous ne les revoyez qu’à la fin !
• Vous avez besoin d’un “cadre” que les autres méthodes Agiles (XP ou SCRUM) ne peuvent vous proposer …

Son origine
Le terme “Unifié” est trés approprié puisqu’il s’agit de la fusion des travaux d’Ivar Jacobson, Grady Booch (au départ chez Objectory) et de James Rumbaugh, enrichie de nombreux apports issus d’UML (développé en parallèle) et du produit commercial RUP, sorti en 1998 et toujours mis à jour par IBM (aprés le rachat de Rational qui avait lui même acheté Objectory en 1995).
D’autres ont permis de peaufiner le processus, notamment Walker Royce et Philippe Kruchten pour la planification et la gestion de projet.

Ses principes
Le Processus Unifié (UP) est piloté par les cas d’utilisation (eux même guidés par les risques) centré sur l’architecture, itératif et incrémental.
Le projet sera donc mené selon les besoins et les exigences (fonctionnelles et non fonctionnelles) : points d’entrée sur lesquels l’analyse des risques va principalement s’exercer pour organiser les plans d’itération, et pour moi en tant qu’ergonome c’est important.
Les risques majeurs (souvent liés à l’architecture) seront traités en premier lieu dans le but de les lever au plus tôt: gestion et pilotage par les risques, de vrais points forts pour la méthode.
Le Processus Unifié est opposé au cycle de vie en cascade (ou séquentiel) trop figé et rigide, et se lit selon deux axes: vertical (enchainement de disciplines et d’activités au sein d’une itération) et horizontal (enchainement dynamique sur l’axe temporel de phases et d’itérations). On va donc par exemple, tester à chaque itération sans attendre la fin du projet…

Il définit donc 4 phases :

• Inception (courte pour estimer, planifier, partager une même vison du problème, et engager les hostilités),
• Elaboration (architecture définie, risques majeurs levés, exigences trés avancées, programmation largement engagée)
• Construction (plus d’itérations mais plus courtes; développement de toutes les fonctionnalités, doc incluse)
• Transition (préparation du lancement, tests beta, formation des utilisateurs, optimisation …).

Mais le Processus Unifié permet aussi et surtout de définir des disciplines, des activités, des rôles et des livrables: en cela il est beaucoup plus complet que la plupart des autres méthodes agiles (XP ou SCRUM) qui n’abordent pas ou trés peu ces questions.
Autre avantage, le Processus Unifié est customisable que ce soit à partir de sa forme la plus répandue et la mieux documentée, le RUP, ou à partir des autres instanciations qui ont été faites ces dernières années :

• EnterpriseUP (Scott Ambler, 2004),
• AgileUP (Scott Ambler, 2006 pour sa dernière version),
• EssentialUP (Ivar Jacobson, 2005),
• OpenUP (Eclipse Process Framework, 2006).

Les évolutions récentes cherchant à être plus légères, plus agiles.
Bref, à vous de l’adapter à votre contexte (organisation, types de projet…) pour qu’il réponde efficacement à vos besoins.

Ses six bonnes pratiques
L’application de ces principes ne peut vous assurer à 100 % de la réussite de votre projet; disons simplement qu’elle y contribuera fortement.

• Iterations courtes de 3 à 6 semaines avec les principes du Timeboxing (on ne bouge pas les dates, on ajuste le contenu des itérations) et du pilotage par les risques
• Développements centrés sur l’architecture (et orientés sur les risques majeurs) avec le principe de la réutilisation des composants
• Focus sur la qualité (tester tôt et souvent, niveau unitaire, intégration, système) avec les principes de la validation et de l’intégration continues
• Modélisation graphique (UML, digrammes, grilles …) avec le principe de l’utilisation du visuel pour communiquer
• Gestion des exigences (organisation, traçabilité, évolution des exigences)
• Contrôle du changement (anticipation, gestion des demandes) avec le principe du réajustement (feedback, adaptation)

Son adaptation, sa customisation
Avant tout être “Agile” (c’est un état d’esprit), faire simple en ne retenant que le strict nécessaire; voici ma démarche:

• S’attaquer aux processus
• Mettre en avant les bonnes pratiques
• Identifier de manière pragmatique ce qui se passe sur les projets en termes de rôles, activités et disciplines. Ce fut notamment pour moi l’occasion d’officialiser certains rôles (dont l’ergonome…)
• Etablir une première mouture et l’appliquer sur 2 ou 3 projets pilotes
• Conduire le changement et généraliser
• Capitaliser et faire évoluer de nouveau

Les pre-requis pour mener à bien ce type de mission :

• bonne connaissance de l’organisation,
• vue globale sur les projets de l’entreprise et sur les activités des différents acteurs,
• bonne connaissance du RUP (bien documenté c’est une bonne référence),
• ouverture sur les différentes instanciations et les autres méthodes agiles (XP, SCRUM)

Les erreurs malheureusement souvent commises
Elles sont le signe d’une mauvaise interprétation du Processus Unifié:

• Decrire les phases d’UP comme les phases du mode séquentiel. L’inception n’est pas que l’analyse des besoins, la transition n’est pas une phase de test. La construction, ce n’est pas que du code ! Toutes ces disciplines peuvent avoir lieu en même temps dans une itération (comme l’indique le schéma).
• Commencer d’entrée par un planning ultra détaillé pour les 12 mois à venir
• Planifier des itérations trop longues (une itération dure entre 2 et 6 semaines : le but est d’être réactif)
• Décaler les dates d’itération à sa guise sans respecter le Timeboxing
• Ne pas tester dans une itération ce qu’on a produit
• Oublier que le but de la phase d’Elaboration n’est pas de produire un prototype jetable mais une architecture viable
• Analyser toutes les exigences avant de commencer à programmer
• Se dire qu’il faut absolument utiliser tous les livrables potentiellement utilisables

Pour aller plus loin…

• The Unified Software development process, Jacobson, Booch, Rumbaugh, 1999
• The Rational Unified Process, An Introduction, Philippe Kruchten, 2000
• Agile and iterative development : A Manager’s guide, Craig Larman, 2003
• Rational Unified Process Version 2003.06.01.06