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 2012- 2013, 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.
AVANT-PROPOS
“Ce qui fait l’homme, c’est sa grande faculté d’adaptation.”
Socrate (-470 à -399) L’aube de l’humanité
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...
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.
TABLE DES MATIERES
INTRODUCTION ... 9
1 GENERALITES ... 11
1.1 Présentation de l’ADIRA ... 11
1.2 Présentation du cas fil rouge ... 12
1.3 Présentation des acteurs ... 14
1.3.1 Localisation géographique des acteurs ... 14
1.3.2 Présentation des acteurs de l’ADIRA ... 14
1.3.3 Présentation du tuteur école ... 17
1.3.4 Présentation de l’équipe EMSI ... 18
2 LE SUJET ... 25
2.1 Reformulation du sujet. ... 25
2.2 La charte projet : notre contrat ... 25
2.3 Agilité, valeurs et principes - définition ... 28
2.4 Agilité, valeurs et principes - découverte ... 30
3 LA CONDUITE DU PROJET ... 33
3.1 Construction de la méthode de travail ... 33
3.1.1 Choix des outils ... 33
3.1.2 Validation de la méthode de travail ... 33
3.1.3 Identification des risques ... 35
3.2 Le projet ... 38
3.2.1 Création de la story mapping ... 38
3.2.2 Notre organisation de projet ... 40
4 LES PRODUITS ... 45
4.1 Le site Internet – www.observatoire-agilite.com ... 45
4.1.1 Le contexte ... 45
4.1.2 Le site en général ... 46
4.1.3 Les outils ... 51
4.1.4 Logo spécifique ... 53
4.2 Les bonnes pratiques et recommandations ... 53
4.2.1 La charte de bon fonctionnement ... 53
4.2.2 La CNIL ... 54
4.2.3 Les licences et copyrights ... 55
4.2.4 Analyse, exploitation, rédaction des résultats ... 57
4.2.5 Création des questionnaires ... 58
4.3 Les questionnaires ... 59
4.4 Livret de formation et transfert à l’ADIRA. ... 63
4.4.1 Site Internet de l’Observatoire ... 63
4.4.2 Exploitation des résultats LimeSurvey ... 63
4.4.3 Les bonnes pratiques et recommandations de la gestion d’un observatoire ... 64
4.5 Ce qui n’a pas été traité : analyse et exploitation des résultats ... 64
5 LES INDICATEURS PROJET ... 66
5.1 Les indicateurs de suivi de projet ... 66
5.1.1 Les indicateurs de livraison ... 67
5.1.2 Répartition des tâches ... 67
5.1.3 Les indicateurs d’équipe ... 68
5.1.4 Les indicateurs d’amélioration continue, le burndown chart ... 69
5.2 Indicateur produit : le pré-test avec Club Agile ADIRA ... 70
5.2.1 Plan ... 70
5.2.2 Do ... 71
5.2.3 Check ... 71
5.2.4 Act ... 71
6 BILAN ... 73
6.1 Humain ... 73
6.2 Les causes de performances et de non performances ... 75
6.2.1 Les éléments de performances ... 76
6.2.2 Les non performances ... 77
CONCLUSION ... 79
REFERENCES ... 81
Liens Internet... 81
Ouvrages ... 82
ABECEDAIRE... 83
DECODER LES SIGLES ... 87
ANNEXES ... 88
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é...
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.
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.
ADIRA
SOLIDARITE
RESPECT MUTUEL
L'ECOUTE
PARTAGE TRAVAIL
COLLABORATIF VEILLE
TECHNOLOGIQUE PROFESSION-
NALISME
ENTHOUSIASME
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.
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 auto- organisé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.
1.3 Présentation des acteurs
1.3.1 Localisation géographique des acteurs
Dans ce cas fil rouge, chacun des acteurs est localisé en Isère.
1.3.2 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.
Thierry
Vincent
Nathalie
ISERE ISERE ISERE ISERE
●
GRENOBLE GRENOBLE GRENOBLE GRENOBLE
Laurent Jonathan
Frederic
Jean-Francois Lema
Figure 2 : Localisation géographique des acteurs
‘’
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 2005. Au vu de la progression des participants dans les conférences sur le sujet, on sent une montée en puissance depuis 2010.
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 sont- elles 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.
‘’
Tuteur entreprise Jean-François JAGODZINSKI – ADIRA / AGILESSENCE Coach Agile indépendant
Figure 3 : Jean-François JAGODZINSKI
Figure 4 : Agilessence
‘’
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é.
• 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
Figure 6 : Frédéric DUFAU-JOEL
Figure 5 : La Boite à Outils
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
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.
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
Figure 8 : Laurent AMOUROUX
Figure 7 : Le cloud par Osiatis
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.
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.
155 160 165 170 175 180 185
Clarificateur Idéateur Développeur Réalisateur
POINTS FOURSIGHT
Profil FourSight Equipe
Figure 9 : Profil FourSight de l'équipe
Analyse du profil Process Communication
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.
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.
58%
72%
84%
93%
94%
100%
Promoteur Rêveur
Rebelle Empathique
Persévérant Travaillomane
Profil Process Communication Equipe
Figure 10 : Profil Process Communication de l'équipe
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.
"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.
CHARTE PROJET
ADIRA « Observatoire de l'agilité » Les enjeux principaux du projet
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 X Proche de 0 dans
notre cas
Figure 11 : Charte projet de l'Observatoire de l'Agilité
2.3 Agilité, valeurs et principes - définition
Les pratiques agiles sont apparues dans le monde du développement informatique dans les années 2000.
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 outilsDes logiciels opérationnels
plus qu’une documentation exhaustiveLa collaboration avec les clients
plus que la négociation contractuelleL’adaptation au changement
plus que le suivi d’un plan Nous reconnaissons la valeur des seconds éléments,mais privilégions les premiers.
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.
Un logiciel opérationnel est la principale mesure d’avancement.
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.
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.
La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
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.
Les meilleures architectures, spécifications et conceptions émergent d'équipes auto organisées.
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.
À 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 12 : Les quatre valeurs de l'Agile Manifesto - agilemanifesto.org
Figure 13 : Les douze principes de l'Agile Manifesto - agilemanifesto.org
Les pratiques agiles se propagent dans l’entreprise, surtout depuis les années 2005.
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
DALY STAND-UP RETOUR
D’EXPERIENCE
LEAN ENGINEERING
SCRUM
XP
PLANNING POKER
KANBAN
PERSONAS
MANAGEMENT VISUEL CULTURE
ETAT D’ESPRIT COLLABORATION
RETROSPECTIVE CHARTE
PROJET
4 VALEURS et 12 PRINCIPES
Figure 14 : Notre vision du périmètre de l’agilité
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.
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.
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.
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 (www.clubagilerhonealpes.org) 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.
Figure 15 : Cours coaché par Jean-François JAGODZINSKI
3 LA CONDUITE DU PROJET
3.1 Construction de la méthode de travail
3.1.1 Choix des outilsOutils Objectifs
Google Hangout
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
Outil de stockage et de partage de documents du projet permettant une réplication de
sauvegardes.
Figure 16 : Outils retenus
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.
3.1.2 Validation de la méthode de travail
"Partir en mode agile ou en standard PMI ? ... Notre choix !"
L’équipe EMSI En début de projet, l’équipe s’est questionnée sur l’approche conduite de projet.
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.
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 :
Figure 18 : Vue synthétique du processus Scrum
Ce que préconise Scrum
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.
3.1.3 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é
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
R6
Manque d'implication d'un des membres
de l'équipe Transfert de la charge sur les autres
R7
Perturbation extérieure (rajout /
modification de tâche) 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
Moyen Élevé Très élevé
Figure 22 : Pondération des risques en fonction de la probabilité
R1 R3
R6 R4
R2
R7 R5
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 2012. Nous en avons retiré 2 tableaux.
Freins externe Actions pour éviter les freins externes Temps alloué des tuteurs sur nos cas fil
rouge
Intégrer les tuteurs dans un team building / rendre notre cas fil rouge attractif pour le tuteur école
On ne connaît pas encore nos tuteurs Intégrer les tuteurs dans un team building / rencontrer nos tuteurs
Manque de clarté dans la communication du tuteur vers nous
Reformuler le sujet et le présenter au tuteur
Exhaustivité du sujet Reformuler le sujet et le présenter au tuteur
Accueil et disponibilité des entreprises Appâter le tuteur école (attractif)
Figure 24 : Freins externes et actions
Freins internes Actions pour éviter les freins internes La disponibilité, le temps personnel alloué
pour le projet
Mettre en place
une méthodologie, planification, entraide et solidarité
Divergence entre nous 5 Communication, mail, téléphone, Skype...
si cela ne marche pas, faire appel au tuteur Faire un hors sujet/ mauvaise
compréhension
appel, liaison avec le tuteur école et entreprise
Logistique (mobilité) Communication, mail, téléphone, Skype...
si cela ne marche pas, faire appel au tuteur Compétence individuelle / lacune
comparativement au groupe
Communication, mail, téléphone, Skype...
si cela ne marche pas, faire appel au tuteur
Manque de cohésion Team building
Tension entre nous Team building
Figure 25 : Freins internes et actions
3.2 Le projet
3.2.1 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…).
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.
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.
3.2.2 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 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.
Figure 29 : Liste des réunions
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 :
Figure 30 : planning du projet Observatoire de l’Agilité
- 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 d’itération avec le product owner.
o 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 : - 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.
Figure 31 : Cartes pour le planning poker utilisées pendant le projet par l'équipe
"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.
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) 2 semaines
Planifier, quantifier (estimation / vélocité)
ok (Planning
poker)
Stand-up quotidien 2 par
semaine Réactivité dégradée. Blocages gérés à mi-sprint.
Backlog du sprint - Découpage en tâches. ok
Backlog du produit global ok
Propriétaire du produit (product-owner) ok
Scrum-master ok
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
Développeur ok
(l'équipe)
Equipe pluridisciplinaire / auto-organisée ok
Revue de sprint (démonstration) ok
Rétrospective de sprint (amélioration par le retour d'expérience du sprint
précédent)
ok
Non pratiquée à tous les sprints, sources d'amélioration pas exploitées.
Burndown chart ok
(Scrumwise)
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
Proximité de l'équipe sur le même site not ok
Limitation des échanges, vélocité ralentie.
PO intégré à l'équipe. not ok
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
4 LES PRODUITS
4.1 Le site Internet – www.observatoire-agilite.com
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
4.1.1 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).
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
"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.
4.1.2 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é
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.
• 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.
Figure 35 : Diagramme de cause à effet
