Projet

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.

Etiquettes : , ,

Catégories : Blog, Méthodologie, Projet

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.

Etiquettes : , ,

Catégories : Blog, Méthodologie, Projet

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.

Catégories : Blog, Méthodologie, Projet

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.

Catégories : Blog, Méthodologie, Projet

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.

Catégories : Blog, Méthodologie, Projet

Méthodes agiles : les enjeux

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

Cible et Problématique

Bon nombre de projets informatiques « s’achèvent » avec un bilan peu satisfaisant, pour cause de retard, de dépassement de budget ou de non-satisfaction des utilisateurs. Malgré une expérience forte de plusieurs décennies, ce constat reste malheureusement d’actualité. Pourquoi ?

L’analyse du bilan des projets qui ont connu un échec fait apparaître quelques causes qui sont presque toujours les mêmes :

  • La confusion entre les besoins estimés et les besoins réels
  • La forte pression d’un contexte économique ou d’un planning très tendu
  • Les modalités de forfaits qui figent dans le marbre les spécifications fonctionnelles
  • La volonté de respecter un ensemble de clauses contractuelles qui font oublier l’objectif initial
  • Des rapports parfois difficiles entre la maîtrise d’ouvrage et la maîtrise d’œuvre
  • L’utilisation de méthodes non adaptées ou mal utilisées
  • Le manque de communication à tout niveau

En réponse à cette analyse, de nouvelles méthodes de conduite de projets informatiques ont vu le jour il y a quelques années. Ce sont les méthodes agiles.

Enjeux

L’importance de la qualité

La définition de la qualité en sens ISO 9000 est la suivante :  » Aptitude d’un produit ou d’un service à satisfaire, au moindre coût et dans les moindres délais les besoins des utilisateurs. « .

C’est donc le point le plus important d’un projet et celui doit guider toutes les décisions d’un projet informatique.

La qualité est au cœur des concepts des méthodes agiles.

La maîtrise des risques

L’identification et l’élimination des risques (à défaut leur réduction) sont des tâches qui doivent être traitées en permanence sur un projet informatique. C’est ce qui s’appelle un pilotage par les risques.

Une fois les risques maîtrisés, les facteurs d’échec se trouvent grandement diminués.

Les méthodes agiles consacrent une grande importance à cet aspect comme cela est présenté plus loin.

Renvois bibliographiques :

Scrum – Le guide pratique de la méthode agile la plus populaire (Claude Aubry – DUNOD)

Gestion de projet : EXtreme Programming (Jean-Louis Bénard, Laurent Bossavit, Régis Médina, Dominic Williams- Eyrolles)

UML 2 en action (Pascal Roques et Franck Vallée – Eyrolles)

Wikipédia : Méthode Agile (http://fr.wikipedia.org/wiki/Méthode_agile)

Catégories : Blog, Méthodologie, Projet

Web mobile révolution

Pourquoi une révolution ?

Un marché en devenir

En 2016, il y avait environ 2,6 milliards de smartphones dans le monde. Selon le cabinet Park Associates, ce chiffre devrait atteindre 6,1 milliards d’ici 2020. En comparaison, fin 2010, on recensait environ deux milliards d’internautes sur PC. On peut donc parler de « Web Mobile Révolution » Leur nombre continuera à progresser mais plus lentement. En voici deux raisons importantes :

  • L’équipement en ordinateur dans les pays développés est arrivé à quasi saturation. En comparaison, le marché des smartphones est en pleine croissance et celui des tablettes le sera bientôt.
  • L’essentiel du potentiel de croissance de l’accès à internet des pays émergeants ou en voie de développement se fera par smartphones car ils y sont (et seront) plus aisément accessibles qu’un ordinateur.

Les sites internet pour mobiles (smartphones et tablettes) sont donc appelés à se développer de manière encore plus rapide et spectaculaire que leurs frères aînés pour ordinateurs il y a 10 ou 15 ans.

Un usage différent

Si le socle technique des sites internet pour mobiles est identique à celui des ordinateurs, il en va différemment de leur utilisation. En effet, ces sites correspondent à un besoin et un usage différent :

  • Un mobinaute peut être pressé, l’information doit donc être accessible très rapidement.
  • Il peut aussi chercher un passe-temps, le site doit être récréatif tout en étant adapté à son support de consultation dont les dimensions sont plus réduites.
  • Un site pour mobile ne doit pas nécessiter de concentration particulière car son visiteur n’est pas nécessairement dans des conditions propices (transports, en déplacement, en groupe).
  • Il doit limiter au maximum les interactions manuelles peu faciles sur un mobile, surtout lorsque celui-ci est utilisé d’une seule main.
  • Il doit s’adapter à l’utilisateur car un smartphone est avant tout un objet personnel bien souvent utilisé comme support pour les réseaux sociaux.
  • Il doit tirer parti au mieux du caractère nomade de son support pour offrir au mobinaute des services adaptés à sa localisation.

C’est pourquoi les sites internet pour mobiles doivent être pensés différemment. 2 Nouvelles contraintes, nouvelle approche Avant de se lancer dans le développement d’un site pour mobiles, il est utile de se rappeler quelques éléments essentiels qui vont conditionner cette réalisation.

De nouvelles contraintes

La diversité des navigateurs internet

Alors que le monde des ordinateurs personnels est caractérisé par une faible variété de navigateurs internet, celui des smartphones est beaucoup plus hétérogène. Parmi ceux qui existent, on pourra noter les plus répandus :

  • les déclinaisons du noyau Webkit sur les appareils Apple (iPhone, iPad), sur les appareils fonctionnant sur Androïd, et sur quelques plateformes propriétaires
  • Opera Mobile et Opera Mini
  • Internet Explorer Mobile

Il en résulte une difficulté accrue pour réaliser un site qui soit compatible avec les différentes plateformes. Il existe cependant des possibilités de tester son site sur différents types d’appareils en utilisant des émulateurs. On retiendra toutefois que l’application de quelques règles de bonnes pratiques associées à l’utilisation de standards favorise considérablement la portabilité d’un site.

Les limitations matérielles

Malgré les progrès spectaculaires réalisés lors des derniers mois, la configuration matérielle des smartphones reste inférieure celle des PC de bureau. Si les résolutions d’écran ont atteint un palier tout à fait acceptable (résolution de 800×400 points voire plus), la taille de l’écran est et restera un facteur limitatif. Ceci a un impact, non pas pour l’affichage des informations, mais en tant que dispositif tactile de pointage. A moins d’utiliser un stylet peu pratique et fort facile à perdre, les doigts du mobinaute offre une surface de contact importante, et donc peu précise. Il faut donc concevoir les éléments actifs de l’interface qui soient adaptés à cette contrainte (boutons, listes, …).

La plupart des smartphones ne disposent pas d’un clavier matériel. Celui-ci est remplacé par un clavier virtuel affiché à l’écran. Pour les même raisons que celles présentées ci-dessus, ce clavier virtuel occupe une place importante de l’écran, réduisant ainsi la surface d’affichage des pages du site. Les claviers des smartphones, qu’ils soient matériels ou virtuels n’offrent pas une ergonomie suffisante pour permettre la saisie de textes longs. Cette limitation doit également être prise en compte dans la réalisation d’un site web pour mobile. Enfin, le débit offert par les réseaux mobiles sur internet n’est pas encore aussi important qu’avec une connexion filaire classique. Cette contrainte qui tendra à s’atténuer dans le futur est aujourd’hui à prendre en compte si le site internet propose le téléchargement de gros volumes de données.

Quelques bonnes pratiques

Le W3C a énoncé les 6 commandements à respecter pour la réalisation d’un site web pour mobiles :

  • Epargnez le réseau
  • Libérez les utilisateurs
  • Appliquez les principes du web
  • Soyez flexible
  • Exploitez les terminaux mobiles
  • Optimisez les temps de réponse

Sans détailler tous ces points, il convient de souligner les quelques bonnes pratiques qu’il convient d’appliquer :

Faire preuve de simplicité

Cette règle est à appliquer en termes de présentation du site. Celle-ci doit être linéaire et intuitive. L’iconographie doit être explicite et universelle (des symboles plutôt que des textes). Les enchaînements de page doivent être logiques et la navigation implicite. Le style doit être épuré pour correspondre à un maximum de configurations.

Minimiser la taille

La taille des images doit être adaptée aux résolutions des mobiles (idéalement pas plus de 300 pixels de large). Elle doit être explicitement définie dans la page pour éviter toute adaptation du navigateur. Si cela est possible, prévoyez un mécanisme d’adaptation des images sur le serveur du site. La taille des pages doit aussi être limitée. En effet, si le défilement sur un écran d’ordinateur est une chose aisée, cela ne l’est plus avec un mobile. Cette opération doit donc être réduite si possible.

Aider l’utilisateur dans ses actions

Cette aide doit prendre plusieurs formes :

  • Limiter les entrées manuelles
  • Guider et contrôler la saisie avant envoi au serveur pour minimiser le risque d’erreur
  • Mémoriser les préférences pour éviter à l’utilisateur de devoir refaire des opérations identiques systématiquement à chaque visite.
Optimiser les échanges de données

Il faut compresser les données nécessaires au chargement des pages et éviter des envois inutiles de données au serveur si ces dernières ne servent que du côté client (stocker localement les données sur le mobile).

Quels supports pour réaliser un site ?

Un site internet est constitué d’un assemblage de composants technologiques dont les rôles sont complémentaires : HTML, CSS, Javascript, images, vidéos. Il existe différentes versions et différents formats pour ces composants. Voici quelques conseils pour bien les choisir :

La famille HTML

Il existe plusieurs déclinaisons du langage HTML et de ses dérivés (XML et XHTML). En ce qui concerne les sites web pour mobiles, le W3C préconise fortement l’emploi du Document Type XHTML 1.0 Strict lorsqu’on souhaite rendre compatible un site à la fois pour les ordinateurs et les mobiles. Le Media Type recommandé pour les fichiers html est text/html.

Du style avec CSS

Les feuilles de style en cascade, aussi appelées CSS de manière abrégée, permettent d’appliquer des styles de présentation au contenu d’un site. Il existe plusieurs versions de syntaxe pour ces feuilles de style. Ces versions sont appelées niveaux. Un niveau a même été conçu spécifiquement pour les sites mobiles : le profil CSS Mobile. Si le site cible doit être compatible à la fois pour les ordinateurs et les mobiles, il est conseillé de choisir le niveau 1 car il est proche du profil CSS Mobile.

Javascript : Le langage de script pour internet

Javascript est le principal langage de script utilisé sur le web aujourd’hui. Le support de Javascript sur les navigateurs mobiles est très contrasté, allant d’une absence complète de prise en charge, au support des fonctions des dernières versions. Dans ce cas, la solution la plus appropriée est de s’appuyer sur une librairie qui prend en charge la gestion de ces différents contextes. JQuery est l’une des principales librairies pour les développements de site sur ordinateur. Une version dédiée aux mobiles JQueryMobile a vu le jour récemment et simplifie énormément la préparation d’un site pour mobiles.

Images

On distingue 2 types d’images : les images vectorielles et les images en mode point (dîtes aussi bitmap). Pour les images vectorielles, il existe aujourd’hui 2 formats répandus : Flash et SVG. Nous recommandons l’utilisation de SVG car le format Flash n’est pas supporté sur certaines plateformes (comme celles d’Apple qui est un acteur important du marché). Pour les images bitmap, le choix se fera entre JPEG (si une altération légère de l’image est tolérée, comme cela peut être le cas pour des dessins) et PNG (à retenir si les images représentent des diagrammes, des logos ou des icones).

Vidéos

Contrairement aux images, les vidéos ne sont pas des éléments qui étaient nativement reconnus par les navigateurs avant l’arrivée d’HTML version 5. Il fallait donc avoir recours à des plug-ins pour exécuter ces dernières. Cette approche est problématique pour les sites à destination des mobiles. En effet, la disparité des plateformes et la difficulté ou l’impossibilité d’installation de plug-in sur ces dernières rend très difficile un choix de format de vidéo. HTML 5 a introduit une nouvelle balise pour résoudre ces problèmes. Pour autant, la gestion des différents formats de vidéos n’est toujours pas un standard car ces derniers continuent à évoluer rapidement.

S’il faut faire un choix, il conviendrait sans doute d’adopter l’un des 3 formats suivants : H.264, Theora ou WebM. Actuellement Google a annoncé renoncer à supporter le format H.264 et promeut le format WebM. Inversement, un consortium comprenant Apple et Microsoft défend le format propriétaire H.264 et tente de faire valoir des brevets sur le codec VP8 intégré au format WebM.

Autres composants

Il existe d’autres composants présents sur les sites web classiques. Le format PDF est ainsi largement répandu. Mais ces derniers ne disposent pas (encore) d’un support suffisamment grand sur les mobiles pour prendre le pari de les intégrer dans des sites dédiés. 3 2 sites différents pour PC et mobiles ? Avec tous les éléments présentés dans le point précédent, il apparaît nécessaire de prévoir 2 sites différents, l’un pour les PC et l’autre pour les mobiles. Pour autant, la réalisation et la maintenance de 2 sites représente un travail supplémentaire non négligeable. Il est donc important d’étudier comment réduire ce surcoût de travail. Pour cela, il existe 2 approches différentes.

Préparer 2 sites, tout en mutualisant au maximum leur développement

Cette approche est la plus coûteuse mais c’est celle qui permet de produire les sites pour mobiles les plus aboutis dont le contenu peut être vraiment spécifique au support. Le travail de conception porte sur la mutualisation de la structure et du contenu qui peuvent l’être sur les deux environnements cibles. Il reste malgré tout un travail conséquent d’adaptation pour les 2 types de sites.

Préparer le squelette d’un site et disposer d’un système de génération de sites pour ordinateurs et pour mobiles

Cette approche est très pratique lorsque le besoin correspond à un CMS. Les dernières versions des principaux CMS, à l’image de Drupal ou SPIP, permettent ainsi de générer à partir d’une base commune des sites pour ordinateurs ou pour mobiles. Cette approche évite de devoir faire la plus grosse partie du travail d’adaptation. Elle requiert toutefois des tests et des ajustements dans certains cas.

Est-il possible de ne pas adapter son site internet PC aux mobiles ?

Il existe une solution gratuite, mais généralement peu satisfaisante. Elle consiste à utiliser les solutions d’adaptation de contenu mis en place par certains opérateurs de réseaux mobiles ou certains moteurs de recherche tels que Google ou Bing. Il est inutile de préciser que cette adaptation se fait selon des règles qui ne tiennent pas compte des spécificités du site puisqu’elles doivent pouvoir s’appliquer à tous les sites transitant par l’opérateur ou le moteur de recherche. C’est un proxy d’adaptation qui se charge de ce travail. Les résultats obtenus sont acceptables pour les mobiles basiques.

Par contre, le système révèle ses limites avec des mobiles plus évolués sur lesquels on peut attendre un rendu plus optimisé. Il est heureusement possible de désactiver ces adaptations automatiques à l’aide de quelques directives insérées dans les pages html. C’est fort utile lorsque l’adaptation a déjà été réalisée à l’aide de l’une des 2 premières solutions.

Dans le cas d’un site spécifiquement conçu pour les mobiles, il ne faut pas oublier de bien communiquer sur cette adaptation. L’utilisation judicieuse d’un suffixe de nom de domaine de type .mobi y contribue sans aucun doute (attention toutefois à respecter les pratiques prescrites par la joint venture mTLD en charge de l’attribution des noms de domaine ayant ce suffixe). 4 Et demain… Les éléments qui ont été abordés dans cet article concernent ceux qu’il est possible de rencontrer aujourd’hui sur un site web. Or, les mobiles apportent des fonctionnalités nouvelles par rapport à un ordinateur. Il est plus que probable que les sites web pour mobiles de demain tireront parti de ces spécificités. Voici donc quelques tendances possibles :

Géolocalisation

La géolocalisation avec un mobile ouvre des perspectives intéressantes pour un ensemble de besoins liés à la position ou à l’itinéraire pour les utilisateurs. De nombreux sites web peuvent ainsi s’enrichir de fonctions clef pour les mobinautes : visite de sites, itinéraire pour aller à une adresse, affichage de cartes, jeux de parcours… Il existe une API Javascript qui offre déjà cette fonctionnalité de géolocalisation qui est exploitable sur l’iPhone, sur Androïd et sur Opera Mobile.

Interactions audio

La fonction première des mobiles était la possibilité d’avoir une conversation téléphonique avec un interlocuteur. L’appareil dispose donc par défaut d’un système d’acquisition de la voix. Il est possible de lui associer un système de reconnaissance vocale. L’intérêt d’un tel système est de pouvoir piloter les applications du mobile à la voix et offrir ainsi une nouvelle manière d’interagir avec ces dernières. Ce système permet de compenser les contraintes liées au clavier et au dispositif de pointage moins aisé à utiliser sur ce type de support. Toutefois, il faut disposer d’API spécifiques permettant de tirer parti de ce nouveau type interaction. Plusieurs groupes travaillent actuellement sur ce type de projet.

Accéléromètre

L’accéléromètre est un autre système qui se retrouve de plus en plus souvent sur les smartphones. Il est actuellement exploité à partir d’applications conçues nativement pour les appareils. Il est tout à fait envisageable d’imaginer de futures API qui exploite cette possibilité. Des projets sont en cours et quelques plateformes bénéficient déjà d’une API Javascript (QtWeb Runtime).

Technologies web et applications natives

Depuis quelques années, il existe un débat autour de l’approche qui doit être faite lors de la réalisation d’une application sur mobile : Faut-il choisir de développer une application native ou bien une application web pour mobile ? Au-delà des querelles de clocher qui peuvent animer les groupes de discussion, il convient de bien garder en tête quels sont les avantages et les inconvénients des deux approches pour faire son choix. A terme, il est tout à fait imaginable d’envisager des applications qui pourraient être mixes pour bénéficier des avantages des deux approches.

Renvois bibliographiques

« Relever le défi du Web mobile » (François DAOUST, Dominique HAZAEL-MASSIEUX – EYROLLES)
« Les bonnes pratiques du web mobile », Site du W3C (http://www.w3c.org/2007/Talks/11-parisweb/#%281%29)
« dotMobi Mobile Web Developers Guide », Site de mobiForge (http://mobiforge.com)

Catégories : Blog, Méthodologie, Projet

Réussir une reprise de données

La reprise de données

La reprise de données constitue une des étapes les plus délicates au sein d’un projet d’implémentation d’un logiciel de gestion. En effet, elle doit souvent être réalisée très rapidement juste avant le démarrage d’un projet. De plus, elle est susceptible de reporter ce démarrage, en cas de problèmes bloquants, ce qui entraîne des coûts supplémentaires.

Or, il arrive très souvent que cette phase pose des problèmes, soit :

  • bloquants, du fait de données impossibles à reprendre,
  • consommateurs de charges supplémentaires non prévues (chez le prestataire en charge de la reprise et chez l’entreprise elle-même), en raison de la complexité de la reprise de données, qui a été identifiée trop tard par les acteurs en charge de cette dernière.

Ces problèmes sont principalement dus à l’analyse, qui n’est pas toujours réalisée de façon exhaustive. En effet, il est nécessaire lors de cette phase de mettre en parallèle tous les champs de données du logiciel source avec les mêmes champs au sein du logiciel de destination. Bien entendu, cela nécessite au préalable d’avoir identifié ces champs au sein du nouveau logiciel, soit via l’utilisation de champs existants, soit via la création de nouveaux champs. Or, pour cela, la compréhension du mode de fonctionnement du logiciel source est indispensable.

Jeux de tests

A partir du moment où cette analyse a été réalisée, il s’agit de réaliser en premier lieu un test avec un volume de données peu important (par exemple, 10 % des données à reprendre).

Cela permet d’identifier les principales anomalies, et de les corriger rapidement. Ce test doit avoir lieu au moins 1 à 2 mois avant la reprise complète des données. La date du test est déterminée en fonction du volume des données, ainsi que du délai prévisionnel de correction des anomalies rencontrées.

Ensuite, en fonction de l’importance de ces dernières, un second test peut être programmé.

Ces tests permettent notamment :

  • de s’assurer que la reprise des données se déroulera dans les meilleures conditions,
  • de prévoir précisément la durée de la reprise des données.

Dans le cas où des statistiques sont générées dans le logiciel source, il s’agit de procéder aux éditions correspondantes, puis de contrôler dans le logiciel de destination que les données restituées au sein des nouveaux états sont identiques.

Catégories : Blog, Consulting, Méthodologie, Projet

Un planning, mais pour quoi faire ?

Le planning !

Moto1

Qui dit planning dit tenue du planning. Voilà une charge de travail que je vois souvent supprimée ou trop fortement réduite dans bon nombre de projets. Mais au fait, à quoi ça sert un planning ?

Bien souvent le chef de projet (expérimenté) sur des projets de taille moyenne a en tête les tâches à mener et le besoin d’un planning ne se fait pas nécessairement ressentir.

Il est donc bien entendu possible de mener à bien un projet sans pour autant faire un planning.

Cela est principalement lié à la taille du projet et aux risques que l’on accepte de prendre sur le projet.

Dans la catégorie casse-cou (du genre saut du grand canyon à moto), il y a ceux qui réussissent et ceux qui y laissent leur peau. L’expérience montre que ceux qui réussissent sont justement ceux qui vont le mieux préparer et planifier leur action afin d’anticiper les risques et de les prévenir. Et bien dans les projets informatiques, c’est un peu pareil.

Les bonnes questions à se poser

En effet, l’élaboration d’un planning oblige à se projeter dans le futur, à réfléchir aux tâches à mener ce qui amène naturellement des questions :

  • untel a-t-il bien été prévenu des tâches qu’il va devoir réaliser ?
  • les ressources disponibles sont-elles suffisantes ?
  • les ressources sont-elles sous occupées, sur occupées ?
  • avons-nous bien l’ensemble du budget associé aux tâches ?
  • l’absence de X sur telle période a-t-elle été intégrée ?
  • pour mener telle tâche je vais avoir besoin de telle autre tâche qui n’était pas prévue ?
  • les délais impartis sont-ils réalistes ?
  • manque-t-il des tâches ?
  • etc…

Rien que l’exercice de création d’un planning est déjà riche d’enseignement en matière de gestion prévisionnelle d’un certain nombre de risques.

Un outil de communication

Le planning est aussi , il permet de partager la vision des travaux à réaliser avec l’ensemble des intervenants. Il permet à chacun de visualiser ce qu’il doit faire, de vérifier si des tâches n’ont pas été oubliées et si tout le monde a confiance dans le fait de mener à bien les tâches dans les délais prévus.

Avec le planning vient la gestion prévisionnelle des ressources et charges associées. Il est essentiel de pouvoir suivre régulièrement le taux d’occupation prévisionnel des ressources. Le problème ici est qu’il est souvent tentant pour bon nombre de personnes de ne pas vouloir connaître l’occupation prévisionnelle des ressources. A court terme, il est bien plus facile de ne pas se poser de questions sur les problèmes potentiels plutôt que de faire face à la réalité. Dans le meilleur des cas, les ressources concernées vont alerter. Bien souvent, il n’y a pas d’alerte par rapport aux surcharges de travail et ça dégénère car il est trop tard.

L’autre avantage du planning est qu’il permet de suivre l’avancement des tâches. En effet, tout dérapage est susceptible de remettre en cause la date de fin.

Le suivi du planning sera d’autant plus fréquent que l’on va approcher des phases critiques du projet telles que la mise en production par exemple. Plus on approche de la mise en production, plus chaque intervenant doit être en phase avec ses tâche et plus les dérapages potentiels doivent être rapidement détectés pour être corrigés. C’est un peu comme un avion qui s’apprête à atterrir et qui intensifie son échange avec la tour de contrôle à l’approche de la piste.

Enfin, il permet de visualiser immédiatement les impacts d’un dérapage (ou d’une avance) de tâche et de prévenir les personnes concernées.

Bien sûr cette gestion de planning à un coût qui est directement proportionnel au nombre de tâche, de ressources et à la fréquence de mise à jour.

Le planning est donc un instrument de pilotage essentiel et indispensable à partir d’une certaine taille de projets. Inutile de préciser que cet instrument n’est certainement pas Excel.

Catégories : Blog, Consulting, Projet

Comment réussir un cahier des charges fonctionnel ?

Du recueil des besoins au cahier des charges

Design d'interface

De notre point de vue, il est essentiel de bien identifier les acteurs qui vont participer à la rédaction du cahier des charges et auprès desquels il sera nécessaire de recueillir les besoins. Ces personnes seront choisies en fonction de leur capacité à identifier et à définir des besoins, ainsi qu’à se projeter dans l’avenir. Il s’agit de personnes qui ont une vue constructive des améliorations qu’il serait souhaitable d’apporter par rapport au fonctionnement actuel.

Bien entendu, ces utilisateurs représentatifs de leurs métiers devront pouvoir dégager le temps nécessaire pour non seulement exprimer des besoins mais également relire des comptes rendus de réunion, lire le cahier des charges et le valider.

Le recueil des besoins est pratiquement un métier en soi. En effet, les utilisateurs ont souvent besoin d’être guidés et la compréhension de leurs besoins doit être constamment vérifiée. Pour cela, diverses techniques peuvent être utilisées comme par exemple :

  • comparaisons par rapport à ce qui se fait chez des confrères,
  • workflow,
  • schémas,
  • maquettes d’écrans,
  • Etc.

Dans le cadre de l’expression des besoins, il arrive parfois que certains besoins exprimés soient contradictoires. Il est dans ce cas très utile de pouvoir disposer d’un représentant des utilisateurs qui dispose du pouvoir de décision en cas de désaccord entre les utilisateurs.

« Fonctionnel… »

Pour le démarquer des cahiers des charges techniques, le cahier des charges qui décrit les besoins est parfois également appelé « Cahier des charges fonctionnel ». Cette caractérisation ne doit cependant pas faire oublier tous les autres types de besoins.

En ce qui concerne les besoins, il ne s’agit pas bien entendu que des besoins fonctionnels. Il est essentiel de traiter également de nombreux autres besoins tels que par exemple les besoins en matière de performances, d’ergonomie ou de sécurité.

La qualité des écrits est bien entendu fondamentale dans le cadre de la rédaction du cahier des charges. Le cahier des charges se doit d’être limpide et sans ambigüité. Pour ce faire, il sera agrémenté d’exemples à chaque fois que possible. A ce sujet, AMJ recommande d’établir notamment une charte rédactionnelle qui servira de guide tout au long de la rédaction du cahier des charges.

La présentation générale est aussi importante, elle doit être jolie et agréable et donner envie au lecteur de lire le document. En aucun cas elle doit rebuter le lecteur.

Il ne faut pas non plus confondre le quoi et le comment. En effet, le cahier des charges tout en étant très structuré doit refléter le besoin métier de l’utilisateur (le quoi). Il ne doit pas exposer des solutions informatiques (le comment) mais des besoins fonctionnels ou métiers.

Les pièges à éviter

Certains pièges sont aussi à éviter, il est essentiel de ne pas non plus tomber dans le syndrome de la recherche de la cible fonctionnelle parfaite qui conduit souvent à définir une usine à gaz. Il convient donc de savoir procéder à des arbitrages lorsque nécessaire afin de ne pas trop complexifier les besoins.

Même s’il est important qu’il soit précis et relativement complet, le cahier des charges n’est pas non plus une spécification fonctionnelle détaillée et il convient de savoir s’arrêter au bon moment pour passer à sa validation.

La validation du cahier des charges est un acte très délicat mais particulièrement important. En effet, les cahiers des charges sont souvent des documents volumineux et peu agréables à lire. L’expérience montre qu’ils sont souvent validés sans être réellement lus ce qui peut s’avérer catastrophique pour le projet. Pour que les cahiers des charges soient lus les utilisateurs doivent disposer d’un temps de validation et la clarté du document contribue aussi largement à sa lisibilité. Le fait de solliciter les utilisateurs pour une signature manuscrite constitue un acte d’engagement fort qui contribue à une réelle validation.

Enfin, il ne faut toutefois pas confondre la réussite du cahier des charges avec la réussite d’un projet qui sont deux éléments liés mais très différents.

Catégories : Blog, Consulting, Projet