Méthodologie

Méthodologie

L’utilisateur moyen n’existe pas

Design d’interface : l’utilisateur moyen n’existe pas.

La réussite des projets informatiques tient en grande part au facteur humain. Tous les maillons de la chaîne sont précieux pour réussir son projet.

Certes la qualité de la méthodologie, de l’usine de développement sont cruciaux, mais le facteur différenciant est la qualité d’écoute que les responsables métier ou technique sont capables d’offrir à l’utilisateur final.

Car au bout du compte, pour qui fait-on une application métier si ce n’est pour des utilisateurs ?

Il convient d’identifier clairement dès le début du projet quels seront les utilisateurs finaux du système avant toute chose. Et surtout garder à l’esprit que l’utilisateur « moyen » – celui que croit connaître le responsable métier ou encore l’idée que s’en fait le chef de projet fonctionnel voire celui rêvé par le designer graphique – N’EXISTE PAS.

On ne suppose pas que quelqu’un travaille comme ceci ou comme cela. Un utilisateur travaille d’une certaine façon, ses besoins sont réels et les manques qu’il subit au quotidien affectent non seulement la qualité de son travail mais altèrent aussi chez lui le sens du travail « bien fait ».

Il est donc nécessaire de déterminer des profils type d’utilisateurs finaux, pour les pousser à émerger nous employons la méthode de l’observation et la méthode des personas.

L’observation des utilisateurs

Design d’interface : l’observation des utilisateurs

Pour un design d’interface réussi, il convient d’identifier les véritables utilisateurs du futur système, d’après une observation sur le terrain et une analyse des données complémentaires.

Plus ou moins poussée, l’observation doit permettre au concepteur de comprendre comment les opérateurs procèdent pour réaliser un ensemble plus ou moins complexe de tâches. Cette observation permet de dresser un constat des actions réalisées et des résultats obtenus, la prise et la nature des informations et leur supports, et les outils et moyen de communication.

L’observation nécessite la mise en place d’un protocole rigoureux car il s’agit bien d’observer le travail d’un opérateur de façon neutre et non pas de se mettre « à sa place » pour imaginer les raisons des actes de celui-ci : « Il suspend son geste » ne doit pas être observé en tant que « Il hésite ».

Cette observation peut être utilement complétée par l’analyse des problèmes remontés par les utilisateurs (hot-line, assistance aux utilisateurs, etc.).

A la suite de cette étape il est possible d’identifier des types d’utilisateur et de créer des personas. A l’encontre du Marketing, les personas ne correspondent pas à des profils ou à une segmentation mais correspondent plutôt à la synthèse des données récoltées pour élaborer plusieurs archétypes d’utilisateurs de l’application. Chaque persona est décrit dans une fiche, toutes ses caractéristiques sont relatives à l’usage du futur système et servira de guide aux concepteurs de l’application.

Nous trouver sur ARIBA Discovery

Ariba Discovery est un outil qui permet de passer et de piloter ses appels d’offre en ligne. De plus en plus, nos clients dématérialisent leurs appels d’offre c’est pourquoi nous avons rejoint la plate-forme ARIBA.

Consulter le profil de AMJ PLANS sur Ariba Discovery

Méthodes agiles : les clefs du succès

Sommaire

  1. Méthodes agiles : les enjeux
  2. Méthodes agiles : la démarche
  3. Méthodes agiles : techniques de mise en œuvre
  4. Méthodes agiles : les principales méthodes agiles
  5. Méthodes agiles : les clefs du succès

Méthodes agiles : les clefs du succès

Voici une présentation synthétiques des clefs du succès des méthodes agiles.

Les méthodes agiles ont démontré à travers de nombreux exemples qu’elles offrent un cadre plus adapté à la réalisation réussie de projets informatiques. Elles doivent donc être appliquées à chaque fois que cela est possible.

De multiples facteurs contextuels peuvent être pris en considération pour valider ou invalider la possibilité d’application d’une méthode agile. Les principaux critères d’éligibilité pourraient être les suivants :

  • Besoin rapide de mise à disposition du produit
  • Imprévisibilité des besoins du client
  • Nécessité de changements fréquents
  • Besoin de visibilité du client sur l’avancement des développements
  • Présence de l’utilisateur assurant un feedback immédiat

A l’inverse, il faut savoir détecter les conditions qui peuvent rendre difficile la mise en œuvre d’une méthode agile :

  • Indisponibilité du client ou de l’utilisateur
  • Dispersion géographique des ressources humaines
  • Inertie des acteurs du projet ou refus des changements

Dans ces conditions, les méthodes traditionnelles pourront (peut-être) être une solution plus adaptée.

Méthodes agiles : les principales méthodes agiles

Sommaire

  1. Méthodes agiles : les enjeux
  2. Méthodes agiles : la démarche
  3. Méthodes agiles : techniques de mise en œuvre
  4. Méthodes agiles : les principales méthodes agiles
  5. Méthodes agiles : les clefs du succès

Les principales méthodes Agiles

On parle quelquefois de méthode agile (au singulier) ou de méthodes agiles (au pluriel). Si le premier terme désigne le concept qui a été décrit ci-dessus, il existe des déclinaisons en termes de plan de mise en œuvre, de vocabulaire et de préconisation. Ce sont les méthodes agiles (au pluriel) dont voici les principales méthodes agiles :

Scrum

Scrum (qui signifie mêlée au rugby) est aujourd’hui la méthode agile la plus populaire. Elle se caractérise par itérations (appelées sprints) assez courts (maximum 1 mois) et un formalisme réduit : rôles (Product Owner, ScrumMaster, équipe), timeboxes (planification de release, planification de sprint, scrum quotidien, revue de sprint, introspection) et artéfacts (backlog de produit, plan de produit, plan de sprint, burdown/burnup de release, burdown/burnup de sprint)

EXtreme Programming (XP)

L’objectif principal de cette méthode est de réduire les coûts du changement. Elle met l’accent sur la revue de code (faite en permanence par un binôme), sur les tests (ils sont faits systématiquement avant chaque développement), la conception continue (refactoring), la simplicité, la traduction des besoins en métaphores.

XP est souvent pratiqué conjointement avec Scrum.

Rational Unified Process (RUP)

Cette méthode qui peut être considérée comme la moins agile des méthodes présentées ici, est un mélange des pratiques issues des méthodes traditionnelles et des méthodes agiles. Le principe est de parcourir un cycle de vie (inspection, élaboration, construction, transition) durant une itération. Chaque phase du cycle de vie est très précisément détaillée.

Son approche assez lourde et le coût d’investissement de cette méthode la réserve à des projets de grande ou moyenne taille.

Feature Driven Development (FDD)

Moins connue que les 2 méthodes précédentes, FDD est essentiellement axé sur le design et le développement. Pour cela elle s’appuie sur une formalisation du modèle objet à l’aide de diagrammes UML, un découpage par fonctions qui seront développées par des petites équipes responsables d’une ou deux fonctions. Elle accorde un aspect très important à la qualité du produit fini, et s’aide d’outils pour suivre le déroulement du projet.

Rapid Application Development (RAD)

C’est la méthode agile la plus ancienne et celle qui a été la première à être en rupture avec les méthodes traditionnelles. Elle a introduit les notions d’itération et d’incrément. Elle vise à adopter la solution la plus stratégique (en termes de délais), la moins risquée, la plus fiable et la moins coûteuse. Son cycle de développement est simple : cadrage, design, construction et finalisation dans le respect absolu d’une durée comprise entre 90 et 120 jours.

Dynamic systems development method (DSDM)

DSDM est méthode agile développée en Angleterre au milieu des années 90. Elle reprend les principes déjà vus dans les autres méthodes (implication des utilisateurs, autonomie de l’équipe, visibilité et adéquation du résultat, développement itératif et incrémental, réversibilité des modifications, tests continus, coopération des acteurs).

Elle est aujourd’hui moins utilisée que les méthodes précédemment décrites.

Voir aussi l’article expliquant la démarche agile.

Méthodes agiles : techniques de mise en œuvre

Sommaire

  1. Méthodes agiles : les enjeux
  2. Méthodes agiles : la démarche
  3. Méthodes agiles : techniques de mise en œuvre
  4. Méthodes agiles : les principales méthodes agiles
  5. Méthodes agiles : les clefs du succès

Pour atteindre les objectifs, les méthodes agiles partagent pour la plupart un ensemble de techniques de mise en œuvre dont voici un aperçu ci-dessous.

Fonctionnement par itérations

Pour intégrer les changements qui peuvent survenir, pour obtenir un retour de la part des utilisateurs ou du client et pour vérifier le bon fonctionnement des modules développés, les méthodes agiles fonctionnent par itérations.

Une itération est un cycle court ou très court durant lequel une partie de l’application doit être développée. Elle doit aboutir à la fourniture d’un livrable applicatif qui permet de constater les travaux réalisés.

Une itération permet également de procéder à des ajustements suite aux retours des précédentes itérations, et d’intégrer des nouveautés pouvant survenir au cours du projet.

Processus incrémental

Chaque itération est bâti selon un processus incrémental qui permet d’enrichir l’application en lui ajoutant des nouvelles fonctionnalités, en affinant les scénarios de tests, et en vérifiant sa bonne intégration dans l’environnement cible.

Un incrément est donc le résultat de la production d’un sous-ensemble de fonctions répondant aux exigences fixées au démarrage de l’itération.

Collaboratif

L’une des particularités des méthodes agiles est de considérer le groupe projet comme une équipe plus qu’une somme de personnes. Les notions de rôles et de hiérarchie sont réduites à leur strict minimum et c’est l’esprit de groupe qui est favorisé. Ce groupe doit partager un but commun : celui de réussir le projet dans l’intérêt de tous.

Ainsi si les notions de MOA, MOE, utilisateur et équipe développement existent toujours, elles travaillent ensemble et de préférence sur un même site.

La composante essentielle de cet aspect collaboratif est la confiance accordée à chaque membre de l’équipe. Les apports de chacun doivent avoir comme unique objectif celui de faire progresser le projet.

Prototypage

L’approche itérative et incrémentale favorise la réalisation d’essais, aussi appelés prototypes, qui permettent de valider une solution ou une approche (en terme d’interface utilisateur) avant son intégration dans l’application.

En effet, la recherche de l’excellence technique pousse à tester des solutions innovantes qui vont répondre aux besoins des utilisateurs.

Pour autant, elles ne pourront être acceptées que si elles ne présentent aucun risque et si leur mise en œuvre ne conduit pas à la réalisation d’une « usine à gaz » (recherche de la simplicité).

Processus d’intégration continue

L’intégration continue est un processus qui vise à intégrer au plus tôt tous les développements réalisés dans la version en cours afin de vérifier sa bonne intégration.

Ainsi, dès qu’une fonction est jugée « finie » (c’est-à-dire développée et testée), elle est mise à disposition dans la version courante.

Ce processus d’intégration continue contient également toute une mécanique visant à tester la version dans son ensemble, et ce de manière automatique et à chaque nouvelle intégration. Les tests doivent donc être automatisée et reproductibles. Ils sont donc définis et développés conjointement aux modules de code.

L’intégration continue est généralement réalisée à l’aide d’outils permettant l’intégration du code, sa compilation automatique pour génération d’une version, et le lancement de tous les tests déjà définis sur la nouvelle version produite. L’automatisation du lancement des tests permet de vérifier le bon fonctionnement de l’application dans l’intégralité de sa version actuelle et l’absence de régressions.

Culture différente

Les méthodes agiles demandent à ceux qui les adoptent de changer leur approche et d’oublier certaines des habitudes acquises avec les méthodes précédentes (accepter le changement, privilégier l’application à la documentation, raisonner uniquement dans l’intérêt du projet, préférer le bon sens aux règles et usages).

Ce changement de culture n’est pas simple à accepter car il entraîne une modification de la position de chaque acteur, une perte de repères et donc une certaine insécurité.

L’adoption d’une méthode agile doit donc être un acte volontaire, accepté dans un état d’esprit positif. C’est l’une des clefs de la réussite du projet qui est à réaliser.

Retour en haut