© Logica 2008. All rights reserved Formation au management de projets Charles ZAOUI Formateur et...

© Logica 2008. All rights reserved

Formation au management de projets

Charles ZAOUIFormateur et méthodologue (méthodes agiles & GO-ON)

Tél : +33.608 [email protected]

Charles ZAOUIFormateur et méthodologue (méthodes agiles & GO-ON)

Tél : +33.608 [email protected]

Sommaire

• INTRODUCTION

• UP/PHARE : phases & disciplines

• PROCESSUS PROJET SELON L’AXE TEMPOREL

• PREPARER, ORCHESTRER ET TIRER LES LECONS

– Préparer d’une itération

– Piloter une itération

– Bilan d’une itération

INTRODUCTION - Sommaire

• Les méthodes de gestion de projet

• Chiffres significatifs et constats

• L’avènement de UP et des méthodes agiles

• La méthode PHARE

Définition :

La gestion de projet est l'application de la

connaissance, des qualifications, des outils, et

des techniques aux activités de projet dans le

but de satisfaire les besoins des parties

prenantes et les attentes d’un projet

(Project Management Institute)

Définition de la gestion de projet

Piloter un projet SI, c’est :

- définir une destination

- garder le cap

=> Nécessité d’une méthode


Au milieu de la mer, tous les vents sont mauvais si on ne connaît ni sa destination, ni la route pour y parvenirMontaigne

Remarque : étymologie du mot « méthode »« meta hodos » : recherche du bon chemin

Définition d’une méthode :

Guide plus ou moins formalisé, démarche reproductible permettant d’obtenir des solutions fiables à un problème. La méthode capitalise l’expérience de projets antérieurs et les règles dans le domaine du problème !

Une méthode définit– des concepts de modélisation– une chronologie des activités– un ensemble de règles et de conseils pour les participants

Description d’une méthode– des gens, des activités, des résultats


Introduction à la notion de processus

Définition d’un processus de développement :Ensemble des activités à mener par la MOE pour transformer

les besoins de la MOA en un système logiciel.

Souvent utilisé dans la préhistoire : le cycle en cascade (waterfall).

Définition de CMM :Un ensemble d'activités, de méthodes, de pratiques et de

transformations permettant le développement et la

maintenance de logiciels et des produits associés.

Sommaire

• Les méthodes de gestion de projet




Chiffres significatifs et constats

D’après le Rapport Standish, 1995

• 53% des projets coûtent au moins 200% des estimations initiales

• En 1995, la somme dépensée aux USA à cause des projets arrêtés avant la fin est estimée à 81 milliards de dollars.

• Ce genre de projet représenterait environ 30% (USA)

Quelques statistiques


Selon le Standish group (1998)25% des projets respectent les délais et les budgets

45% dépassent le budget ou sont en retard

28% sont abandonnés ou voient leur périmètre largement restreint

Quelques statistiques


0

10

20

30

40

50

60

10 100 1000 10000 100000

Taille des projets en points de fonction

Hau

sse

des

exi

gen

ces

en %

p

ar r

app

ort

au

x es

tim

atio

ns

d'o

rig

ine

Source : Applied Software Measurement, Capers Jones, 1997. Fondé sur 6 700 systèmes.

Evolution des exigences selon la taille des projets :

Introduction : Chiffres significatifs et constats

Les exigences qui ne servent à rien, ou très peu

Avis d’expert : Statistiques pas vraiment surprenantes lorsqu’on pense que les spécifications sont issues des besoins définis en début du projet.

D’après une étude du Standish group (2002)


Non productive Productive

Réutiliser mauvais livrables (-300%) Réutiliser livrables de qualité (+350%)

Management de peu d’expérience (-90%) Management expérimenté (+65%)

Développeurs de peu d’expérience (-87%) Développeurs expérimentés (+55%)

Exigences trop changeantes et manque de gestion de ces dernières (-77%)

Outils de développement mal adaptés au projet (-75%)

Outils de développement adaptés et efficaces (+27%)

Pratiques influant sur la productivité(*)

(*) D'après « Software Assessments, Benchmarks and Best practices » de Capers Jones. Livre de référence

des bonnes et mauvaises pratiques dans le monde du logiciel


(*) D'après Mc Connel (prix Software Development en 1996), recueil de conclusions de la recherche en

matière de logiciel. Reconnu meilleur livre d’ingénierie logicielle.

Bonnes pratiques reconnues (*)

• Développement itératif & incrémental basé sur feedback

• Réutiliser des composants de qualité

• Développer en « timeboxing »

• Contrôler en permanence la qualité non seulement au niveau du code mais aussi au niveau des exigences et de la conception

• Revoir et simplifier les exigences de façon régulière

• Communiquer régulièrement l’avancement au client


Cycle itératif et incrémental :

• On identifie et traite en priorité les exigences les plus prioritaires

• Mise au point au plus tôt dans la compréhension mutuelle

• Réalisation de petites itérations (2 à 6 semaines) qu’on affinera à l’aide de « Feedback & Adaptation ».

• On s’impose le « timeboxing » : Une fois la date de fin fixée, elle ne change pas, quitte à réviser les objectifs pour l’itération.

• Le progrès est mesurable par des programmes démontrables.


Cycle itératif et incrémental :

Ce cycle est aussi appelé « évolutif, en spirale ». On réalise une mini-cascade pour chaque itération.

Idées fausses sur le cycle itératif :

• Encourage la bidouille

• Engendre des problèmes

• Eternel recommencement

• Absence de planification

• Ne concerne que les développeurs

• Génère de nouveaux besoins

Exercice : Trouver le contre-argument aux idées fausses suivantes


Conclusion :

• Le cycle de vie itératif

– est en phase avec la réalité

– permet la prise en compte de l’évolution

– repose sur l’évaluation objective de prototypes

– demande un pilotage continu

– demande un environnement de soutien

– bien adapté à l’approche objet (et inversement)


• Introduction à la notion de processus




Le développement itératif nécessite d'avoir le courage de dire ‘nous ne savons pas’ et la conviction que la réponse proviendra rapidement d'un ‘sondage exploratoire’.”Craig Larman

Le concept de méthode agile

Méthodes agiles :

Le développement agile (aussi appelé "développement adaptatif") : peut être considéré comme "un style de développement logiciel itératif centré sur les personnes mettant l'accent sur la satisfaction client à travers l'intégration continue d'un logiciel vraiment fonctionnel".

• Exemples :

◦ Extreme Programming (XP)

◦ Rational Unified Process (RUP)

◦ Scrum

◦ Feature-Driven Development (FDD)


Méthodes agiles :

Autre définition :

« Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu'il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l'évolution des besoins des clients »

Véronique Messager Rota

Auteur de l’ouvrage : Gestion de projet vers les méthodes agiles.


Pratiques communes des méthodes Agiles


Méthodes agiles v.s. Méthodes classiques


XP : Extreme programming

• Proposée par Kent Beck. Il s'agit plus d'un ensemble de pratiques à dimension humaine que d'une véritable méthode.

• Facile à mettre en œuvre, au prix d'un changement de mentalité et d'une acceptation par l'ensemble des équipes impliquées.

• Il s'agit d'appliquer "à l'extrême" les principes du développement agile, en se focalisant sur les quatre points suivants :

besoins du client, individualités, développement itératif intégration continue.


XP : les 13 principes fondamentauxEnoncé But

Le planning est fait avec le client

Se focaliser sur les buts principaux et différer les autres. Gérer les priorités, fonctionnelles comme techniques.

Développement itératif, logiciel livré souvent

Le fonctionnel de l'application est décrit en brefs scenariis qu'on peut implémenter tout de suite et que le client peut juger très tôt. Réduire les mésententes de compréhension

Mettre tôt en production un système simple

Disposer rapidement d'un pilote opérationnel et réduire les risques dès le début du projet.

Métaphores Clarifier les fonctionnalités à atteindre

Design simple Se focaliser sur les besoins actuels du client, ni + ni -

Produit testé et validé à tout moment

Les développeurs écrivent les tests d'abord et codent ensuite (Test-Driven Development) . Conseil : utiliser les scénarios des cas d’utilisation

Programmer à 2 Code robuste et de qualité. Montée en compétence


XP : les 13 principes fondamentauxEnoncé But

Système remanié progressivement, par morceaux

Le logiciel est propre : pas de duplication, une grande communication, simple, mais complet. Le nettoyage doit se faire régulièrement (prévoir des séances pour toute l'équipe).

Le code est à tous les programmeurs

Responsabilité collective. Quand il faut changer quelque chose, on peut le faire tout de suite => travail à plein régime

Intégration continue Système plus stable et opérationnel rapidement.

Les semaines n'ont que 40 heures

Diminution du nombre d’erreurs, donc augmentation de la qualité. Les programmeurs fatigués font plus d'erreurs

Client représenté sur place

Assister les développeurs par une personne dédiée, chargée de déterminer les besoins, fixer les priorités, rédiger les cahiers de recette et répondre aux questions

Standards codage Code de style unifié, avec des règles pour communiquer clairement (les "design patterns" sont vite indispensables)

SCRUM

SCRUM (Jeff Sutherland & Ken Schwaber) :

• "Scrum se rapproche plus d'une gestion de ressources humaines que d'une méthode de développement. Il s'agit de ne pas oublier le côté humain du développement.

• Théoriquement, Scrum peut se marier avec XP, en fournissant aux développeurs "agiles" un cadre de prise en compte du facteur humain. On peut envisager des projets + importants qu'avec XP.

• Scrum est incrémental, mais moins formalisé que UP : Ne propose aucune pratique de développement, juste de management. Il s'agit d'un cadre de gestion de projets adapté aux méthodes agiles, comme XP.

SCRUM

SCRUM :

• Les principales caractéristiques de Scrum sont :

– Identifier les changements très tôt

– Donner toute confiance aux développeurs et les laisser faire leur travail.

– Itérations de 30 jours ("sprints") pour laisser le temps de coder. Une itération a un objectif précis ("backlog") et fournit une nouvelle fonctionnalité testée.

– Faire des réunions tous les jours pour encadrer les équipes et recaler les objectifs.

SCRUM

SCRUM (Ken Schwaber) : Les rôles

Les rôles : Intéractions

Scrum Master

FacilitationFonctionnalités

Définition des objectifs

Experts métier

L’équipe

Product owner

No .4511/04/23

SCRUM

SCRUM (Ken Schwaber) : Les rôlesRôle Responsabilité

Scrum Master

Rôle capital : protéger l'équipe des éléments perturbateurs extérieurs et résoudre ses problèmes non techniques (ex : administratifs). Il doit aussi veiller à ce que les valeurs de Scrum soient appliquées.

Product Owner

Représente les clients et utilisateurs. Définit l'ordre dans lequel seront développées les fonctionnalités et prend les décisions importantes concernant l'orientation du projet. Le terme directeur n'est pas à prendre au sens hiérarchique, mais dans le sens de l'orientation. Son objectif majeur est de maximiser le ROI (retour sur investissement).

Scrum Team

Livrer des executables à la fin du sprint. L'équipe ne comporte pas de rôles prédéfinis pu de hiérarchie interne, elle est autogérée : toutes les décisions sont prises ensemble et personne ne donne d'ordre à l'équipe sur sa façon de procéder. S'adresse directement au directeur de produit.

Stakeholders

Personnes souhaitant avoir une vue sur le projet sans vraiment s‘y investir. Ex : experts techniques ou d'agents de direction qui souhaitent avoir une vue très éloignée de l'avancement du projet

SCRUM

SCRUM : Le processus

SCRUM

SCRUM : La mêlée quotidienneBut• Évaluer l'avancement du travail

• Identifier les obstacles (problèmes) nuisant à la progression

• Garder l'équipe concentréesur l'objectif de l’itération

• Améliorer l'esprit d'équipe

• Permettre une communication objective sur l'avancement

Input• Backlog de l’itération

• Backlog des problèmes

No .4911/04/23

SCRUM

SCRUM : Les autres conceptsRôle Définition et But

Daily Scrum ou mêlée quotidienne

La journée de travail commence par une réunion d’au plus 15mn : la mêlée quotidienne. Seuls l'équipe, le Product Owner et le ScrumMaster peuvent parler (les autres peuvent juste écouter, leur présence étant non obligatoire). Chaque membre répond à 3 questions : Qu‘ai-je fait hier ? Que vais-je faire aujourd'hui ? Quelles difficultés je rencontre ? But : synchronisation et transparence. C'est le niveau quotidien du principe inspect and adapt de Scrum.

Sprint Itération. En théorie 30 j. En fait, de 2 à 4 semaines. Possède un but et on lui associe une liste d'items de « Product backlog », décomposés en tâches élémentaires de quelques heures par l'équipe, les items de «sprint backlog». Pendant un sprint, les items de sprint backlog ne peuvent être changés. Si changements => pris en compte dans le Product backlog et pourront être réalisés dans les sprints suivants. Exception : l'équipe se rend compte lors du sprint qu'elle n‘a pas le temps de terminer un item du sprint backlog ou qu'elle aura fini en avance. Dans ce cas, d'un commun accord entre l'équipe et le Product Owner, on peut enlever ou ajouter un item.

No .5011/04/23

Si besoin : Rappel de SCRUM

SCRUM : Les autres conceptsRôle Définition

Sprint backlog

Liste des tâches à réaliser par l'équipe pendant un sprint. A chaque nouveau sprint, il y a un nouveau sprint backlog, élaboré lors de la réunion de planification en début de sprint et destiné à l'équipe. Pour un sprint on sélectionne les éléments du Product backlog. Le travail nécessité par la réalisation d'un élément du backlog est décomposé en tâches qui sont les éléments du backlog de sprint.

Sprint PlanningMeeting

Réunion d’au plus 4h, où tout le monde est présent, qui consiste à définir un but pour le sprint, puis à choisir les items de « product backlog » à réaliser dans ce sprint. Cette 1ère partie du sprint planning représente l'engagement de l'équipe. Puis l'équipe décompose chaque item du backlog de produit en tâches, puis estime chaque tâche en heures.

Product Backlog

Essentiellement bâti par le Product Owner. Un par produit, on y trouve ses fonctionnalités. À chaque item , 2 attributs : estimation en points arbitraires et valeur client, définie par le Product Owner. La somme des points des items du Product backlog est le RAF total du projet.

No .5111/04/23


SCRUM : Les autres concepts

Rôle Définition

Revue de sprint En fin de sprint, tout le monde se réunit pour effectuer cette revue, qui dure au plus 4 heures. Objectif : valider le logiciel produit pendant le sprint. L'équipe énonce les items réalisés du Product backlog, effectue une démonstration du logiciel produit, sur la base de laquelle le Product owner valide chaque fonctionnalité planifiée pour ce sprint. Une fois le bilan du sprint réalisé, l'équipe et le Product Owner proposent des aménagements sur le backlog et la planification provisoire de la release.

Evaluation Chaque sprint finit par une demonstration du travail réalisé.

Rétrospective du sprint

Interne à l'équipe (incluant ScrumMaster). Objectif : comprendre ce qui n'a pas bien marché dans le sprint, les erreurs commises et de prendre des décisions pour s'améliorer. On peut apporter des aménagements à Scrum dans le but de s'améliorer.

Burndown chart de release

Graphe, mis à jour en fin de chaque sprint, montrant la tendance de l'avancement dans la réalisation des éléments du backlog.

No .5211/04/23


SCRUM : Le burn-down chart

No .5311/04/23

Unified Process

Unified Process :Devenu un standard mondial

des processus de développement.

Regroupe les meilleures pratiques et les met en œuvre de façon souple et optionnelle, tout en permettant un enrichissement ponctuel.

Basé sur 3 principes fondamentaux : - Itératif et incrémental,

- Centré sur l ’architecture,

- Piloté par les cas d ’utilisation.

Permet de facilement atteindre le niveaux 3 de CMMI

No .5511/04/23

Unified Process

Unified Process : use case driven

Les UC représentent d’abord les exigences fonctionnelles, mais un UC induit

aussi des exigences non fonctionnelles (disponibilité, volume, temps de

réponse, confidentialité, concurrence…)

=> Phase d’Élaboration : on est capable d’identifier les UC qui auront une

Incidence sur l’architecture. On les détaillera et on construira sur cette base.

On est capable d’identifier les UC à risque et ceux mettant en évidence la

viabilité et la raison d’être même du système. C’est par ceux-ci qu’il faudra

commencer par le biais d’incréments les réalisant d’abord en version simple.

No .5611/04/23

Unified Process

Unified Process : use case driven

Use-case A

Version Complète

-----

-----

-----

-----

Use-case B

Version Complète

-----

-----

-----

-----

Use-case C

-----

-----

-----

-----

Use-case A

Version Simplifiée

-----

-----

-----

-----

Itération 3Itération 2Itération 1 …

Use-case B

Version Simplifiée

-----

-----

-----

-----

No .5811/04/23

Unified Process

No .5911/04/23

Unified Process

Unified Process : La qualitéD’après le UP, on ne se contentera pas de réaliser les tests et l’AQ

(assurance qualité) en fin de projet, mais on traitera au plus tôt les

anomalies (pendant que l’élément est créé). Un Workflow est

explicitement prévu à cet effet.

D’après les experts, corriger les anomalies tard coûte 10 à 100 fois plus

cher que de la corriger au plus tôt. On considère qu’en général, 60%

des anomalies existent déjà au moment de la conception.

Il est utile à ce sujet d’utiliser la notion de « programmation à 2 » de XP

(une 2° personne inspecte en temps réel le code et la conception).

No .6011/04/23

Unified Process

Unified Process : S’accommode d’UML

Parce que la modélisation visuelle est considérée comme le meilleur

moyen d’impliquer le cerveau et d’assurer la mémorisation.

Intervient dans les éléments fondamentaux du UP :

- « Diagrammes UC » : vecteur du processus d’un projet.

- « Modèle de conception » : (dans UP, s’ identifie à celui d’analyse d’après I.Jacobson) « Diagrammes de Classes »,

« Diagramme des packages », « Diagrammes de collaboration ».

- « Modèle de déploiement »

No .6111/04/23

Unified Process


• Introduction à la notion de processus




Un bon scientifique doit avoir des idées originales. Un bon ingénieur doit créer des conceptions qui marchent en utilisant le moins possible d’idées originales. Il n’y a pas de star dans l’ingénierie. Freeman Dyson (physicien) dans Disturbing the Universe

No .6311/04/23

Qu’est-ce que PHARE ?

PHARE : La nouvelle méthode PHARE de l'armée de terre a été

réalisée par LOGICA dans le cadre du marché UCRM.

Cette méthode est basée sur UP, intègre l'approche SOA et respecte

le standard SPEM. Un outil définit l’ensemble de la méthodologie,

montrant phase, activités, rôles, artefacts et donne les lignes

directrices et les recommandations.

Avantages sur UP :

Continue d’évoluer

Intègre des éléments supplémentaires d’autres méthodologies ou standards à l’état de l’art (SCRUM, PMBOK, CMMI, LEAN)

Adaptée à SOA (disciplines différentes)

PHARE

No .6411/04/23

La méthode PHARE

De UP à PHAREPHARE est la nouvelle méthode de Gestion des Projet SI de l'Armée de Terre. PHARE a plusieurs avantages par rapport au standard UP.

Moins complexe et plus opérationnelle que UP, PHARE permet un passage à l'action plus rapide

Simplification de certaines parties selon les souhaits de l'Armée de Terre

Adaptation au contexte de l'Armée de Terre : types de projets et d'architectures traités, rôles, types de livrables...

La nouvelle méthode PHARE de l'armée de terre a été réalisée par LOGICA dans le cadre du marché UCRM.

Commanditée par le CPSIAT, elle a été réalisée à partir du référentiel GO-ON des pratiques EA/SOA de Logica.

No .6511/04/23

La méthode PHARE

De UP à PHAREPHARE hérite donc des avantages de GO-ON.

GO-ON est basée sur la capitalisation du savoir-faire des consultants de LMC sur plusieurs centaines de projet et sur les meilleures pratiques du marché : LEAN pour la gestion de la performance et PMBOK pour les activités de Gestion de Projet ;

SCRUM pour la gestion des itérations et UP pour les Phases ;

XP pour les recommandations sur le développement ;

DSDM pour son approche des groupes de travail ;

CMMI pour la définition des Processus et ses recommandations par niveau de maturité ;

ISO9001 pour la discipline d'assurance qualité ;

TOGAF9 pour la discipline d'Architecture ;

UML 2.0 pour les notations de Modélisation ;

OBJECT Primer pour son approche agile de la modélisation.

No .6611/04/23

Unified Process

Scope général des pratiques Agiles SCRUM XP PHARERecueil élémentaire des besoins

Simple liste ou fiches de récits utilisateurs

OUI OUI OUI

Gestion systémique des exigences

Formalisation Agile d’un document structuré mais élémentaire

NON NON OUI

Gestion formelle des communications complexes

Organisation, charte projet, plan de communication, techniques de maîtrise de réunions en contexte difficiles.

NON NON OUI

Estimation de charges Agiles niveau « équipe » Axée sur la vision des intervenants, (ex : planning poker)

OUI OUI OUI

Techniques et outillage d’estimation de charges Agiles

Basées « métriques » standardisées (points de Cas d’utilisation, de scénarios, d’objets WEB, Evaluateur, etc.)

NON NON OUI

Pilotage des niveaux d’itérations d’un projet OUI MINIMA OUI

Gestion des réunions « équipe » OUI OUI OUI

Techniques extrêmes de qualité du code NON OUI OUI

Justification financières agiles et formelles NON NON OUI

Techniques Agiles de suivi des risques externes NON NON OUI

Techniques simples d’amélioration du processus Agile (lean management) OUI OUI OUI

Rapprochement avec des bases normées (CMM) NON PARTIEL OUI

Sommaire

• INTRODUCTION







Sommaire de « UP/PHARE : phases & disciplines »

• Les Phases dans UP

• Les phases dans PHARE

• Les disciplines

• Exercice pratique : QCM sur les concepts vus

• Zoom sur les livrables de management

Unified Process

Plusieurs ItérationsPlusieurs Itérations

Inception~5-10%

Élaboration~10-30%

Construction~40-70%

Transition~10-20%

#1 #2 #3 #1 #2 #3 #4 #5 #6 #n #1 #2

Analyse & Conception

Gestion des Exigences

Implémentation

Test

Déploiement

Gestion de Configuration

& Gestion du Changement

Gestion de Projet

Gestion de l’Environnement

Modélisation Métier

9 Disciplines :9 Disciplines :

4 Phases4 Phases

No .7411/04/23

Unified Process

UP : Artefacts principaux (1/3)

Unified Process

UP : Artefacts principaux (2/3)

Vision

Objectif : faciliter la communication sur les objectifs du projet tout en résumant comme son nom l’indique la vision du projet.

- Pourquoi le projet a été lancé.- Problèmes posés.- Qui sont les parties-prenantes ? De quoi ont-elles besoin ?- Quelles sont les fonctionnalités principales de la solution ?

Peut aussi contenir l’étude de rentabilité du projet (business case)

Spécificationsupplémentaire

Objectif : rassembler les attributs de qualité, évolutivité, fiabilité… et toutes les autres exigences non spécifiées dans les UC.

• Evolutivité, fiabilité, performance, maintenabilité, …ité, rapports• Contraintes logicielles et matérielles (systèmes d'exploitation, …) • Contraintes de développement (par ex. outils de développement et processus) • Autres contraintes de conception et d'implémentation liées à

l'internationalisation• Documentation• …

Unified Process

UP : Artefacts principaux (3/3)Le couple valeur-attribut attaché à chaque exigence, tel que :

Un cas d'utilisation.Une étape dans un cas d'utilisation.Une exigence non-fonctionnelle.Une fonctionnalité.

Attributs courants :

priorité,

statut (demandé, approuvé, en-cours, …),

risque, …

Glossaire

Termes importants utilisés dans le projet.

C'est le dictionnaire de données (validation, plage, formats,…)

No .7711/04/23

Unified Process

UP : Artefacts de l’inception

Modèle du domaine Vision Modèles des UC Glossaire Plan d’itération Liste des risques

No .7811/04/23

Unified Process

UP : Artefacts de l’élaboration

Artefacts de l’inception raffinés Modèle d’implémentation Modèle de conception SAD (Software Architecture Document) Plan de tests Plan de gestion du changement SDP (software development plan)




• Les disciplines



PHARE : les phases

PHARE : cadrage

PHARE : élaboration

PHARE : construction

PHARE : transition




• Les disciplines



Les disciplines dans UP

On peut classifier les neuf disciplines du UP en quatre groupes (découpage conforme à celui proposé par CMMI) :

Celles inhérentes à la gestion de projet Project management (PP + PMC + RSKM)

Celles inhérentes à la gestion de processus Business Modeling

Celles inhérentes à l’ingénierie Gestion des exigences (REQM) Analyse et conception (RD + TS) Implémentation (RD) Test (VER + VAL) Déploiement (PI)

Celles de Support Configuration & Change management (CM) Gestion de l’environnement (PPQA)

Les principales disciplines dans UP & PHARE

Disciplines inhérentes à la gestion de projet (1/5)

UP : Project managementObjectifs :• Fournir un cadre de travail pour la gestion de projets

informatiques intensifs;• Fournir les directives pratiques pour la planification, le

recrutement de personnel, la réalisation et le contrôle de projets• Fournir un cadre de travail permettant de gérer les risques

PHARE : Gestion de projetObjectifs :• Assurer la planification, le choix du personnel, l'exécution et le suivi

des projets informatiques;• Organiser le projet d'une manière à diminuer les risques.


Disciplines inhérentes à la gestion de projet (4/5)Gestion de Projet : livrables


Disciplines inhérentes à la gestion de processusBusiness Modeling

Décrire les objectifs métier à accomplir par le projet et

envisager le fonctionnement du métier après la fin du projet

Les processus métier actuels sont modélisés (en s'appuyant

éventuellement sur des modèles existants), principalement pour

étudier l'impact du projet.

Les processus métier cible (tels qu'ils seront à la fin du projet) sont modélisés.

Les informations manipulées par l'entreprise sont modélisées sur le

périmètre du projet, en rajoutant du détail éventuellement aux modèles existants avant le début du projet.

En préparation de la gestion des exigences du projet, les tâches candidates à automatisation ou qui sont déjà

automatisées sont mises en évidence.


Disciplines inhérentes à l’ingénierie

Analyse des exigences

Établir et maintenir un consensus entre tous les acteurs sur les exigences attendues du système ;

Fournir une description cohérente et assez détaillée des exigences à l’équipe en charge de leur conception ;

Fournir les éléments nécessaires à la planification des itérations avec leur contenu ;

Fournir les éléments nécessaires à l’estimation des charges, des délais et des coûts.

Vision stratégique : processus d’analyse des exigences dans PHARE

En élaboration, on découvre, clarifie, raffine et stabilise la plupart des exigences (70-80 %) en même temps qu’on construit et qu’on stabilise l'architecture.Cadrage : 20%

des exigences seront connues et détaillées et une revue des UC permettra d’attester de la compréhension des exigences.

Construction : phase stable de fabrication avec des exigences claires et stables (environ 20% de modifications).

Vision stratégique : processus d’analyse des exigences dans PHARE

Attention : dans le développement itératif avec UP et PHARE, on n'essaye pas d'écrire toutes les exigences au début !

On ne pense pas qu'elles seront parfaites au premier jet.

On écrit "quelques" exigences (20% environ), puis on démarre rapidement l'implémentation. Puis, le feedback et l'adaptation permettent de clarifier et de raffiner les exigences à travers les itérations d'élaboration.

Attention : dans le développement itératif les exigences ne sont pas constamment instables !

Elles le sont pendant la phase d'Elaboration, mais la plupart des exigences sont stabilisées à la fin de l'Elaboration.

Les fluctuations des exigences ne s'arrêtent jamais complètement, mais elles se calment grandement en phase de construction.


Disciplines inhérentes à l’ingénierie (3/6)

Architecture et conception

Concevoir de manière détaillée les composants en vue de leur développement

Créer une architecture technique répondant aux besoins fonctionnels et non fonctionnels du projet



Implémentation

Définir et configurer l'environnement de développement ; Définir l’organisation du code en termes de projets d’implémentation ; Implémenter les composants définis en conception ; Tester unitairement les composants développés ; Assembler successivement les composants produits par l'équipe ;



Recette

Fournir indicateurs permettant d'évaluer la couverture des exigences par le code qui a été implémenté

Documenter les anomalies d'implémentation et fournir des pistes pour leur résolution


Disciplines de support : Conduite du changement

Objectifs• Préparer la mise en production • Réduire la résistance au changement

Activités• Définir stratégie de changement en identifiant les populations cibles et les impacts

• Définir un plan d’accompagnement et produire tous les livrables (manuels utilisateur, dossier d'exploitation, scripts d'installation, supports de formation) définis dedans

• Accompagner les managers et les opérationnels (support pour aider les managers et les opérationnels à réaliser leurs objectifs et surmonter les réticences et deuils, coaching, analyse des risques, gestion des crises, mobilité/recrutement)

• Mener les actions de communication, de formation, de relations sociales (envers le personnel, les instances, les partenaires)

• Évaluer réussite de l’accompagnement et sa contribution à la réussite du changement


Disciplines de support

Gestion de configuration

Contrôler les demandes de changement faites par rapport à tous les artefacts du projet

Maintenir la cohérence entre les versions des artefacts du projet Assurer de la stabilité du produit généré par le projet Donner des pistes d’audit sur le processus projet Obtenir et configurer les outils (logiciels, matériel) nécessaires au projet


Disciplines PHARE – Résumé




• Les disciplines




Exercice : cochez les affirmations vous semblant vraies

Les exigences d’un projet sont généralement stables

La gestion des exigences est une discipline à part entière d’UP

Il est toujours bon de réutiliser des composants

Le choix des outils est plus important que celui des personnes

Le développement itératif ne concerne que les développeurs

Il encourage la bidouille

Il est adapté à la démarche orientée objet

Les méthodes agiles peuvent s’accommoder de CMMI

L’intégration continue est recommandée par XP

Il est recommandé de développer en timeboxing



UP est proche du cycle en cascade

Il y a 5 disciplines dans UP

Il y a 4 phases dans UP

Scrum annule et remplace UP

UP prévoit des activités pour la gestion humaine

Il y a trois grandes caractéristiques essentielles à UP

SCRUM est plutôt axé sur les développements

SCRUM prévoit au moins une réunion par jour

Dans SCRUM, la rétrospective est le moment de régler ses comptes



PHARE est cohérent avec UP et SCRUM

PHARE est adaptée à SOA

PHARE est une réalisation d’IBM

La phase d’inception peut durer jusqu’à 40% du projet

La phase de construction est généralement la plus longue

PHARE est peu adaptée à la démarche orientée objet

PHARE se soucie particulièrement de la qualité

Les disciplines de PHARE peuvent se partitionner selon des groupes conformes avec le découpage CMMI.




• Les disciplines



Zoom sur les livrables de management

• PMP (Plan management Project)

• CM Plan (Change Management Plan)

PMP (Plan management Project)

PMP (Plan de management de Projet)

Document définissant : le périmètre du projet, son cadre financier, ses activités et livrables, les phases, itérations et leurs objectifs, le plan de gestion des risques, le plan de suivi analytique, le plan de gestion de la configuration, le plan de conduite du changement, le plan de revues de qualité et de gestion documentaire.

Synonyme de Plan de Développement Logiciel ou de Plan Projet. Correspond dans UP au « SDP » (Software Developement Plan).

SDP : Software Development Plan

PMPSDP

Composé d'autres artefacts, mais contient aussi ses propres sections

SDP

ProductAcceptance Plan

RiskManagement Plan

RiskList

ProblemResolution Plan

MeasurementPlan

QualityAssurance Plan

Project Management

ConfigurationManagement Plan

Conf. Manag.

DevelopmentCase

Environment

RequirementsManagement Plan

Requirements

PMP

PMP : table des matières (extraction PHARE)

PMP

PMP : table des matières (suite)

Zoom sur les livrables de management

• PMP (Plan management Project)

• CM Plan (Change Management Plan)

CM : Change management Plan

CM Plan Plan de conduite du changement (PCC)

Définit la manière dont le système seramis en production et dont les ancienssystèmes seront arrêtés.

Identifie les acteurs métier impactés par le projet et définit un plan d’action pour assurer le changement :

- communication, - formation, - support opérationnel.

PCC

Sommaire

• INTRODUCTION







Processus projet selon l’axe temporel

• Accord entre les parties prenantes sur la définition du périmètre du projet : liste d'exigences identifiées et leur description.

• Accord sur les évaluations des coûts et sur le planning, les priorités et le processus de développement

• Les risques ont été identifiés et des stratégies visant à les réduire ont été définies

Le projet peut être abandonné ou repensé au cas où ce jalon n'est pas validé. Les livrables suivants doivent être produits et validés :

•Référentiel des exigences - Selon le contexte, il peut être nécessaire de décrire la Vision métier, un Modèle de processus métier et un Modèle de domaine métier avant d’identifier et évaluer la charge associée aux exigences

•Classeur des risques

•Plan de management de projet - Ce plan regroupe plusieurs sous-livrables, parmi lesquels notamment le Processus projet, le Classeur d'évaluation des charges et le Classeur financier

Phases et jalons de fin de phase : CadrageFin de cadrage : objectif de définir le périmètre du projet, la manière dont il sera couvert (coût et macro planning) et avec quels risques.


Phases et jalons de fin de phase : Elaboration

Dans PHARE : ce jalon marque la fin de la phase d'élaboration qui vise à décrire de manière précise les exigences du projet et à concevoir une architecture qui permet d'y répondre.

Critères d'évaluation permettant de valider ce jalon :

•Liste d'exigences du projet : stable et décrite de manière précise

•L'architecture est stable

•La démarche de recette est définie

•La recette d'un périmètre pilote a démontré que les risques majeurs ont été traités et résolus

•Les plans des premières itérations de la phase de construction sont assez bien définis pour lancer cette phase

•Toutes les parties prenantes sont d'accord pour dire que les exigences définies peuvent être couvertes en appliquant la plan actuel de management et en utilisant l'architecture définie

•Les estimations de coûts mises à jour sont acceptables par rapport aux gains attendus du projet


Phases et jalons de fin de phase : Elaboration

• Les livrables suivants doivent être produits (ou mis à jour) et validés pour répondre aux critères définis plus haut :

Le Document de spécification des exigences - Selon le contexte du projet, une Maquette de l'IHM peut être suffisante

Dossier d'architecture technique (s'il ne s'agit pas d'un petit projet de maintenance) et le Document de conception couvrant le périmètre pilote qui valide l'architecture

L'Environnement de développement et le Système exécutable implémenté en utilisant cet environnement sur le périmètre pilote

La Stratégie de recette (s'il ne s'agit pas d'un petit projet de maintenance) et le Rapport de recette concernant le périmètre pilote

Plan management de projet mis à jour en utilisant le feedback des 1ères itérations

Planning d'itération : préparé pour la première itération de la phase de construction


Phases et jalons de fin de phase : Construction

Les livrables suivants doivent être produits et validés pour répondre aux critères définis plus haut :

Le(s) Document de conception couvrant le périmètre complet du projet

Le Système exécutable sur le périmètre complet du projet

Le(s) Rapport de recette sur le périmètre complet du projet

Selon le contexte du projet, le Plan de conduite du changement a été validé et déroulé (au moins en partie). Si planifiés, les Support de communication et Supports de formation utilisateur ont été développés et utilisés avec une efficacité suffisante.

Selon le contexte du projet, le Dossier d'exploitation et le Dossier d'installation

Sommaire

• INTRODUCTION







LES TEMPS FORTS D’UN PROJET

• Préparer une itération◦ Estimation de charges

◦ Risques (PRISM / Référentiel de risques)

◦ Planification

◦ Rôles / compétence

• Piloter une itération◦ Préparer un comité de pilotage (orienté décision, finir CQFD)

◦ Suivi projet (Livrable / RAF, courbe Effort en j.h en fonction du délai)

◦ Le suivi de l’équipe (Lean)

• Bilan d’une itérationoBilan : Réel Vs Planifié

oFeedback / Démonstration

oRétrospective (partie publique et partie privée)

Préparer une itération

Programme global d’une itération


Programme global d’une itération

Analyse et modélisation UML(binôme)

2j

DéveloppementOn teste beaucoup

Arrêt Dev

Mardi

Atelier expressionBesoin et demo

Mercredimatin

Demo/Feedback(recette éventuelle)puis rétrospective

Réunion planifItération n+1

Jeudi/Vendredi

Dernière semaine

Revue quotidienne

Point sur avancementRévision du périmètre

4 semaines

Exécution (n) Bilan (n)

Étapes

Cadrage (n+1)

3 semaines

Cadrage itérationsuivante


L’atelier d’expression des besoinsDécrire et prioriser les besoins

Participants

•Les CP MOA et MOE

•l’équipe MOA et MOE

•le groupe utilisateurs

Produits en entrée

•La liste des cas d’utilisation

Produits en sortie

•Le backlog : liste des cas d’utilisation priorisés

•Les cas d’utilisation décrits dans un outil

•Quelques éléments UML

1. Now is the time for men in the ranks to stay in the ranks.












Estimation de charges

Techniques possibles d’estimation

• Méthode d’estimation par points de fonction, statistiques & analogie (planning Poker)

•COCOMO II Modèle Post-Architecture plus micro-estimation avec WBS (*)

•PHARE : Méthode basée sur les cas d’utilisation ou feuille Excel pour valoriser les charges

•Autres…

En entrée de l’estimation

• La liste des cas d’utilisation à réaliser pendant l’itération

En sortie de l’estimation

• Le reste à faire prévisionnel

Remarque préliminaire

Il existe deux niveaux de planification que sont : le Plan de phase (haut-niveau), et les plans d'itérations (fin, mais ne décrit que l'itération suivante). Dans le cadre de ce chapitre, on ne s’intéresse pour les estimations qu’au niveau « itération ».

(*) WBS : La notion de décomposition arborescente des tâches du projet


Estimation de charges (focalisation)

Le planning Poker (*)

(*) James Grenning (2002) et popularisée par Mike Cohn dans « Agile Estimating and Planning »

Estimation basée sur un consensus entre les membres de l’équipe de développement et le responsable produit.

Généralement utilisée pour estimer l’effort ou la taille des tâches à réaliser dans une itération.

Peut-être vue comme une Variante de la méthode Wideband Delphi



Le planning Poker

Déroulement 1/ Les participants s'installent autour d'une table, placés de façon à ce que tout le monde puisse se voir. Chacun des participants reçoit un paquet de cartes.

2/ Le responsable de produit explique à l'équipe un scénario utilisateur (user story).

3/ Les participants posent des questions au responsable de produit, discutent du périmètre du scénario, évoquent les conditions de satisfaction qui permettront de la considérer comme "terminée".

4/ Chacun des participants évalue la complexité de ce scénario, choisit la carte qui correspond à son estimation et la dépose, face vers le bas, sur la table devant lui.

5/ Au signal du facilitateur, les cartes sont retournées en même temps. S'il n'y a pas unanimité, la discussion reprend.

6/ On répète le processus d'estimation jusqu'à l'obtention de l'unanimité


Estimation de charges (focalisation)Le planning Poker

L'essence de cet exercice est de permettre à toute l'équipe de s'exprimer sur l'effort requis, en minimisant l'influence des autres membres de l'équipe.

L'estimation se fait en points => mesure de complexité relative : les scénarios sont comparés entre eux.

L'équivalent en jours-hommes est propre à chacun, selon ses compétences, son expérience et sa connaissance du domaine.



Le planning Poker

Avantages : - Permettre à tous de s'exprimer librement. L'estimation sera meilleure parce que plusieurs personnes l'auront validée : des participants avec des niveaux d'expérience et d'expertise différents.

- Permet de favoriser les échanges entre le responsable de produits et l’équipe de développement.

-Avis d’un expert : le working poker marche bien car c’est fun !

Préparer une itération : gestion des risques

Risques Définition

Risque : événement qui peut faire que le projet n'atteigne pas ses objectifs.

Chaque risque a :

-une certaine probabilité (la probabilité que l'événement associé se produise)

-et un certain impact (dépassement de délais, de budget, diminution du périmètre couvert ou de la qualité...).

Les phases de PHARE (cf. les jalons de fin de phase) et le contenu des itérations sont définis pour prendre en compte les risques. Par exemple, en réalisant un prototype pour valider les choix d'architecture ou en réalisant en priorité un périmètre fonctionnel stratégique car indispensable et dont la faisabilité (avec les moyens prévus) nécessite une validation au plus tôt.

!


Analyse des risques

L’analyse des risques consiste à évaluer le projet, la technologie et les ressources, afin de déterminer et comprendre l’origine des risques.

L’évaluation des risques permet de déterminer dans quelle mesure les conséquences d’un risque sont acceptables. Les risques doivent être quantifiés, sinon, il ne sera pas possible de savoir s’ils ont été éliminés.

Toute l’équipe projet doivent prendre conscience des risques => doivent être répertoriés dans un référentiel, dans un formalisme compréhensible.

A la fin d’une chaque itération, une évaluation déterminera les risques éliminés ou réduits. Le plan des prototypes sera révisé en conséquence.


Risques Il existe 4 grandes catégories de risques :

-Commerciaux : La concurrence peut capturer le marché avant qu’il soit prêt ?

- financiers : A-t-on les capacités financières pour mener le projet à terme ?

- techniques : La base technologique, est-elle solide et éprouvée ?

- développement : Equipe expérimentée ? Maîtrise technologies mises en œuvre ?


Réduction des risques insignifiante jusqu’à ce que commence l’intégration.

Les plus grands risques techniques sont liés à l’architecture : performances, intégrité des interfaces du système, qualité du système (adaptabilité, portabilité).

=> Ne peut être évalué avant qu’une grande partie du code ait été développée et intégrée. Le risque est élevé durant la majeure partie du cycle de vie.

RisquesRisques et projets en cascade


RisquesRisques et projets agiles

Décroissance plus rapide du risque par une segmentation judicieuse de l’effort de développement. Il peut être réduit de façon significative dès l’élaboration.

D’itération en itération, les exécutables valident le choix du projet de manière concrète et mesurable, et le niveau de confiance en l’application augmente.

waterfall

itératif

Elaboration


RisquesRisques et projets agiles

Tau

x d’

expo

sitio

n au

ris

que

Cycle de vie projet

Cadrage Elaboration Construction TransitionElevé

Faible

Période d’exploration des risques

Période de résolution

des risques

Période de gestion des risques controllés

Projet

itératif

Projet conventionnel

(Waterfall)

Réduction du risque


Risques (PRISM / Référentiel de risques)Démarche proposée par PHARE

Identifier, analyser et hiérarchiser les risques du projet Déterminer des stratégies de gestion des risques appropriées Mettre à jour la liste des risques pour refléter le statut du projet actuel

Remarque : PHARE propose un outil sur la gestion des risques sous forme de feuille Excel : la fiche PRISM, qui comporte plusieurs onglets : Le 1er est l’onglet « PRISM » qui montre un graphique mettant en évidence les zones possibles de risques dans lesquelles le projet peut se trouver, et l’endroit où il se trouve à l’aide d’une formule dont les paramètres d’entrée sont des scores sur les critères suivants :

- Durée, - Intégrité, - Engagement, - Management, - Equipe, - Effort, - Autres


Risques (PRISM / Référentiel de risques)Onglet PRISM


Risques (PRISM / Référentiel de risques)Onglet “Effort”


Risques (PRISM / Référentiel de risques)Onglet “Autres”


Risques (PRISM / Référentiel de risques)Exemples et outils de Phare

Démonstration !


Planification

Il existe 2 niveaux de planification :• Plan de phase (haut-niveau)• Les plans d'itérations (fin, mais ne décrit que l'itération suivante).

Le plan de phase est démarré en phase de cadrage. • Il précise les dates de fin des phases ainsi que leurs objectifs.• Raffiné si nécessaire (glissement de phase).• Synthétique


Planification dans PHARE

Définir structure détaillée de la répartition du travail concernant tâches et responsabilités

Définir les jalons et les livrables pour chaque itération

Définir les critères d'évaluation pour l'itération

Déterminez le périmètre de l’itération

Définissez les critères d’évaluation de l’itération

Définissez les activités de l’itération

Attribuez les tâches aux personnes

Etapes

En sortie Planning d'itération : Détail des activités à réaliser pendant l'itération courante.


Rôles / compétences

Ressources

Temps

Construction TransitionElaborationCadrage

Avec UP ou PHARE constituer l’équipe est un processus dynamique qui s’adapte au fur et à mesure des phases, voire des itérations


Rôles / compétences

PHARE donne des recommandations pour le recrutement des personnes en fonction des compétences requises et de l’avancement du projet dans le temps.1/ Recrutement : Intégrez à l’équipe projet les ressources dont vous avez besoin pour l’itération et anticipez les besoins pour les itérations suivantes : certains profils étant rares, il vaut mieux anticiper le plus longtemps à l’avance.

2/ Matrice de correspondance entre les rôles du processus et les personnes : Vérifier que les compétences requises sont couvertes

3/ Définition de l’organisation hiérarchique de l’équipe : définir les responsables et les contributeurs aux tâches.

4/ Planifier les formations pour l’équipe projet : Si certaines compétences ne sont pas couvertes vous devez organiser des formations : attention, les cycles de formations sont à planifier longtemps à l’avance.




◦ Planification








Piloter une itération

Comité de pilotage

•Valide les objectifs opérationnels du projet et le plan de projet dans son ensemble

• Est tenu informé de l’avancement des activités clés

• Valide les choix du chef de projet

• Résout les questions ouvertes

• Réfère au comité de direction lorsque des décisions stratégiques doivent être prises


Préparer un comité de pilotage • Le chef de projet réfère au comité de pilotage des décisions prises ou à prendre

• Le chef de projet tient informé le comité de

pilotage de l’avancement des activités clés.

Remarque essentielle :

Un comité de pilotage réussi doit être orienté décision => préparer les arguments pour amener les participants (en ayant le pouvoir) à prendre la décision souhaitée.

L’argumentaire devrait idéalement se terminer par « CQFD »


Le suivi du projet

Le but est de suivre le déroulement de chaque itération.

A cet effet, le chef de projet consolide l'avancement des objectifs du projet en utilisant les informations remontées par les différents responsables en utilisant les outils de reporting.

Le CP effectue le recueil des données et consolide les indicateurs. Cela se fait en trois étapes :

•Recueillir données des indicateurs de base (consommé, reste à faire évalué...)

•calculer, vérifier et valider les indicateurs dérivés (budget prévisionnel...)

•inclure les métriques dans le rapport d'évaluation de l'état


backlog

Suivi du Reste à faire

Équipe de Dev Cas d’utilisation

ExigencesNon

fonctionnelles


Le suivi du projet : Les tableaux de bordCourbe Effort en j.h en fonction du délai


Le suivi de l’équipe et Scrum

Le but de la manœuvre est de maintenir l’équipe soudée, motivée et productive.

A cet effet, il y a dans Scrum la revue quotidienne qui est un point de rencontre entre tous les membres de l'équipe pour réguler les tâches de l’itération en cours.

La revue quotidienne repose sur 3 questions, auxquelles chaque participant va répondre à l’ensemble de l’équipe :

- Qu’ai-je fait hier ?

- Que vais-je faire aujourd’hui ?

- Quels problèmes je rencontre ?


Le suivi de l’équipe et Scrum

Buts de la revue quotidienne :

• Évaluer l'avancement du travail

• Identifier les obstacles (problèmes) nuisant à la progression

• Garder l'équipe concentrée sur l'objectif de l’itération

• Améliorer l'esprit d'équipe

• Permettre une communication objective sur l'avancement

Participants

• Toute l'équipe projet participe à la réunion.

• La réunion peut être animée par le chef de projet.

No .17111/04/23


En sortie de la revue quotidienne : Le burn-down chart


Le suivi de l’équipe & Lean :Présentation de Lean :

Une approche simple et efficace qui améliore la productivité et renforce la culture de progrès continu.

Lean n’est pas une nouvelle méthode d’organisation mais une philosophie qui a pour but de supprimer les taches sans valeur ajoutée et de simplifier les pratiques autant que possible. Le principe est simple : « Avec moins on peut faire beaucoup plus ! »

Quelques repères 1960 : Conception du système de production Toyota 1980 : Extension de la méthode à l’ensemble de l’industrie automobile 1990 : 1ères démarches dans les entreprise High Tech (HP, Schneider, …) 2000 : Applications du Lean dans de grands groupes européens du secteur Aéronautique et défense : EADS, Safran, Thalès, …


Le suivi de l’équipe & Lean :

Le Lean Software Development met en avant 4 outils, ou plutôt bonnes pratiques pour appliquer son principe :

Autodétermination, Motivation, Leadership, Expertise.


Le suivi de l’équipe & Lean : la motivation

Ce qui démotive :

Excès de règles, Supervision, Bureaucratie

Ce qui motive :

Réalisation, Reconnaissance, Responsabilisation

Lean préconise de respecter les personnes et de faire confiance à l’intelligence collective, et garantit ainsi qu’on avancera plus vite, plus loin !




◦ Planification








Bilan d’une itération

Bilan : Réel Vs PlanifiéComparer l'évolution (le réel) de l'itération au planning initial. Identifier les points à améliorer et définir un plan d'actions en conséquence.

Vers la fin de chaque itération, l'équipe projet doit se réunir pour évaluer l'itération, en se concentrant sur les points suivants :

L'itération a-t-elle rempli ses objectifs ?

Les livrables à produire ont-ils été produits et sont-ils complets ?

Quelle est la qualité du système et des livrables produits ?

Quel processus a réellement été suivi ?

Quelles compétences ont réellement été nécessaires ?

Comment est le planning final en comparaison avec celui initial ?

Des changements extérieurs se sont-ils produits (changements sur le marché, dans la communauté des utilisateurs ou dans les exigences) ?


Feedback / Démonstration

Il s’agit d’une revue qui permet un feedback concret sur le produit.

Le but de la revue est de montrer ce qui a été réalisé pendant l’itération afin d'en tirer les conséquences pour la suite du projet.

Participants

L'équipe MOE étendue, avec le chef de projet et la MOA, est présente à la réunion. Toutes les personnes qui sont partie-prenantes du projet y sont invitées et leur présence encouragée.

Produit en entrée

Le produit partiel potentiellement livrable. C'est la version opérationnelle obtenue comme résultat de l’itération


Feedback / Démonstration : étapes1. Préparer la démonstrationLa préparation de la réunion consiste à imaginer un scénario pour présenter les différents cas d’utilisation qui seront présentés et à vérifier que le matériel utilisé pour la démonstration fonctionne bien. La revue de sprint ne nécessite pas une présentation formelle.

2. Rappeler les objectifs de l’itérationLe chef de projet rappelle le but de l’itération défini lors de la réunion de planification. Il donne la liste des cas d’utilisation sélectionnés.

3. Effectuer la démonstrationL’équipe présente le résultat de ses travaux en faisant une démonstration des éléments du backlog de produit (cas d’utilisation) réalisés. Seules les cas d’utilisation complètement finies sont présentés. Cela permet d’avoir une mesure objective de l’avancement. La démonstration est faite par un ou plusieurs membres de l'équipe, en principe les plus impliqués dans les choses montrées. Si possible, les personnes présentes à la réunion sont aussi invitées à manipuler le produit.

4. Evaluer les résultats du sprintLa MOA et les intervenants présents posent des questions à l’équipe et donnent leur impression sur le produit montré. Leur feedback se concrétise en propositions et demandes de changement. Le backlog de produit est enrichi avec les éventuels bugs découverts et les demandes d’évolution suggérées.

5. Calculer la vélocité réelleLa liste des éléments du backlog considérés comme finis est établie. La vélocité de l’itération est obtenue en faisant la somme de tous les points attribués à ces éléments. Elle est comparée à celle des itérations précédentes, pour obtenir une vélocité moyenne


Rétrospective (partie publique et partie privée)

Faire un compte-rendu de la réunion avec une partie publique et éventuellement une partie privée que pour l'équipe.

On peut en effet en tant que chef de projet écrire des points d'amélioration personnalisés qui seront des contrats entre les membres de l'équipe, cela doit être connu de l'équipe mais on peut ne pas l'étaler sur la place publique. Cela renforce la cohésion de l'équipe sans tomber dans une auto critique lue de la hiérarchie.

Interne à l'équipe (incluant le chef de projet).

Objectif : comprendre ce qui n'a pas bien marché dans l’itération, les erreurs commises et de prendre des décisions pour s'améliorer.


ConclusionLa gestion de projet est un métier à part entière qui met en exergue des rôles et des tâches tout au long de la vie d’un projet.

PHARE préconise une démarche sur la gestion de projet, avec la définition de tout un processus et de best practices.

La démarche, les conseils et les recommandations proposés par PHARE portent aussi bien sur l’ingénierie que sur la dimension humaine ou organisationnelle de ce corps de métier.

Le but final : réussir le projet !

Questions

Questions

© Logica 2008. All rights reserved Formation au management de projets Charles ZAOUI Formateur et...

Documents

Transcript of © Logica 2008. All rights reserved Formation au management de projets Charles ZAOUI Formateur et...