Piloter son projet

informatique
Les acteurs d’un projet informatique

Dans la réalisation de tout projet informatique, différents acteurs interviennent :

 la maîtrise d’ouvrage (MOA) : il s’agit du « client » du projet, soit celui qui en
attend des résultats concrets. Il revient à cet acteur de définir les objectifs,
le budget et les délais ;
 la maîtrise d’œuvre (MOE) : il s’agit du « fournisseur » du projet, soit celui
qui réalise l’ouvrage même. Il revient à cet acteur de concevoir et de
proposer des solutions, d’effectuer des tests avant la livraison et de respecter
les coûts et les délais fixés ;
Les priorités d’un projet informatique

Pour piloter son projet informatique ou de système d’information, la·le chef·fe de

projet s’appuie sur des données qualitatives et quantitatives, afin de respecter les
attentes sur différents plans :
 les coûts : toute action entreprise doit respecter le budget défini au lancement du
projet. La maîtrise des coûts passe notamment par l’anticipation des risques de
déviation et par l’instauration de mesures correctives pour éviter tout
dépassement de l’enveloppe allouée ;
 les délais : la conduite du projet doit tenir les délais annoncés au client, en
suivant des jalons intermédiaires. Le respect des délais implique l’identification
des potentiels dérapages par rapport au planning initial et à la mise en œuvre des
actions de correction ;
 la qualité : l’exécution du projet implique également des phases de validation
avec les différents intervenants. La garantie de la qualité est permise par la
vérification de la conformité aux exigences.
Activités de développement
Activités de développement

 Elles sont décrites de façon indépendante en indiquant leur rôle, utilisent et produisent des
“artefacts”
 Selon le modèle, une activité peut jouer un rôle plus ou moins important et parfois ne pas
exister du tout.
 Elles concernent :
 Planification (Étude de la faisabilité)
 Spécification des besoins (Requirement analysis)
 Analyse (Spécification formelle)
 Conception (Spécification technique)
 Implémentation (Codage) et tests unitaires
 Intégration et tests d’ensemble
 Livraison
 Maintenance
Planification
Spécification des besoins
Analyse
Conception
Impléméntation
Intégration et test du système
Livraison, maintenance, évolution
Du prédictif à l’adaptatif
Choisir une méthodologie efficace

Une méthode définit une démarche en vue de produire des résultats. Une méthode permet
d’assister une ou plusieurs étapes du cycle de vie du logiciel. Les méthodes d’analyse et de
conception fournissent des notations standards et des conseils pratiques qui permettent d’aboutir
à des conceptions «raisonnables»
Il existe de nombreuses méthodologies en gestion de projet, telles que :
 les méthodes traditionnelles (les méthodes prédictives) qui correspondent à un cycle de vie
du logiciel en cascade ou en V, sont basées sur une planification très précise et très détaillée,
qui a pour but de réduire les incertitudes liées au développement du logiciel. Cette
planification rigoureuse ne permet pas d’évolutions dans les besoins des utilisateurs, qui
doivent donc être figes dès l’étape de définition des besoins.
 les méthodes Agile (les méthodes adaptatives) : Scrum, Kanban, Extreme Programming. Ce
sont des méthodes qui correspondent à un cycle de vie itératif, incrémental et adaptatif.
Elles sont inévitables et doivent être pris en compte par les modèles de développement. Ces
méthodes privilégient la livraison de fonctionnalités utiles au client à la production de
documentation intermédiaire sans intérêt pour le client.
Cycle de vie en cascade
C’est un modèle qui a comme objectif majeur de jalonner (présenter sobrement)
rigoureusement le processus de développement et de définir de façon précise les
rôles respectifs du fournisseur qui produit un livrable et du client qui accepte ou
refuse le résultat. Le découpage temporel se présente comme une succession de
phases affinant celles du découpage classique : Étude de faisabilité, Définition
des besoins, Conception générale, Conception détaillée, Programmation,
Intégration, Mise en œuvre. Chaque phase donne lieu à une validation officielle.
Si le résultat du contrôle n’est pas satisfaisant, on modifie le livrable. En
revanche, il n’y a pas de retour possible sur les options validées à l’issue de
phases antérieures
Cycle de vie en cascade

 Longtemps, le développement de programmes informatiques a été régi par

des approches relativement cadrées, pour ne pas dire rigides. Non que ces
approches soient mauvaises ou contre-performantes, mais le succès d’un
développement selon le processus cascade (ou ses dérivés) dépend d’abord de
la stabilité de ses spécifications.
Les méthodes adaptatives : Agiles

 Parce que les méthodes de gestion de projet en cycle linéaire et prédictif ne répondaient pas bien
aux complexités que comporte la vie d’un projet.
 Ils rédigent ensemble le Manifeste Agile qui est composé de 4 valeurs et de 12 principes généraux.
 En réalité il n’existe pas une mais plusieurs méthodes agiles. Elles regroupent un ensemble de
pratiques flexibles, itératives et donc plus réactives face au changement. Elles impliquent
davantage le client dans la réalisation du projet en mettant l’objectif final du projet au cœur de ses
préoccupations.
 Les méthodes agiles reposent donc sur un cycle itératif et adaptatif laissant cette place tant
nécessaire aux changements.
 Agile représente un ensemble de “méthodes et pratiques basées sur les valeurs et les principes du
Manifeste Agile”, qui repose entre autre sur la collaboration, l’autonomie et des équipes pluri-
disciplinaires.

17
Itératif

 Une méthode agile est avant tout itérative sur la base d’un affinement du besoin mis en œuvre dans des fonctionnalités en cours de réalisation
et même déjà réalisées. Cet affinement, indispensable à la mise en œuvre du concept adaptatif, se réalise en matière de génie logiciel sous
deux aspects :
 fonctionnellement, par adaptation systématique du produit aux changements du besoin détecté par l’utilisateur lors de la
conception-réalisation du produit (notion de validation permanente de l’utilisateur avec RAD et notion de conception émergente
avec XP) ;
 techniquement, par remaniement régulier du code déjà produit (refactoring).
 Le développement itératif n'est pas une idée récente, il existe depuis longtemps sous différentes appellations: évolutionnaire, à paliers, spirale,
ainsi que de nombreuses autres désignations. D'après Fowler, l'idée dans le développement itératif est de produire fréquemment une version du
système qui fonctionne, mais n'ayant qu'une partie des fonctionnalités demandées qui doivent être intégrées et testées aussi soigneusement
qu'une livraison finale (Fowler, 2005).
 Une méthode itérative est caractérisée par sa capacité à planifier une itération de production en termes de fonctionnalités et
d'interdépendances. Le processus de développement est appliqué plusieurs fois. Le terme itération fait référence à la nature cyclique d'un
processus dans lequel les activités sont répétées d'une manière structurée.
18
Incrémental

 Une méthode agile est, éventuellement, incrémentale. Lorsque le projet, quel que
soit le nombre de participants, dépasse en durée une dizaine de journées en
moyenne, la production de ses fonctionnalités s’effectue en plusieurs incréments
 Dans le développement itératif, chaque itération augmente la quantité
d'information, la quantité de logiciel fonctionnel, etc. Dans une méthode dite
incrémentale, le logiciel évolue par incrément et chaque itération correspond à un
incrément. Le terme incrément fait donc référence au résultat de chaque
itération. Le système croît avec le temps de façon incrémentale, itération par
itération, d'où le terme de développement incrémenta!.

19
Itératif-incrémental

20
Itératif, incrémental et adaptatif

 Elle se base sur la mesure objective du changement afin de l’accepter. La

dernière génération de méthodes adaptatives se qualifie « d’Agiles ». Elle se
structure selon un cycle dit « itératif, incrémental et adaptatif ».

21
Itératif, incrémental et adaptatif

22
Itératif, incrémental et adaptatif

 La notion d'adaptatif, quant à elle, nécessite au-delà d'un simple principe, la

mise en œuvre de techniques de contrôle de l'évolution du livrable et d'une
métrique formelle des modifications, avant, après et en cours de la
production. Il en découle une planification opérationnelle élémentaire,
directement visible par le biais de l'affichage mural.

23
VALEURS AGILES

 Pour répondre à ce problème est créé en 2001 le manifeste Agile. Rédige par
17 experts qui se dressent contre l'échec des cycles en cascade, Il propose 4
valeurs fondamentales, et 12 principes

La réactivité face au changement plutôt que le suivi d'un plan

l’interaction avec les personnes plutôt que les processus et les outils
un produit opérationnel plutôt qu’une documentation pléthorique
La collaboration avec le client plutôt que la négociation de contrat

24
Méthodes agiles
Classées par date de publication
 Rapid Application Development(RAD, 1991)
 Dynamic systems developmment method(DSDM, 1995, consortium anglais
commercialisant le RAD)
 Scrum(1996)
 Feature Driven Development ((en)FDD) (1999)
 Extreme programming(XP, 1999)
 Adaptative software development(ASD, 2000)
 Crystal clear(2004)
 Autres méthodes se reconnaissant un lien avec l'agilité :
 2TUP (2 track unified process, prononcez « toutiyoupi ») ,
 Rational Unified Process (RUP)

25
Exemple de méthode agile : Scrum
La méthodologie Scrum

 La méthode Scrum, élaborée à partir de 1986, s’est répandue et imposée

depuis quelques années comme étant la référence dans la mise en œuvre de
projets agiles. Il s’agit d’une approche holistique qui procède par cycles
courts (des sprints ou itérations) pour organiser le développement logiciel de
façon incrémentale et itérative. Les fonctionnalités sont réalisées
progressivement et livrées au fur et à mesure.
 L’origine du nom est un terme de Rugby : melée. Analogie: les membres de
l’équipe doivent atteindre l’objectif en équipe, comme les joueurs qui se
passent le ballon.
Scrum

 Scrum est un cadre structuré pour soutenir le

développement de produits complexes.
 Scrum se compose d'équipes Scrum et de leurs rôles,
d'évènements, d'artéfacts et de règles associés.
 Chaque élément du cadre répond à un but spécifique et
est essentiel à la réussite et l'utilisation de Scrum.

28
Cycle de vie de Scrum
Product Backlog
:
Fonctionnalités Daily Scrum
priorisées par Meeting
le client

Sprint Review
Meeting

Sprint Planning
Meeting

Sprint Backlog :
Fonctionnalités affectées Deliverable :
à l'itération (Sprint) Incrément 29potentiellement
estimées par l'équipe. exploitable
Roles
‣The Product Owner manages the product (and
return on investment)
‣The ScrumMaster manages the process
‣The team manages itself
30
Le product owner

 Product Owner : porte la casquette et la vision du produit à réaliser : le

représentant du client
 Partage une vision produit
 Définit et décrit les fonctionnalités
 Définit leur priorités
 Coordonne les interlocuteurs métier
 Est responsable du produit

31
Le scrum master

 Garant du processus que l’équipe a défini pour elle même

 Gardien du cadre de scrum
 Protecteur de l’équipe
 Rend visible les problèmes
 Accompagne la résolution de problème
 Faciliter les rituels définis dans le process

32
Equipe

 Didiée
 Pluridisciplinaire(architectes, développeurss, testeurs, analystes, graphistes, etc): Des
équipes pluridisciplinaires ont toutes les compétences nécessaires pour réaliser le
travail sans dépendre de personnes ne faisant pas partie de l'équipe.
 Stable
 Co-localisée
 Auto-organisé : Des équipes auto-organisées choisissent la meilleure manière de
réaliser leur travail, plutôt que d'être dirigées par des personnes extérieures à l'équipe.
 7 personne (+/-2) : Une équipe de développement de taille optimale est assez petite
pour demeurer agile et assez grande pour effectuer du travail significatif.
 Le modèle d'équipe de Scrum est conçu pour optimiser la flexibilité, la créativité et la
productivité.

33
Renions

34
Sprint Planning

 Résumé : réunion de préparation d’un Sprint, typiquement divisée en deux

parties (la première partie c’est le « quoi » et la seconde partie c’est le «
comment »).
 Participants : Partie une : Product Owner, Equipe, ScrumMaster. Partie deux :
Equipe, ScrumMaster, Product Owner (optionnel, mais doit être disponible
pour toutes questions).
 Durée : chaque partie est limitée à une heure par semaine de Sprint.
 Au démarrage de chaque Sprint, la Réunion de Planification de Sprint a lieu.
 Sprint Planning : Planifier les itérations en deux phases :
 Présenter les user story (les histoires des utilisateurs, fonctionalités)
 Décomposer les story en tache
35
Product Backlog Refinement
 Résumé : fractionner les gros éléments, analyser les éléments, ré-estimer, et re-
prioriser, pour les Sprints à venir.
 Participants : l’Equipe; le Product Owner participera entièrement à l’activité s’il
possède lui-même l’expertise requise pour l’analyse détaillée, sinon il pourra
simplement indiquer les directions à suivre où les re-priorisation à effectuer.
 Durée : habituellement pas plus de 10% de la capacité de production de l’Equipe sur le
Sprint, bien que cela puisse prendre plus de temps pour les éléments nécessitant une
analyse poussée. Par exemple, sur une durée du Sprint de deux semaines, un jour
pourra être consacré à l’affinage
 Cela inclut une analyse détaillée des exigences, le fractionnement d’éléments de forte
granularité en éléments plus petits, l’estimation de nouveaux éléments, et la
réestimation d’éléments existants. Scrum ne dit pas comment faire ce travail, mais
une technique fréquemment utilisée consiste à organiser une réunion dédiée en milieu
ou fin du Sprint, de sorte que l’Equipe et le Product Owner puissent se focaliser sur ce
travail sans être perturbé.

36
Product Backlog Refinement

 Cette activité de clarification ne concerne pas les éléments sélectionnés pour

le Sprint en cours, mais les éléments futurs, qui seront généralement traités
dans un ou deux Sprints.
 Grâce à cette pratique, la Planification des Sprints devient relativement
simple car le Product Owner et l’Equipe travaillent sur un lot d’éléments
clairs, bien analysés et soigneusement estimés.
 Lorsque cet atelier d’affinage n’a pas été effectué (ou bien mal effectué), il
y a signe qui ne trompe pas: la réunion de Planification de Sprint engendre de
nombreuses questions, des découvertes, de la confusion, et se termine au
final sur un sentiment d’inachevé!

37
Daily scrum

 Résumé : suivi et coordination entre les membres de l’Equipe.

 Participants : l’ensemble de l’Equipe est requise ; le Product Owner
est optionnel ; le ScrumMaster est généralement présent mais s’assure
que l’Equipe est autonome.
 Durée : 15 minutes maximum.
 Elle se déroule chaque jour de travail à une heure fixe où chaque
membre expose :
 Qu’est ce que j’ai fait hier?
 Qu’est ce que je compte faire?
 Obstacles

38
Daily scrum
 C’est le moment privilégié pour une Equipe auto-organisée
d’échanger sur la bonne marche de l’activité, et de se
coordonner.
 Une personne note les problèmes rencontrés, et le
ScrumMaster doit aider les membres de l’Equipe à les
résoudre.
 Il y a peu ou pas de discussion approfondie durant le Daily
Scrum, l’objectif n’étant que de répondre à ces trois
questions. Si des discussions sont nécessaires, elles se tiennent
lors de réunions consécutives, immédiatement après le Daily
Scrum.
 => un moyen supplémentaire d’inspection et d’adaptation.

39
Daily scrum

40
Sprint Review

 Résumé : inspection et adaptation de l’incrément de fonctionnalité du

produit.
 Participants : l’Equipe; le Product Owner, le SrumMaster. Toutes parties
prenantes en fonction du besoin, conviées par le Product Owner.
 Durée : timebox d’une heure par semaine de Sprint.
 Une fois le Sprint terminé, il y a la Revue de Sprint, réunion durant
laquelle l’Equipe et le Product Owner passent le Sprint en revue.
 Sprint Review: on fait le bilant de notre itération en faisant une
présentation devant notre client on va recueillir le feedback client et le
client peut éventuellement ajuster ses besoin ou mieux les exprimer
puisqu’il se base sur des éléments tangibles
41
Sprint Review

 La Revue de Sprint est une activité d’inspection et d’adaptation pour

le produit. C’est un moyen pour le Product Owner de connaître la
situation actuelle du produit et de l’Equipe (un examen du Sprint, en
quelque sorte) ; et pour l’Equipe de connaître la situation actuelle du
Product Owner et du métier.
 La revue inclut certainement une manipulation de la version de
l’application réalisée par l’Equipe durant le Sprint, mais si on se
focalise uniquement sur le visionnage du produit plutôt que sur
l’échange autour du produit, il y a alors un déséquilibre.

42
La rétrospective

 Résumé : inspection et adaptation du processus et de

l’environnement.
 Participants : l’Equipe, le SrumMaster, le Product Owner (optionnel).
Toute autre partie prenante peut être invitée par l’Equipe, sans quoi
elle n’est pas autorisée à y participer.
 Durée : timebox de 45 minutes par semaine de Sprint.
 La rétrospective : un moment d’amélioration continu on se remet en
question on va recenser nos point de force nos points de faiblesse nos
blocage et nos actes d’amélioration pour l’itération qui suit

43
La rétrospective

 C’est l’opportunité pour l’Equipe d’échanger sur ce qui fonctionne

bien et sur ce qui ne fonctionne pas, et de s’accorder sur des
changements à expérimenter.
 Beaucoup d’Equipes se concentrent sur les problèmes, et c’est
dommageable. Cela peut conduire à associer les rétrospectives à des
événements négatifs ou déprimants. Au lieu de cela, il faut s’assurer
que les rétrospectives abordent également les forces et les aspects
positifs.

44
 ‣Product Backlog
‣Sprint Backlog
‣Burndown Chart

Artifact
45
Product Backlog

 Example Scrum Product Backlog

46
Product Backlog

 The Scrum Product Owner uses the Scrum Product Backlog during the Sprint
Planning Meeting to describe the top entries to the team. The Scrum Team
then determines which items they can complete during the coming sprint.
Each Scrum Product Backlog has certain properties that differentiate it from a
simple to-do list: an entry in the Scrum Product Backlog always add value for
the customer
 the entries in the Scrum Product Backlog are prioritized and ordered accordingly
 the level of detail depends on the position of the entry within the Scrum Product Backlog
 all entries are estimated
 the Scrum Product Backlog is a living document
 there are no action-items or low-level tasks in the Scrum Product Backlog

47
Product Backlog

48
Sprint Backlog
 Most teams will know the sprint backlog as the task board,
which is the physical representation of the list of work they
have committed to do during the current sprint.
 The task board tells the whole team and anyone else what
work they have planned or the sprint and their current status.

49
Sprint Backlog

50
Burndown chart (graphe de combustion)

51
Burndown chart (graphe de combustion)

 Il est courant qu’à la suite une personne additionne les efforts

restants pour l’ensemble de l’Equipe, et le trace sur le Sprint
Burndown Chart.
 Ce graphique montre, chaque jour, une nouvelle estimation du reste
à faire estimé pour terminer les tâches de l’Equipe. Ce graphique se
présente idéalement sous la forme d’une courbe inclinée vers le bas,
suivant une trajectoire visant à atteindre «zéro effort restant » le
dernier jour du Sprint.

52
Product or Release Burndown chart

53
Release Burndown chart

 It measures the rate of delivery of a stream of running, tested, features over

time.
 This rate is know as the team’s velocity.
 Because features vary in complexity, and therefore effort and time, we use a
scale to compare their size. The most common scale is known as story points.
Once a team has worked together for a few sprints, it generally establishes its
velocity within a definable range. Product Owners then use this velocity to
predict the rate at which the team will deliver features in the future, leading
to credible release plans.
 Using this chart Product Owners are able to report progress, determine
release dates and predict release scope.

54
Les systèmes intégrés de gestion de projet
 De nombreuses équipes travaillent avec Jira (le produit phare d’Atlassian) ou
avec VSTS selon qu’elles évoluent dans l’écosystème open source ou
Microsoft. Ces deux systèmes intégrés de gestion de projet ont de nombreux
points communs. Une fois le backlog créé, ils présentent des tableaux de bord
pour chaque projet à dérouler selon un processus personnalisable de type
Scrum ou Kanban. Outre d’innombrables états du projet, ces systèmes sont
aussi intégrés à la production de code.