Gestion de projet Vers les méthodes agiles Des approches prédictives aux méthodes agiles appliquées avec SCRUM Présenté par Jordan RICHET et Ronan BARZIC

Sommaire Partie 1 : La société Altran Quelques chiffres Organisation Les projets Altran Partie 2 : Les méthodes agiles Le constat L’approche classique et ses limites Méthodes agiles Partie 3 : La méthodologie SCRUM L’équipe SCRUM Le client Les sprints La stratégie de documentation La stratégie de tests Les avantages et limitations de la méthode Synthèse Questions / réponses

Partie 1 : La société Altran

ALTRAN, pionnier du Conseil en Innovation Technologique et R&D Altran fédère, en Europe, en Amérique du Nord, en Amérique du Sud et en Asie … des sociétés de conseil en innovation, des organisations dédiées à l’offshore : Inde, Chine, Russie … des liens privilégiés avec des Universités et Laboratoires les plus prestigieux : MIT, Cambridge Altran c’est : plus de 17 500 personnes 1 591 M€ de chiffre d’affaires en 2007 (+6,4% par rapport à 2006)

ALTRAN Ouest Leader du conseil et de l’ingénierie en hautes technologies, Altran – présent dans l’Ouest depuis 1984 – fédère aujourd’hui près de 400 ingénieurs en Bretagne, Pays de Loire et Poitou-Charentes. Implantée à Brest, Rennes et Nantes, ALTRAN Ouest dispose d’une situation géographique idéale à proximité immédiate des acteurs majeurs du grand Ouest. ALTRAN Ouest est partenaire des grands acteurs économiques et technologiques implantés dans l’Ouest et a réalisé 30 M€ de chiffre d’affaires en 2007 (+10% par rapport à 2006). Brest : 90 consultants Rennes : 210 consultants Nantes : 90 consultants

ALTRAN Ouest - BREST Technologies de l’Information et ALTRAN Ouest - Etablissement de Brest est une société d'ingénierie et de conseil qui, depuis sa création en 1984, a fait de l'innovation technologique sa culture. Notre savoir-faire multi métiers s'exprime principalement au travers de deux pôles d’activités (TIC / STM). Technologies de l’Information et de la Communication Sciences et Technologies Marines TIC : 55 consultants - système d’information - informatique & électronique - télécoms & réseaux CA 2007 : 5,4 M€ STM : 30 consultants - sciences de la mer - instrumentation ALTRAN Brest est un acteur du tissu économique régional, par sa collaboration avec les groupements ou associations professionnelles, les centres de recherche, les écoles et les universités.

Technologies de l’information et de la communication TIC Technologies de l’information et de la communication Secteurs d’activité Métiers Types d’interventions Défense Télécoms Environnement Etat et collectivités Services Informatique & génie logiciel Télécoms & réseaux Systèmes embarqués & électronique Méthodes & BE Développement Intégration de systèmes R&D, veille technologique Etudes techniques Conseil Assistance à maîtrise d’ouvrage Exploitation de service

Types d’intervention : ATLANTIDE STM Atlantide est aujourd’hui une marque commerciale du groupe ALTRAN dédiée aux activités de conseil et d’ingénierie en Sciences et Technologies Marines. Secteurs d’activité :  Défense  Environnement  Offshore Thématiques :  Sciences de la Mer - Acoustique sous-marine - Océanographie - Géophysique marine - Informatique scientifique  Instrumentation - Ingénierie - Systèmes embarqués - Electronique - Industrialisation Types d’intervention :  Etude, audit, conseil  Assistance à maîtrise d’ouvrage  Conception, développement  Intégration de systèmes  R & D, veille technologique  Etudes scientifiques  Mesures, campagnes d’essais

Quelques références G. E. THALES A.S. TIC Quelques références G. E. THALES A.S. Etude et gestion d’ondes électromagnétiques dans le cadre de la guerre électronique Téléphonie ALCATEL-LUCENT service de Routage Intelligent des appels téléphoniques, statistiques. Accessibilité ALCATEL-LUCENT Rendre accessible un applicatif multimédia pour les déficients visuels

ATLANTIDE, quelques références STM DORT DGA / SPN Sonar actif dédié à la détection en environnement petits fonds, basé sur le retournement temporel MAREL IFREMER - NKE Réseau de surveillance de la qualité des eaux par mesure de paramètres physico-chimiques DUBM44 THALES US Mise au point du module de navigation du véhicule d’un sonar de chasse aux mines PREVIMER IFREMER Démonstrateur opérationnel de prévision des paramètres biogéochimiques dans le Golfe de Gascogne (www.previmer.org)

Partie 2 : les méthodes agiles

Le constat Selon le Standish Group 26 % des projets respectent les délais et le budget 46 % dépassent le budget ou sont en retard 28 % sont abandonnés ou voient leur périmètre largement restreint Combien correspondent à des besoins utilisateurs réels ? Exemple des projets, mon projet est en retard Réputation aussi bonne que dans le batiment Faire un sondage !!!!!!!!!!!!!!

Pourquoi ? Le contexte économique difficile met une pression forte Rapports parfois difficiles entre la maîtrise d’œuvre et la maîtrise d’ouvrage Confusion entre des besoins estimés et des besoins réels Les guerres contractuelles font oublier l’objectif initial Chacun s’abrite derrière les modalités d’un forfait qui fige dans le marbre des spécifications incomplètes Point 1: A faire pour hier, niveau dans l’urgence Point 2 : Relation de soustraitance difficile, communication, adapatation Point 3 : J’aimerai mais en faite non c’étais pas ça Point 4 : Point 5 : Exemple du champ vitesse

Les facteurs habituels d’échec Le manque de communication à tous les niveaux Une mauvaise compréhension des besoins L’insuffisance de l’architecture La mauvaise formation des personnes Le cadre contractuel inadapté L’insuffisance des tests L’absence d’une démarche Think Big – Start small L’absence réel de gestion du risque Com : Hiérachie, chef de projet et sont équipe exemple de gars qui gère un projet brestois sans réunion Insuffisance de l’architecture : PB de perf Ajout de fonctionnalité a gros rework Mauvaise formation : Le gars qui ne connais pas JAVA L’expert du jour Cadre contractuel inadapté : Artillerie lourd sur des petits projet Insuffisance des tests L’exemple du gars qui par en courant Ca compile donc c’est bon QUESTION A TOUS LE MONDE Risques : Il y a des risques techniques Il ya des risques humains trop souvent oubliés

Des vérités qu'il faut accepter Le client va faire évoluer son besoin Sans implication des deux parties le projet est un échec assuré Le conflit est un échec quelque soit sa forme Faire intervenir la hiérarchie n’est pas toujours une bonne solution pour résoudre les conflits. Ils doivent être résolus en amont avant de prendre de trop grandes proportions Dans la liste initiale des fonctionnalités 40 % ne serviront jamais Il n’y a aucune chance que le planning de GANTT initial soit respecté Le changement est inévitable Point 1 : Maturation Différence de vision Mauvaise maîtrise du besoin par la MOA Point 3 : Exemple de réunion qui se passe mal avec on s’enguele et rien n’est statué pour le projet Point 4 : Seul les chiffres comptent le reste n’est qu’accessoire Point 5 : word Point 6 : Diagrame de GANT, plus de temps à le mettre à jour qu’a gérer l’équipe et trouver des solutions LE CHANGEMENT EST UN FAIT Etre près que lutter contre

Les approches classiques Caractéristiques : Attachement farouche à tout planifier Pilotage du projet par des plans, des process Documentation importante basée sur un référentiel Une définition scrupuleuse du besoin en début de projet Approches dites « Prédictives » Point 1 : Diagramme de GANT sur 200 tâche 11 personne sur 1 ans Point 3 : Documentation importante 3 500 page de doc Spec 450 page MCD 200 pages TEST 750 paes

Tests, contrôle qualité L'approche en cascade Recueil des besoins Analyse détaillée Conception détaillée Développement Conception : Tous est sur le papier Différence entre la théorie et la pratique Confortable Développement : Pic de charge La pratique Les problèmes d’architectures Les premières versions avec plein de changement Tests : S’ils ne sont pas s’accrifié PB de perf Tests, contrôle qualité Intégration

Limites des approches classiques La rigidité de l’approche L’effet tunnel Une mauvaise communication Une documentation pléthorique Levée tardive des facteurs de risque

Méthodes agiles : historique En 1986, Barry W. Boehm présentait un nouveau modèle de développement itératif et incrémental. En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont réunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique du développement Agile et de ses principes sous-jacents.

Méthodes agiles : le manifeste Règle Principes Priorité des personnes et des interactions sur les procédures et les outils Construire des projets autours d’individus motivés. Leur donner l’environnement et le support dont ils ont besoin pour remplir leur mission Garder un haut niveau de motivation La méthode la plus efficace de communiquer des informations à une équipe est le face à face Porter une attention continue à l’excellence technique et à la conception Les meilleures architectures, spécification et conception sont le fruit d’équipes qui s’auto-organisent

Méthodes agiles : le manifeste Règle Principes Priorité d’applications opérationnelles sur une documentation exhaustive Le fonctionnement de l’application est le premier indicateur d’avancement du projet La simplicité – art de maximiser la quantité de travail non fait – est essentielle Livrer le plus souvent possible des versions opérationnelles de l’application

Méthodes agiles : le manifeste Règle Principes Priorité de la collaboration avec le client sur la négociation de contrat La priorité est de satisfaire le client en lui livrant très tôt et régulièrement des versions opérationnelles Le Client et les développeurs doivent coopérer quotidiennement tout au long du projet Sponsors, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniement Le projet doit avancer à un rythme soutenable et continu

Méthodes agiles : le manifeste Règle Principes Priorité de l’acceptation du changement sur la planification Une remise en cause à intervalles réguliers puis ajustement du comportement en conséquence Accepter le changement dans les exigences, même tard dans le cycle de vie du projet

Méthodes agiles / Méthodes classiques

Partie 3 : La méthodologie SCRUM ? Partie 3 : La méthodologie SCRUM

Le découpage de l’équipe SCRUM Le ScrumOwner ou directeur de produit : Interface client Oriente les choix et les priorités Décision sur le besoin Maitrise le besoin Disponible pour l’équipe Le ScrumMaster  : protéger l'équipe résoudre les problèmes non techniques Il doit fournir tous ce qui est nécessaire valeurs de Scrum soient appliquées, pas un chef de projet Equipe : Pas de rôle Auto gère Une seule entité

La notion d'équipe SCRUM Communiquer est la clé de tout Pas de hiérarchie, pas de distance au sein de l’équipe Pas de responsable dans l’équipe, l’équipe est responsable L’équipe avant tout, éviter les individualités Les décisions sont prises collégialement La répartition des tâches est faite collégialement Tous les membres participent à la conception

La notion d'équipe SCRUM L’acceptation de la critique et de la remise en question est essentielle Personne ne reste seul sur son problème L’équipe est ensemble dans la même salle Les membres de l’équipe tournent sur les différents types de tâche Chaque membre est garant de la méthode Chaque membre est un formateur pour les nouveaux arrivants

Le client La confiance est la clé Une véritable collaboration du client est essentielle Le client est fortement impliqué tout au long du projet et de manière continue Le client doit valider chaque livraison et faire un retour Le client participe à l’organisation de chaque « sprint » Partage des risques, des problématiques, des impératifs Une transparence totale entre les deux parties La confiance est la clé Plage de calendrier réservée Confiance Pas d’effet tunnel Réorientation possible Plus agile sur la réactivité face à l’évolution du client Une communication maintenue

Le découpage du projet Définition des fonctionnalités du produit : Description de la fonctionnalité Indice de la charge selon la suite (1,2,3,5,8,13,20,40) Indice de priorité pour le client Backlog = liste des fonctionnalités restant à développer Découpage du projet en sprint Backlog = liste des fonctionnalités

La répartition de la charge Projet traditionnel Phase du projet Charge Charge étalée sur tout le projet Découpage itératif Phase du projet

Le suivi d'avencement des sprints Indice de charge restant Définir les axe Point 1 : Hausse lié à une contraintes, doit être analysé

Le déroulement d’un sprint Réunion de planification du sprint Objectif du sprint + Points d’amélioration Définition du backlog du sprint avec les priorités Décomposition en tâches des items du backlog Daily meeting Qu'est-ce que j'ai fait hier ? Qu'est-ce que je compte faire aujourd'hui ? Quelles difficultés est-ce que je rencontre ? La démo chez le client Backlog = Liste des fonctionnalités restantes Le débriefing du sprint Analyse du sprint Amélioration de la méthode

Le suivi du sprint

La stratégie de documentation Une question : Est-ce que ce document va m'être vraiment utile, et tout de suite ? Le backlog, la liste des tâches, les deux graphiques Diagrammes métier associés au backlog du produit Diagrammes de séquence associé à un item du backlog Diagrammes d’architecture Un manuel utilisateur à chaque fin de sprint Un WIKI pour les FAQ et le partage d’information Point important : son utilité est réelle et immédiate. Graphiques : quantité totale de points restant à faire la quantité totale d'heures restantes à faire dans le sprint

La stratégie de tests Approche Test driven Development Travailler avec des interfaces Implémenter les tests unitaires avant le code Objectif : couverture du code en tests unitaires à 100 % Test d’intégration Valide les scénarii d’utilisation de l’application Un test minimum par item backlog du sprint CheckStyle, Findbugs, Profiling du code Qualité du code, vérifie les failles de sécurité Performance du code, fuite de ressource

L’intégration continue Principes : chaque soir les opérations suivantes sont effectuées Re-génération du produit récupéré du repository Analyse de la version Lancement des tests unitaires et d’intégration Génération et publication des résultats Avantages Automatisation du passage des tests Identification au plus tôt des régressions Mise en évidence des mauvaises pratiques Historique des versions, des analyses

Les limitations de la méthode Le client doit être « éduqué » à la méthode Le client doit s’impliquer fortement dans le projet L’équipe dirigeante doit accepter la méthode et ses impératifs (pas de budget fixe, pas de planning détaillé) Le maintien de la dualité Scrum Master / Product Owner est un exercice difficile Les individualités fortes sont incompatibles avec la méthode Accepter de se remettre en question n’est pas un exercice aisé

Les avantages de la méthode Une équipe soudée, motivée où chaque membre est acteur de la méthode et joue un rôle essentiel Montée en compétence de l’ensemble de l’équipe Une première version du logiciel qui fonctionne très rapidement Une charge étalée sur tout le projet et une meilleure tenue des jalons/délais Flexibilité aux changements Une qualification automatique avec une détection immédiate des régressions Un produit plus en phase avec le besoin final du client avec un client satisfait et impliqué

Synthèse

Questions / réponses

Les sources utilisées Livres Gestion de projet : vers les méthodes agiles (édition EYROLLES) Présentation Méthodes agiles : Jean-Louis Bénard – Business Interactif Site Web Wikipedia