Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

1 Notes de cours (résumé) Gestion de projets Cours 420-253-RL : Gestion de proj

1 Notes de cours (résumé) Gestion de projets Cours 420-253-RL : Gestion de projets et formation TABLE DES MATIÈRES Introduction ................................................................................................................................ 3 Exemples de projets trop coûteux ou abandonnés au Québec ................................................. 4 Le registre des armes à feu .................................................................................................. 4 Le dossier santé et la CARRA : .............................................................................................. 4 L’exemple d’Hydro-Québec : ............................................................................................... 4 Méthode de gestion de projets classique versus agile .............................................................. 4 La méthode scrum agile .............................................................................................................. 6 Définition ................................................................................................................................ 6 4 valeurs ................................................................................................................................. 6 L’équipe : ............................................................................................................................ 6 L’application : ...................................................................................................................... 6 La collaboration : ................................................................................................................. 6 L’acceptation du changement : ............................................................................................ 6 12 principes ............................................................................................................................. 7 Pratiques Agile ........................................................................................................................ 7 L’équipe .................................................................................................................................. 7 Chef de produit (Product owner) ......................................................................................... 7 Chef de projet (Scrum master) ............................................................................................. 8 Membres de l’équipe........................................................................................................... 8 Backlog de produit .................................................................................................................. 8 Types de stories ...................................................................................................................... 8 User story ............................................................................................................................ 8 Story technique ................................................................................................................... 8 Défaut ................................................................................................................................. 8 2 Release ................................................................................................................................... 8 Planification d’une release et des sprints en équipe ................................................................ 9 Le QUOI : définir l’objectif du sprint ...................................................................................... 10 LE COMMENT : les tâches ...................................................................................................... 10 Le tableau des tâches mural .................................................................................................. 10 La mêlée quotidienne ou Scrum ............................................................................................ 10 Introduction à DevOps .............................................................................................................. 11 Étapes et outils : .................................................................................................................... 11 Les démarches fondatrices de DevOps .................................................................................. 12 Terminologie ............................................................................................................................. 13 Webographie ............................................................................................................................ 14 Bibliographie ............................................................................................................................. 14 3 Introduction Dans tout projet, peu importe la méthode de gestion, il est important d’atteindre l’équilibre : - TECHNIQUES : ce qu’on veut FAIRE - DÉLAI : en combien de TEMPS ? - COÛT : avec quel BUDGET ? 4 Exemples de projets trop coûteux ou abandonnés au Québec Le registre des armes à feu Le dossier santé et la CARRA : Le Dossier santé Québec (DSQ), dont les coûts estimés atteignent pratiquement le double des prévisions, ou le projet de la CARRA, qui était évalué à 75 millions $ et qui est rendu à 110 millions $, ne sont que quelques exemples du fiasco en termes de gestion des ressources informatiques. La CARRA n’existe plus puisqu’elle a été, entre-temps, fusionnée avec la Régie des rentes pour devenir Retraite Québec. https://www.journaldemontreal.com/2016/10/02/30-m-pour-des-projets-agonisants L’exemple d’Hydro-Québec : « Hydro-Québec fait face, depuis juillet 2012, à un deuxième recours collectif, après celui de 2010 qui portait sur des calculs de frais d’intérêt excessifs. La clientèle a en effet subi des problèmes de facturation depuis 2008, date de l’implantation d'un nouveau système informatique. » … le système informatique n’était pas capable de calculer le taux d’intérêt de manière composée. Article complet : http://leclub.clubhec.ca/profiles/blogs/le-gouffre-sans-fond-de-l- informatique-au-qu-bec Méthode de gestion de projets classique versus agile L’expérience a démontré que dans le cas des projets de développement informatique il n’est pas approprié d’utiliser la démarche de gestion de projets classique. Premièrement, dans le développement logiciel tout n’est pas prévisible. Il est difficile d’estimer précisément les tâches à cause de la complexité du développement informatique. On constate aussi qu’íl est souvent difficile de s’entendre avec le client. Deuxièmement, plus une anomalie est détectée tard, plus les coûts sont élevés. Selon Standard Reports, un faible poucentage des projets sont réussis, mais ce nombre est en augmentation à cause des raisons suivantes :  une plus grande généralisation des méthodes ou principes de gestion de projets  une meilleure gestion des risques 5  le développement des Projet Management Office (voir PMO - Project Management Office - Tour d’horizon, qui apporte une meilleure maturité dans la gestion des projets.  l’apport des méthodes agiles : D’après Standish Group 2011 Réussis En difficulté Abandonnés 1994 16% 53% 31% 1996 27% 33% 40% 1998 26% 46% 28% 2000 28% 49% 23% 2002 34% 51% 15% 2004 29% 53% 18% 2006 35% 46% 19% 2009 32% 44% 24% 2010 37% 42% 21% Selon Standish group Source : http://blog.apollo-formation.com/les-methodes-agiles/ Causes des retards dans la livraison des projets 6 La méthode scrum agile Définition Approche dont le cycle de vie est itératif, incrémental et adaptatif pour le développement de logiciels, réalisée de manière collaborative. À chaque itération, une version mimimale du produit est présentée au client. Il existe plusieurs méthodes Agiles, mais nous travaillerons avec SCRUM. Être agile c’est être capable de s’adapter au changement. Que ce soit des changements de besoins, de priorités, de technologies, ou d’équipe projet. Les méthodes Agiles datent de 2001 avec le manifeste Agile qui véhicule les valeurs et principes suivants : Démarche classique Démarche Agile 1. Estimer le délai 2. Estimer le coût 3. Recenser les activités 4. Calculer la durée des activités 5. Ordonnancer les activités 6. Établir le planning 7. Ajuster le planning 1. Vision du produit 2. Road map (jalons) 3. Plan de release (1 release=pl.sprints) 4. Plan de sprint (itération) 5. Cycle quotidien 4 valeurs L’équipe : Les personnes et leurs interactions sont plus importantes que les processus et les outils. La communication est fondamentale. L’application : Un logiciel qui fonctionne prime sur de la documentation, par contre le code doit être commenté abondamment. La collaboration : Le client doit être impliqué dans le développement, il doit collaborer avec l’équipe et fournir du « feedback » continu sur l’adaptation du logiciel à ses attentes. L’acceptation du changement : La réponse au changement passe avant le suivi d’un plan. 7 12 principes 1. Satisfaire le client en livrant tôt et régulièrement. 2. Accepter les changements 3. Livrer fréquemment une application qui fonctionne. 4. Collaborer quotidiennement entre clients et développeurs. 5. Bâtir le projet autour de personnes motivées : leur fournir environnement, support, confiance. 6. Communiquer par des conversations en face à face. 7. Mesurer la progression avec le logiciel qui fonctionne. 8. Garder un rythme de travail durable. 9. Rechercher l’excellence technique et la qualité de la conception. 10. Laisser l’équipe s’auto-organiser. 11. Rechercher la simplicité. 12. Réfléchir aux moyens de devenir plus efficace à intervalles réguliers. https://www.youtube.com/watch?v=Wm2sGXv6Y0o Pratiques Agile  Livrer fréquemment et régulièrement le logiciel.  Faire des cycles de développement courts et limités dans le temps.  Constituer une équipe complète pour un développement.  Gérer les membres de l’équipe en les responsabilisant.  Produire des plans pour plusieurs niveaux : détaillés pour le court terme et généraux pour le moyen terme.  Développer en intégrant le code de façon continue.  Faire des bilans pour améliorer la façon de travailler.  Avoir un backlog de produit tenant compte des priorités.  Suivre l’avancement des projets par la tenue d’une réunion (spécifique à SCRUM) : mêlée quotidienne de 15 minutes. Les objectifs visés sont : améliorer la motivation, synchroniser les tâches, débloquer les situations difficiles, accroître le partage de connaissances. L’équipe Chef de produit (Product owner) : spécialiste du domaine métier (client). 8 Chef de projet (Scrum master) : dans SCRUM il n’y a pas de hiérarchie autoritaire, sa responsabilité est d’aider l’équipe à appliquer SCRUM. Le chef de projet est axé sur le processus. C'est le groupe de travail qui dispose du pouvoir de décision car l’un des rôles de SCRUM est l’auto-organisation. Le chef de projets doit avoir une bonne connaissance de SCRUM, comprendre les aspects techniques, communiquer facilement, guider, avoir un talent de médiateur, être tenace, être transparent, et être au service de l’équipe. Membres de l’équipe Backlog de produit Le backlog de produit est l’élément pivot du développement SCRUM. Il s’agit d’une liste classée en ordre de priorités des futures réalisations, tâches en attente et changements. Chaque entrée est appelée story, il doit donc y avoir une liste de stories partagée et mise à jour régulièrement par l’équipe. Chaque story devrait inclure les informations suivantes : nom, identifiant, description, type, état et taille. Le backlog de produit sera en fait entré sous Excel. Types de stories User story : décrit un comportement du produit visible par les utilisateurs. Story technique : est invisible pour les utilisateurs mais visible par l’équipe de développement. Défaut : il s’agit d’une demande d’amélioration du produit, il n’existe pas de bogues en SCRUM Agile. Release Définition : une release est une période de temps avec un jalon à date fixe, constituée d’une séquence d’au moins 4 sprints. 9 Planification d’une release et des sprints en équipe Toute l’équipe SCRUM participe à la planification. Chaque sprint doit être planifié quelques jours avant la fin du sprint courant lors d’une réunion d’un maximum d’une heure. Les sprints ne doivent pas se chevaucher, une modification dans le sprint courant deviendra une story du sprint suivant. Idéalement les sprints devraient avoir la même durée pour donner un rythme au projet. Cette réunion consiste à sélectionner les exigences prioritaires pour le client dans le backlog du produit. Celles-ci seront développées, testées et livrées au client (sous-ensemble de produit fonctionnel). Il faut inclure dans la planification les rencontres de feedback, et les rencontres de planification de release / sprint, mais pas le scrum quotidien. Source : mailto:http://ineumann.developpez.com/tutoriels/alm/agile_scrum/ 10 Le QUOI : définir l’objectif du sprint L’objectif est défini en une phrase, il doit être SMART Spécifique Mesurable Acceptable Réaliste Temps LE COMMENT : les tâches 2.1 Identifier les tâches (courtes) à partir des stories sélectionnées (périmètre) 2.2 Estimer les tâches (durée en heures) 2.3 uploads/Management/ notes-de-cours-scrum-agile.pdf