MIAGE MASTER 1 Cours de gestion de projet

1. MIAGE MASTER 1Cours de gestion de projet Session 3 : Méthodes de réalisation d’un Projet

2. Questions sur le cours précédent Régie? Assistance Technique? Forfait? Projet de développement? TMA? TRA? Infogérance?

3. Sommaire • Les disciplines standard d’un projet • …, Spécifications, Conception, Développement, Recette, … • Les méthodes « classiques et obsolètes » (V, W) • Intérêts • Difficultés à postériori • Les méthodes « itératives » (RUP, 2TUP) • Intérêts • Difficultés à postériori • Les méthodes Agile • Fondements • Scrum, XP, Lean • Problématiques soulevées et difficultés rencontrées • Exemples

4. Les disciplines d’un projet : vue d’ensemble Rappel (session 1) : Le cycle de vie du projet ne concerne que la réalisation du produit informatique (en rouge) Maîtrise d’ouvrage Domaine Production Projet domaine « Etudes »

6. Les disciplines d’un projet : spécifications • Spécifications = manière dont l’application va implémenter les besoins (étape précédente = expression de besoin) • Définir le périmètre de l’application : • au niveau fonctionnel : activités métier à informatiser (souvent sous UML) • Navigation dans l’application • Description détaillé des écrans : maquettes, règles de gestion écran • Organisation des traitements • Description détaillée des traitements « batch » • Gestion des habilitations • Paramétrage et contrôle des traitements • au niveau technique : interfaces techniques du projet (normes, flux de données, interfaces matérielles (info indus, imprimantes, équipements mobiles, …) • Livrables • Spécifications Fonctionnelles Générales (SFG) - option • Spécifications Fonctionnelles Générales (SFD) - obligatoire • Spécifications Techniques Générales (STG) - option • Spécifications Techniques Détaillées (STD) - option 6

7. Les disciplines d’un projet : Architecture Technique • Peut être optionnel (si l’architecture est déjà en place et maîtrisée) • Nécessaire s’il faut industrialiser les développements sur de gros projets • Tâches : • Sélectionner avec soin les outils de développement • Récupérer un framework existant ou le créer • Mettre en place des fonctions standard pour les DAO • Identifier et contourner les contraintes techniques (ex : projets J2EE : comportements différents selon les navigateurs) • Réaliser des modèles d’implémentation qui seront largement utilisés, exemple : • Écran de saisie, navigation standard dans l’écran • Fenêtres standard d’erreurs et gestion standard des retours d’erreur • Livrables • Dossier d’architecture logicielle 7

8. Les disciplines d’un projet : Conception Technique • Conception Technique = Passerelle entre SFD et Code • Point d’entrée des développeurs • Tâches : • Analyser les SFD et détecter d’éventuelles anomalies • Identifier les composants à développer (classes, écrans, services métier, …) • Formaliser la navigation entre les écrans • Formaliser sous forme de pseudo code les traitements • Livrables • Dossier de Conception Technique 8

9. Les disciplines d’un projet : développement • Tâches • Développement, dans le respect : • Des spécifications • De la conception applicative • Tests usine • Tests Unitaires • Tests d’intégration • Tests par mutation, tests par propriétés • Tests fonctionnels, Tests IHM • Tests de montée en charge, de robustesse, de sécurité, de scalabilité, …. • Livrables • Code source • Exécutables, dans un package de livraison complet • Documentation du code (si intérêt) • Documentation utilisateur (dérive spécifications fonctionnelles) • Documentation des tests 9

10. Les disciplines d’un projet : recette • But • Passage de ses tests avant mise en production • Plusieurs niveaux : • VT : Validation technique (non contractuelle) : porte sur des sous ensembles de l’application • VA : Vérification d’Aptitude (ou VABF : VA au Bon Fonctionnement) : opération contractuelle : vérifier que l’application finale respecte scrupuleusement les spécifications. Cette validation déclenche la mise en production • VSP : Vérification sur Site Pilote (optionnel) : correction de bugs éventuels en production sur une extraction des sites client • VSR : Vérification pour Service Régulier (contractuel) : correction de bugs en production sur tous les sites clients. Déclenche le début de la garantie contractuelle • Livrables • Bordereaux de livraison (chaque étape) • PV (procès verbal) de recette (chaque étape) • « sans réserves » • « avec réserves » : bugs à corriger (mineurs) 10

12. Les méthodes « classiques et obsolètes » : Le Modèle en V • Part d’une conception globale et décompose le système en sous-ensembles, qui sont développés et testés séparément. On fait ensuite l’intégration et les tests du système complet. Il ne prévoit pas de retour arrière.

13. Les méthodes « classiques et obsolètes » : Le Modèle en W • Il part du modèle en V, en y ajoutant des phases d’élaboration de maquettes permettant de valider la conception. Il ne prévoit pas de retour arrière.

14. Les méthodes « classiques et obsolètes » : Synthèse • Intérêts : • Permettent de connaître « dès le départ » l’ensemble des fonctionnalités d’une application  Rassurant • Fournies une documentation avancée du logiciel • Simple à appréhender  Rassurant pour beaucoup de décideurs • Difficultés à postériori : • Savez-vous aujourd’hui définir dans le détail et par avance la maison de vos rêves ??  Réponse oui en théorie, et NON dans la pratique : au mieux vous en aurez une idée plus ou moins précise (votre 3ème maison sera la bonne!) • Il en va de même avec la conception d’une application. • Le besoin réel se construit au fur et à mesure de son utilisation. • Cela implique la plus part du temps : • Une application mal pensée par rapport aux besoins réels des utilisateurs • Un dépassement des délais et des coûts établis au départ du projet

16. Les méthodes « itératives » : Principes • L'idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par étapes. • Notion « itérative » • Modèle souple, proche des réalités de terrain, non figé comme les modèles précédents évitant les cloisonnements stricts entre analyse et réalisation par exemple (dans les modèles précédents, on considère qu'il faut terminer 100% des spécifications avant de démarrer le développement => faux en pratique) • Lié à une démarche de conception UML (scénario nominal, scénarii alternatifs, scénarii d’erreurs)

17. Les méthodes « itératives » : Comparaison avec les méthodes « classiques » • Ce qu’il y a de nouveau avec les méthodes itératives : Avant : approche en lots (qui sont des sous-ensembles fonctionnels), chaque lot étant implémenté complètement Méthode itérative : chaque livraison a pour périmètre l’application globale, mais en incluant des raffinements successifs

18. Les méthodes « itératives » : Un cycle itératif • Les quatre phases : • phase d'initialisation (Inception) : mise en place et finalisaton du SDP (Software Development Plan, ou Plan de Développement Logiciel) en définissant les itérations nécessaires. Début de la modélisation métier et de la réalisation de prototypes ; • phase d'élaboration (Elaboration) : fixe le maximum de règles fonctionnelles (uses cases) et réaliser des prototypes permettant de lever les risques et les maquettes permettant de modéliser l'IHM générale de l'application ainsi que la cinématique d'accès, • phase de construction (Construction) : développement et tests (unitaires, intégration, pré-qualification au gré de l'avancement des itérations de cette phase), • phase de transition (Transition) : préparation du déploiement et conduite du changement.

19. Vue « pragmatique » : les tâches sont continues dans le temps (en pratique, les spécifications ne sont jamais totalement figées) Opérations de modélisation et d’analyse Opérations de développement Opérations connexes Démarche itérative Les méthodes « itératives » : Implémentation RUP • RUP (Rational Unified Process) : les principes

20. Même en phase de pré-déploiement, les modifications dedétail des spécificationssont possibles On démarre les développementsalors que les cas d’exception desspécifications ne sont mêmepas encore abordés. On démarre les maquettes et prototypes avec uniquement 30% des spécifications Les méthodes « itératives » : Evolution de la couverture applicative • Illustration de la souplesse de la méthode : exemple type d’évolution de la couverture des spécifications sur le projet

21. Etape Initialisation Elaboration Construction Transition Charge de travail ~5 % 20 % 65 % 10% Proportion de temps dans le projet 10 % 30 % 50 % 10% Les méthodes « itératives » : RUP, Répartition de charges • La répartition des charges selon les phases du RUP :

22. Les méthodes « itératives » : Prise en compte d’évolutions dans RUP • Chaque évolution majeure du logiciel est traitée comme un projet à part entière, et consiste donc à redémarrer un cycle. • A un instant donné, les différentes évolutions du logiciel peuvent être dans des phases différentes

23. Les méthodes « itératives » : Le cycle en « Y » ou 2 TUP : 2 Tracks Unified Process Description des processus métier Spécifications Techniques Spécifications Fonctionnelles Architecture Technique Charte graphique Architecture Logicielle Maquette / Prototype Conception itération 1 Réalisation itération 1 Tests Techniques itération 1 Tests Fonctionnels itération 1 Recette Technique itération 1 Recette Fonctionnelle itération 1 Itération 2 Itération n Recette Technique itération n Recette Fonctionnelle itération n Mise en production Déploiement

24. Les méthodes « Itératives » : Comment contractualiser? (en général) • Le client envoi son cahier des charges plus ou mois flou • Le prestataire effectuer une réponse chiffrée l’engageant sur le respect de besoin et de son estimation de charge • Problème ! Cahier des charges flou => Nombreuses discussions contractuelles (= pertes de temps pour le projet) => Nombreux avenants => Non maîtrise du budget du projet • Une fois le client satisfait de la qualité, il paie son prestataire • De plus en plus les clients mettent des pénalités sur : • Les retards de livraison (1 jour de retard = 1 000 euros) • Sur la non qualité (1 anomalie bloquante = 2 000 euros)

25. Les méthodes « itératives » : Synthèse • Intérêts : • Permettent de connaître rapidement les principales fonctionnalités d’une application  Rassurant • Autorise de revoir une partie du besoin en cours de route • Fournies une documentation avancée du logiciel • Simple à appréhender et à contractualiser  Rassurant pour beaucoup de décideurs • Difficultés à postériori : • Méthode encore trop orientée sur une définition figée du besoin utilisateur • Ne traite pas les problématiques de qualité de code, de non régression • Ces méthodes s’approchent d’un processus de création incrémental

27. Les méthodes Agiles : Le manifeste Extrait du manifeste Agile : http://agilemanifesto.org/ Nous découvrons comment mieux développer des logicielspar 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.

28. Les méthodes Agiles : Le manifeste

29. Les méthodes Agiles : plusieurs solutions • Scrum • eXtreme Programming • Lean • Devops • Kanban • Crystal clear • FDD • ASD, DSDM, …………

30. Agile : Focus sur SCRUM La méthode Scrum est un processus itératif représenté par le diagramme suivant :

31. Agile : Focus sur SCRUM • Le « Backlog de produit » est constitué d’une liste de « User story », à savoir des cas d’utilisation simples et représentatifs. Il est modifié tout au long du projet par le directeur de produit. Chaque « User story » est orienté « fonctionnel » et est identifié de façon unique.

32. Agile : Focus sur SCRUM

33. Agile : Focus sur SCRUM Les rôles dans Scrum sont : Le « Directeur du produit ou Product Owner» est le représentant des clients et utilisateurs. C’est lui qui défini le produit au travers du « Backlog » de produit. Le « ScrumMaster » est chargé de protéger l'équipe de tous les éléments perturbateurs extérieurs à l'équipe et de résoudre ses problèmes non technique. L’ « Equipe » ne comporte pas de rôle prédéfini et est autogérée. Elle s’adresse directement au directeur de produit.

34. Agile : Focus sur SCRUM Le « Backlog de sprint » est réalisé à chaque début de sprint. Il contient l’ensemble des « User story » à réaliser pour celui ci. Le « Backlog de sprint » n’évolue jamais. La mêlée quotidienne (ou Daily Scrum) est effectuée chaque matin afin de vérifier qu’aucun élément ne perturbe le développement. Il s’agît d’un Stand-up Meeting (on reste debout pour que la réunion ne s’éternise pas…) Point court de 10 à 15min Exposer l’avancement de chacun et les problèmes rencontrés

35. Agile : Focus sur XP • Méthode résolument incrémentale et focalisée sur la programmation qui met en œuvre les pratiques suivantes : • TDD (Test DrivenDevelopement) • Refactoring • Intégration Continue • Propriété collective • Normes de développement • Pair programming • Rythme soutenable • Approche très complémentaire avec Scrum qui met en place l’organisation projet • Scrum et XP se sont mutuellement inspirées 35

36. Agile : Focus sur Lean • http://blog.octo.com/qu-est-ce-que-le-lean • Ensemble de principes et de pratiques issus de Toyota : • Respect des gens : • Le travail doit être motivant, épanouissant, inspirant • Le personnel doit être formé, encouragé et responsabilisé • Eliminer le gaspillage : • Surproduction, • Délai (exemple : temps d’organisation d’une réunion), • Stock, • Transport, mouvement inutile, processus inutile et défauts • Amélioration continue : • Innover : faire quelque chose de nouveau • Imiter : reprendre quelque chose qui a déjà marché ailleurs • Améliorer en continu pas à pas : partir de la situation actuelle et la changer petit à petit en s’assurant que chaque changement est une amélioration 36

37. Agile : Focus sur Lean • Ensemble de principes et de pratiques issus de Toyota : • Management visuel : • Consiste à rendre visible les écarts par rapport au standard. Comme cela il n’est pas besoin d’être courageux pour parler de ces écarts, ils sont traités tout de suite soit en renforçant la formation aux bonnes pratiques, soit en ajustant le standard. • Gemba : Avoir conscience du lieu où la valeur ajoutée est crée. • Kanban : Méthode de planification de production d’un flux tendu • Attention : Comme tout principe (méthode, dogme, religion, …), lorsque celui-ci est appliqué de manière excessive il devient néfaste! 37

38. Les méthodes « Agiles » : Comment contractualiser? • Rappel sur un contrat forfait classique : • Le client porte le risque du besoin, tant dis que le fournisseur porte le risque du produit. • Du fait qu’en ingénierie logicielle, le besoin évolue très fréquemment, mais que le contrat lui ne bouge pas, le client tente souvent de faire porter le risque du besoin sur le prestataire, ce qui donne souvent lieu à de nombreuses négociations contractuelles. Client Fournisseur

39. Les méthodes « Agiles » : Comment contractualiser? • Solution pour contractualiser en agile : • Engagement de moyen (régie) sur une équipe complète (Scrum Master Architecte, Développeur) • Les itérations étant courtes, en cas de non satisfaction de la part du client, celui-ci pourra remercier rapidement l’équipe constituée. • Forfait basé sur une métrique de productivité • 1ères itérations facturées au temps passé pour mesurer la vélocité de l’équipe • L’équipe est capable de produire tant de points (si l’on est en SCRUM) • Ensuite l’engagement forfaitaire porte sur un nombre d’itérations devant respecter un certaine vélocité • Le besoin fonctionnel peut évoluer en cours, à condition que la vélocité des itérations à produire reste la même. • D’autres formes contractuelles existent : • Target Coast, Target Delay, Partage de profit • Exemple de contrat Agile proposé par Xebia : • http://contrat-agile.org/

40. Les méthodes « Agiles » : Synthèse • Intérêts : • Favorise clairement la productivité • Permet aux utilisateurs de mieux appréhender leurs besoins • Difficultés à postériori : • Nécessite une forte implication du client • Conceptuellement plus complexe à appréhender (pour le client et pour les prestataires) • Nécessite des collaborateurs trèscompétents, capables d’être performants aussi bien sur le fonctionnel que sur le technique • Nécessité absolue de mettre en œuvre des outils de contrôle de qualité et de non régression • Méthodes (très) difficiles à mettre en œuvre sur des gros projets (30, 40, … ETP) • La contractualisation est rendue plus difficile

41. Cycle de vie des TMA Management et suivi de la prestation Réversibilité Prise en compte Maintenance Opérationnelle Réversibilité Montée en charge équipe Client Organisation Organisation Maintenance en mode autonome Réalisation des services de maintenance Acquisition des connaissances Maintenance en mode assisté Projets d’évolution Transfert de l’activité Recette Recette Lancement Fin de TMA TMA • Le Cycle de vie peut être spécifique à chaque métier • Tierce Maintenance Applicative (exemple => ) • Infogérance • Etc.

42. Les TMA : Comment contractualiser? (en général) • La phase de prise en compte est forfaitaire • Il arrive qu’elle soit offerte au client en tant que geste commercial • En phase opérationnelle : • Les activités de MCO, Support sont forfaitaires, mais basées sur un volume d’activité déjà constaté ou estimé (nombre d’anomalies, nombre d’incidents, …) • Les évolutions sont forfaitaires et utilisent des Unités d’Œuvre pour les valoriser • La phase de réversibilité est forfaitaire

44. « Votre » méthode Technique ERP/Décisionnel Important (>5000 j/h) Type de projet Dév. Spécifique C/S Moyen Dév. Spécifique J2EE Petit (<500 j/h) Taille du projet Normal Élevé Très élevé Risque Quelle méthode pour quel cas ? • Comment savoir quelle méthode appliquer ? Client CQFD ! Peu impliqué Volontaire Expérimenté

45. Prochaines sessions • Session 4 : Découpage d’un projet • TP 1 : Outil de suivi d’un projet (L. Descamps) • Session 5 : Estimation des charges • Session 6 : Outils de planification • Session 7 : Gestion des ressources d’un projet • Session 8 : Suivi d’un projet • TP2 : Suivi pratique d’un projet (L. Descamps) • Session 9 : Coûts d’un projet / Gestion des risques • Session 10 : Assurance Qualité • Session 11 : Recette et AMOA • Session 12 : Conduite du changement • Session 13 : Bilan de projet • Examen, correction