Vous êtes sur la page 1sur 14

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

1
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

2
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 ?

3
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

4
 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

5
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 1. Vision du produit
2. Estimer le coût 2. Road map (jalons)
3. Recenser les activités 3. Plan de release
4. Calculer la durée des (1 release=pl.sprints)
activités 4. Plan de sprint (itération)
5. Ordonnancer les activités 5. Cycle quotidien
6. Établir le planning
7. Ajuster le planning

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.

6
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).

7
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.

8
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/

9
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 Choisir les tâches

Le chef de projet peut ensuite distribuer les tâches non choisies. Notons aussi
qu’une tâche peut être réalisée par plusieurs personnes.

Le tableau des tâches mural

Le tableau des tâches sert à montrer à toute l’équipe l’état de l’avancement des
travaux au cours d’un sprint. Ce tableau est divisé en trois ou quatre sections
verticales : À faire, En cours, En test (facultatif), Terminé. Pour chaque story
sélectionné, l’équipe définit les tâches qui y sont correspondantes et chacune est
inscrite sur un « post-it ». On y inscrit la tâche, le nom du technicien qui la
réalise, le temps planifié en heures, la date, et le temps réel en heures.

Si les techniciens ne sont pas tous dans un même lieu commun, il existe des
logiciels permettant de partager un tableau.

La mêlée quotidienne ou Scrum

Le but de cette réunion est d’optimiser la possibilité que l’équipe atteigne les
objectifs du sprint. Elle se tient près du tableau des tâches.

3 questions :
 Qu’est-ce que tu as fait hier?
 As-tu rencontré des problèmes?
 Qu’est-ce que tu fais aujourd’hui?

10
Introduction à DevOps
Le DevOps est un mouvement, une approche qui privilégie l’étroite collaboration
entre les équipes de développement (dev) et d’exploitation (ops) pour toute
solution TI.

https://www.youtube.com/watch?v=M6F6GWcGxLQ

Étapes et outils :

11
Les démarches fondatrices de DevOps

Le mouvement DevOps s’appuie sur l’adoption et l’intégration de trois principales


démarches ou méthodes actuelles :

 Les méthodes Agile de développement logiciel telles que Scrum.


 La gestion des Services IT (ITSM) liée aux bonnes pratiques préconisées
par ITIL.
 Lean qui permet d’optimiser le travail et améliorer la qualité de la
production

12
Terminologie

Release
Une release est une période de temps avec un jalon à date fixe, constituée d’une
séquence d’au moins 4 sprints.

Jalon
Le jalon est un élément constitutif d'un délai représenté par une date fixe.

Sprint
C’est le découpage du projet en incréments, chacun comportant un périmètre de
stories du backlog.

Itération
Modèle en spirale, synonyme de Sprint.

Backlog
C’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.

Story
C’est une entrée dans le backlog, il s’agit d’une future réalisation, tâche en attente
ou changement.

Périmètre
Stories sélectionnées dans un sprint.

Scrum quotidien ou mêlée quotidienne


Réunion quotidienne de l’équipe de 15 minutes maximum, qui se tient au début de
chaque journée.

Product Owner
Chef de produit, spécialiste du domaine métier. Il s’agit généralement du client.

Product Master
Chef de projet

13
Webographie

http://fr.wikipedia.org/wiki/M%C3%A9thode_agile
http://www.access-dev.com/access-dev/la-gestion-de-projet-methodes-
classiques-vs-methodes-agiles/
http://ineumann.developpez.com/tutoriels/alm/agile_scrum/
http://m.emery.management.pagesperso-orange.fr/MP1projetpdf.pdf

Bibliographie

MESSAGER ROTA Véronique. Gestion de projet agile avec Scrum…, Eyrolles 3e


édition. Architecte logiciel, Paris, 2010, 278 pages.

AUBRY, Claude. SCRUM le guide pratique de la méthode agile la plus populaire.


DUNOD. Études, développement et intégration. 2010, 267 pages.

14

Vous aimerez peut-être aussi