Avant tout chose, je tiens à remercier les personnes suivantes pour leur collaboration et commentaires :

Transcription

1

2

3

4 a. 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 pour la traduction 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 Laurent DuBerger pour la révision et l optimisation des textes Toute l équipe Dynamite GSoft pour leur expertise, relecture et commentaires GSoft au complet b. 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:

5 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 outils existants auxquels 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 : 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. a. A qui s adresse-t-il? 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 :

6 Les analystes fonctionnels, architectes d informations et développeurs qui mettent en place un projet SharePoint. Ce guide leur permettra : 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 : 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. b. Une règle importante : 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 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.

7 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. c. 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. À très bientôt pour la suite!

8

9

10 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. Situons-nous dans le contexte d un fournisseur devant répondre à une demande d un client.

11 Partie 1 : Vos besoins et SharePoint 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 Qu est-ce qu 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. 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 à sa pleine capacité. 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).

12 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 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. 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 (ou le choix d'une technologie en début de projet avant même l'analyse des besoins qui 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.

13 ð 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. ð 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:

14 Figure 3: Processus idéal

15 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 :

16 Figure 4: La vraie vie

17 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 celle-ci ne corresponde 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 : 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. 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 se 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.

18 Il va donc falloir lui expliquer plusieurs choses : 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. 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.

19 Figure 5 : L alternative

20 Partie 2 : La technique du User Story Mapping 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 Facilite l expression des besoins car ceux-ci sont mis dans un contexte Offre une vue d ensemble d un système Facilite la priorisation Révèle les relations entre les besoins Met de l avant les chaines de valeurs de la solution

21 Principe de fonctionnement Voici la manière de lire une User story Map :

22 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 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. 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 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

23 Etc.. Il est possible d avoir autant de profils que l on souhaite! 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 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.

24 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 efficace pour recherche de la cause fondamentale d un besoin ou problème (attention, ne le faites pas à chaque fois, cela peut devenir long). Pour vous aider à formaliser votre besoin, vous pouvez toujours vous servir de ce modèle de phrase : En tant que «Qui» je souhaite «Quoi» afin de «Pourquoi». D expérience, la partie «Pourquoi» est très souvent négligée, jugée rébarbative et coûteuse en temps (en effet, définir des besoins peut être long et tous les justifier encore plus). C est pourquoi on remonte généralement la notion de gain à des niveaux plus haut comme par exemple sur le système au complet ou bien sur les activités en ne gardant simplement que le «Qui» et «Quoi» pour le niveau le plus granulaire de besoins. Vous noterez que le «Comment?» n apparait pas ici pour la simple et bonne raison que c est le sujet de la prochaine partie, après l analyse des besoins : l analyse fonctionnelle. L ensemble des besoins forme ainsi le carnet de produit ou «backlog», représentant la liste priorisée des fonctionnalités à développer pour le système. Exemple: Utilisateur lambda Directeur de projet Voir le contenu Gérer les projets Voir les infos d un projet Ajouter un projet Supprimer un projet Rechercher un projet

25 Note : Il est possible de rassembler les actions «CRUD» (Create, Read, Update, Delete) dans une seule et même histoire utilisateur (ex : CRUD un projet). Cependant rappelez-vous que vous vous engagez à livrer cette fonctionnalité au complet à la fin de votre sprint. Estimez donc bien la granularité de vos histoires utilisateurs. Remarque : Un besoin peut se retrouver sous deux profils différents. Dans ce cas, il faut impérativement que le comportement soit différent selon l acteur qui réalise l action. Exemple : Utilisateur lambda Directeur de projet Voir le contenu Gérer les projets Voir les infos d un projet Ajouter un projet Rechercher un projet Supprimer un projet Rechercher un projet Dans cet exemple, cela implique que rechercher un projet pour un utilisateur sera différent de la recherche de projet pour un directeur de projet. Les contraintes Il est impératif de prendre les contraintes en considération lors de la réalisation d un besoin. Celle-ci peut être de nature technique, fonctionnelle ou humaine. Elle peut intervenir à plusieurs niveaux : Objectifs métiers Accès à l externe requis Profils Utilisateurs novices

26 Activités Contenu confidentiel ð Vous remarquerez qu il n y a pas de contrainte au niveau de l histoire utilisateur. En effet, au niveau de l histoire utilisateur, on parlera plutôt de critères d acceptation représentant les étapes de l analyse fonctionnelle. Par convention, on modélisera une contrainte au-dessus de l élément sur lequel elle s applique. (une contrainte pèse sur un élément...) Un exemple complet Accès à l externe requis Améliorer la productivité Renforcer l esprit d équipe Utilisateurs novices Utilisateur lambda Directeur de projet Gestionnaire de contenu Contenu confidentiel Voir le contenu Gérer les projets Voir les infos d un projet Ajouter un projet Supprimer un projet Flux de données Rechercher un projet

27 Avec SharePoint Dans le cadre de SharePoint, la User Story Map possède plusieurs avantages : Elle constitue votre gouvernance applicative. En effet, cette technique étant centrée sur les rôles et responsabilités, elle vous permet de répondre à la question «Qui fait quoi et comment dans la solution?». Elle révèle les flux de données entre les besoins permettant d identifier un scénario d implémentation SharePoint lors la phase d analyse fonctionnelle (notion expliquée dans les parties suivantes). Elle vous indique implicitement les permissions liées aux contenus qui seront manipulés à travers les différents besoins. (exemple pour le type de contenu «Projet» : Utilisateur lambda se verra accorder les droits de lecture seule alors qu un directeur de projet ceux de contribution). De même les profils peuvent se manifester par des groupes de sécurité dans SharePoint. Astuces méthodologiques Ces quelques astuces méthodologiques vous permettront d éviter certains pièges du début. Organiser les ateliers Une définition de besoins par la technique de User Story Mapping peut être longue. C est pourquoi, il est intéressant de procéder par ateliers successifs regroupant un nombre restreint de personnes. Typiquement, une session d atelier doit se concentrer sur maximum d une à deux notions de la technique. Si vous essayez d attaquer toutes les notions de front, d expérience, vous perdrez vos interlocuteurs De même, n excédez pas 4 heures par session. Au-delà de ça, la productivité diminue fortement. Règles à respecter lors d un atelier : Ne jamais proposer, simplement écouter et challenger : votre rôle ici est de guider votre client, pas de l influencer dans ses besoins. Ne jamais parler de SharePoint : découlant directement du point #1.

28 Voici un exemple de planification d ateliers éprouvée : On retrouve généralement trois types d ateliers # 1 : Identification des acteurs et des objectifs. # 2 : Identification des activités à partir de tâches en vrac # 3 : Transformation des tâches en histoire utilisateur. Note : chaque type d atelier peut être décliné en plusieurs sessions selon la taille du projet. Type Atelier 1 Découverte du projet Titre Durée Lieu Type Atelier 1 Découverte du projet 4 heures <Lieu> Participants Objectifs Matériel nécessaire ð Expliquer la méthode de «User Story Mapping» pour la définition de besoins (30 min) ü Ensemble de postit de couleur ð Identifier le ou les grands objectifs métiers pour la solution (Réflexion libre 5 minutes) Si l'on vous demandait les objectifs que vous souhaiteriez atteindre avec la solution, quel seraient-ils? Exemple : Que les utilisateurs accèdent rapidement à leur informations, gèrent mieux leur projets, etc. ð Identifier les acteurs concernés (Réflexion libre 5 minutes) Quels seront les types de personnes concernées par la solution? Exemple : Département RH, Finances, Utilisateurs basiques, administrateurs, gestionnaires, etc ü Logiciel SpecLog ü Rétroprojecteur ü Tableau blanc et crayons effaçables

29 Type Atelier 2 Définition des tâches et activités Type Atelier 2 Définition des tâches et activités Durée Lieu Participants 4 heures <Lieu> Objectifs Matériel nécessaire ð Définir les tâches des utilisateurs dans l intranet Listez, en vrac, les tâches qui seront réalisées par les profils identifies. Exemple : Les gestionnaires peuvent créer un projet, ajouter des personnes au projet, etc. Les utilisateurs consultent les dernières nouvelles de ð Définir les regroupements de tâches sous forme d activités Parmi ces tâches, peut-on créer des regroupements définissant une activité plus globale pour un utilisateur? Exemple : Les gestionnaires peuvent gérer un projet, les utilisateurs peuvent consulter de l information. ü Ensemble de postit de couleur ü Logiciel SpecLog ü Rétroprojecteur ü Tableau blanc et crayons effaçables ð Définir l ordre des tâches dans l activité pour constituer une chaîne d actions chronologique Pour chaque activité, il y a-t-il un ordre particulier dans lequel sont réalisées les tâches pour la compléter? Exemple : La gestion de projet par un gestionnaire inclut en premier la création du projet, l assignation et ensuite le suivi.

30 Type Atelier 3 Définition des histoires utilisateurs Titre Durée Lieu Type Atelier 3 Définition des histoires utilisateurs N x 4 heures <Lieu> Participants - Coach agile - Un seul responsable fonctionnel pour tous les profils identifiés OU Un responsable par «catégorie» de profils (ex : découpage par service RH, Finances, etc ) Note : Si un découpage par service de l entreprise est envisagé, le nombre d ateliers pour cette étape sera égal au nombre de services N avec à chaque fois un responsable des besoins. (N x 4heures) Objectifs Matériel nécessaire ð Définir les histoires utilisateurs découlant de chacune des tâches Pour chacune des tâches identifiées dans une activité, est-il possible de découper en plusieurs actions plus granulaires ou spécifiques? Exemple : Pour la tâche de création de projet, il faut que je sois capable de créer d abord un projet de type A au minimum. Pour la tâche de suivi de projet, il me faut impérativement au minimum les heures facturables sous forme de tableau de bord. ü Ensemble de postit de couleur ü Logiciel SpecLog ü Rétroprojecteur ü Tableau blanc et crayons effaçables Bien identifier ses interlocuteurs Lorsque vous entreprenez de réaliser une définition de besoins, il est important avant toute chose de bien choisir vos interlocuteurs qui seront avec vous lors des ateliers. Pour cela, il va falloir identifier les «responsables produits». En méthodologie agile, un responsable produit est la personne garante des besoins présents dans un carnet de produit. Par conséquent, un responsable produit doit : Connaître parfaitement le métier pour être en mesure de l expliquer aux analystes fonctionnels (les comportements, détails, etc...) Être en mesure de prioriser et choisir les fonctionnalités en fonction de leur coût et de leur valeur. Pour de petits projets, cela est relativement maintenable, une même personne est capable de disposer de ces deux compétences. En revanche, dans le cas de plus gros

31 projets, il est rare (et dangereux?) de laisser la définition et responsabilité des besoins à une seule et unique personne. Pour cela, il peut être intéressant de «découper» le carnet de produit principal par domaines métier avec un responsable de produit pour chacun, laissant ainsi la connaissance des besoins aux personnes pertinentes. La priorisation finale et la décision finale revienent au responsable produit principal. Autre élément important : le nombre d interlocuteurs. Ne jamais dépasser 3 interlocuteurs dans un atelier. Pourquoi? Pour éviter tout simplement les «combats de coq» ou chacun essaie de prouver à l autre comment cela doit marcher et prouver par A+B que sa fonctionnalité est plus importante. En clair, au-dessus de 3 interlocuteurs, vous risquez de perdre beaucoup de temps en discussions inutiles. Par exemple, ces personnes peuvent être un décideur, un soutien au décideur, et l analyste d affaires qui anime l atelier.

32

33