# Pilotage de projet

[e-mail]

###### tags: `cours`

## Séance 1: Intro

### Quel rôle pour le ~~chef de projet~~ / pilote ?

- à l'écoute
- arbitre, prioriser
- fédérer (motiver, embarquer ses colaborateurs)
- prendre les responsabilités
- s'adapter
- savoir déléguer
- organisé
- présent

__


| Organisation et pilotage | Le quoi utilisateur (fonctionnel) | Le comment informatique (technique) |
|:------------------------:|:---------------------------------:|:-----------------------------------:|
| Contrat | Valeur | Complexité |
| Budget | Besoins | Architecture |
| Planning | Périmètre | Composants |
| Equipe | Acceptation | Code |
| Lotissement | | Qualité |


= Carrefour des exigences:
- Hiérarchie, qualité, juridique --> Reporte en échange de directives et contraintes (satisfaire les interets)
- Client, utilateurs, MOA --> Livre en échange de besoins, retours (satisfaire les besoins)
- Equipe, sous-traitants --> Affecte tâche, suivi en échange de livrables (**Motiver**, **Faire progresser**, **Optimiser compétences**)

### Qu'est-ce qu'un projet ?

- **Aventure humaine** (Processus **temporelle** avec un début et une fin)
- **Transformation**, évolution
- **Valeur ajoutée** Objectif: satisfaire un besoin.
- Suite de mini victoires intermédiaires
- processus récurrent != projet one shot

### Comment mesurer sa réussite ?

Avant un projet :

**WHAI**
- **Why** ?
- Répondre à ... Une nouvelle stratégie, besoin métier, contrainte réglementaire.
- **How to** ?
- **Techno**: Solution du marché adaptée à mes besoins ?
- La meilleure **organisation**
- La bonne démarche (Agile ou pas --> dépend du client)
- **Added value** ?
- Processus qui fonctionnent mieux ??
- Bénéfices qualitatifs/quantitatifs
- **Indicators** ?
- Critères de réception (nb de US)
- Mesure la satisfaction client
- Indicateurs: quantitatifs, économiques (ex: perf)

### Comment avoir une vision analytique pour piloter le projet ?

##### Outils de suivi


### Les démarches

- En **V** classique
- En **Y** (Unified Process)
- **Agiles** (SCRUM, KANBAN, LEAN)
- **itérative** (MPI)

#### Classique Vs Agile


| | Classique | Agile |
|:------------:|:--------------------:|:-------------------:|
| **Fixe** | Exigences | Ressources, Date |
| **Estimé** | Ressources, Date | Exigences |
| Organisation | Penser puis réaliser | Penser en réalisant |

___

## Séance 2 : L'avant-projet

### Les étapes

1) **Design** (exploration, cadrage)
2) **Build** (mis en Oeuvre, déploiement)
3) **Run** (maintenance)

### Estimation

- délicat (experts)
- continue (avant-vente, init, pendant réal)
- formalisée (évaluation des charges)
- pratiquer l'évaluation contradictoire (2 évaluateurs doivent avoir un écart de - de 10%)

--
- exigences non connues en avance
- facteurs complexes
- productivité variable

--

-
Découper à la demi-journée max 5j, en micro tâches pour ne pas se planter sur l'évaluation, estimation de charge (temps, complexité.
Revers: somme surestimée ? Tâches répétitives plus rapides après

___

## Séance 3 : Plan de production

### Définition

- Le but du plan de production est de faire coïncider une **vue statique** (chantiers et ressources du projet) avec une **vue dynamique dans le temps** (tâches)
- solution non unique

### Règles

#### 1 Double projection

#### 2 Triple pour les chantiers :
- tâches **fonctionnelles**
- **techniques**
- **méthodologiques**

#### 3 Garder une poire pour la soif
- qualification, intégration
- garantie
- pilotage
- logistique

#### 4 Discuter avec équipe
- **appétances** des gens différentes, Organiser, affecter en fonction des compétences, congés, déplacements...
- Montrer les scénarios de test au début. Il y aura pas de nouvelles demandes après. Vérouille le contrat.

### Exemple

Pour 100j de dev, projet globale c'est 220 (avec les charges et tout compris)
Pour un projet web
- **Spécifications** : 20% de la réal
- **Conception** : 20% de la réal
- **Architecture** : 10% de la réal
- **Intégration** : 15 %
- **Qualification**: 10% de la réal
- **Documentation**: 5% de la réal
- **Garantie** : 10% de la réal

--> 90j

- Pilotage : 15% du projet total

--> 15% de 190j -> 29j

Réal brut + TU = 100j ==> Total projet 220j

Ratios qui s'adaptent.

### Petit projet et gros projet


### Pilotage interne externe


### Gérer les imprévus
1) Récup Information
2) Analyse
3) Plan d'action
4) Communication

### Les lois de gestion du temps

#### Loi de **Parkinson** (projection dans le temps de l'humain)
> Le **temps consacré** à une tâche dépend du **temps disponible**.
:arrow_right: Fixer des **objectifs raisonnables** en terme de distance : ni trop proches, ni trop lointains.

#### Loi de **Murphy** - Loi de Finagle (pessimisme raisonné)
> Tout ce qui est susceptible d'aller mal ira **mal**.
:arrow_right: Etre **réaliste** dans l’évaluation du temps, adopter un **pessimisme raisonné**, ne pas sous-évaluer.

#### Loi de **Pareto** (l'essentiel)
> 20% de nos activités produisent 80% de nos résultats.
:arrow_right: **Privilégier l’essentiel**, ne pas s’obstiner sur des tâches secondaires, distinguer en permanence les activités stratégiques.

#### Loi de **Carlson** (continuité)
> Un travail **interrompu** est moins efficace.
:arrow_right: Privilégier des **séquences** de travail **homogènes**.

#### Loi d'**Illich** (rythme de travail)
> Au delà d'un certain seuil, l'efficacité décroit.
> :arrow_right: Tenir compte de ses propres rythmes de travail et de ceux de l’entreprise et s’organiser en conséquence.

#### Loi de **Laborit** (individualisme)
> Chaque **individu** a tendance à faire d’abord ce qui lui **fait plaisir**.
> :arrow_right: Distinguer **l’important et l’urgent**, ne pas appliquer des principes FIFO ou FILO, prioriser en fonction de l'important et l'urgent.

### Diagramme de GANTT
- Relations d'antériorité.
- Tâches = barres horizontales

### Diagramme de PERT = Program Evaluation and Review Technique


- **Dépendances** des US entre elles pour optimiser la chronologie des tâches.
- Notion de **chemin critique**.
- Pas vraiment fait pour agile, Jira fait ça...

### Une tâche

#### Définition

- un travail à réaliser
- un périmètre fonctionnel/technique
- un livrable
--
- charges de réalisation (en nb de jours)
- dates

#### Suivi des tâches grâces aux indicateurs...

- Charge **budgetée** (avant-vente)
- Charge **estimée** (initialisation du projet)
- Charge **consommée** (jours depuis début de tache)
- Charge **RAF** (estimée pour finir la tache)

#### Gestion des priorités

Distinguer urgent de important et en fonction :
- Faire soi-même ou déléguer.
- Faire immédiatement, rapidement, donner échéance, reporter.
___

## Séance 4: Cerner le besoin

### La US

#### Avant: les 3C
- **Carte** : Représentation synthétique.
- **Conversation** : Fruit d'un échange entre client et PO et équipe.
- **Confirmation** : Présente conditions d'acceptation.

#### Aujourd'hui: INVEST
- **Indépendant** : - d'indépendance entre US --> + facile de prioriser.
- **Négociable** : Story peut évoluer.
- **Valuable**: Valeur métier obligatoire.
- **Estimable**: Suffisament de précision pour compréhension et quantification de l'effort.
- **Small** : Granularité à adapter au fur et à mesure.
- **Testable** : Pouvoir exprimer conditions d'acceptation.

#### Modèle

Titre : explicite.
Description : vision orientée client + besoin fonctionnel + bénéfice attendu (valeur de la US).


- **Titre** : Authentification
- Valeur --> priorité: 3
- Complexité: 13
- **Description** : En tant qu'utilisateur, je dois m'authentifier pour accéder au site selon des règles strictes
- **Acceptance** : Si non authentifié, redirection sur module dédié. Suite à l'authentification je susi redirifé vers la page1.

___

## Séance 5: Méthode agile

### Définition

- Officialisée en 2001 par un document **Manifeste Agile** (Agile Manifesto) signé par 17 personnalités impliquées dans l'évolution du génie logiciel et généralement auteur de leur propre méthode.
> « 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**. »

### Agilité: Scrum

- :person_with_blond_hair: **Product Owner** : Représente le client et / ou les utilisateurs, priorise les fonctionnalités, doit savoir dire non et l'argumenter.
- :busts_in_silhouette: **Equipe** : **auto-gérée** (pas de chef de projet mais un leader), pluridisciplinaire. Réalise.
- :person_frowning: **Scrum Master** : **Vérifie la bonne application de SCRUM**, « protège » l’équipe de tous les éléments « perturbateurs » hors projet, **facilitateur**, animateur, régulateur.
- Intervenants : par exemple expert technique affecté au projet mais n’y participant que ponctuellement

### 4 valeurs et 12 principes

#### Les valeurs

| Valoriser... | Plutôt que... |
|:-------------------------------:|:-------------------------:|
| Individus et leurs intéractions | Outils et processus |
| Logiciel fonctionnel | Documentation exhaustive |
| Collaboration avec les clients | Négociation contractuelle |
| Adaptation au changement | Exécution d'un plan |

#### Les principes

1. **Priorité: satisfaire le client --> livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.**
2. Accueillir positivement les **changements** de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
3. Livrer **fréquemment** un logiciel fonctionnel, dans des cycles de quelques semaines à quelques mois, avec une préférence pour les plus courts.
4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler **ensemble** quotidiennement tout au long du projet.
5. Réaliser les projets avec des personnes **motivées**. Fournissez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
6. La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le **dialogue en face à face**.
7. Un **logiciel fonctionnel** est la **principale mesure de progression** d'un projet.
8. Les processus agiles encouragent un **rythme** de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
9. Une attention continue à l'**excellence technique** et à un **bon design**.
10. La **simplicité** – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
11. Les meilleures architectures, spécifications et conceptions émergent d'équipes **auto-organisées**.
12. À intervalles réguliers, l'équipe réfléchit aux moyens possibles de **devenir plus efficace**. Puis elle s'adapte et modifie son fonctionnement en conséquence.

#### :+1: Les bénéfices
- **\+ de visibilité** (livraisons régulières, RAF)
- **maîtrise du budget** (arrêt possible à tout moment avec un produit fonctionnel)
- **maîtrise des risques** (feedback permanent, qualité sur chaque livraison)
- **\+ de productivité** (- de doc, - de report???, - de validation formelle)
- \+ valeur métier (directement utilisable --> VA, prise en compte des changements)
- \+ de réactivité dans les arbitrages
Indicateur projet WILD

### Un sprint :repeat:


- Temps de batement au début d'un projet: mise en place de la chaine, des environnements, des frameworks et connexions: ceci n'est pas visible.
- Done: Quels critères pour dire qu'une tâche est faite (testée, documentée, intégrée...)
- Scrum Board

| Story | To do | In Process | To verify | Done |
| ----- | ----- |:----------:| --------- | ---- |
| | | | | |

- Pilotage avec le diagramme **BurpUp** :chart_with_upwards_trend: et **BurnDown** :chart_with_downwards_trend:

#### Expression des besoins: Backlog

1) Product Backlog (Product Owner)

- liste priorisée de fonctionnalités (User Stories)
- évolutif et itératif
- affinage des US au fur et à mesure
- backlog **produit** et non pas backlog "projet" --> satisfaction des utilisateurs finaux, du client.

2) Sprint Backlog (Equipe)

#### Sprint planning :date:

#### Dailys

Un deli mou = un produit mou
Un deli top = présidence tournante
Souvent la partie build du kanban chart gonfle (manque d'info ou de tests)

#### Sprint review

- 1-2h max
- inventaire de ce qui a été produit avec les utilisateurs
- pas de technique

:dart: **Objectifs:**
- Rassurer client
- Captiver client
- Impliquer/Remotiver développeurs
- Capter évolution besoin et retours

1) Présentation du tableau des DONE
2) Présentation fonctionnalités
3) Retours
4) Projection pour sprint suivant

#### Rétrospective

- 30-90min max
- Retours collaborateurs
- Tableaux de 3/4 compartiments: collaborateurs apposent au - un postit/compartiment
- But: s'améliorer pour le prochain sprint.
- backlog non finalisé (reste pour le sprint planning)

:clipboard: Différents tableaux:
- **MSG** (**Mad Sad Glad**)
- **DAKI** (**Drop Add Keep Improve**)
- **Starfish** (étoile de mer): ce qui a marché ou pas + ce qui mérité d'être développer pour améliorer.
- **Speed Boat**: Forces, Objectifs, Contraintes et Obstacles.

1) **Poser cadre** (objectif, focus, plan de réunion)(sentiment général, synthèse de sprint review)
2) **Point de situation, faits** (repasser les US... et remarques d'utilisateurs, burndown produit + backlog produit)
3) **Générer idées** (tableau)
4) **Plan d'action** (prochain sprint, projection)
5) **Conclusion**

**ESVP** = **Explorateur**, **Shoppeur**, Vacancier, Prisonnier

___

## Séance 7 : La réunion

### Etapes

1) Accueil (ordre du jour)
2) Production Echange (consensus)
3) Synthèse reformulation formalisation
4) Cloture, point sur les actions

### L'animateur

- Faciliter, réguler
- Privilégier questions ouvertes
- Amener au consensus


### 5 Règles de négociation

1) Exigence initiale **élevée**
2) **Résister** aux demandes
3) Rien accorder **sans contrepartie**
4) Reculer à **petits pas**
5) Avancer vers conclusion (vérouiller les points à chaque fois)

### Méthodes

#### **DESC**: Entretien de recadrage
- **D**écrire situation de manière factuelle.
- **E**xprimer sentiments.
- **S**olutions.
- **C**onclusion

#### CNZ: Traitement des objections

- Creuser (la question)
- Neutraliser (Reformuler, recadrage)
- Zoomer (sur son agumentaire)

#### 4C: Architecturer sa communication, gérer le face-à-face

- Contact (conditions de communication)
- Connaître (Faits)
- Convaincre (Opinions, échange)
- Conclure (Plan d'action)

___

## Etude de cas : exemple

https://moodle.bordeaux-inp.fr/pluginfile.php/192810/mod_resource/content/1/Contr%C3%B4le%20-%20Evaluation%20des%20acquis%202019.pdf

2) Préparation de la réunion:
- **Objectif**, enjeu: affiner l'expression du besoin (citer tous les manques)
- **Participants**
- **Méthodo/strat**:
- à l'écoute, ne pas se perdre et ne pas oublier (avoir un agenda)
- gestion du temps
- bien noter les réponses, les formaliser pour les envoyer pour vérification

Préparation à l'atelier demande 1j pour le chef de projet
Tenue de l'atelier, 0.5 chef + 0.5 concepteur = 1j
synthèse: 1j chef

3) **22j par mois**, durée du projet
profils

**Plan de charge**

**Ventilation des tâches**

**Plan de production**