age d accueil du ebook Complet *** TODO : Couverture du document à restyler ***

Transcription

1 age d accueil du ebook Complet *** TODO : Couverture du document à restyler ***

2

3 Table des matières I. Introduction... 7 II. III. IV. A. Présentation de l auteur... 7 B. Remerciements... 8 C. Pourquoi ce guide?... 9 D. A qui s adressetil? E. Une règle simple : Gardez ça simple F. SharePoint au cœur du processus agile Votre mémo sur la méthodologie Vos besoins et SharePoint A. Qu est-ce que un besoin? B. Le besoin et le moyen, l histoire de SharePoint C. SharePoint, nécessairement le bon outil? D. SharePoint + vos besoins = compromis E. SharePoint et le mode «patch» F. Une question de point de vue La technique du User Story Mapping A. Principe de fonctionnement Les objectifs métiers Les profils Les activités Les histoires utilisateurs Les contraintes Un exemple complet Avec SharePoint B. Astuces méthodologiques Organiser les ateliers Bien identifier ses interlocuteurs C. Conclusion V. Préambule L accès à l information : le nerf de la guerre A. La recherche, le nouveau «buzz word» B. L accès à l information dans SharePoint Les langages de requête structurée... 43

4 2. Les langages de recherche Dans quels cas utiliser quel langage? VI. Visualiser le besoin VII. Décrire l information A. Information statique vs dynamique B. Identifications des types C. Hiérarchie des types D. Identification des métadonnées E. Gestion des types dans SharePoint VIII. Définir les relations entre les informations A. Rappel sur les cardinalités B. Gestion des relations dans SharePoint La colonne de type recherche Les métadonnées gérées Les ensembles de documents Les dossiers IX. Répartir l information A. Critères de répartition des informations B. Gestion de la répartition dans SharePoint X. Déterminer le sens de circulation de l information A. Le flux d information B. Gestion du flux d information dans SharePoint Scénario 1 : Stockage dans un site SharePoint. Accès dans le même site Scénario 2 : Site différent, même collection de sites Scénario 3 : Site différent, collection de sites différentes XI. Définir les points d accès A. Contexte d informations et cas d utilisation B. Gestion des points d accès dans SharePoint Informations non typées : Pages wiki Agrégation de données : Page composants WebPart Informations typées : Page de publication XII. Définir les critères de requête sur les informations A. Gestion des informations hiérarchiques dans SharePoint

5 XIII. XIV. XV. XVI. 1. Types de contenus Métadonnées gérées B. Gestion des requêtes relationnelles C. Gestion du multilinguisme dans la récupération d information Cas des métadonnées gérées Cas des propriétés de recherche avec SharePoint D. Gestion de la réutilisation des requêtes Réutilisation de requête CAML Réutilisation de requêtes KQL E. Gestion du ciblage de contenu dans SharePoint F. Gestion des requêtes conditionnelles Définir les comportements relationnels A. Mécanismes de connexion et filtrage dans SharePoint Composants basés sur le langage de requête structurée Composants basés sur le langage de recherche Définir l affichage A. Gestion de styles d affichages et conditions dans SharePoint Les transformations XSLT Le JavaScript et les gabarits d affichage Conclusion Annexes A. Annexe A - Créer des gabarits de page rapidement avec SharePoint B. Annexe B : Visualiser les requêtes CAML d un composant WebPart de requête de contenu C. Annexe C : Fonctionnement des propriétés de recherche sous SharePoint Processus de création D. Annexe D : Fonctionnement de la récupération de métadonnées gérées en CAML 158 E. Annexe E : Faire une requête sur une colonne de recherche en KQL F. Annexe F : Rendre la recherche SharePoint multilingue Rendre la propriété TaxCatchAllLabel «crawlable» Utiliser les synonymes SharePoint G. Annexe G : Créer des pages en dehors de la bibliothèque de pages dans SharePoint : attention au bug!

6 XVII. Liens A. Outils indispensable du petit analyste B. De la lecture de développeurs C. Petit cadeau pour les développeurs

7 I. Introduction A. Présentation de l auteur Franck Cornu, Spécialiste SharePoint Ingénieur en génie logiciel de formation, je travaille avec SharePoint depuis maintenant plus de 3 ans. J accorde beaucoup d importance aux méthodologies de travail et aux techniques de communication permettant à une équipe de produire des solutions finales bien conçues qui répondent aux besoins du client. Pour moi, la technique ne doit être que le résultat d une réflexion, la valeur d un système se mesurant principalement par la qualité de sa conception plutôt que par son nombre de lignes de code. À travers cette publication, je souhaite transmettre ma passion du métier et les connaissances que j ai pu acquérir tout au long de mes expériences en SharePoint pour vous guider dans vos analyses avec cette technologie.

8 B. Remerciements Avant tout chose, je tiens à remercier les personnes suivantes pour leur collaboration et commentaires : Mathieu Roy pour la traduction et les commentaires apportés Geneviève Mérat et Natasha Sirois pour la publication et mise en forme Philippe Ouellette pour sa bonne humeur, son expérience et ses précieux commentaires Frédéric Blanchet pour m avoir inspiré l idée d entreprendre cette publication Samuel Gremaud et Laurent DuBerger pour la révision et l optimisation des textes Émie Ratté pour le design Toute l équipe Dynamite GSoft pour leur expertise, relecture et commentaires GSoft au complet ;)

9 C. Pourquoi ce guide? Ce guide a été créé pour démontrer que tout ce qui est fait dans SharePoint (toutes versions confondues) doit être issu d un travail de réflexion sur un besoin à combler en connaissance des concepts et contraintes de la plateforme. Trois constats inter-reliés ont motivé sa rédaction: Premièrement, les nouvelles fonctionnalités de SharePoint 2013 placent la recherche au centre de l accès à l information. Cette nouvelle stratégie fait réagir et mérite d être expliquée. Ensuite, sur bon nombre de projets, l étape d analyse, de conception et d architecture d information (lorsque présente) est souvent négligée au profit d une implémentation précipitée. Enfin, dans le cadre de chaque solution SharePoint, il est primordial d être en mesure de comprendre pourquoi certaines fonctionnalités sont privilégiées par rapport à d autres. Au terme de la lecture de ce guide, vous devriez être en mesure de comprendre la réflexion logique adoptée pour choisir telle ou telle solution en connaissance des possibilités de l outil. Par exemple, vous serez en mesure de répondre à la question suivante : «Pourquoi ce WebPart de requête de contenu a été utilisé dans une page donnée plutôt qu un autre composant ou même qu un développement personnalisé?» Nous avons trois réponses possibles: A. J ai lu sur un forum ou un blog que ce composant offrait plein de possibilités, je vais donc l essayer. B. J ai compris les mécanismes et concepts en jeu dans SharePoint et suis certain que ce composant est la solution la plus adaptée à mon besoin. C. Je suis une fougère (vous pouvez arrêter de lire ici dans le cas présent). Il y a fort à parier que la réponse la plus appropriée sera «B»! Ce guide vous accompagnera vers cette conclusion. Ma vision du métier : Concevoir une application sous SharePoint (intranet, extranet, ) équivaut ni plus ni moins à faire de l ingénierie logicielle classique, mais dans un cadre d outil existant auquel il faut s adapter. C est cette façon de voir le métier que je vous exposerai dans ce guide. ð Ce que vous y trouverez :

10 Un schéma de réflexion logique pour concevoir vos applications, du besoin jusqu à l implémentation, en connaissance des possibilités et limitations de SharePoint (selon les versions). L explication de ces différentes solutions dans l outil lors de la conception d une solution. Des exemples concrets. ð Ce que vous n y trouverez pas : Des solutions toutes faites. Comment configurer dans le détail une fonctionnalité ou un composant en particulier. Le Web regorge d articles sur le sujet! (Cependant, vous trouverez à la fin du document des annexes techniques appuyant ou complétant certains points de méthodologie). À noter : Les versions de SharePoint abordées dans ce guide sont de 2007 à 2013, en passant par Office 365. Vous verrez que l approche demeure fondamentalement la même dans tous les cas, seules les possibilités changent entre les versions.

11 D. A qui s adressetil? Ce guide s adresse à toute personne qui possède des notions de base sur SharePoint (peu importe la version) et qui souhaite comprendre les étapes de conception d un projet liées à cette technologie et les contraintes inhérentes à celles-ci. Ce guide s adresse principalement aux profils suivants : Les analystes fonctionnels, architectes d informations et développeurs qui mettent en place un projet SharePoint. Ce guide leur permettra : o o D adopter une démarche cadrée d analyse fonctionnelle et de conception logicielle adaptée à SharePoint en se posant les bonnes questions. De comprendre les mécanismes de SharePoint et d identifier les solutions optimales disponibles dans l outil en réponse à des situations connues (pour la plupart) Les décideurs en informatique, qui désirent conjuguer des concepts «métier», compréhensibles par tous à des solutions technologiques dans SharePoint. Ils pourront : o o Identifier clairement les besoins avant d embarquer dans SharePoint. Comprendre les étapes de conception d un projet SharePoint et les contraintes associées à celui-ci. Si vous ne connaissez pas du tout SharePoint, je vous recommande de vous familiariser avec cet outil par le biais de formations, de publications ou de programmes de mentorat. La lecture de ce guide vous paraîtra plus facile lorsque vous aurez acquis quelques notions de base. E. Une règle simple : Gardez ça simple Peut-être avez-vous déjà constaté que la plupart des projets SharePoint se ressemblent très fortement dans le principe (si ce n est pas le cas, je vous expliquerai par la suite). Par conséquent, il est important de garder en tête les besoins réels des utilisateurs et de ne pas se laisser emballer par les nombreuses possibilités techniques de l outil lors de la phase de conception. C est un peu le piège SharePoint qui fait passer la phase d analyse au second plan, favorisant une méthode empirique. À éviter : «Dites-moi ce que SharePoint peut faire et je vous dirais ce dont vous avez besoin» Lorsqu on débute un projet SharePoint, il est important de se poser les bonnes questions et d appliquer un cheminement logique de réflexion sur la base de

12 questions fonctionnelles simples, intervenant dans le cadre du processus de conception du projet. En parallèle, il est nécessaire de comprendre certains mécanismes propres à SharePoint. Vous serez ainsi en mesure d ajuster cette architecture, car n oublions pas que nous devons nous adapter à l outil dans tous les cas. Ce document propose en quelque sorte un amalgame entre ce que SharePoint peut faire, l expression des besoins et la capacité à les modéliser et ce, de manière simple et concise. F. SharePoint au cœur du processus agile Une bonne façon de rester le plus simple possible est d adopter une gestion de projet en mode agile, comme cela sera le cas dans ce guide. Appliquez cette réflexion sur l histoire utilisateur sur laquelle vous travaillez, vous gagnerez en efficacité plutôt qu en vous attaquant à la globalité. N oubliez pas qu un projet SharePoint est aussi un projet d ingénierie logicielle à laquelle les méthodes agiles se prêtent très bien (attention, je ne parle ici que de la partie applicative). Note importante Le présent guide propose une approche personnelle de conception d applications SharePoint basée sur l expérience. Loin de prétendre être l unique référence, ni même être totalement exhaustive, elle se concentre sur des points essentiels. Vous êtes bien sûr libres de les suivre en tout ou en partie. Des modèles de fichiers et exemples seront mis à disposition à la fin de cette série pour vous permettre de réaliser vos analyses efficacement avec SharePoint. Bonne lecture!

13 II. Votre mémo sur la méthodologie La méthodologie complète se présente de la manière suivante. Tout au long du document je m appuierais sur un besoin concert pour illustrer les différents concepts à chaque étape. Il est intéressant de noter que toutes les étapes ne sont pas obligatoires. Voici donc votre mémo sur la méthodologie d analyse fonctionnelle faite sur une fonctionnalité seule : Définir le besoin Quel est votre besoin? Besoin Exemple : Visualiser le besoin Décrire l information Définir les relations entre les informations Répartir l information Déterminer le sens de circulation de l information Définir les points d accès À quoi ressemble-t-il visuellement? Quels sont les types d informations s y rattachant? Quelles sont les relations entre ces types? Comment sont-ils répartis logiquement dans la structure SharePoint? Quel est le sens de circulation ces informations dans cette structure? deux? Était-ce plutôt un flux de lecture, d écriture ou les Dans quel scénario SharePoint vous trouveriezvous? Où se trouvent les points d accès à ces informations dans cette structure? Sous quelle forme? Parmi tous ces points d accès Déterminer les critères de requête sur les informations Quels sont les conditions de récupération de ces informations? Devaient-elles correspondre à la réalité à l instant «t» dans SharePoint? Doivent-elles être triées?

14 Possèdent-t-elles des contraintes de récupération hiérarchiques? Impliquent-t-elles des relations entre les types d informations? Impliquent-t-elles une récupération supportant le multilinguisme? Les requêtes doivent-elles être réutilisables? Définir les comportements relationnels Quelles sont les contraintes relationnelles et les connexions entre ces informations? Quelles sont les informations à afficher aux utilisateurs? Définir l affichage Devaient-elles être affichées de manière groupée ou unique? Si de manière groupée, devait-on les dissocier visuellement lors de l affichage? Implémentation Si vous avez répondu à toutes ces questions et suivi les solutions offertes par SharePoint selon les réponses, vous avez résolu votre besoin de manière optimale!

15 III. Vos besoins et SharePoint The value of an idea lies in the using of it. Thomas A. Edison La première étape dans tout projet, peu importe sa nature, est de définir son utilité en réponse à un ou plusieurs besoins. En effet, si un système ne répond à aucun besoin, alors à quoi peut-il bien servir? Figure 1: Une gestion de projet sans analyse (source non identifiée) Cette étape est, à mon sens, la plus importante et ne doit en aucun cas être négligée. Si vous arrivez à identifier précisément le travail à faire correspondant à la réalité des attentes (et donc la résolution du besoin), alors vous aurez complété la moitié de votre projet. Toutefois, il est souvent difficile de formuler un besoin, aussi bien du côté d un client que d un fournisseur, car il y a parfois décalage entre ce qui est dit et ce qui est compris. Heureusement, il existe des outils et techniques permettant de réaliser cette étape efficacement.

16 Situons-nous dans le contexte d un fournisseur devant répondre à une demande d un client. La méthode que je présente ici est basée sur les méthodologies agiles, dont il sera important d en comprendre les concepts. Pour en savoir plus sur la méthodologie agile, visitez le scrum.org. A. Qu est-ce que un besoin? Tout d abord, commençons par résumer ce que représente un besoin dans le cadre d un système informatique : Dans le cadre d un système, un besoin représente la traduction d une nécessité fonctionnelle constituant un gain relatif pour la personne qui en fait l expression. Gardez-cela à l esprit, lorsque l on parle de besoin, on parle nécessairement de VALEUR. La valeur peut être soit tout fait objective ou, au contraire, très subjective. Néanmoins, elle doit toujours motiver le besoin. Un besoin n est lié à AUCUNE technologie. Ce genre d exercice ne devient donc pas obsolète dès lors que vous changez de technologie. Les solutions peuvent changer, les besoins, eux, restent. B. Le besoin et le moyen, l histoire de SharePoint Faisons d abord un constat : au fur et à mesure des différents projets SharePoint sur lesquels j ai eu l occasion de travailler, j ai souvent constaté que le moyen conditionne le besoin. En effet, certaines personnes réfléchissent inconsciemment de la manière suivante : «J ai vu, à un endroit X ou Y, que SharePoint offrait telle ou telle fonctionnalité, il faut donc que je trouve un besoin pour pouvoir l exploiter» Une sorte de soulagement de conscience d avoir utilisé ladite fonctionnalité disons On peut aisément comprendre cette réaction, car en acquérant SharePoint, on obtient un produit complet avec son lot de fonctionnalités et cela peut s avérer frustrant de ne pas pouvoir l utiliser à ses pleines capacités. Un directeur TI n appréciera pas vraiment que la plupart des possibilités du logiciel qu il s est procuré ne soient pas exploitées. Certes, cela ne signifie pas que nous devons nous créer des besoins en fonction de l outil (ou comment faire rentrer un carré dans un rond). C. SharePoint, nécessairement le bon outil? Pour comprendre ce phénomène, il est intéressant de se pencher sur la manière dont SharePoint est généralement amené en entreprise. Très souvent, il est issu d un

17 choix technologique imposé dès le début d un projet sur la base de grands domaines génériques comme : La gestion électronique de documents La gestion de contenu Les réseaux sociaux d entreprises Etc. D un point de vue macroscopique, SharePoint se positionne comme l outil idéal dans ces domaines, présentés par l intermédiaire de plaquettes marketing (Microsoft ou autres firmes expertes), d articles de blogues, etc., qui vous donnent un aperçu ce de que pourrait vous amener l outil dans un contexte (trop) souvent générique*. Le problème est que ce choix est souvent fait avant même de connaître les besoins réels des utilisateurs. En effet, qui vous garantit que SharePoint est le bon outil pour vos besoins? Pourquoi ne pas utiliser un autre outil, ou même une solution entièrement développée de A à Z? Si vous vous trouvez dans cette situation, vous faites un pari en faisant confiance à ce que vous avez pu voir. Ceci n est pas nécessairement mauvais, mais il vous faudra observer quelques règles * Préférez la lecture d articles orientés «Business» ou présentant des cas d utilisation pratiques pour vous donner une idée de ce que SharePoint peut accomplir et éviter les mauvaises surprises ;). D. SharePoint + vos besoins = compromis Il faut bien comprendre que le choix de SharePoint peut aussi bien vous faire gagner du temps que de vous en faire perdre. Tout est une question de besoins. En effet, SharePoint, à l inverse de solutions entièrement personnalisées (où le choix d une technologie en début de projet avant même l analyse de besoins n impactera que très peu la réalisation), ne pourra répondre à 100% de vos besoins. Il sera question alors de compromis. Le besoin doit conditionner le moyen, jamais l inverse. Intervient alors une zone d équilibre qui représente les compromis faits entre les possibilités de l outil et vos besoins réels. Voici une illustration de cette zone d équilibre. Le but est de se trouver aux alentours du croisement entre ce que SharePoint peut faire et ce que vous avez réellement besoin. ð Si vous apportez beaucoup de modifications à l outil de base par des développements personnalisés, c est peut-être que SharePoint n est pas le bon système ou que vous ne traitez pas le besoin fondamental en arrière.

18 ð En revanche si vous vous efforcez d utiliser toutes les fonctionnalités de SharePoint, alors peut-être vous détournez-vous de vos besoins réels et êtes-vous en train de développer une solution non-adaptée. Éloignement du besoin réel Zone dūéq uilibr e Détour nement du produit original Figure 2: Zone d'équilibre Besoins/Moyens De mon avis personnel, une des raisons de la non-adoption de la plateforme par les utilisateurs est souvent liée à une implémentation trop éloignée de la réalité de leur travail quotidien. Il y a souvent une grosse différence entre les plaquettes commerciales de Microsoft, les articles de blogs théoriques et la réalité des utilisations de l outil dans le milieu professionnel. En résumé, voici en quoi devrait idéalement consister les étapes d un projet SharePoint:

19 Orientée Besoins Carnet de produit Histoire utilisateur Développement incrémental L idéal Analyse des besoins Choix de la technologie Analyse fonctionnelle Réalisation Livraison User Story Mapping SharePoint Orientée SharePoint Légende Livrable d entrée/sortie Orientation Figure 3: Processus idéal de gestion de projet avec SharePoint Techniques/Outils

20 E. SharePoint et le mode «patch» Comme nous l avons vu précédemment, le choix technologique, bien qu il ne doive pas être effectué à cet instant, est très souvent imposé en début de projet, encore plus avec SharePoint. Avant la réalisation, il est très rare qu un client vous arrive avec déjà un carnet de produit priorisé et des besoins formalisés. La plupart du temps, il vous arrive avec une liste de «Quoi», sans le «Qui» ni le «Pourquoi» : Par exemple, voici des requis pour le projet «Mon super Intranet» Bottin d entreprise Petites annonces classées Le mot du président Moteur de recherche Bilinguisme Site de gestion des projets Etc On constate qu il est impossible de donner ça tel quel à une équipe de réalisation sous peine de grosses divergences d attentes ð Note : Ceci est un cas extrême. Voici un exemple d étapes d un projet avec SharePoint que l on rencontre fréquemment :

21 Figure 4: Processus réel de gestion de projet SharePoint Prélivraison Postlivraison La vraie vie Choix de la technologie SharePoint Liste de fonctionnalités Orientée SharePoint Précisions sur les fonctionnalités Réalisation Manque de détails fonctionnels Livraison «Patch» ou DDC Légende Livrable d entrée/sortie Orientation Techniques/Outils

22 On observe généralement deux phases distinctes: La pré-livraison Intervenant pendant la réalisation du projet. La liste des fonctionnalités données est souvent trop floue et bien souvent orientée vers la technique. L équipe de développement doit donc : Régulièrement demander au client des précisions sur la fonctionnalité à implémenter (fonctionnement, détails, etc ) ce qui entraîne des allers-retours très couteux en temps (surtout si le client est peu disponible). Implémenter la fonctionnalité selon ses propres choix fonctionnels, le risque étant que celles-ci ne correspondent pas au besoin. La post-livraison Intervenant après la livraison du projet. Les fonctionnalités ne correspondent pas à la réalité des utilisateurs. Ici, deux causes possibles : o o Les fonctionnalités n ont pas été assez détaillées par le client et les choix de l équipe de développement ne correspondent pas aux attentes des utilisateurs. Les utilisateurs eux-mêmes n ont pas étés impliqués suffisamment dans le processus de développement. Manque de feedback pour ajuster les besoins et donc obligation de corriger. Il sera donc indispensable d appliquer des «patchs» successifs d améliorations pour correspondre à la réalité d utilisation ou aux spécifications. F. Une question de point de vue Soyons réalistes, plus les entreprises sont volumineuses, plus les habitudes de gestion ont la vie dure. Il peut donc sembler utopique de supposer un changement radical de processus ou de méthodologie. Toutefois, il est possible de trouver une alternative entre la vision idyllique et la réalité du déroulement d un projet SharePoint. Cependant, il va falloir batailler quelque peu ;). Ne nous le cachons pas : faire une bonne définition de besoins prend du temps, beaucoup de temps, et celui-ci n est souvent pas inclus dans les budgets. De même, cela demande beaucoup d implication du coté de votre client. Il va donc falloir lui expliquer plusieurs choses :

23 L Qu il faudra reprendre du temps au début de son projet pour «reformater» ses besoins en quelque chose de plus exploitable pour les équipes de développement. Tout le temps requis pour faire cela sera pris sur le temps de réalisation potentiel inclus dans son budget si il ne l a pas prévu. Que lui ou ses équipes devront être disponibles et impliqués pour définir les besoins et en expliquer le fonctionnement. J Que le temps alloué à cet exercice permettra de réaliser une solution qui répondra PRÉCISEMENT à ses besoins impliquant moins de modifications futures et une meilleure vision globale. Le temps «perdu» au début vous fera au final économiser.

24 Figure 5: Processus alternatif de gestion de projet SharePoint Orientée Besoins Carnet de produit Histoire utilisateur Développement incrémental L alternative Choix de la technologie Liste de fonctionnalités Reformatage et analyse des besoins Analyse fonctionnelle Réalisation Livraison SharePoint Orientée SharePoint User Story Mapping Orientée SharePoint Légende Livrable d entrée/sortie Orientation Techniques/Outils

25 IV. La technique du User Story Mapping Comment définir des besoins dans le cadre d un nouveau projet? Aperçu du chapitre Définir et organiser ses besoins : pas toujours évident! Le but de ce chapitre est de vous démontrer l importance d un tel exercice dans le cadre de solutions d'entreprises sous SharePoint et de vous guider dans l expression des besoins de vos utilisateurs. L utilisation d'outils dynamiques tels que la technique de User Story Mapping et autres techniques de communications pourront vous aider à organiser un carnet de produit de manière efficace et mener à une définition de besoins structurée et exploitable facilement pour l'analyse fonctionnelle. Notions clés ü ü ü ü Comprendre les attentes et enjeux lors de cette étape Apprendre une démarche simple permettant de définir un besoin Organiser et structurer des besoins dans le cadre de projet agile Les exploiter dans le cadre de cas de solutions d entreprises SharePoint

26 Cette technique est adaptée à l identification d histoires utilisateurs et donc à la définition d un carnet de produit. Elle est généralement réalisée en plusieurs étapes sous forme d ateliers. Elle peut être réalisée de manière «Manuelle» (avec post-its et crayons) ou de manière électronique (SpecLog est un très bon outil, mais payant Tout d abord, si vous souhaitez en savoir plus sur les techniques de User Story Mapping vous pouvez lire les articles suivants, le but n étant pas de repasser sur la méthode au complet mais plutôt de savoir comment en tirer parti dans le cadre de projets SharePoint Le principe est assez simple. Au lieu de définir un carnet de produit sous forme de liste, comme il est coutume de faire, la définition se fait ici sous forme de «carte». Les avantages sont multiples : Les besoins sont orientés sur les rôles et les responsabilités o Facilite l expression des besoins car ceux-ci sont mis dans un contexte Offre une vue d ensemble d un système o Facilite la priorisation Révèle les relations entre les besoins Met de l avant les chaines de valeurs de la solution A. Principe de fonctionnement Voici la manière de lire une User story Map : La User Story Map se lit de haut en bas. Le point d entrée se situe à la définition des objectifs métiers pour finir par la spécification des histoires utilisateurs (priorisées

27 du haut vers le bas). Des contraintes peuvent également s ajouter à travers les niveaux hiérarchiques. Une question fondamentale est associée à chaque niveau hiérarchique, vous amenant à définir les éléments qui le constitueront. L axe horizontal représente en théorie la chronologie des actions effectuées par un profil. Il arrive que celui-ci puisse être négligé compte tenu du temps nécessaire à sa réalisation et surtout, il n apporte pas fondamentalement de valeur pour la suite. 1. Les objectifs métiers Les objectifs métiers consistent simplement en la justification du système ou de l application à développer. Il s agit en quelque sorte de la ligne directrice de votre solution. Par exemple, une solution d entreprise SharePoint pourra vouloir améliorer la productivité de ses employés ou forger un esprit d équipe, etc. Améliorer la productivité Renforcer l esprit d équipe 2. Les profils Les acteurs ou profils sont les utilisateurs de votre système. Attention ici un profil N EST PAS une personne physique. En ce sens qu une personne physique peut posséder plusieurs profils. Voici un exemple. M. Martin est directeur de projet chez Contoso.inc et utilise l intranet. Voici les profils que M. Martin pourrait détenir dans l intranet de Contoso.Inc Gestionnaire de contenu Utilisateur lambda Directeur de projet Utilisateur lambda: Il s agit de toute personne connecté sur l intranet peu importe son appartenance à d autres rôles. En résumé ce que tout le monde peut faire sur l intranet. Directeur de projet : Le rôle principal de M. Martin, son métier finalement. Gestionnaire de contenu : Personne pouvant contribuer au contenu de l intranet Etc..

28 Il est possible d avoir autant de profils que l on souhaite! 3. Les activités Une activité est un regroupement d actions que peut faire un profil particulier. Cet élément sert davantage à des fins d organisations d histoires utilisateurs pour permettre une meilleure visibilité des actions et rôles de chaque profil. Généralement, on retrouvera souvent le verbe d action «Gérer» dans ces activités Exemple : Mr Martin, dans son rôle de directeur de projet, aura très certainement des tâches liées à la gestion de projets. Ainsi, il est possible d isoler une activité à part entière. De même qu un utilisateur lambda pourra visualiser les informations contenues dans ces projets. Utilisateur lambda Directeur de projet Voir le contenu Gérer les projets 4. Les histoires utilisateurs Il s agit de la partie la plus importante de l outil, celle où l on définit le besoin final exprimé par le demandeur et sur laquelle le fournisseur s engagera à sa réalisation. Pour être suffisamment complet, un besoin doit, en théorie, comporter les notions suivantes : Qui? (Obligatoire): Qui est concerné? Cette information vous est donnée directement par le profil réalisant l action. Quoi? (Obligatoire) : Quelle est la nécessité? Habituellement, il s agit souvent d un verbe d action. Pourquoi? (Optionnel): Quel gain procure la réalisation de cette action? La justification du besoin. Note : le demandeur est le seul juge de sa pertinence. En d autres termes, vous n avez pas à remettre ses besoins en cause ni même d en proposer même si vous trouvez que ceux-ci ne sont pas légitimes. Astuce : Si à première vue, vous doutez fortement de la justification que votre client vous apporte, je vous conseille la «règle des cinq pourquoi» qui est très