Exécutive Manager des Systèmes d Informations Promo page 3 -

Transcription

1

2

3 REMERCIEMENTS Nos remerciements vont en priorité à notre propre entourage, nos conjoints et nos enfants ainsi que nos amis, qui nous ont soutenus et encouragés, particulièrement dans les moments difficiles. Nous remercions également Jean-François JAGODZINSKI, notre tuteur Entreprise, animateur du groupe Agile de l ADIRA, qui nous a offert un cas fil rouge très intéressant et qui a été présent tout le long de ce projet. Nous remercions par la même occasion notre tuteur Ecole ; Laurent AMOUROUX, pour sa présence, son soutien et ses précieux conseils. Nos remerciements vont aussi à Renaud CORNU-EMIEUX, Directeur de l EMSI ; Fanny RABOUILLE, Directrice du Programme Mastere Executive, ainsi qu à l ensemble du personnel pédagogique et aux intervenants, pour la qualité de la formation et des cours dispensés. Nous tenons également à remercier Pascal BUFFARD, parrain de notre promotion EMSI , Président d AXA Group Solutions et Président du CIGREF, pour son investissement en tant que Parrain. Sans oublier l ensemble des personnes qui ont accepté de nous consacrer une partie de leur temps : - Frédéric DUFAU-JOEL, DSI du groupe SAMSE, pour nous avoir accompagnés tout au long de ce cas fil rouge. - Marc PRUNIER, Professeur de Grenoble Ecole de Management, pour ses apports sur la Quality of Service et sur l urbanisation, - Le Club Agile Rhône-Alpes, pour nous avoir accueillis lors d une soirée CARA, - Joël HAUFMAN, Bouygues Telecom et membre du comité de pilotage pour le pôle Alpes de l ADIRA, pour nous avoir accordé du temps, - Arnaud SANGIORGIO, infographiste, pour ses contributions graphiques pour l Observatoire de l Agilité, - La SAMSE, pour avoir organisé une rencontre CARA dont l ordre du jour était le pré-test de l Observatoire de l Agilité - Ainsi qu aux testeurs présents, pour leurs avis et commentaires lors de ce pré-test, - L équipe sécurité de Grenoble Ecole de Management et tout particulièrement Nabil KALFALAH, de Prosegur, pour son amabilité à notre égard lors de ses rondes de fermeture de l école. - Pascale GARNIER, correcteur littéraire et traducteur, pour ses relectures minutieuses et ses corrections. Et bien évidement, toutes les personnes non citées qui ont participé de loin ou de près à notre réalisation, sont chaleureusement remerciées. - page 3 -

4 AVANT-PROPOS L aube de l humanité Ce qui fait l homme, c est sa grande faculté d adaptation. Socrate (-470 à -399) Il y a 3,6 millions d années, un groupe de créatures se dressent sur la plaine d un continent qui devrait devenir l Afrique. Le comportement de ces êtres peut sembler étrange, compte tenu de l époque et du contexte. En effet, leur mode de déplacement n est pas conventionnel, voire maladroit, ils «marchent», de plus ils se sont regroupés et constituent ainsi des tribus primitives. Ces êtres sont probablement les ancêtres communs de l humanité, leurs traits de comportement sont les premiers signes connus de la capacité d adaptation de l être humain à son environnement. Cet Être, qui a priori n avait que peu de chances de survie, démontre ainsi les premiers signes de son agilité : cette étape constitue les premiers pas de notre futur «Homo-Agilitus». L aube du projet Le projet proposé par l ADIRA était la mise en place d un observatoire sur l usage de l agilité dans les entreprises de la région Rhône-Alpes. Dès le début nous avons analysé, décortiqué et reformulé le sujet auprès de nos tuteurs entreprise, pour nous apercevoir que, si nous avions entendu parler de méthodes agiles ou de l agilité, dans les faits nous ne connaissions pas réellement tout ce qu implique ce vocable. Notre mission étant d observer, ou a minima de préconiser des méthodologies et des instruments d observation, nous avons voulu apprendre à connaître notre proie, avant de pouvoir nous lancer à sa poursuite. L aube de l agilité Avant de devenir une culture liée à des méthodes de développement de logiciel, l'agilité est ou a été avant tout une façon de penser et d'agir naturelle de l'être humain. C'est cette agilité, cette capacité d'adaptation à l'environnement changeant qui a permis à notre ancêtre d'arriver à l'homme moderne d'aujourd'hui. L oubli de cette capacité naturelle, la perte de cet instinct semble dus à notre besoin de tout maîtriser et quantifier par le biais rassurant de formules mathématiques. Cette croyance a pu donner l illusion que l'homme était en capacité de tout modéliser y compris le comportement humain, et donc de tout prévoir. Cette frénésie de maîtrise a entraîné la limitation du droit à l'erreur, la crainte de l échec, la peur de l inconnu, ainsi que de l anxiété face au changement. L Homme a ainsi (re)commencé à se regrouper... - page 4 -

5 L aube de nouvelles tribus ou l équipe auto-organisée pour redécouvrir les bénéfices à réfléchir et travailler ensemble. Ce regroupement correctement mis en œuvre, dans le respect de valeurs humaines, est à même d engendrer une intelligence collective dont le potentiel créateur est bien supérieur à la somme arithmétique des individualités. Les réseaux sociaux, les forums, les outils web, et plus généralement Internet, sont des catalyseurs permettant l'accélération de la mise en commun de ressources intellectuelles ou techniques, le partage d expériences et la diffusion de nouvelles pratiques. Face aux changements continus de son environnement, qu ils soient dus à l homme ou pas, la pérennité la «survie» de l'espèce humaine sera subordonnée à notre capacité à valoriser cette intelligence collective. La «tribu primitive» devient «tribu mondiale» par le biais d Internet et des technologies de l information. Léma, Nathalie, Jonathan, Vincent, Thierry. - page 5 -

6 TABLE DES MATIERES INTRODUCTION GENERALITES Présentation de l ADIRA Présentation du cas fil rouge Présentation des acteurs Localisation géographique des acteurs Présentation des acteurs de l ADIRA Présentation du tuteur école Présentation de l équipe EMSI LE SUJET Reformulation du sujet La charte projet : notre contrat Agilité, valeurs et principes - définition Agilité, valeurs et principes - découverte LA CONDUITE DU PROJET Construction de la méthode de travail Choix des outils Validation de la méthode de travail Identification des risques Le projet Création de la story mapping Notre organisation de projet LES PRODUITS Le site Internet Le contexte Le site en général Les outils Logo spécifique Les bonnes pratiques et recommandations La charte de bon fonctionnement La CNIL Les licences et copyrights Analyse, exploitation, rédaction des résultats page 6 -

7 4.2.5 Création des questionnaires Les questionnaires Livret de formation et transfert à l ADIRA Site Internet de l Observatoire Exploitation des résultats LimeSurvey Les bonnes pratiques et recommandations de la gestion d un observatoire Ce qui n a pas été traité : analyse et exploitation des résultats LES INDICATEURS PROJET Les indicateurs de suivi de projet Les indicateurs de livraison Répartition des tâches Les indicateurs d équipe Les indicateurs d amélioration continue, le burndown chart Indicateur produit : le pré-test avec Club Agile ADIRA Plan Do Check Act BILAN Humain Les causes de performances et de non performances Les éléments de performances Les non performances CONCLUSION REFERENCES Liens Internet Ouvrages ABECEDAIRE DECODER LES SIGLES ANNEXES page 7 -

8 - page 8 -

9 INTRODUCTION Si l on vous demande de mettre en place un «Observatoire de l'agilité», savez-vous en quoi cela peut consister? Pour répondre à cette question, nous devons distinguer deux aspects : d une part la notion d observatoire et d autre part, celle de l agilité. Un observatoire est un lieu d échanges et d analyses sur un thème donné. Il traite de différents types de sujets, et aujourd hui, se caractérise le plus souvent sous la forme d un site Internet dédié. Quant à la notion d agilité, c est un ensemble de méthodes, de pratiques et d outils apparus dans les années 2000 aux États-Unis. Au départ, ce courant s est propagé dans le monde du développement informatique porté par les nouvelles technologies, bousculant les habitudes de conduite de projets traditionnelles puis s est étendu vers d autres domaines d activités. À l heure actuelle, nous constatons un foisonnement de différents types d observatoires. Ils peuvent être consacrés à des sujets variés, autant sur des thèmes matériels comme «l observatoire de l agriculture» ou immatériels comme «l observatoire des inégalités». Les différentes publications telles que les synthèses et les livres blancs permettent aux internautes de partager sur les sujets abordés. «L Observatoire de l'agilité» peut être un relais vers divers événements traitant de l agilité sous forme de conférences et de séances de partages, tels que les ScrumDays ou les rencontres du Club Agile Rhône-Alpes. C est pourquoi nous vous invitons, par la lecture de ce mémoire, à découvrir la construction de notre Observatoire de l'agilité... - page 9 -

10 - page 10 -

11 1 GENERALITES 1.1 Présentation de l ADIRA L ADIRA Association pour le Développement de l Informatique en Rhône-Alpes. L ADIRA, l Association pour le Développement de l Informatique en Rhône-Alpes est une émanation de la Chambre de Commerce et d Industrie de la Région Rhône-Alpes (CCIR) et du MEDEF, en relation étroite avec les universités et les rectorats d Académie. Elle a vu le jour en 1969 simultanément à Lyon et Grenoble et regroupe en 2013 plus de 400 entreprises. SOLIDARITE ENTHOUSIASME RESPECT MUTUEL PROFESSION- NALISME ADIRA L'ECOUTE VEILLE TECHNOLOGIQUE TRAVAIL COLLABORATIF PARTAGE Figure 1 : Les valeurs de l'adira. L objectif de l ADIRA est de partager, par des rencontres fréquentes et régulières, les connaissances et les domaines d expertise répartis en dix-sept groupes d études thématiques. Parmi ces groupe se trouvent les thématiques «Agile Pôle Alpes», «Stratégies de DSI Grenoble» ou encore «Cloud Computing» pour n en citer que quelques-uns. - page 11 -

12 L ADIRA est une structure d accueil et de mise en relation de tous les acteurs régionaux des technologies de l information. Accélérateur de productivité dans les entreprises, elle est aussi considérée comme un révélateur dans l éprouvette des systèmes d information. L Agile Pôle Alpes. L Agile Pôle Alpes ou groupe Agile ADIRA a été créé en 2012 et est animé par Monsieur Jean-François JAGODZINSKI ; il se compose actuellement de vingt-deux membres. Ce groupe définit l'agilité comme un mouvement de fond qui change fortement la vision des projets du SI. Le groupe Agile ADIRA est un lieu privilégié pour découvrir, échanger et apprendre principalement en mettant en avant les retours d expériences. Les participants ont défini 3 objectifs à la création de ce groupe : - Donner envie aux entreprises souhaitant se lancer dans l agilité en s appuyant sur les retours d expériences. - Devenir un observatoire des pratiques Agiles. - Adresser le management et la gouvernance dans ce cadre. 1.2 Présentation du cas fil rouge L Observatoire de l Agilité en Rhône Alpes. Le Cas fil rouge proposé par le groupe Agile de l ADIRA via l EMSI de Grenoble Ecole de Management poursuit deux objectifs. Premier objectif : Définir la notion d'observatoire de l'agilité. En Rhône-Alpes, les pratiques et méthodes agiles se propagent dans tous les secteurs de l entreprise, aussi il nous est demandé de définir les différents angles de vues et données à observer. - page 12 -

13 Les domaines potentiellement impactés peuvent être : - La Direction des Systèmes d Information, - Les autres directions de l entreprise : direction générale, financière, ressources humaines, technique, méthode, qualité, etc. La propagation du changement dans l entreprise peut se faire, entre autre : - Par l introduction de nouvelles méthodes de conduite de projet : Scrum, XP, Kanban, Lean engineering - Par la mise en place de nouvelles pratiques: management visuel des projets au quotidien, rédaction des exigences sous forme d'histoire, l estimation des projets en points, etc. - Par l acceptation de la remise en question : le client est au centre du projet, l équipe est autoorganisée, les itérations successives permettent des adaptations et améliorations permanentes. Deuxième objectif : Récupérer les informations auprès des entreprises, tout en commençant à alimenter une base de données. Sur la base de cet Observatoire, l'adira pourra : - Publier régulièrement des indicateurs, - Réaliser des analyses sur la propagation des méthodes et pratiques agiles en Rhône- Alpes, - Mesurer la diffusion dans les différents domaines d activités de l entreprise et le niveau de maturité d intégration de l agilité, - Quantifier et qualifier les abandons, - Détecter les pratiques phares, émergentes, etc. - page 13 -

14 1.3 Présentation des acteurs Localisation géographique des acteurs Dans ce cas fil rouge, chacun des acteurs est localisé en Isère. ISERE Thierry Laurent Lema Vincent Frederic GRENOBLE Jonathan Nathalie Jean-Francois Figure 2 : Localisation géographique des acteurs Présentation des acteurs de l ADIRA L équipe ADIRA est composée de deux personnes ; Monsieur Jean-François JAGODZINSKI qui est notre tuteur et Monsieur Frédéric DUFAU-JOEL qui s est joint à nous dès la deuxième rencontre. - page 14 -

15 L ADIRA est une structure d accueil et de mise en relation de tous les acteurs régionaux des technologies de l information. Accélérateur de productivité dans les entreprises, elle est aussi considérée comme un révélateur dans l éprouvette des systèmes d information. L'Adira compte plus de 400 entreprises membres et utilise entre autre des échanges entre professionnels au sein de 17 groupes d études thématiques. L'un de ces groupes s'est donné pour but de partager les connaissances et les retours d'expériences autour du nouveau schéma d'organisation que proposent les approches Agile. L'agilité est apparue récemment dans nos entreprises, les pionniers ont mis en place ces pratiques en Au vu de la progression des participants dans les conférences sur le sujet, on sent une montée en puissance depuis Mais il existe peu d information et aucune statistique qui permette de mesurer l'adoption réelle par les entreprises. L'un des objectifs que le groupe s'est donné est d'obtenir les informations à l'échelle de la région sur l'utilisation des pratiques Agiles. Quel est leur degré d'utilisation? Dans quels secteurs? Comment sontelles abordées? Comment se diffusent elle dans l'entreprise...etc Pour répondre à ce besoin, un observatoire semblait une bonne idée et le fait que l'adira soit partenaire de L'EMSI sur le programme Fil Rouge était une solution tout à fait intéressante pour mettre en route ce projet et le réaliser. J'ai créé le cabinet Agilessence. Mon métier est d'accompagner les entreprises et les DSI dans leur transformation Agile. Cela passe par de la formation, de l'accompagnement sur le cadre de pratique et le coaching d'équipe et de managers. Figure 4 : Agilessence Figure 3 : Jean-François JAGODZINSKI Tuteur entreprise Jean-François JAGODZINSKI ADIRA / AGILESSENCE Coach Agile indépendant - page 15 -

16 L Observatoire de l'agilité sera un formidable outil de promotion de l Agilité. Il doit permettre de connaître l importance de la diffusion de l Agilité dans nos entreprises, le niveau d utilisation des différentes pratiques et les bénéfices que cela apporte à nos organisations. Je pense que cette connaissance sera le meilleur moyen de donner envie à d autres entreprises d emprunter le fantastique chemin de l Agilité. Figure 5 : La Boite à Outils Figure 6 : Frédéric DUFAU-JOEL Grenoblois, montagnard citadin, Directeur Systèmes Informations et Méthodes de «La Boite à Outils», groupe SAMSE Démarche AGILE, XP, SCRUM, Lean, Innovation Games depuis 2005 Tuteur entreprise Frédéric DUFAU-JOEL La boîte à outils Directeur des Systèmes d Information - page 16 -

17 1.3.3 Présentation du tuteur école Etudiant sur la huitième promotion de l'emsi en formation continue, j'ai connu une transformation personnelle. Après mes 17 premières années d'expérience dans le monde des Systèmes d'information, j'ai souhaité m'ouvrir vers de nouvelles perspectives professionnelles et personnelles. L'EMSI a été le levier important et essentiel à cette transition : «Open your eyes» pour reprendre l'expression de Jean-Pierre CORNIOU. L'EMSI m'a redonné l'envie d'être curieux, de prendre de la hauteur dans mes analyses et perceptions et plus globalement, m'a fait reprendre conscience des fonctions de mes deux hémisphères cérébraux. Les termes sont forts mais réels. C'est pourquoi, à la proposition de Renaud CORNEAU-EMIEUX, je ne pouvais que répondre Figure 8 : Laurent AMOUROUX positivement. Cela allait me permettre de me tenir en éveil en poursuivant mes analyses critiques et mes remises en question dans ce vaste monde des Services d'information. J'ai donc choisi le cas fil rouge de l'adira et son sujet autour des méthodes Agiles. Le groupe d'étudiants ou plutôt cette véritable équipe, allait m'offrir l'opportunité d'accroître mes connaissances de l'agilité et des méthodes qui l'accompagnent. Objectif atteint : via les échanges et les écrits tout au long de ce programme, je vais mettre en pratique au sein du Centre de Services, dont j'ai aujourd'hui la responsabilité, la méthode Kanban via du «visual management» et des «stands up» quotidiens. Figure 7 : Le cloud par Osiatis Enfin, je profite de cette brève intervention pour remercier l'emsi, Renaud et son équipe mais aussi ce groupe d'étudiants qui sont pour moi véritablement rentrés dans cette grande famille. Tuteur école Laurent AMOUROUX OSIATIS Manager - page 17 -

18 1.3.4 Présentation de l équipe EMSI L équipe EMSI est composée de six personnes : - Léma CHASTAGNER, - Nathalie NEGRE, - Jonathan ROELLINGER, - Vincent SANGIORGIO, - Thierry PONCERY. Analyse du profil FourSight de l équipe. 185 Profil FourSight Equipe 180 POINTS FOURSIGHT Clarificateur Idéateur Développeur Réalisateur Figure 9 : Profil FourSight de l'équipe L'équipe dispose de deux préférences dominantes, clarificateur en bleu et développeur en vert. Le profil de l équipe est méthodique. Cela s'est traduit au niveau de l équipe par différentes facettes : - Explorer les problèmes. - Approfondir les situations. - Explorer les différentes possibilités. - Soigner les solutions. - Donner vie aux solutions. - Travailler dans le détail. - Plaisanter pour alléger les relations de travail. Cependant, l équipe doit faire attention à ne pas être trop pointilleuse sur les détails au risque de ne pas passer à la réalisation. - page 18 -

19 Analyse du profil Process Communication Profil Process Communication Equipe 100% 94% 93% 84% 72% 58% Travaillomane Persévérant Empathique Rebelle Rêveur Promoteur Process com, arrivé en fin de projet, a permis un nouvel éclairage sur les modes de communication de l équipe. Les points forts que nous avons constatés pendant le cas fil rouge sont les suivants : - Organisé. - Engagé. - Consciencieux. - Adaptable. - Ludique & créatif. - Chaleureux. Et voici également quelques points qui auraient pu devenir bloquants : - Perfectionnisme. - Sûr adaptable. - Sûr contrôle. Figure 10 : Profil Process Communication de l'équipe En conclusion et grâce au cours sur la Process Communication, nous avons pu déterminer que l équipe dispose d une base Travaillomane en bleu et d une phase actuelle Persévérante en violet. Profil détaillé de chacun des membres de l équipe. - page 19 -

20 - page 20 -

21 - page 21 -

22 - page 22 -

23 - page 23 -

24 - page 24 -

25 2 LE SUJET 2.1 Reformulation du sujet. Présentation Le sujet présenté par Jean-François représentant l ADIRA, nous a séduit par le cas d étude proposé à connotation «nouvelle technologie», témoin la vague montante de développements en mode agile. Du côté de l'équipe, nous avions aussi le souhait de partir à la découverte de nouveautés, de méthodes innovantes et nous avions l envie de sortir de notre «zone de confort». La problématique initialement posée et proposée était de mettre en place un observatoire des pratiques agiles ; pas uniquement dans le domaine de la programmation ou des développements logiciels. Analyse La demande ne spécifiait pas les moyens techniques, ni les outils à utiliser pour la réalisation de l'objectif, et laissait donc d'importantes possibilités d'innovations et de créativités. Nous avons donc analysé et revu le besoin avec l'aide et la participation active des représentants du client. Ceux-ci dans le cadre de Scrum seront désignés comme les Product Owner (PO). Pour mener cette analyse à bien, nous avons tenu compte des contraintes et souhaits de chacun des participants du projet. Les éléments pris en compte ont été les suivants : - Les besoins du client au-delà du cahier d expression de besoin. - La volonté de livrer une solution exploitable et opérationnelle, à la fin du projet. - Le «budget temps» que chacun pouvait raisonnablement consacrer au projet. - La limite de ce budget dans la durée, lié à notre cursus de formation. - Aller à la découverte de nouveaux acquis. Reformulation La démarche de pré-analyse a permis de mettre rapidement en évidence que le besoin était relativement vaste et pas complètement défini ou délimité. Celui-ci nécessitait donc d'être recadré, au même titre qu'un projet professionnel quelle que soit la méthode de conduite retenue. Le cadrage élaboré collectivement du projet nous a amené à rédiger une «charte projet» prenant en compte d un côté les exigences du donneur d ordre et de l autre, les capacités et les compétences de l équipe «Red Adira». 2.2 La charte projet : notre contrat Nous avons retenu dans les bonnes pratiques de management, la charte projet, qui permet de définir entre autre le périmètre du projet. - page 25 -

26 "La simplicité c est-à-dire l art de minimiser la quantité de travail inutile est essentielle." Dixième principe de l Agile Manifesto - agilemanifesto.org En référence à deux notions de l agilité : le management visuel et le Lean Engineering. Elle doit tenir sur une page afin d'être être visible par tous et tout le temps. Elle rappelle l essentiel du projet et se positionne comme un guide en cas de dérive. La charte projet se trouve sur la page ci-après. - page 26 -

27 Les enjeux principaux du projet CHARTE PROJET ADIRA «Observatoire de l'agilité» Rédiger une définition du rôle de l'observatoire de l'agilité. Proposer et partager la mission de l'observatoire. Mettre en œuvre un système pilote. Périmètre du projet Les parties prenantes sont : - L'ADIRA, représenté par le tuteur du cas fil rouge. - Les entreprises adhérentes de la région Rhône-Alpes. - L'équipe étudiante de GEM et son tuteur école. Engagements réciproque de toutes les parties prenantes Le représentant de l'adira se propose de jouer le rôle de product owner. L'équipe projet composé de, l équipe étudiant, se propose de mener le projet en mode Agile. Un des livrables étant une définition d'un observatoire, ainsi que les axes retenus à observer. L autre livrable étant un pilote, sous une forme à définir, permettant de valider le processus d'observation, définition d'une série d'axes, leur collecte, l'analyse, la communication des résultats. L'équipe projet s'engage à mettre en œuvre tous les moyens à sa disposition au service du cas fil rouge, dans la limite des sprints établis au départ, et sans perdre de vue la réalisation du mémoire de soutenance. Matrice des compromis : Fixe Ferme Variable Cible Date X Périmètre X Qualité X Budget Figure 11 : Charte projet de l'observatoire de l'agilité X Proche de 0 dans notre cas - page 27 -

28 2.3 Agilité, valeurs et principes - définition Les pratiques agiles sont apparues dans le monde du développement informatique dans les années Le Manifeste Agile rédigé en 2001 a permis de fédérer cette nouvelle pratique de conduite de projet. Il met l accent sur 4 valeurs : Manifeste pour le développement Agile de logiciels Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser : Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L adaptation au changement plus que le suivi d un plan Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. Figure 12 : Les quatre valeurs de l'agile Manifesto - agilemanifesto.org 12 Principes sous-jacents au manifeste Nous suivons ces principes : Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client. Un logiciel opérationnel est la principale mesure d avancement. Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. Une attention continue à l'excellence technique et à une bonne conception renforce l Agilité. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. Réalisez les projets avec des personnes motivées. Fournissez-leur l environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. La méthode la plus simple et la plus efficace pour transmettre de l information à l'équipe de développement et à l intérieur de celle-ci est le dialogue en face à face. La simplicité c est-à-dire l art de minimiser la quantité de travail inutile est essentielle. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto organisées. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. Figure 13 : Les douze principes de l'agile Manifesto - agilemanifesto.org - page 28 -

29 Les pratiques agiles se propagent dans l entreprise, surtout depuis les années Les praticiens de l agilité ne cherchent pas à prouver qu ils sont «agiles» par l utilisation de telle ou telle pratique, ils se nourrissent de leurs expériences pour optimiser leur organisation et ainsi améliorer leur performance. "Une informatique plus humaine et plus efficace " Institut Agile - institut-agile.fr Selon l institut agile, les valeurs et principes sont des garde-fous pour prévenir des dérives du projet et rester aligné sur les besoins du client. L agilité, est un nouveau paradigme, un état d esprit de collaboration différent de la méthode classique de gestion de projet, regroupant un courant de pratiques variées : AGILE MANIFESTO RECONNAISSANCE NIKO-NIKO SCRUM RETOUR D EXPERIENCE CHARTE PROJET COLLABORATION XP PLANNING POKER 4 VALEURS et 12 PRINCIPES CULTURE ETAT D ESPRIT LEAN ENGINEERING KANBAN RETROSPECTIVE PERSONAS MANAGEMENT VISUEL DALY STAND-UP Figure 14 : Notre vision du périmètre de l agilité - page 29 -

30 L agilité est-elle l exclusivité de l IT? L émergence des méthodes et pratiques agiles dépasse le domaine du développement informatique. Ce nouveau courant s adapte aux changements économiques et environnementaux tout en restant en adéquation avec les exigences du client. Il se propage dans l organisation de l entreprise en diffusant une nouvelle culture managériale. L objectif du cas fil rouge est de mesurer l utilisation et la propagation de l agilité par l intermédiaire de l Observatoire de l'agilité. L équipe EMSI découvrant l agilité, l étude des fondamentaux a été nécessaire pour s imprégner du sujet. 2.4 Agilité, valeurs et principes - découverte Lors de notre premier entretien avec nos tuteurs entreprise, nous avons défini deux rendez-vous essentiels pour la compréhension de l Agilité. Le premier est une visite de la SAMSE, entreprise de l un de nos tuteurs, Frédéric. Il a voulu nous faire bénéficier de sa grande expérience de l Agilité. Le deuxième est un cours coaché, dispensé par notre autre tuteur Jean-François. La visite des bureaux de la SAMSE. La SAMSE, est une entreprise qui prône et porte des valeurs d indépendance, de partage, d ouverture et de créativité, ces valeurs sont proches des valeurs de l Agile Manifesto. " Des logiciels opérationnels plus qu une documentation exhaustive" Deuxième valeur de l Agile Manifesto - agilemanifesto.org Arrivés à la SAMSE, nous rentrons très vite dans le vif du sujet et lors de la visite des bureaux, en particulier les zones de développement de logiciels, nous faisons immédiatement le lien avec la deuxième valeur de l Agile Manifesto. Frédéric nous explique que la plupart des logiciels du groupe sont développés en interne, avec une méthodologie Scrum. Les projets sont définis avec les employés du terrain, par l élaboration d une story mapping conçue collectivement. Nous avons pu apercevoir en particulier une story mapping construite en huit heures par une équipe de vingt à vingt-cinq personnes. Un lieu spécifique a été aménagé pour l occasion. Les user stories ont été exprimées conjointement entre les acteurs du projet et le rôle des personnes de terrain, les personas. Une Charte Projet est élaborée sur une feuille A4 et est visible par toute l équipe durant toute la réalisation. C est le cap à suivre du projet. - page 30 -

31 Suite à la story mapping, les user stories les plus valorisées, d un point de vue du product owner, sont envoyées en «production» à l équipe de développement, pour découpage en tâches. Elles sont évaluées en termes de charge puis complétées par des conditions d acceptabilité. Elles permettent ensuite à l équipe de développement de savoir si les logiciels réalisés correspondent aux attentes client et sont terminés. Nous avons pu voir l application concrète et réelle de l usage des post-it, les murs du département développement en sont littéralement couverts. Nous avons constaté, sans faire partie de l équipe, l état des développements en cours par la répartition des post-it dans les différentes zones des tableaux. Frédéric a évoqué quelques pratiques associées à ses équipes, notamment le niko-niko. C est un tableau sur lequel chaque membre de l équipe exprime son état d'esprit jour par jour. Ce document, visible par tous, permet d avoir une vision du moral des personnes impliquées dans le projet en cours. La propagation est telle que les ressources humaines et la logistique ont adopté les post-it pour manager leurs équipes, pratiquant le Kanban et le management visuel en lieu et place de Scrum. La visite s est terminée par une présentation d autres pratiques agiles et par l exploration du site de l Institut Agile qui recense un certain nombre de définitions et de pratiques. Ce premier aperçu de l agilité a suscité de l enthousiasme au sein de l équipe et a été un vrai «choc culturel» par comparaison aux méthodes traditionnelles de management de projets et d équipes. Cette visite nous a permis de nous imprégner de l agilité. Cette visite de la SAMSE nous a permis de lancer cas fil rouge en connaissance de cause. Nous en avons extrait beaucoup d information et aussi beaucoup d interrogation quant à la manière de commencer un projet en agile. Notre cours Coaché. Jean-François nous a proposé un cours coaché sur la méthode Scrum et quelques valeurs agiles. L équipe s est réunie à l EMSI afin de suivre ce «cours». La visite de la SAMSE la veille nous a permis de définir plusieurs questions à lui poser. Le coaching a eu lieu de manière agile, Jean-François s est appuyé sur nos questions pour articuler son cours. Elles ont été produites en directe et de façon personnelle. Tout en répondant à nos interrogations, Jean-François nous a décrit le cheminement et les principes de Scrum à l aide d un tableau. Nous avons appris comment utiliser la méthode et acquis quelques définitions des termes associés. Ce fut un échange permanent entre l équipe et notre professeur d un soir. - page 31 -

32 Nous sommes sortis de cette formation avec une vision plus claire de Scrum et de l Agilité. Par contre, l équipe a été déroutée par une impression de «flou» et une interrogation en est ressortie : «Nous ne savons pas où nous allons!». Selon Jean-François, ce ressenti fait partie intégrante de l Agilité. Par ce cours Jean-François a su nous inculquer les prémices de la culture agile, ses valeurs et ses principes. Il nous a permis de le faire de façon interactive et ludique. Figure 15 : Cours coaché par Jean-François JAGODZINSKI L équipe a pris la décision d utiliser Scrum afin de réaliser le projet, l Observatoire de l Agilité. Les soirées CARA Lors de nos découvertes sur l agilité, nous apprenons que le Club Agile Rhône-Alpes ( organise, mensuellement, des soirées agile accessibles à tous. Elles sont annoncées sur le site Internet du club ainsi que sur les réseaux sociaux. Elles ont pour objectif de traiter d un sujet en particulier, puis de partager et confronter les expériences de chacun des participants. Le sujet est défini au préalable par les membres actifs du CARA. Nous avons décidé de participer à l une de ses réunions afin de mieux s imprégner et de faire plus ample connaissance avec le milieu agile. Deux membres de l équipe se sont portés volontaires pour participer à cette soirée. Soirée CARA du 24 janvier 2013 à Grenoble INP, ENSIMAG - Sujet : l effectuation La soirée se déroule ainsi : un maître de conférences pose les bases sur le sujet puis partage sa propre expérience. L échange avec le public vient en fin de séance et chacun peut s exprimer librement. Les personnes qui y assistent viennent d horizons et d entreprises différents, c est un véritable mélange, une «famille» qui entre dans un dialogue authentique dans le but d avancer dans les méthodes Agile. La visite de la SAMSE, le cours coaché et la soirée CARA nous ont révélé les méthodes, les pratiques et la culture agile. Nous comprenons progressivement l état d'esprit que cela suppose et le niveau d implication des agilistes dans leurs méthodes de travail : c est une entraide perpétuelle. - page 32 -

33 3 LA CONDUITE DU PROJET 3.1 Construction de la méthode de travail Choix des outils Outils Google Hangout Objectifs Système de «chat» vidéo collectif, permettant de réaliser des conférences à distance via Internet. Scrumwise Outil informatique sécurisé de gestion de projet permettant la pratique de Scrum. Management visuel du task board Suivi du burndown Gestion du backlog Google Drive Figure 16 : Outils retenus Outil de stockage et de partage de documents du projet permettant une réplication de sauvegardes. Notre choix s est porté sur les services de Google, car nous possédons tous un compte Gmail. Nos tuteurs, eux-aussi, utilisent les services de Google. Il nous a paru opportun d utiliser les mêmes outils, tout en étant conscient des risques encourus en terme de sécurité des données. Cependant, compte tenu de l enjeu, il ne nous a pas paru pertinent d augmenter le niveau de sécurité (cf. Annexe 1 page 88). Pour limiter les risques de pertes ou d erreurs humaines, nous avons mis en place un système de sauvegarde indépendant et automatique de tout le contenu du projet Validation de la méthode de travail "Partir en mode agile ou en standard PMI?... Notre choix!" En début de projet, l équipe s est questionnée sur l approche conduite de projet. L équipe EMSI Le standard PMI était connu d une partie de l équipe, les autres membres ne pratiquaient pas la conduite de projet, et le cas fil rouge traitait de la propagation des pratiques agiles. La décision a été prise unanimement sur le critère suivant : puisque le sujet traite de l agilité, alors pratiquons-la! En essayant, nous pourrons capitaliser et comprendre les enjeux de ce nouvel état d esprit, et utiliser ce retour d expériences. - page 33 -

34 L équipe ayant entériné cette première étape, la seconde a consisté à valider avec nos product owners : - Que l idée était adaptée à la constitution de notre équipe, - Que l approche était appropriée à la nature du projet à mener, - Que le choix de méthode Scrum était conforme à cette conduite de projet. Afin de comprendre en quoi consistait Scrum, le schéma suivant a été produit : Figure 17 : NOTRE vision de Scrum en début de projet L équipe a décidé de mettre en œuvre les principes suivants de façon adaptée : Ce que préconise Scrum Figure 18 : Vue synthétique du processus Scrum - page 34 -

35 A. Constituer une équipe auto-organisée, travaillant dans une même salle, avec : a. Un product owner, qui donne la vision du produit. b. Un scrum-master, qui coordonne l équipe. Il a la responsabilité d aider l équipe à travailler de façon autonome et à s améliorer constamment. C est aussi le garant de l application du processus. c. Une équipe de développement, pour réaliser les produits. B. Créer un backlog : C. Gérer ce backlog de manière séquencée, par des itérations (ou sprints), dont la durée est fixée par l équipe ; ce sprint peut durer entre une à deux semaine(s) et un mois. D. Avant de lancer le sprint, planifier et découper chaque user story en tâches, puis l équipe estime en poids (point ou heure) la complexité de chaque tâche. Cette pratique peut, entre autres, se réaliser en pratiquant un planning poker. E. Débuter le sprint. F. Mettre en place une «mêlée» quotidienne, ou «daily stand-up», pour que l équipe partage l avancement des tâches. G. Pratiquer un point d avancement à mi-sprint pour faire un bilan et s assurer que l équipe produit en accord avec ce qui est attendu du livrable de fin de sprint. H. En fin de sprint, réaliser la démonstration : l équipe présente au product owner le résultat de son travail. I. Le product owner valide ou rejette les user stories. Celles qui sont rejetées sont soit remises dans le backlog, soit abandonnées. J. Réaliser la rétrospective, permettant de faire le bilan de l équipe, et surtout d échanger sur les facilités et difficultés rencontrées. Puis l équipe décide collectivement des axes d amélioration à donner pour la future itération Identification des risques Evaluation des risques projet : Observatoire de l Agilité En agilité, la gestion des risques ne se pratique pas comme en mode PMI. Il n y a pas d analyse de risques en début de projet. Le seul exercice qui est fait s appelle la matrice des compromis. Ce tableau pose les limites du projet, et fait partie de la charte projet. Les itérations du projet sont des opportunités d amélioration par le changement, aussi, si une dérive apparaît, l équipe est capable de détecter l écart par la charte et de se recadrer par elle-même. Pour la réalisation de l Observatoire de l Agilité, une matrice des compromis a été réalisée en début de sprint 1 avec le product owner. Fixe Ferme Variable Cible Date X Périmètre X Qualité X Budget X Proche de 0 dans notre cas Figure 19 : Matrice des compromis de l Observatoire de l Agilité - page 35 -

36 Malgré l absence d analyse de risque en agilité, l équipe a cependant décidé d en réaliser une a posteriori. Nous avons identifié et évalué sept risques. Liste des risques et conséquences RISQUES DESCRIPTIF CONSEQUENCES R1 L'équipe ne se comprend pas Dislocation équipe/retard du projet R2 L'équipe ne s'approprie pas la méthode Retard du projet R3 Pas de livraison Arrêt du projet ou retard R4 Manque de critère d'acceptation Livrer produit insatisfaisant R5 Problème de compréhension avec le client (PO) Livrer produit insatisfaisant Manque d'implication d'un des membres R6 R7 de l'équipe Perturbation extérieure (rajout/ modification de tâche) Transfert de la charge sur les autres Retard du projet Figure 20 : Tableau des risques et des conséquences RISQUES PLAN D ACTION POUR MAITRISER LES RISQUES R1 Team building + tableau freins et solutions (cf. Figure 24 page 37 et Figure 25 page 38) R2 Changement de méthode/outils R3 Contrôle avancement du task board régulier R4 Demander les critères d acceptabilité à chaque lancement de sprint R5 Reformulation du besoin R6 Recadrage par l'équipe elle-même / aide bienveillante du scrum-master R7 Injecter le changement dans le backlog pour traitement ultérieur Figure 21 : Plan d'action pour maîtriser les risques Evaluation des risques Incidence Probabilités Faibles Moyennes Élevés Très élevés Faible R1 R3 Moyen R4 R6 Élevé R2 Très élevé R5 R7 Figure 22 : Pondération des risques en fonction de la probabilité - page 36 -

37 Légende : Risque extrême Risque élevé Risque moyen Risque acceptable Risque sans impact sur le projet Figure 23 : Graduation des risques L équipe a analysé les conséquences de tous les risques identifiés au-dessus. Les risques R5 et R7 sont dans une zone ou l événement est très improbable et ne surviendra probablement jamais. L équipe a constaté que R4 et R5 se sont produits lors du projet. Nous avons appliqué, de manière intuitive, les solutions identifiées par le tableau de plan d action. Le R3, bien que potentiellement très handicapant, n a pas eu lieu lors de notre conduite de projet. En Agilité, l équipe produit à chaque fin d itération, ce qui fait huit livraisons au total dans notre cas. Les freins et les solutions du projet L équipe a fait cet exercice lors du cours de l accompagnement au changement de A.TONNELE en décembre Nous en avons retiré 2 tableaux. Freins externe Temps alloué des tuteurs sur nos cas fil rouge On ne connaît pas encore nos tuteurs Manque de clarté dans la communication du tuteur vers nous Exhaustivité du sujet Accueil et disponibilité des entreprises Actions pour éviter les freins externes Intégrer les tuteurs dans un team building / rendre notre cas fil rouge attractif pour le tuteur école Intégrer les tuteurs dans un team building / rencontrer nos tuteurs Reformuler le sujet et le présenter au tuteur Reformuler le sujet et le présenter au tuteur Appâter le tuteur école (attractif) Figure 24 : Freins externes et actions - page 37 -

38 Freins internes La disponibilité, le temps personnel alloué pour le projet Divergence entre nous 5 Faire un hors sujet/ mauvaise compréhension Logistique (mobilité) Compétence individuelle / lacune comparativement au groupe Manque de cohésion Tension entre nous Actions pour éviter les freins internes Mettre en place une méthodologie, planification, entraide et solidarité Communication, mail, téléphone, Skype... si cela ne marche pas, faire appel au tuteur appel, liaison avec le tuteur école et entreprise Communication, mail, téléphone, Skype... si cela ne marche pas, faire appel au tuteur Communication, mail, téléphone, Skype... si cela ne marche pas, faire appel au tuteur Team building Team building 3.2 Le projet Figure 25 : Freins internes et actions Création de la story mapping Avant de démarrer le sprint 1, l équipe a réalisé une «story mapping». Le but de cette pratique est de constituer un ensemble de user stories priorisées par le product owner, qui seront injectées par l équipe, au fur et à mesure de l avancement du projet à chaque début de sprint. L exercice se déroule en deux étapes : - Etape 1 : l équipe et le product owner identifient toutes les parties prenantes concernées par le sujet. L objectif consiste à trouver toutes les entités qui pourraient être concernées par le livrable final. A la fin de cet exercice, nous nous retrouvons avec une multitude de cartes regroupées par nature (ex : l administrateur de l observatoire, les entreprises publiques ou privées, ou bien les écoles ). - page 38 -

39 Figure 26 : Identification des parties prenantes - Etape 2 : l équipe travaille à l aide de post-it (ou cartes) et imagine les besoins de chaque partie prenante (ex : à partir de la carte administrateur : je souhaite pouvoir avoir un site fonctionnel ) Figure 27 : Identification des besoins des parties prenantes A la fin de cet exercice, le backlog du projet est constitué, le product owner priorise les user stories et choisit celles à travailler par l équipe en premier. - page 39 -

40 Figure 28 : User stories sélectionnées au lancement du premier sprint A partir de cette liste, l équipe a choisi la quantité de user stories pour lancer le premier sprint, et le lancement du projet a pu débuter Notre organisation de projet La méthode Scrum requiert proximité et une collaboration quotidienne ; la configuration de l équipe l a rendue possible moyennant une certaine flexibilité. Tous les acteurs étant localisés sur le bassin grenoblois, nous décidons dès le lancement du projet : - de mettre en place une réunion hebdomadaire le jeudi à l école, - de la compléter par une séance de travail intermédiaire. L adaptation de Scrum à notre organisation nous a permis ainsi de répondre au mieux, aux besoins du projet. Le déroulement du projet est Figure 29 : Liste des réunions construit sur plusieurs itérations ou sprints, d une durée de deux semaines. Cette durée a été validée par l équipe et quantifiée afin de livrer un certain nombre de produits recevables par le product owner. - page 40 -

41 Figure 30 : planning du projet Observatoire de l Agilité Légende : Jour 1 (J1): début du sprint. Jour 4 et Jour 8 (J4) (J8) : rencontre à mi-sprint - Partage de l avancement des tâches en cours de réalisation. - Détection des points de blocage de l équipe. Jour 15 (J15) : fin du sprint Entre l équipe et le product owner : - Validation ou rejet des produits livrés par l équipe : la démonstration. - Alimentation du backlog avec de nouvelles user stories pour le sprint suivant. Par l équipe. - Rétrospective de fin de sprint. - Validation des user stories à travailler par l équipe. - Planning poker pour quantifier en poids et en complexité chaque user story, la découper en tâches, en ouvrant ainsi le début du sprint suivant. Organisation de la Période 1 (24/01 au 25/02) Réunion le jeudi pour assurer les instances J1 et J15 Le lundi via Google hangout (J4) et le jeudi suivant (J8) pour le mi-sprint Dans la première partie du projet, l équipe se rencontre le lundi (J4) via Google hangout, pour découper et planifier les tâches, mais nous constatons des problèmes : - page 41 -

42 - La quantification de la charge de travail doit se faire à l issue du bilan de fin de sprint, et nous perdons du temps. - Le planning poker est réalisé trop tard, et nous constatons que cette tâche doit être pratiquée ensemble pour pouvoir : o Débattre face à face de la complexité et du poids de chaque tâche (Argumentaire de chaque acteur projet). o Traiter à chaud les décisions, suite au bilan o d itération avec le product owner. Répartir le travail pour ne pas perdre de temps. Après la rétrospective du sprint 2, l équipe s aperçoit que de ne pas faire le planning poker dans la foulée de la fin du sprint fait perdre 4 jours de travail. L organisation est modifiée en conséquence : - Mise en place d une «time-box» pour limiter le temps d intervention du product owner. - Transfert du planning poker à la suite de la démonstration (J15). La séance de J15 devient plus longue, et l équipe réalise alors : - La démonstration, - La rétrospective - Et le planning poker. Organisation de la période 2 (du 25/02 au 16/05) Rencontres chaque jeudi pour assurer les instances J1, J8 et J15 L ajustement de l organisation a permis de conduire notre projet, au plus proche de l esprit de l agilité et de Scrum. Répartition des tâches "Réalisez les projets avec des personnes motivées. [ ] faites-leur confiance pour atteindre les objectifs fixés." Cinquième Principe de l Agile Manifesto - agilemanifesto.org Pour la répartition des tâches, nous avons appliqué le cinquième principe de l Agile Manifesto. La répartition des tâches s est réalisée de manière naturelle en binôme ou seul : Figure 31 : Cartes pour le planning poker utilisées pendant le projet par l'équipe - Soit par type de compétence ou d expertise, - Soit par envie de se tester dans un domaine, en lâchant prise sur ses habitudes, - Soit par intérêt pour le sujet à travailler. - page 42 -

43 "La simplicité c est-à-dire l art de minimiser la quantité de travail inutile est essentielle." Dixième Principe de l Agile Manifesto - agilemanifesto.org L équipe a mis en œuvre les principes du Lean Engineering, et a appliqué le dixième principe de l Agile Manifesto, en travaillant sur le découpage des tâches. Cette pratique lui a permis d aller à l essentiel de ce qui était attendu par le product owner. Rôle du scrum-master Pour comprendre le rôle, nous avons décidé que chaque membre de l équipe tiendrait ce poste, au moins pour la durée d un sprint. Nous avons constaté, que le scrum-master n est pas un chef de projet, que le leadership ne lui appartient pas, mais que sa tâche consiste principalement à faciliter le fonctionnement de l équipe. La personne en charge du rôle de scrum-master devait porter une attention particulière aux points suivants : - la bienveillance, - la recherche de cohésion et de compromis, - la protection de l équipe contre les intrusions venant de l extérieur. - page 43 -

44 Comment l équipe a-t-elle appliqué la méthode Scrum? Comparaison Méthode Scrum / fonctionnement de l'équipe. Méthode (principes, acteurs, ) Equipe Statut Commentaires Itérations à durée fixe (durée 2 sem à 1 mois) Planifier, quantifier (estimation / vélocité) Stand-up quotidien Backlog du sprint - Découpage en tâches. Backlog du produit global Propriétaire du produit (product-owner) Scrum-master Développeur Equipe pluridisciplinaire / auto-organisée Revue de sprint (démonstration) Rétrospective de sprint (amélioration par le retour d'expérience du sprint précédent) Burndown chart Proximité de l'équipe sur le même site PO intégré à l'équipe. 2 semaines ok (Planning poker) 2 par semaine ok ok ok ok ok (l'équipe) ok ok ok ok (Scrumwise) not ok not ok Réactivité dégradée. Blocages gérés à mi-sprint. Rôle tenu par chaque membre de l'équipe. Bémol sur son rôle de gestion des priorités dans le backlog > équipe "passive" Vs PO Non pratiquée à tous les sprints, sources d'amélioration pas exploitées. Burndown non exploité réellement car le rôle de scrum-master n'a pas été tenu par la même personne pendant le projet Limitation des échanges, vélocité ralentie. Pas de validation intermédiaire. Attente réponse fin de sprint. Efficacité diminuée. Conclusion : l'adaptation de la méthode par l'équipe a bien fonctionné. Point positif : L'équipe auto-organisée et soudée a livré les produits souhaités par le product owner. Point négatif : Le fait que l'équipe (y compris le product owner) ne travaille pas à 100% sur le projet et au même endroit, a ralenti le rythme des prises de décisions. Figure 32 : Tableau de l'application de Scrum par l'équipe - page 44 -

45 4 LES PRODUITS 4.1 Le site Internet Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Janvier 2013 Février 2013 Mars 2013 Avril 2013 Mai 2013 Figure 33 : Représentation par sprint de l'humeur de l'équipe pour le site Internet Sprint 1 : Elaboration de la maquette Sprint 2 : Ergonomie du site Sprint 3 : Mise en ligne des questionnaires sur WordPress et Ergonomie Sprint 4 : Tests sur LimeSurvey et changement d hébergeur Sprint 5 : Intégration de LimeSurvey à WordPress et du logo Sprint 6 : Finalisation du site pour le pré-test Sprint 7 : Corrections suite au pré-test et hébergement définitif Sprint 8 : Corrections et transfert de compétences Le contexte Dans le cadre de ce projet, notre product owner était ouvert à toute proposition pour la diffusion et la récolte des données. Nous avons constaté que l ADIRA récoltait des données via des questionnaires au format Excel qui était envoyés par mail, puis certainement dépouillés et gérés manuellement. Cette solution, simple à mettre en œuvre, ne nous paraissait pas exploitable pour des enquêtes multiples et sur une grande échelle. D autant que le projet portait sur la mise en place de l observatoire et son alimentation à partir des données récoltées. Notre cursus de formation, orienté sur la gestion des systèmes d information, nous a amenés à proposer une solution automatisé et scalable, une fois déployé pour 10 capable de le déployer pour 1000, et plus (cf. «Le signe Noir» dans la partie REFERENCES page 81). En consultant les autres observatoires nous sommes arrivés à la conclusion que le site Internet était indispensable afin de rendre la collecte, la saisie, le traitement et la diffusion plus efficaces. Comment répondre à la mise en œuvre de l observatoire? Nous avons soumis cette idée à nos product owners qui ont été conquis. Ceux-ci nous ont demandé de faire une maquette afin de leur soumettre un produit. La maquette était simple, fonctionnelle, basé sur WordPress, et sans contenu (cf. Annexe 2 page 89 et Annexe 3 page 90). - page 45 -

46 "Des logiciels opérationnels plus qu une documentation exhaustive" Deuxième valeur de l Agile Manifesto - agilemanifesto.org Lors de la démonstration du premier sprint, en lien avec la deuxième valeur de l Agile Manifesto, la maquette a été présentée à nos product owners. Ceux-ci ont tout de suite adhéré à ce concept, en phase avec l une des valeurs agile. Cette maquette couvrait un certain nombre de besoins de nos product owners, elle a permis l exploration des fonctions nécessaires à la gestion de questionnaires. Sur cette base nos product owners nous ont rapidement proposé des user stories afin d alimenter notre premier backlog. Les principales user stories étaient les suivantes : - Pouvoir administrer le site Internet sans connaissances particulières en informatique. - Pouvoir créer un questionnaire via une interface d administration. - Permettre de diffuser et de remplir le questionnaire. - Pouvoir diffuser les résultats des enquêtes. - Un design attirant So sexy. Nous en avons déduit trois axes de travail principaux : - Gestion du site Internet. - Gestion des questionnaires. - Design. Nous allons justifier, par la suite, nos choix sur le site Internet et verrons plus en détails les outils utilisés pour répondre aux besoins Le site en général Un site Internet est un puissant outil de communication. C est une façon unique de partager avec le monde et cela permet de toucher un maximum de personnes tout en étant le moyen le plus économique. Lors de la création du site, il nous a fallu garder en tête le but du projet, car il est facile de se limiter à l aspect esthétique et économique (bien que ces points soient importants). Les utilisateurs ne visitent pas un site seulement parce qu'il est beau : s'ils le font pour cette seule raison, ces visites n'ont qu'une importance secondaire et sont souvent uniques. Figure 34 : Page questionnaires de l Observatoire de l agilité - page 46 -

47 Dans le cadre du projet nous devions rester focalisés sur l objectif de l observatoire (diffusion, partage, récolte des données...). Le challenge était de fournir un produit de gestion et publication des questions répondant à un certain nombre de critères, dont : Gérable et administrables par des non-spécialistes en informatique. Rapide à mettre en place. Configurable et paramétrable, sans développement. Peu coûteux, voire gratuit Être dans nos compétences. Peu exigeant pour l hébergement. Compatibilité avec le site de l ADIRA. Les inconvénients de la mise en place d un site Internet : - Disposer de compétences techniques (hébergement, base de données, programmation). - Temps de développement (compter vingt à vingt-cinq jours). - Entretien et évolution du site. "Des logiciels opérationnels plus qu une documentation exhaustive." Deuxième valeur de l Agile Manifesto - agilemanifesto.org L équipe a livré un logiciel opérationnel et testable, au lieu d un volumineux document de spécifications, toujours en appliquant la deuxième valeur de l Agile Manifesto. Afin de pouvoir effectuer la cartographie du système livré, et de proposer un schéma d'urbanisation aligné sur des objectifs entreprise, nous sommes partis d hypothèses qui sont uniquement là dans un but démonstratif ; elles ne reflètent pas des informations émanant de l'adira. La mise en œuvre d'un observatoire n'étant pas un acte anodin de la part d une organisation, nous avons fait les suppositions suivantes : La stratégie business : Étendre le rayonnement de l'adira en tant que référentiel des pratiques et méthodes liées au management des Systèmes d Information. Capter de nouveaux adhérents par des recommandations sur la mise en œuvre de pratiques agiles dans des domaines peu explorés. Augmenter la capacité d'expertise des pratiques dans le domaine du Système d Information. Objectif stratégique : Perfectionner la gestion des campagnes de questionnaire et leur diffusion auprès des adhérents. Améliorer la vitesse, l ergonomie et la qualité de traitement des questionnaires pour les adhérents. - page 47 -

48 Standardiser le processus de collecte, analyse et diffusion des questionnaires. La mise en œuvre des objectifs stratégiques permettrait d agir directement sur les ROI suivants : Conserver et gagner des adhérents. Optimiser le nombre de personnes pour le traitement de données. Sur la page ci-après, notre diagramme de cause à effet dont le but est de définir l objectif stratégique du site Internet de l observatoire. - page 48 -

49 Figure 35 : Diagramme de cause à effet - page 49 -

50 Et enfin le flux complet de la création d un questionnaire jusqu'à la diffusion du rapport d analyse : Création questionnaire Invitations des participants Mise en place des accès aux questionnaires Participation via un token Remplissage questionnaires Collecte Analyse Diffusion ADHERENT Figure 36 : Flux complet de la création d'un questionnaire Pour le site Internet nous avons privilégié WordPress qui permet de: Mettre en place rapidement le site. Répondre aux besoins du product owner. Proposer un stock important de thèmes visuels. Quant à la partie questionnaire, dans un premier temps nous sommes partis sur une extension WordPress (Survey and Quizz Tools). Pendant l avancement du projet, le produt owner nous a demandé des spécificités de plus en plus compliquées à mettre en œuvre. Finalement, les produits que nous avions mis en place, notamment la partie questionnaires, ne répondaient plus aux besoins client. Afin de répondre aux demandes, nous avons dû changer de produit et nous nous sommes orientés vers LimeSurvey. - page 50 -

51 4.1.3 Les outils WordPress Le site Internet principal, ou portail, s appuie sur WordPress, c est un système de gestion de contenu de la catégorie des Content Management System. Ils permettent : Créer Adapter Modifier CMS Moduler Diffuser Gérer Figure 37 : Représentation d'un CMS Ces logiciels ne nécessitent aucune installation sur les ordinateurs, un simple navigateur Internet (Firefox, Internet Explorer, Chrome, etc) suffit. En contrepartie, pour que le monde entier puisse profiter du contenu rédactionnel, ce logiciel nécessite d'être hébergé sur un «serveur» accessible sur Internet, il faut donc louer un «espace Internet» ou une machine chez un «hébergeur». Mais une fois installés et configurés, les CMS peuvent être utilisés et administrés sans nécessiter de compétences informatiques spécifiques. Le choix s est porté sur WordPress, pour les raisons suivantes (cf. Annexe 4 page 91 ): C est le logiciel utilisé par le site Internet de l ADIRA, avec possibilité de réutilisation d existants. Le produit est connu et maîtrisable par des techniciens de l équipe projet. Possibilité d intégrer une extension «Réseau Social» interne à WordPress. Passerelle existante avec LimeSurvey, même si en début de projet cet outil n était pas notre premier choix. WPSurvey&Quiz Tool Les possibilités de l extension de gestion de questionnaire intégré à WordPress, WPSurvey&Quiz Tool, ont rapidement montré ses limites au cours de la validation des produits en fin de sprint. - page 51 -

52 Les besoins de gestion autour de la conception et l administration des questionnaires sont devenus plus importants. Cette prise de conscience du client sur ce sujet a pu avoir lieu grâce à la livraison rapide d un logiciel fonctionnel : on retrouve là encore l esprit et la force des méthodes agiles. Cela a permis au client de toucher du doigt les problématiques concrètes posées par la gestion de campagnes, et ainsi de le faire évoluer dans ses exigences. Pour nous s est présentée l occasion «d accueillir positivement des changements de besoins tardifs» dans l esprit du deuxième principe du Manifeste Agile. LimeSurvey Une fois le constat des limites de WPSurvey&Quiz Tool passé, nous avons proposé et mis en place un logiciel plus complet de gestion de questionnaires : LimeSurvey. Ce produit est complètement autonome et indépendant de WordPress, il permet un couplage lâche avec WordPress, au sens Service Oriented Architecture (SOA), c est à dire que chaque système est peu ou pas dépendant de l autre, LimeSurvey peut fonctionner sans WordPress, et réciproquement. L interface se fait par l intermédiaire de la gestion des comptes utilisateurs de WordPress. En effet, via une extension nommée SurveyPress, ce dernier permet de gérer l accès à LimeSurvey tout en définissant des droits spécifiques (administrateur, lecteur, participant, créateur). Les fonctions proposées par LimeSurvey sont bien plus étendues et complètes (cf. Annexe 5 page 92). Figure 38 : LimeSurvey Dans les points forts, nous avons retenu : Il est «open source». La possibilité de gérer des questions conditionnées par les réponses précédentes, cela permet d adapter le questionnaire en fonction des réponses. Dans notre cas, cette fonctionnalité a servi pour le questionnaire Scrum. En effet si la réponse à la première question, qui est «Connaissez-vous Scrum?» est «Non», il n y a aucun intérêt à faire dérouler le reste du questionnaire. Les possibilités d exportation pour le traitement des données (qui sont complètes et filtrables). Thèmes et rapports personnalisables, moyennant des compétences de développeur. - page 52 -

53 4.1.4 Logo spécifique Nous avons évoqué, au début du projet, la création d un logo. La notion d observatoire et de vision a inspiré sa création. Il a été dessiné spontanément par un membre de l équipe (influence du cours de créativité sur la personne ayant le plus le sens graphique du groupe). Bien que cette tâche n ait pas été identifiée dans le backlog, l équipe puis le product owner ont validé l idée et une user story a été injectée dans le sprint trois. L Agile Manifesto tient une place centrale dans l œil en lien avec le référentiel des agilistes. Figure 39 : Logo de l'observatoire de l'agilité Il est complété par quelques pratiques agiles mettant en valeur la diversité de ce nouvel état d esprit. L équipe a fait appel à un infographe pour le retranscrire numériquement. Nous avons apprécié de déléguer cette tâche à un professionnel, nous permettant de nous focaliser sur la conduite de projet. 4.2 Les bonnes pratiques et recommandations La charte de bon fonctionnement Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Janvier 2013 Février 2013 Mars 2013 Avril 2013 Mai 2013 Figure 40 : Représentation par sprint de l'humeur de l'équipe pour la charte de bon fonctionnement Sprint 3 : création de la charte de bon fonctionnement du site Sprint 4 : Suite et fin de la charte Sprint 7 : validation par le product owner Le site Internet étant validé par tous les membres de l équipe y compris le client, il nous a paru évident de créer une «charte de bon fonctionnement» (cf. Annexe 6 page 93). C est un «contrat» passé entre le site et l utilisateur qu il soit simple visiteur, membre ou administrateur. Lors de la création d un site Internet, l administrateur se doit de donner la bonne marche à suivre, les règles à respecter pour les visiteur et membres du site de l Observatoire de l Agilité. Cela permet également de définir le périmètre de responsabilité de chacun dans le but de protéger l Observatoire de l Agilité et d'asseoir sa crédibilité. La charte développe les points suivants : - L objectif - Les destinataires - page 53 -

54 - Rappel de l objectif de l Observatoire de l Agilité - La gouvernance du site - Modalité et fonctionnement de l Observatoire - Modification de la charte Nous avons porté une attention particulière à ces chartes de bon fonctionnement (url dans la partie REFERENCES page 81) : - Mairie de Sceau - Union Marocaine pour la Qualité - Observatoire des Métiers de la Presse - Site du Zéro La CNIL Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Janvier 2013 Février 2013 Mars 2013 Avril 2013 Mai 2013 Sprint 3 : La CNIL Figure 41 : Représentation par sprint de l'humeur de l'équipe pour la CNIL Lors de la conception des questionnaires, notre product owner nous a demandé une authentification des interviewés. Pour cela nous devons récolter des données personnelles et les stocker dans une base sécurisée. La loi française stipule, dans ce cas, de déclarer le site Internet auprès de la Commission Nationale de l'informatique et des Libertés (CNIL). L équipe a donc implémenté une nouvelle tâche durant le projet afin de répondre à cette problématique. Les recherches se sont portées essentiellement sur le site de la CNIL. Pour la déclaration officielle du site de l Observatoire de l Agilité, nous avons dû chercher les documents à remplir (cf. - page 54 -

55 Annexe 7 page 95, Annexe 8 page 96, Annexe 9 page 97 et Annexe 10 page 98), toutes les informations nécessaires sont disponibles sur le site de CNIL. Liste des différents points dont relève l observatoire : - Les obligations : la sécurité des fichiers, la confidentialité des données, la durée de conservation des données, l information des personnes, la finalité des traitements et l autorisation de la CNIL permettant la récolte des informations personnelles. - L observatoire : statut par rapport l ADIRA (couvert par l ADIRA, indépendant de l ADIRA, ), identité du responsable légal, identité du responsable ou service du traitement, service et adresse où les personnes peuvent exercer leur droit d accès, de modification, de rectification et de suppression des données les concernant, destinataire(s) des données, finalité d un traitement informatique des données personnelles : - Les données : le déclarant, organisme ou personne chargé de la mise en œuvre, le chargé peutêtre identique au déclarant, finalité, données traitées, données sensibles (facultatif), sécurité, transfert des données hors UE, interconnexions, droits d accès, contact, identification du responsable, validation et envoi - Information : formulaire de collecte des données, informations destinées aux adhérents, note d information à afficher Les licences et copyrights Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Janvier 2013 Février 2013 Mars 2013 Avril 2013 Mai 2013 Figure 42 : Représentation par sprint de l'humeur de l'équipe pour les licences et copyrights Sprint 5 : recherche des types de licences et validation par le product owner Le product owner a demandé de pouvoir «mettre à disposition le rapport d analyse, en format pdf, à tous les membres et visiteurs de l observatoire». Pour une question de protection des données, nous avons préconisé à notre client une licence afin de prévenir des dangers du piratage. L Observatoire est un lieu d analyse, de partage, de communication, il se doit d être intègre et d être une référence dans le domaine de l Agilité. Dans ces conditions il est important, essentiel et nécessaire de protéger les données exposées sur Internet. Après quelques recherches sur Internet, nous avons soumis 6 licences «Creative Commons» à notre client. Elles sont gratuites, courantes, reconnues dans le monde Internet et homologuées juridiquement. - page 55 -

56 Notre client a retenu la licence suivante parmi les licences ci-après : Attribution - Pas d Utilisation Commerciale - Partage dans les Mêmes Conditions CC BY-NC-SA Cette licence permet aux autres de remixer, arranger, et adapter votre œuvre à des fins non commerciales tant qu on vous crédite en citant votre nom et que les nouvelles œuvres sont diffusées selon les mêmes conditions. Cela permettra de partager, d échanger tout en faisant connaître l observatoire grâce à la citation obligatoire de celui-ci. Désormais la licence CC-BY-NC-SA est intégrée à tous les documents publiés sur et part l Observatoire de l Agilité, les rapports, les synthèses, les analyses. Cette licence est spécifiée dans la charte de bon fonctionnement du site Internet de l Observatoire de l'agilité. Voici les différentes licences existantes : Attribution - CC BY Cette licence permet aux autres de distribuer, remixer, arranger, et adapter votre œuvre, même à des fins commerciales, tant qu on vous accorde le mérite de la création originale en citant votre nom. C est le contrat le plus souple proposé. Recommandé pour la diffusion et l utilisation maximales d œuvres licenciées sous CC. Voir le Résumé Explicatif Voir le Code Juridique Attribution - Partage dans les Mêmes Conditions - CC BY-SA Cette licence permet aux autres de remixer, arranger, et adapter votre œuvre, même à des fins commerciales, tant qu on vous accorde le mérite en citant votre nom et qu on diffuse les nouvelles créations selon des conditions identiques. Cette licence est souvent comparée aux licences de logiciels libres, open source ou copyleft. Toutes les nouvelles œuvres basées sur les vôtres auront la même licence, et toute œuvre dérivée pourra être utilisée même à des fins commerciales. C est la licence utilisée par Wikipédia ; elle est recommandée pour des œuvres qui pourraient bénéficier de l incorporation de contenu depuis Wikipédia et d autres projets sous licence similaire. Voir le Résumé Explicatif Voir le Code Juridique Attribution - Pas de Modification - CC BY-ND Cette licence autorise la redistribution, à des fins commerciales ou non, tant que l œuvre est diffusée sans modification et dans son intégralité, avec attribution et citation de votre nom. Voir le Résumé Explicatif Voir le Code Juridique Attribution - Pas d Utilisation Commerciale - CC BY-NC Cette licence permet aux autres de remixer, arranger, et adapter votre œuvre à des fins non commerciales et, bien que les nouvelles œuvres doivent vous créditer en citant votre nom et ne pas constituer une utilisation commerciale, elles n ont pas à être diffusées selon les mêmes conditions. Voir le Résumé Explicatif Voir le Code Juridique Attribution - Pas d Utilisation Commerciale - Partage dans les Mêmes Conditions - CC BY-NC- SA Cette licence permet aux autres de remixer, arranger, et adapter votre œuvre à des fins non commerciales tant qu on vous crédite en citant votre nom et que les nouvelles œuvres sont diffusées selon les mêmes conditions. Voir le Résumé Explicatif Voir le Code Juridique Attribution - Pas d Utilisation Commerciale - Pas de Modification - CC BY-NC-ND Cette licence est la plus restrictive de nos six licences principales, n autorisant les autres qu à télécharger vos œuvres et à les partager tant qu on vous crédite en citant votre nom, mais on ne peut les modifier de quelque façon que ce soit ni les utiliser à des fins commerciales. Voir le Résumé Explicatif Voir le Code Juridique - page 56 -

57 4.2.4 Analyse, exploitation, rédaction des résultats Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Janvier 2013 Février 2013 Mars 2013 Avril 2013 Mai 2013 Figure 43 : Représentation par sprint de l humeur de l équipe pour les bonnes pratiques de récoltes des données Sprint 2 : Recherche information sur les feedbacks Sprint 4 : Recherche d exploitation de résultats des autres observatoires Sprint 6 : Squelette analyse de données Ce sujet a été traité à trois reprises durant le projet, l objectif étant de créer un livrable qui permet d exploiter les données collectées. Lors de nos différentes recherches, nous avons constaté qu il y avait de multiples astuces, mais pas véritablement de méthodes reconnues. Cependant, nous avons identifié des axes de traitement : Description Enjeu 1 L analyse et le reporting. Permettre une première synthèse de tous les résultats engrangés par la campagne de questionnaire. 2 Le traitement d un échantillonnage. Avoir un minimum de personnes pour avoir une marge d erreur connue et acceptable. 3 La retranscription des résultats. Respecter certaines règles pour ne pas laisser de côté les potentiels lecteurs : - Rappel de l objectif - Présenter des graphiques sous différentes formes : histogramme, secteurs, barres, courbes... - Rappeler l'échantillon de population - Afficher le total des personnes qui ont répondu. - Faire ressortir les chiffres les plus importants. - Prévoir un emplacement pour débattre sur les résultats : RSE 4 Une bonne définition du périmètre. Récupérer les données auprès des bonnes cibles. Dans notre cas ce sont les entreprises de l ADIRA que nous allons interroger dans un premier temps. 5 Les pertes potentielles, ou non-réponses. 1) Conserver les non réponses (NR): - lorsque celles-ci sont importantes et qu elles apportent une information ou une opinion intéressante. - quand elles indiquent que la question était trop difficile à comprendre. 2) Supprimer les NR lorsque celles-ci sont faibles et n apportent pas d informations intéressantes. Figure 44 : Axes de traitements pour une bonne collecte de données Avant lancement d une campagne de questionnaire, effectuer un pré-test. Il permet de : - vérifier la bonne compréhension des questions - tester l enchaînement des questions - vérifier l absence d oubli dans les modalités de réponse - mesurer le temps moyen d administration Les résultats du pré-test sont exclus de l analyse globale. - page 57 -

58 4.2.5 Création des questionnaires Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Janvier 2013 Février 2013 Mars 2013 Avril 2013 Mai 2013 Figure 45 : Représentation par sprint de l'humeur de l'équipe pour les bonnes pratiques de création de questionnaires Sprint 1 : recherche des bonnes pratiques de création de questionnaire Sprint 2 : création du questionnaire avis des testeurs Les recherches ont été réalisées en binôme, afin de confronter les sources et les conclusions. Cette tâche supplémentaire a été intégrée au backlog sur l initiative de l équipe, pour permettre la cohérence de la forme avec le fond des questionnaires. Le résultat de ces explorations sur Internet a produit une synthèse, validée par l équipe et mise en œuvre dans la conception des questionnaires. 1 Préciser l objectif et l enjeu. 2 Contenu du questionnaire : Description Commencer par des questions ouvertes puis affiner sur des fermées. Quantité maximum de questions à répondre : 20 questions. Ne pas dépasser 10 à 15 minutes de temps de saisie des réponses. Mélanger le type et la nature des questions (ouverte/fermée/question à choix multiples/ ). Le questionnaire doit être presque entièrement visible sur une page. Enjeu Faire une courte introduction pour situer le contexte du questionnaire. Principe de l'entonnoir : débuter par des questions générales, avant d'épurer par des questions précises. Ne pas perdre la personne interviewée. Avoir un questionnaire qui donne envie, convivial et varié. Soigner la formulation et impliquer les interviewés. Avoir des questions compréhensibles, et faire en sorte que les personnes qui répondent se sentent concernées. Graduer les questions de 1 à 4. Forcer l'interviewé à se positionner : la graduation impaire propose une position neutre qui n'est pas exploitable. 3 Pré-tester le questionnaire. Avoir un retour extérieur sur une V1, prendre en compte les 4 Recueillir l'avis des interviewés. retours dans le but d'améliorer le questionnaire avant sa mise en ligne. 5 Faire une courte conclusion au questionnaire. Notion de courtoisie. 6 Remercier les personnes qui ont répondu. Donner une information sur ce qui va être produit à partir du dépouillement des réponses. Figure 46 : Tableau des six bonnes pratiques pour la création de questionnaires Essentiel! Les points 3 et 4 sont incontournables, pour avoir une vision externe, avant la mise en production. - page 58 -

59 Nous avons porté une attention particulière à ces bonnes pratiques de création de questionnaires (url dans la partie REFERENCES page 81) : - Paperblog - Formaeva - Blog Stratégie Marketing - Questionnaires en lignes du Rectorat l académie de Nancy-Metz - Surveystore Cette liste de bonnes pratiques a constitué un guide dans la conception des questionnaires créés pour alimenter l Observatoire de l Agilité. 4.3 Les questionnaires Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Janvier 2013 Février 2013 Mars 2013 Avril 2013 Mai 2013 Figure 47 : Représentation par sprint de l humeur de l équipe pour les questionnaires Sprint 1 : Questionnaire au format Excel de façon générale. Sprint 2 : Éclatement du questionnaire en plusieurs questionnaires distincts. Sprint 3 : Mise en ligne et tests des questionnaires sous WordPress. Sprint 4 : Corrections des bugs et reformulations des questions. Sprint 5 : Migration sous LimeSurvey, tests, corrections et reformulations des questions. Sprint 6 : Préparation du pré-test au Club Agile Rhône-Alpes. Sprint 7 : Rétrospective du pré-test et corrections. Sprint 8 : Corrections et reformulations définitives. Entre l affectation de notre cas fil rouge, mi-décembre 2012 et le premier sprint, mi-janvier 2013, nous avons effectué des recherches sur des observatoires existants. Plusieurs d'entre eux ont retenu notre attention (url dans la partie REFERENCES page 81) : - L Observatoire du Numérique - L Observatoire Scientifique de la Vallée du Galeizon Il existe différentes méthodes pour effectuer une enquête : - Le démarchage téléphonique. - Le démarchage à domicile. - Le partenariat. - Le formulaire en ligne. Elles reposent toutes sur un questionnaire. - page 59 -

60 Le questionnaire étant l outil de collecte de données avéré, nous avons décidé d étudier les bonnes pratiques en termes de construction d enquête, d observation et d exploitation des données récoltées. Les recherches effectuées nous ont permis de recueillir un certain nombre de règles à respecter. Nous avons retenu les plus pertinentes en corrélation avec notre sujet (cf Création des questionnaires page 58). Les deux règles qui nous ont paru les plus judicieuses sont : - De faire plusieurs petits questionnaires. - Que la saisie des réponses ne dépasse pas 15 minutes, au risque de perdre l attention des personnes questionnées, le but étant d avoir un questionnaire dûment complété. Le choix de découper notre enquête en multiple sondage s est donc imposé. Nous avons démarré notre démarche par la construction de deux questionnaires, l un portant sur Scrum et l autre portant sur l Agile Manifesto. Nous avons commencé à saisir ces deux questionnaires au format Excel qui est un standard presque universel. Le questionnaire Scrum Nous avons commencé par nous poser les questions suivantes : "Mon projet est-il agile?" "Puis-je mesurer mon niveau d agilité?" L équipe EMSI Les réponses trouvées ont permis d'engranger beaucoup d informations et de créer un questionnaire assez conséquent. Lors du mi-sprint, nous nous sommes aperçus que Scrum est un sujet très vaste. L équipe s est rendue compte que cette tâche a été sous-estimée en termes de temps et de complexité. Malgré la formation dispensée par Jean-François, l équipe n a pas réussi à quantifier correctement cette tâche. Nous avons donc décidé de représenter Scrum graphiquement et de définir les termes associés avant de poursuivre le questionnaire (cf. Figure 17 page 34). Par conséquent, cette tâche n a pu être terminée à la fin de la première itération. Lors de la démonstration de fin de sprint, nous avons livré un questionnaire Scrum de plus de quatre-vingt questions abordant seulement vingt pour cent du périmètre. - page 60 -

61 Suite à cette démonstration et en accord avec le product owner, le questionnaire Scrum a été découpé en trois questionnaires ; un questionnaire Scrum, un questionnaire Entreprise, et un questionnaire Avis des testeurs. Ce nouveau découpage va dans le sens d une des bonnes pratiques préconisées : quinze minutes par questionnaire. Le questionnaire Scrum basique Le product owner souhaitait que les questions aient une tournure didactique afin de ne pas mettre l interviewer en défaut par rapport à ses pratiques personnelles. Le résultat est un enchaînement de vingt-sept questions durant environ huit minutes. Le questionnaire Entreprise L objectif principal de ce questionnaire est de connaître l identité de la personne répondant ainsi que les données administratives de son entreprise. L identification permet de faire le lien avec d autres sondages et doit, lors de futures campagnes, ne pas reposer systématiquement les mêmes questions. Les objectifs secondaires sont de ne pas perdre un questionné et de le fidéliser. Le questionnaire Avis des testeurs Accueillez positivement les changement [...]. Les processus agiles exploitent le changement pour donner un avantage [...] Deuxième Principe de l Agile Manifesto - agilemanifesto.org L amélioration continue et la remise en question font référence au deuxième principe de l Agile Manifesto. Dans un souci d amélioration continue, nous avons créé un questionnaire permettant aux interviewés de s exprimer ouvertement, de noter le contenant ainsi que le contenu, et de proposer des idées ou axes d améliorations. Les avis extérieurs permettent d'accéder à des domaines jusqu alors non étudiés ou non exploités. Pour cela nous avons fait appel à l expérience de Monsieur Marc Prunier, Professeur à Grenoble Ecole de Management, sur le sujet de la Quality of Services (QoS). Il a accepté de nous assister sur la formulation des questions afin d obtenir des réponses pertinentes. Le fait de valoriser les interviewers et prendre en compte leurs remarques permet d une certaine façon de les fidéliser. - page 61 -

62 Le questionnaire Agile Manifesto Les quatre principes et douze valeurs de l Agile Manifesto nous ont demandé un investissement sous-estimé en complexité. Il été très difficile de s approprier les concepts pour les restituer dans un questionnaire. L Agile Manifesto est le seul cadre de référence commun aux pratiques agiles. Il est considéré comme une «Loi» par certain agilistes. La construction de ce questionnaire s est déroulée sur les trois premiers sprints par une démarche itérative et par un processus d amélioration, visant une construction graduelle, comme la méthode Kaizen le décrit. "Le mot Kaizen est la fusion de deux mots japonais : KAI (changement) ZEN (bon)." Wikipédia Le questionnaire permet de mesurer le degré de compréhension, d appropriation et d adhésion des entreprises sondées à ces valeurs et principes. Pour améliorer la pertinence des résultats, nous avons travaillé sur la formulation, l orientation et le type de questions, puis sur le format des champs réponses. (cf Création des questionnaires page 58). Nous avons ensuite retranscrit sous Excel chaque question ainsi que les réponses associées. Chaque questionnaire a été testé, chronométré et approuvé par l ensemble de l équipe puis validé à la fin du second sprint par le product owner (cf. Annexe 11 : Extrait du questionnaire Scrum basique au format Excel dans son intégralité page 99). Le transfert des questionnaires sur notre site de développement a eu lieu lors du troisième sprint. Durant cette période, la prise en main de l outil WordPress gérant les questionnaires sur notre site a nécessité une brève formation des membres de l équipe. Lors de cette mise en ligne, nous avons rapidement détecté des problèmes techniques de mise en forme, tels que des retours chariot en surnombre et des slashs (/) à la place des apostrophes. Des interrogations sur la forme sont également apparues, telles que la numérotation des questions, la casse, les questions imbriquées ou encore les questions obligatoires. Suite au changement de l outil de sondage, lors du cinquième sprint, nous avons remis en ligne les questionnaires ; pour des raisons d efficacité, la migration a été effectuée par deux membres de l équipe maîtrisant l outil LimeSurvey. A la demande du product owner, les tâches demandées des deux derniers sprints ont scindé l équipe en deux. Il s agissait plus d un travail de mise en forme nécessitant la maîtrise de LimeSurvey qu un travail de fond sur les questionnaires. Se sont retrouvées d un côté les personnes ayant un savoir-faire sur l outil et de l autre côté, le reste de l équipe témoin des dernier changements du projet. - page 62 -

63 4.4 Livret de formation et transfert à l ADIRA Site Internet de l Observatoire Afin de pouvoir gérer de façon autonome le site Internet, nos product owners ont souhaité, au moins dans un premiers temps, s occuper de la gestion de ce site. L exploitation du site étant basée sur Wordpress et complètement pré-paramétrée, le site est donc immédiatement utilisable, au moins d un point de vue technique. Les opérations de gestion sont transférables telles quelles aux équipes internes ou externes de l ADIRA : leur site principal étant déjà sous Wordpress, il n y a pas besoin de compétences supplémentaires. Pour LimeSurvey, le logiciel de gestion des questionnaires, un accompagnement plus poussé devait être fait. Ce transfert de compétence a été complété avec quelques vidéos sur les fonctions de base. À noter que la préconisation et le choix de LimeSurvey ont été conditionnés par le fait que leur site propose une abondante documentation, au bémol près que celle-ci est essentiellement en anglais. Par manque de temps nous n avons pas réalisé la totalité des modules de formations. En effet, ces derniers auraient dû être effectués en amont du projet avec des mises en pratique afin de s assurer que les product owners soient complètement autonomes. Au vu des connaissances acquises par les product owners il est évident qu un accompagnement de la part de l équipe sera nécessaire, pour mener à bien la ou les premières campagnes de questionnaires Exploitation des résultats LimeSurvey Limesurvey intègre un générateur de rapport, permettant de sortir les résultats, soit au format HTML en ligne et interactif, soit au format PDF, téléchargeable. L export au format Excel n a pas été oublié, et permet de sortir toutes les données d une enquête à la demande, même si la campagne n est pas terminée. Toutes les données peuvent être exportées soit en totalité, soit partiellement. LimeSurvey propose un filtrage assez complet et puissant. Ce filtrage s applique aussi bien pour les rapports que pour les exportations de données. Figure 48 : exemple de graphique au format directement utilisable en ligne - page 63 -

64 4.4.3 Les bonnes pratiques et recommandations de la gestion d un observatoire "Le principe même de l observatoire mise sur l enrichissement de la base de données au fur et à mesure des années pour constituer un référentiel historique et pouvoir ainsi comparer les années, étudier les concomitances d évènements pour aider à la compréhension des mécanismes. [ ]" Extrait du «Guide de recommandations pour l'élaboration d'un observatoire territorial des pratiques agricoles» Nos recommandations, compte tenu de notre expérience et des pratiques constatées, sont les suivantes : - Passer par une phase de maquette le site actuel : l expérience d autres observatoires montre qu il faut compter de un à deux ans pour la mise en place d un observatoire. - Étaler les campagnes, afin de d avoir le temps de récolter, d analyser, exploiter et diffuser les rapports. Établir une fréquence de mise à jour de ces données vers les utilisateurs. - Ne pas diffuser les statistiques récoltées à travers les questionnaires sans analyse préalable par les experts du domaine concerné, cela permettra d intégrer des synthèses et des interprétations pertinentes dans les rapports, ce qui fait partie intégrante de la valeur ajoutée de l observatoire. - Planifier la mise en place d un bilan au bout d une période significative, à déterminer en fonction de la mise en œuvre des différentes fonctionnalités. Le bilan devra permettre de valider la pérennité et la perspective d évolution de l observatoire. - Une fois l observatoire établi, et dans l optique de le garder pérenne, mettre en place un espace personnel pour les utilisateurs, afin que ceux-ci puissent échanger, partager. Cela peut être rendu possible par la mise en place d un RSE. 4.5 Ce qui n a pas été traité : analyse et exploitation des résultats Le travail réalisé par l ensemble de l équipe a permis de livrer un produit opérationnel techniquement, mais aussi un ensemble de guides de bonnes pratiques nécessaires à la conception de questionnaires. Ce produit permet dès aujourd hui de lancer une campagne et de collecter les résultats brut, et de sortir un rapport standard au format PDF ou une page WEB en ligne. Cependant la valeur apportée par l observatoire vis-à-vis des utilisateurs portera sur l interprétation, les commentaires, et les recommandations d experts autour de ces résultats. Les données fournies au moins pour un premier cycle ne permettront d avoir qu une photo instantanée ; ce sont les campagnes suivantes qui permettront de mesurer des évolutions des axes observés. - page 64 -

65 Idéalement le suivi complètement informatique de ce type de données nécessite la mise en place d un système de type BI (Business Intelligence), soit spécifique, soit interfacé avec le système de l entreprise cible. Figure 49 : Représentation multiaxes. Le cube OLAP - blog.soat.fr L objectif de ce type de logiciel étant de fournir des données historisées afin de permettre des analyses multiaxes, le temps étant une des dimensions permettant de faire des analyses comparatives, mais aussi permettant de produire des analyses prospectives pertinentes. - page 65 -

66 5 LES INDICATEURS PROJET 5.1 Les indicateurs de suivi de projet Les indicateurs, en agilité, ne sont pas de même nature que ceux du standard de management PMI. Le pilotage ne se concentre par forcément sur le suivi des indicateurs, il se situe en arrière-plan de la conduite du projet. Dans la pratique de Scrum, l équipe n a pas ressenti le besoin de suivre un ou plusieurs indicateurs. Le suivi des burndowns, au cours des sprints, ont permis de piloter et visualiser un statut à chaque instant du projet. Nous avons privilégié la satisfaction du client et de l équipe de manière intuitive, comme Scrum nous y invite. Nous vous proposons d explorer les indicateurs de notre projet. Vous trouverez ci-dessous une illustration des trois familles d indicateurs de notre projet : Réalisation Equipe Amélioration continue 0 conflit d'équipe Prise de décision commune répartition du travail (cf. Figure 51 page 67) 16% de tâches rejetées par le product owner en fin de sprint 30% des tâches réalsées ont concouru à la qualité des livrables 98% réunions pratiquées au complet "Banane" à chaque réunion Tendance niko-niko (cf. Figure 53 page 68) 100% des tâches visibles par tous (cf. Figure 52 page 68) 100% des rétrospéctives ont été effectuées, Amélioration progressive et continue de la courbe du burndown (cf. Figure 54 page 69 & Figure 55 page 69) Figure 50 : Les indicateurs du projet Observatoire de l Agilité Les calculs du schéma ont été quantifiés par l intermédiaire de notre outil Scrumwise, complétés par la tenue d une liste de réunions, et par le suivi de la pratique du niko-niko. - page 66 -

67 5.1.1 Les indicateurs de livraison Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Total Nathalie Jonathan Thierry Vincent Léma PO Figure 51 : Nombre de tâches produites par membre de l équipe TOTAL 142 La répartition est globalement uniforme, à part pour Jonathan qui se distingue avec un tiers des tâches à son actif, il s agit principalement du développement technique lié au site Internet. Afin de mettre l observatoire en ligne, nous avons affecté des tâches à nos product owners sur les 3 derniers sprints Répartition des tâches Le site de l observatoire est un produit abouti et complet qui correspondant aux demandes du product owner, mais si l on regarde en détail, 39% sur les 203 heures ont été allouées au site de l observatoire. Ce qui nous a paru relativement excessif car le site Internet n est que l outil. Répartition des tâches contenu 61% technique 39% technique contenu - page 67 -

68 5.1.3 Les indicateurs d équipe Scrumwise Les tâches et de leur statut sont visibles en permanence sur le task board de Scrumwise. Cela permet au scrum-master de gérer et de pointer l avancement du projet ainsi qu à l équipe de suivre la progression de l itération. Niko-Niko Figure 52 : vue du task board depuis Scrumwise pour un sprint Figure 53 : vue du Niko-Niko A la fin du sprint 2 le niko-niko a été mis en place et alimenté quotidiennement par chaque membre de l équipe. C est une mesure subjective de l état d esprit de chacun des membres de l équipe. Il a été utilisé par les scrum-masters pour détecter les blocages et les leviers afin améliorer la qualité de vie du projet. - page 68 -

69 5.1.4 Les indicateurs d amélioration continue, le burndown chart Figure 54 : Courbe de burndown du sprint 1 Légende : Figure 55 : Courbe de burndown du sprint 5 - axe des ordonnées : nombres d heures quantifiées par l équipe pour réaliser le sprint - axe des abscisses : nombre de jours constituant un sprint (douze jours) La comparaison des deux courbes (sprint 1 et sprint 5) nous montre deux notions d amélioration : - L évolution de l axe des ordonnées indique que l équipe a su quantifier son temps disponible à la réalisation du projet et progressivement adapter sa capacité de travail. - L évolution de la courbe démontre notre aptitude à ajuster la charge de travail à la quantité totale de jours du sprint. L intégralité des burndown charts est disponible en annexe (cf. Annexe 12 page 100). L équipe a réussi à trouver sa vélocité sur ce projet au sprint 3. L équipe a pratiqué une conduite de projet agile avec des indicateurs adaptés ce qui a permis de livrer au product owner le produit attendu à chaque fin de sprint. "Le meilleur indicateur C est la banane!" Frédéric DUFAU-JOEL, DSI Samse - page 69 -

70 Après avoir identifié plusieurs indicateurs de notre conduite projet, il a fallu en trouver un pour notre produit et plus particulièrement les questionnaires. Comme les bonnes pratiques le préconisent, nous avons lancé un pré-test sur notre site de développement avec une partie des membres du CARA. 5.2 Indicateur produit : le pré-test avec Club Agile ADIRA Au cours du sixième sprint du projet, un pré-test des questionnaires a été réalisé. Dans sa recherche d amélioration continue, l équipe a suivi un «Plan, Do, Check, Act» (PDCA), afin de sécuriser le fond et la forme des questionnaires, base essentielle du projet. DO PLAN o Organisation du pré-test par l équipe : o Détermination du périmètre à tester o Planification des activités de préparation o Validation de l objectif à atteindre o Mise en œuvre des activités planifiées. CHECK o Confrontation des résultats obtenus, avec les objectifs attendus. ACT o Capitalisation et analyse des résultats o Préconisation des bonnes pratiques Figure 56 : le PDCA Plan L équipe a identifié rapidement via une bonne pratique, qu un pré-test permet de valider, contrôler et améliorer un questionnaire. Après la démonstration du sprint 5, notre product owner a accepté d organiser cette instance, réalisée le jeudi 11 avril, à mi-sprint, avec quelques membres du CARA, dans les locaux de la SAMSE. En début de sprint 6, l équipe valide le périmètre, les étapes préparatoires, répartit la charge et définit les objectifs de ce test. Liste des tâches identifiées : - Mise en place des questionnaires sur notre site de développement. - Exécution d une boucle de contrôle interne de l équipe pour vérifier le bon fonctionnement. - Préparation d un support de collecte des points bloquants (organisé et qualifié préalablement). - Préparation d une présentation succincte du projet sur Prezi dans le but d expliquer notre venue. - page 70 -

71 5.2.2 Do Voici comment s est déroulé le pré-test à la Samse Accueil des participants Introduction/présentation de Frédéric DUFAU-JOEL Tour de table des membres du CARA Présentation de l'équipe et du Projet Observatoire de l'agilité. Réalisation du pré-test Accompagnement de l'équipe RED ADIRA Echange de remarques, questions, interrogations sur les questionnaires (fond & forme) puis sur le site Internet. 5 Collecte des informations par chaque membre de l'équipe répartie dans la salle 6 Fin du pré-test. Figure 57 : Déroulement du pré-test à la Samse Check Suite au pré-test, les informations collectées ont été synthétisées dans un tableau (cf. Erreur! Source du renvoi introuvable. page Erreur! Signet non défini.). Nous avons pu établir une liste définitive de : - reformulations, - problèmes techniques, - remarques, - questions manquantes. puis nous les avons priorisés. Sachant qu il restait deux sprints avant la fin du projet, les commentaires et modifications mineures ont été pris en compte par l équipe dans les questionnaires, sans validation du product owner. Les modifications majeures, quant à elles, ont été soumises à son approbation à la fin du sprint Act L équipe a su se diviser pour être plus efficace. Étant en fin de projet, il nous a paru nécessaire de faire réaliser les détails techniques aux deux membres maîtrisant l outil Limesurvey. Les modifications ont été effectuées et validées de nouveau par nos product owners. Pour entériner les ajustements des questionnaires, une deuxième phase de test a été prévue, mais elle ne sera pas conduite par l équipe RED ADIRA, le projet arrivant à son terme. - page 71 -

72 Ce pré-test nous a apporté une réelle avancée dans la validation des questionnaires. La vision extérieure, que nous ont apportée les pré-testeurs, nous a permis de pratiquer l amélioration continue sur cette partie du projet Nous avons pu également dresser une liste de préconisations pour le bon fonctionnement de l Observatoire, qui sera détaillée dans la partie Produit Livret de formation et transfert à l Adira (cf Annexe 13 page 102). - page 72 -

73 6 BILAN 6.1 Humain Dans le bilan, il faut distinguer le résultat de la mise en œuvre du projet d observatoire, et le bilan de l apprentissage de la culture Agile, dont les pratiques et outils associés, comme scrum. Notre manque de connaissance de la culture agile, en phase de démarrage, ainsi que l apprentissage de l outil scrum, avec en simultané, la mise en route du projet observatoire, nous ont fortement ébranlés. Bien que nous ayons bénéficié d un coaching et d un accompagnement dès le départ du projet, il nous a fallu quelques sprints pour nous ajuster. Cette période d adaptation est normale, même pour des équipes expérimentées. Nous avons perçu cela, tout du moins sur le moment, comme une perte de temps. Par le biais de l auto-organisation de l équipe, le manque de productivité apparent du départ c est vite transformé en produits palpable et utilisable. Tous les acteurs du projet résident à proximité de Grenoble. Cette proximité a permis de se rencontrer fréquemment et se connaître plus rapidement. C est une des raisons qui a contribué au choix de la méthode scrum pour notre projet. Une des grandes forces de l équipe a été sa complémentarité, permettant à chacun de trouver sa place et de s exprimer, en fonction de ses envies ou appétences. Afin de renforcer la cohésion de l équipe pour créer un environnement de travail favorable, nous avons décidé de faire une soirée team building. Ce rendez-vous, comme le préconise les bonnes pratiques a permis d échanger et de discuter d autres sujets que le cas fil rouge ou le cursus de formation. Dans notre cas nous avions choisi une soirée bowling, révélateur des profils individuels et de la cohésion de l équipe de par l aspect compétitif et distrayant de l épreuve. Dans le cadre de la mise en œuvre de Scrum, le travail à distance, et par conséquent la difficulté de se retrouver quotidiennement pour les daily stand-up a été un frein important que nous n avons pas identifié suffisamment tôt dans les phases de lancement. En effet, le travail à distance tel que nous l avons expérimenté, entre en opposition à l un des principes de scrum, qui prône une réunion quotidienne en présentiel (malgré les moyens de communications actuels). Notre manque de compréhension initial de la culture agile et des méthodes associées a limité les sollicitations des product owners, en particulier durant les sprints. Au sein de l équipe, nous avons rencontré : - peu de conflits, - beaucoup de discussions, - des reformulations, - page 73 -

74 - des échanges, - de l entraide, - pas de censure, - de l écoute. Cela peut paraître déroutant par rapport aux modes de fonctionnements classiques des projets. Dans «Le guide de Survie à l Adoption ou Transformation Agile» (cf. Ouvrages page 82), il est indiqué que la mise en place de l agilité, et en particulier le choix d une méthode dépend de la culture dominante de l entreprise en question. En effet, dans cet ouvrage, il est indiqué que le «modèle de culture de Schneider» définit quatre types de cultures différentes: 1. La culture de la Collaboration : travailler ensemble. 2. La culture du Contrôle : avoir et garder le contrôle. 3. La culture de la Compétence : être le meilleur. 4. La culture du Développement personnel : apprendre et se développer en visant un objectif ayant du sens. Figure 58 : Modèle de culture de Schneider tiré du «Guide de Survie à l Adoption ou Transformation Agile» On y apprend aussi que suivant la culture de l entreprise il y a des incompatibilités avec la mise en place de certaines pratiques agiles. - page 74 -

75 Entre autre, Scrum n est pas très recommandé et sera difficile à introduire dans une entreprise basé sur une culture du contrôle, c est plutôt Kanban qu il faudra envisager. Transposons cela à notre groupe d étudiant, en nous assimilant à une petite entreprise de cinq personnes, plus nos deux product owners (des Start-up ont commencé à moins!). Dans notre cas de figure, la culture de l équipe issue de la mise en commun des expériences de chacun, de par le fait de vouloir suivre la formation à l EMSI, nous positionne plutôt dans les quadrants 4, voir 3. Et donc d après «le guide de Survie [ ]», nous serions compatibles avec la mise en œuvre de Scrum. 6.2 Les causes de performances et de non performances La fin du cas fil rouge étant arrivé, un bilan s impose, le but de cette partie est de s interroger sur la méthode que nous avons employée et également sur la gestion du sujet de l observatoire. Afin d y répondre nous allons faire le point sur les performances et non performances. 250 Burdown chart HEURE Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 SPRINT Burdown Figure 59 : Représentation des burndown charts par sprint - page 75 -

76 6.2.1 Les éléments de performances Nous avons identifié quatre éléments de performances. 1 -Expériences de l équipe qui s améliore pour l estimation Au lancement du projet lorsque la décision avait été prise de partir en agile, notre product owner, nous a indiqué que l un des avantages de l agilitéétait: toute la charge de travail se déroule en début de projet. Ce fut une agréable surprise de constater que notre projet, d une façon générale, n a pas dérogé à la règle(cf graphique ). La pression, importante au début, a diminué tout au long du projet. Ce constat vient du fait que l équipe s est améliorée dans l estimation des fonctionnalités et que nous répondions correctement au besoin du client. A noter une dérive lors du sprint 1 du à notre apprentissage de l agilité et une lors du sprint 4 suite au passage du plugin WPQuizz&tool à Limesurvey. 2 -Un produit correspondant à la demande du client L'un des avantages majeurs de Scrum est de pouvoir fournir, à chaque fin d'iteration, un livrable, validé par le product owner lui même. La conséquence etant d'éviter l'incompréhension entre l'équipe et le product owner. 3 - Auto-organisation de l équipe l auto-organisation de l équipe. En agilité, on parle d'équipes auto-organisées, les bénéfices que nous avons constatés sont multiples. En organisation traditionnelle, le chef de projet analyse, chiffre et assigne les tâches à son équipe. En agilité, l'équipe prend toutes ses tâches pendant les différentes réunions: planning poker, sprint planning et daily stand-up l'équipe est plus engagée, les chiffrages sont plus justes. Cela permet une grande flexibilité. En effet, connaissant la durée d une tâche, chacun des membres de l équipe se l attribue en fonction de sa charge personnelle et professionnelle durant le sprint. Cette modularité a permis d évoluer dans un cadre idéal renforçant ainsi la cohésion du groupe 4 - Rotation du scrum-master Cette décision a été intéressante d un point de vue humain, elle a permis de faire sortir chaque acteur projet de sa zone de confort, renforçant ainsi, la cohésion du groupe. Figure 60 : Les éléments de performances - page 76 -

77 6.2.2 Les non performances Nous avons également relevé quatre causes de non performances 1 -Problème de communication et réactivité du à notre organisation Il était difficile de partager l'avancement quotidien des différentes tâches. Mais surtout lorsque nous avions un point de bloquage il nous a fallut attendre les fins de sprint. De ce fait les tâches étaient valider sur le tard. 2 - Critère d acceptabilité non defini Malgrè la validation de notre product owner, nous avons recommencé, à plusieurs reprise, cinq tâches : -Le bugdet -Notion de persistance (gestion d'un login/sauvegarde) - Contenu de questionnaire - Charte de bon fonctionnement -CNIL Nous en avons conclu que l'équipe doit progresser dans le domaine du leadership. 3 -Rotation du scrum-master difficulté pour remplir correctement son rôle Nous n avons pas pratiqué les indicateurs dans les règles de l art. Ces derniers nous aurait peut-être permis d identifier plus rapidement les tâches posant problème. 4 -Adira non impliquée Un dernier point ou plutôt une interrogation subsiste et que nous avons considéré comme un facteur de non performance. Bien que notre product owner ait été très présent durant tout le projet, il nous a été très difficile d obtenir des informations de la part de L ADIRA. Il n en demeure pas moins que L ADIRA est restée une inconnue pour notre équipe. Ainsi il a été très difficile de connaitre le budget du projet, nos possibilités d hébergement (héberger sur un site indépendant, intégration dans leur propre site), d'obtenir une liste de diffusion pour les questionnaires. Figure 61 : Les causes de non performances La mise en place de l observatoire a été une expérience très enrichissante dans le sens où il nous a permis de découvrir un monde inconnu pour tous, aussi bien pour des personnes issues de gestion de projet classique (PMI) que des personnes plus techniques n ayant que très peu de connaissances dans ce sujet. - page 77 -

78 Deux questions se posent également : "SCRUM a-t-il été le catalyseur nous permettant d avoir une équipe soudée et de mener à bien notre projet?" "La composition du groupe a-t-elle permis de réussir le projet en SCRUM?" Cela revient à répondre : "Qu'est-ce qui est apparu en premier : l'œuf ou la poule?" L équipe EMSI Paradoxe de l œuf ou la poule - page 78 -

79 CONCLUSION Le site permet l exécution des principales fonctions attendues d un observatoire, sans toutefois atteindre le niveau d'exigence imaginé par l équipe. Le produit livré peut donc paraître incomplet. Cependant, ce produit a été façonné en utilisant une méthode agile, avec ses atouts et ses contraintes, mais correspond avant tout aux demandes du client, exprimées durant les différents sprints. Le but était de livrer rapidement et fréquemment des fonctionnalités à forte valeur ajoutée. En huit sprints de quinze jours nous avons livré une maquette fonctionnelle correspondant à la vision du client, elle a permis d'initier des campagnes de sondages et de diffuser les résultats par l intermédiaire du site Internet. Lors du dernier sprint et en accord avec le client, nous avons planifié un transfert de compétence, dont le point d orgue était la mise en ligne de l Observatoire de l Agilité à l adresse suivante : Cet événement a marqué la fin de notre projet. La remise du produit et du mode d emploi au client va permettre d exploiter le produit de façon autonome. Durant les premières itérations du projet, nous avions proposé plusieurs idées qui nous semblaient novatrices ou qui pouvaient permettre à notre produit de se différencier des autres observatoires. Pour des raisons principalement liées au temps, ces idées n ont pas pu être déployées, mais ont tout de même suscité de l engouement de la part de notre client. Deux objectifs se détachent. Le premier, le partage d expérience, partie intégrante de la culture agile, peut se matérialiser par la mise en place d un réseau social ou d un forum. Le second, accroître le rayonnement de l observatoire et implicitement l association ADIRA, en proposant par exemple, un calendrier des événements nationaux voire internationaux liés à l agilité. Déjà deux pistes pour un prochain cas fil rouge... Enjoy :) Ce n est pas l espèce la plus forte qui survit, ni la plus intelligente, mais bien celle qui s adapte le mieux au changement. Charles Darwin, XIX ième siècle - page 79 -

80 - page 80 -

81 REFERENCES Liens Internet Agile Manifesto Agilessence Blog de la stratégie marketing (Bonnes pratiques création de questionnaires) Blog Formaeva (Bonnes pratiques création de questionnaires) Blog Octo (Mon projet est-il agile?) Blog Soat (BI, Cube OLAP) Club Agile Rhône-Alpes (CARA) Commission Nationale de l Informatique et Libertés (CNIL) Creative Commons EMSI Grenoble Ecole de Management Groupe SAMSE Institut Agile L Association pour le Développement de l Informatique en Rhône-Alpes (ADIRA) La Chose Agile LimeSurevy Observatoire de l Agilité (L ) Observatoire des métiers de la presse (Charte de bon fonctionnement) Observatoire du numérique (L ) Observatoire scientifique de la vallée du Galeizon (L ) OSIATIS Paperblog (Bonnes pratiques création de questionnaires) Questionnaire en ligne par l académie Nancy-Metz (Bonnes pratiques création de questionnaires) - page 81 -

82 SAMSE Scrumwise Site du Zéro (Charte de bon fonctionnement) Survey Store (Bonnes pratiques création de questionnaires) Unions Marocaine pour la qualité (Charte de bon fonctionnement) Ville de Sceaux (Charte de bon fonctionnement) Wikipédia WordPress Ouvrages «Écriture et professionnalisation (Revue française de pédagogie, n 156, juillet-août-septembre 2006, )» Jacques Crinon Michèle Guigue, «Gestion de projet Agile» Véronique Messager Rota, «Guide de recommandations pour l'élaboration d'un observatoire territorial des pratiques agricoles» Observatoire Territorial des Pratiques Agricoles (OPTA), «Kanban et Scrum - tirer le meilleur des deux» «La pensée aux prises avec l informatique» «Le Cygne Noir : La puissance de l imprévisible» Henrik Kniberg Mattias Skarin, 2010 Laurent Bloch, Nassim Nicholas Taleb, «Le Product Backlog, qu est-ce c est?» Ludovic Larché, Agile Tour 2012 Renne, «Spécifiez agile, expression de besoins : la boîte à outils du Product Owner» Thierry Cros, «Transition vers l agilité à l échelle d une organisation, deuxième édition» Valtech, «Un guide de Survie à l Adoption ou Transformation Agile : Travailler avec la Culture d une Organisation» Michael Sahota, «Un petit pas peut changer votre vie ; La voie du Kaizen» Robert Maurer, «Une équipe si particulière» Jean-François Jagodzinski, Agile France 2013, page 82 -

83 ABECEDAIRE BACKLOG BURNDOWN CHARTE PROJET DAILY STAND UP DEMONSTRATION DE FIN D ITERATION EQUIPE AGILE EXTENSION FOURSIGHT GOOGLE DRIVE GOOGLE HANGOUT HEBERGEUR (Internet) Liste de tâches (user stories) produite par l'équipe et le product ower. Elles sont nécessaires et suffisantes pour la réalisation du projet. Il est possible d ajouter ou de retirer une tâche si cela s'avère nécessaire ; elle est par conséquent évolutive. Courbe d évolution d un sprint, elle suit un axe prédéfini par l équipe. Elle est le témoin pour observer le bon ou mauvais déroulement de l itération. Définit la vision d'ensemble du projet, elle donne les axes principaux de travail, elle définit un périmètre et un temps limite. Elle doit être visible par l équipe à tout moment, et n'excède jamais plus d'une page. Brève réunion de l équipe qui s effectue tous les matins, dix minutes maximum, à heure fixe, et debout pour déterminer l'avancement et obstacles des tâches en cours. Généralement elle se fait en posant 3 questions: - Qu'est-ce que tu as fait hier? - Que vas-tu faire aujourd hui? - As-tu eu des difficultés? Consiste à montrer le (ou les) livrable(s) de fin de sprint au product owner. Constituée au minimum de trois personnes et au maximum dix. Elle réunit les compétences nécessaires au bon fonctionnement d'un projet. Egalement appelé plugin ou greffon. Module qui complète un logiciel pour lui apporter de nouvelles fonctionnalités. Méthode permettant de déterminer les préférences basses et dominantes d une personne ainsi que son profil d innovation. Stockage des différents documents d échange de l équipe. Système de «chat» vidéo multi-participants, permettant de réaliser des conférences à distances via Internet. Entité ayant pour vocation de mettre à disposition des internautes un espace dédié sur leurs serveurs distants et à assurer une pérennité du service. ITERATION/SPRINT Intervalle de temps, répétée plusieurs fois dans le projet. L'intervalle est fixe et ne bouge pas durant tout le déroulement du projet. KANBAN LEAN ENGINEERING LIMESURVEY MANAGEMENT VISUEL MATRICE DES COMPROMIS Outil de développement de produits logiciels et processus mettant l'accent sur la livraison «juste-à-temps» tout en ne surchargeant pas les développeurs de logiciels. Dans cette approche, le processus de la définition d'une tâche jusqu à sa livraison au client est affichée pour les participants. Les développeurs tirent leurs tâches à partir d'une file d'attente. Concept développé pour augmenter l'efficacité des processus des services d'ingénierie au sein des entreprises. Logiciel de sondage en PHP pour créer des sondages en ligne. Pratique consistant à faire passer des informations, des orientations au moyen d éléments visuels. Outil de gestion dont les paramètres (délai, budget, périmètre, qualité) sont définis avec le product owner pour le projet. - page 83 -

84 NIKO-NIKO NOM DE DOMAINE OBSERVATOIRE OPEN SOURCE PERSONAS Pratique agile permettant de capter quotidiennement l état d esprit subjectif de chaque collaborateur ai sein de l équipe projet. Un nom de domaine est une adresse saisie par un internaute dans la barre d adresse d un navigateur pour se connecter à la page d accueil d un site, exemple : L adresse se compose du nom du site «yahoo» et d une extension «fr» séparés par un point. L extension peut indiquer la nationalité (exemple:«.fr» pour la France, «.uk» pour la Grande Bretagne) ou le type d activité (exemple:«.com» pour un commercial, «.gov» pour but gouvernemental). Lieu d échanges et d analyses sur un thème donné. Cette désignation s'applique aux logiciels dont la licence respecte des critères précisément établis par l'open Source Initiative, c'est-à-dire la possibilité de libre redistribution, d'accès au code source et aux travaux dérivés. Fiche détaillée d un utilisateur «fictif» ou non du produit fini, elle est rédigée par l équipe. Elle tient généralement sur une feuille A4 et est continuellement exposée dans la salle dédiée à l équipe projet. La fiche n est écrite que si cela est nécessaire dans le projet. PLANNING POKER Étape pratiquée en début de sprint où l'on estime la valeur d'une user story (en heures ou en points). Chacun donne son estimation personnelle, s il y a eu divergence, les deux extrêmes discutent et argumentent. Une nouvelle estimation est faite par l intégralité de l équipe, jusqu à que la totalité de l équipe soit accord. POINT PRE-MORTEM PREZI PROCESS COM PRODUCT OWNER (PO) RETROSPECTIVE D ITERATION Unité de valeur utilisée en pratique agile à la place du classique «hommejour». Elle permet de connaitre la vélocité de l équipe par sprint, et met une moindre pression au projet. Pratique agile réalisée en début de projet : chaque personne écrit sur un postit ce qui pourrait mal se dérouler le lendemain de la mise en production du produit fini. Il en ressort des tâches priorisées (par le product owner) qui seront injectées dans les sprints si besoin. C est une pratique qui permet de faire ressortir les freins et les peurs de l équipe. Outil de présentation dynamique concurrent de PowerPoint. Aussi appelé Process Communication. Technique permettant de se découvrir, de mieux se comprendre, à travers ses codes, son langage, ses références, visant ainsi à adapter sa communication vis-à-vis de l'autre ou encore décoder les signaux de celui-ci. Personne ayant la responsabilité et l'orientation du projet en lien avec le client. Il possède la vision du produit fini et c est avec lui que la communication doit se faire. Il alimente le backlog de user stories, si cela s avère nécessaire il les priorise. Il est à l entière disposition de l équipe. A chaque fin d itération, l équipe se réunit pour que chacun puisse donner son avis sur les difficultés et les facilités rencontrées durant ses phases de travail. Puis l équipe décide collectivement, les axes d amélioration à donner pour la future itération. - page 84 -

85 RETROSPECTIVE JALON SALLE DEDIEE SCALABLE SCRUM Aussi appelé mi sprint. Se pratique en milieu de sprint. C'est un bilan intermédiaire permettant de voir ce qui a été fait et également de mesurer l état d esprit dans lequel se trouve l équipe. Salle qui est faite pour répondre aux besoins fonctionnels de l'équipe et qui ne change pas durant tout le projet. Cette pratique permet une meilleure diffusion de l information. Ce terme (issu du mot anglais «échelle») désigne la capacité d'un produit à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge). En particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande. L'idée consiste à adopter une organisation telle que la puissance croisse en même temps que la charge. Méthode agile pour la gestion de projet basée sur de petites équipes indépendantes. Pratique initialement conçue pour le développement informatique. SCRUM MASTER Rôle identifié dans la pratique de Scrum. Cette personne peut avoir 2 statuts : - Soit elle fait partie de l'équipe de réalisation - Soit c est un poste à part entière. C est un facilitateur, il s assure que tout le monde ait compris la méthode et il ne possède pas de pouvoir hiérarchique dans le groupe. Il gère toutes les perturbations extérieures au travail de l équipe. SCRUM OF SCRUM Pratique utilisée pour des grandes équipes (> 10 personnes) sur des gros projets. Elle permet de diviser l équipe en plusieurs petites équipes. SCRUM TASK BOARD SCRUMWISE SPRINT PLANNING MEETING STORY MAPPING SURVEY PRESS TEAM BUILDING THEME (visuel) Tableau représentant l avancement du sprint, il est généralement composé de 3 colonnes, «TO DO», «IN PROGRESS», «DONE». Les user stories sont réparties par leurs propriétaires dans chacune des colonnes suivants leur statut. Outil informatique de gestion de projet permettant la pratique de Scrum. L équipe estime (quantifie et planifie), généralement en points le poids des user stories tirées du backlog pour l itération à venir. Histoire du projet. On se met dans la peau de l utilisateur final et on définit ce que l on aimerait avoir. Il en ressort des users stories. Elle se présente sous 2 axes : - Axe vertical > permet de prioriser - Axe horizontal > matérialise la chronologie du sprint. Extension qui sert à interfacer LimeSurvey avec le système Wordpress. Activité qui a lieu en dehors du projet, afin de construire, de consolider et de lier les membres d une équipe entre eux. Ensemble de couleurs et d'images permettant de personnaliser l'apparence complète ou partielle d une page Internet, d une application... - page 85 -

86 TOKEN Terme informatique signifiant jeton, il est utilisé : - pour désigner un identificateur, USER STORY VELOCITE WORDPRESS WORLD CAFE WPSURVEY AND QUIZ TOOL - pour désigner une entité (ou unité) lexicale, dans le cadre de l'analyse lexicale, - pour désigner un jeton d'authentification, boîtier électronique générant des nombres, synchronisés destiné à l'authentification ou stockant des informations chiffrées. «Le scénario» : c'est une découpe de l'intégralité du travail à réaliser. Ce sont des hypothèses émises par l'équipe et le client afin de produire un travail. Elles ont toutes une valeur plus ou moins grande pour le projet. Généralement couchées sur des post-it, elles apparaissent de façon arbitraire. Puis elles sont priorisées et estimées. Il existe 4 façons de créer les user stories : - Les 3C : Carton (post-it), Conversation, Confirmation - La grille INVEST : elle permet de juger la qualité d une user story, elle pourra être éventuellement réécrite (annule et remplace un post-it). - La matrice rôle-fonctionnalité-bénéfice : permet de formaliser, «en tant que», «je veux que», «afin de». - La matrice «given-when-then» : un contexte, l utilisateur effectue certaines actions, constatations des conséquences. Nombre de tâche en termes de points, qu'est capable de réaliser une équipe dans une itération. Il n'y a que les tâches définitivement finies qui sont comptabilisées. Système de gestion de contenus. Logiciel destiné à la conception et à la mise à jour dynamique d Internet ou d'applications multimédia. Processus qui vise à faciliter un dialogue constructif, de partage de connaissances et d idées. Les participants débattent d un sujet en petit groupe autour d une table avec un hôte. Puis à intervalle régulier, tout le monde change de table sauf l hôte, et va se rattacher à une autre table pour que les idées continuent à «hybrider». Elles seront alors débattues et acceptées par l ensemble des participants. Extension qui permet de gérer les questionnaires dans Wordpress. - page 86 -

87 DECODER LES SIGLES PO CMS QoS PMI Propriétaire du produit ; Product-Owner. Content Management System. Système de gestion de contenu ou SGC. Famille de logiciels destinés à la conception et à la mise à jour dynamique d Internet ou d'applications multimédia. Quality of Service. Indicateur permettant de mesurer le niveau de qualité du service rendu. Project Management Institute. Cet institut a développé et promut des standards internationaux en management de projet. PHP Langage de programmation compilé à la voléehttp://fr.wikipedia.org/wiki/logiciel_libre principalement utilisé pour produire des pages Internet dynamiques via un serveur HTTP, mais pouvant également fonctionner comme n'importe quel langage interprété de façon locale. SOA HTML SE ROI OLAP URL Service Oriented Architecture. L'architecture orientée services est une forme d'architecture de médiation qui est un modèle d'interaction applicative mettant en œuvre des services (composants logiciels) : - avec une forte cohérence interne - et des couplages externes «lâches». L HyperText Markup Language. Format de données conçu pour représenter les pages Internet. Il permet d écrire de l hypertexte, d où son nom. HTML permet également de structurer sémantiquement et de mettre en forme le contenu des pages, d inclure des ressources multimédias dont des images, des formulaires de saisie, et des programmes informatiques Réseau social d entreprise. Réseau social regroupant les membres d'une même organisation qui a pour vocation d'encourager et de favoriser la collaboration, l'interaction, le travail en équipe, l'entraide, le partage, l'échange et la communication horizontale. ROI est un acronyme utilisé pour le terme anglais Return On Investment : retour sur investissement en français. C est une mesure de rentabilité. OnLine Analytical Processing. En informatique, et plus particulièrement dans le domaine des bases de données, le traitement analytique en ligne est un type d'application informatique orienté vers l'analyse sur-le-champ d'informations selon plusieurs axes, dans le but d'obtenir des rapports de synthèse tels que ceux utilisés en analyse financière Uniform Resource Locator. Le sigle URL désigne une chaîne de caractères utilisée pour adresser les ressources du World Wide Web : document HTML, image, son, forum Usenet, boîte aux lettres électronique, entre autres. - page 87 -

88 ANNEXES Annexe 1 : Le choix des outils Ces outils se composent de : Google drive Google Drive est un service de stockage, de consultation, de partage et de gestion de fichiers/dossiers en ligne lancé par Google en avril L'offre Google Drive (gratuite) se décompose ainsi : o o o o Gmail 5 GO d'espace de stockage (avec l'arrivée de Google Drive, Gmail passe automatiquement à 10 GO d'espace de stockage). Une application de bureau pour synchroniser les fichiers de son ordinateur avec le service en ligne Google Drive. Une application Google Drive pour Android (Google Drive pour Apple à venir). Un espace de stockage qui communique avec les autres services de Google (Google Docs). Gmail est un service de messagerie gratuit proposé par Google. Les messages reçus sur un compte Gmail peuvent être lus via un client de messagerie ou avec un navigateur web. De nombreuses fonctionnalités du service ne sont cependant accessibles qu à travers le navigateur web. En janvier 2012, 425 millions d internautes utilisent ce service de messagerie électronique. Hangout Intégré à Google +, les hangouts permettent la vidéo conférence, messagerie instantanée, partage de fichiers avec la possibilité d'utiliser Google Drive pour une modification de documents en direct. - page 88 -

89 Annexe 2 : Page d'accueil du site Internet - page 89 -

90 Annexe 3 : Page Mission de l'observatoire du site Internet - page 90 -

91 Annexe 4 : Tableau récapitulatif des CMS CMS Avantages Inconvénients JOOMLA Les ++ : Très facile à installer, Limité dans la personnalisation, manque configuration poussée pour convenir à de fiabilité sur certains modules n importe quel site, extension possible (développés par la communauté de avec les modules et plug-ins disponibles, développeurs, certaines ne fonctionnent des milliers de templates disponibles, pas, certains ne sont plus à jour), création facile d un template. intégration compliquée de la librairie DRUPAL Très puissant, entièrement personnalisable, bon gestionnaire de contenu, convient aux utilisateurs confirmés, possibilité de créer des solutions performantes. SPIP Modules optionnels performants, beaucoup de souplesse, facilité d utilisation, performant en tant qu outil collaboratif (utilisé par des magazines et des associations) WORDPRESS Très puissant avec ses extensions, simple d utilisation, beaucoup de possibilités offertes (boutique, blogs multiples, site d intermédiation), grosse communauté (utilisé à la base par tous les blogueurs). jquery. Nécessite une connaissance en PHP pour utiliser toutes ses capacités, manque de templates (par rapport à d autres CMS). Utilise un langage personnalisé (ça peut être un atout pour certains ) et donc une maîtrise de celui-ci, une évolution du logiciel non collaborative. Pas vraiment un CMS à la base, beaucoup de mises à jour qui nécessitent un contrôle de compatibilité des modules ayant été installés au préalable. - page 91 -

92 Annexe 5 : Tableau récapitulatif des logiciels de sondages Denomination LimeSurvey Google Form Intégrations à wordpress Facilité d utilisation Questionnaires illimités Limite de questions Réponses limitées Personnalisation thèmes Export en PDF, EXCEL Report temps réel Nombre de type de questions Support en différentes langues Intégrations images/vidéos WP Survey and Quiz Tool Wuffo Illimités 255 Illimités 10 Illimités /question naires Illimités 100/questionnair es page 92 -

93 Annexe 6 : Charte de bon fonctionnement du site Internet CHARTE DE BON USAGE DU SITE INTERNET Objectif de la charte Cette charte a pour but de préciser le bon usage et le bon fonctionnement de l observatoire ainsi que les règles prises pour offrir les meilleurs résultats possibles. A qui s applique la charte A tous les utilisateurs, membres et administrateur de l observatoire. Objectif de l observatoire o C est un lieu de synthèse Un observatoire rassemble, analyse, caractérise et diffuse les informations et les données relatives à l'usage des pratiques agiles dans les entreprises de la région Rhône-Alpes. o Évaluation de l'impact des pratiques Un observatoire a fréquemment comme mission l'évaluation de l'impact de l'usage des pratiques agile sur les entreprises et leurs performances économiques et sociales. Pour cela, et même si ce n'est pas son objectif direct, il doit être en lien avec un système d'observation des pratiques en entreprise afin de mettre en parallèle l'évolution o C est un lieu d échanges d expériences Entre l Adira et les entreprises de la région Rhône-Alpes, qui permet de favoriser l harmonisation des méthodes agile, la mutualisation des connaissances, et de créer les conditions de diagnostics partagés sur l état des pratiques agiles dans les entreprises. C est un lieu d innovation et d expertise : il anime un programme d études et de recherches, et contribue à la mise au point des cadres conceptuels et des outils adaptés aux nouveaux besoins de comparaisons entre territoires à l échelle européenne et internationale. o C'est un lieu d'aide à la décision L'observatoire doit être présenté comme un outil d'aide à la réflexion, à travers la valorisation des données collectées. L'observatoire peut aussi proposer des scénarios à visée prospectives, permettant aux entreprises adhérentes de se projeter dans un futur plus au moins lointain. o Communication L'observatoire doit communiquer et gérer la promotion de ses actions et résultats. Gouvernance du site L observatoire a été souhaité par des membres du club Agile de l ADIRA (Association pour le Développement de l Informatique en Rhône-Alpes). Ils souhaitent connaitre le niveau de propagation et l impact de l utilisation de l agilité dans la région Rhône-Alpes. L observatoire a été conçu par un groupe d étudiant de l EMSI (Grenoble Ecole de Management) dans le cadre d un projet cas fil rouge durant leur année de formation. Le site sera repris et administré par une personne membre l ADIRA afin de faire perdurer le site de l observatoire. Modalités et fonctionnalités de l observatoire o Type d information L observatoire s appuie sur les réponses, des visiteurs et membres de l observatoire, à plusieurs questionnaires. Ils seront renouvelés régulièrement par les modérateurs de l observatoire. Les données recueillies seront mises dans une base de données définies plus bas. Certaines pratiques agiles sont définies sous forme de glossaire. Il est à disposition de tous les utilisateurs du site. Les valeurs et les principes du Manifesto sont reportés dans le site. C est la «bible» des agilistes. o Utilisation et destinataire - page 93 -

94 Toutes personnes souhaitant répondre aux questionnaires sont autorisées à le faire. Afin d avoir des résultats les plus précis possible, nous demandons de répondre de façon honnête et intègre. Vos observations, commentaires et remarques sont souhaités, ils pourront faire évoluer l observatoire. L observatoire et les questionnaires sont adressés aux débutants, aux utilisateurs, aux certifiés, aux experts des méthodes et pratiques agiles. C est un lieu où il sera possible de voir et de mesurer la propagation des méthodes dans la région Rhône-Alpes. o La base de données La base de données sera alimentée par les réponses aux questionnaires sur le site de l observatoire. Les premiers questionnaires ont été établis par les étudiants de l EMSI. L observatoire servira à : Recueillir régulièrement des informations quantitatives et qualitatives sur les pratiques agiles. Alimenter les bases de données de façon pertinentes et régulières (avec des questionnaires fréquents). Retranscrire les résultats sous formes de synthèse à tous les visiteurs et membres de l observatoire. Les résultats seront disponibles et en libre accès pour toutes personnes naviguant sur le site Internet. La base de données sera administrée et modérée par des membres. o Diffusion des travaux de l observatoire Toute diffusion ou communication externes sur les travaux en cours ou réalisés sera soumise à l approbation préalable des modérateurs de l Observatoire de l agilité. Puis les résultats seront transmis aux membres de l observatoire et recopiés sur le site. L observatoire de l agilité autorise la reproduction de tout ou partie des informations figurant dans les synthèse/rapports à condition que l observatoire soit cité comme source de l information. La licence qui a été choisi est la suivante : «Attribution - Pas d Utilisation Commerciale - Partage dans les Mêmes Conditions CC BY-NC-SA Cette licence permet aux autres de remixer, arranger, et adapter votre œuvre à des fins non commerciales tant qu on vous crédite en citant votre nom et que les nouvelles œuvres sont diffusées selon les mêmes conditions. Voir le Code Juridique : o L administration du site L administration et la vie de l observatoire seront prises en charge par plusieurs personnes membre de l ADIRA, des modérateurs. Vous avez la possibilité de rentrer en relation avec eux par l onglet «contact» prévu à cet effet sur le site. o Les utilisateurs de l observatoire Lors de l inscription l utilisateur s engage à respecter l ensemble des lois en vigueur ainsi que les règles de l observatoire définies plus haut. Chaque utilisateur du site s engage à ne pas divulguer ses identifiants à un tiers. Il s engage à prévenir l administrateur du site en qu a de vol ou de perte de ces identifiants. o Modification de la charte Le signataire est informé que cette charte peut être modifiée à tout moment. La charte est amenée à évoluer en même temps que les fonctionnalités de l observatoire. Les modifications apportées lui seront notifiées périodiquement par les modérateurs du site. - page 94 -

95 Annexe 7 : La CNIL - Le déclarant - page 95 -

96 Annexe 8 : La CNIL - Finalité - page 96 -

97 Annexe 9 : La CNIL : Contact - page 97 -

98 Annexe 10 : la CNIL - Engagement du responsable - page 98 -