PLANIFICATION AGILE

 

Démarche générale

 

conduite de projets la demarche agile

 

Taille, vélocité et calendrier

 

ü  première étape : estimer la « taille » des fonctionnalités

ü  La « vélocité » permet de déduire la durée de réalisation d’une fonctionnalité

 

conduite de projets la velocite

 

 

 

Vélocité = coefficient qui determine en combien de temps je fais une unité (jours d’hommes, etc.)

(d’après Mike Cohn « Agile Estimating and Planning » : www.mountaingoatsoftware.com/)

 

Une question? Posez-la ici

 

Estimation Agile : « Story Points »

 

« Mieux vaut être grossièrement juste que précisément faux. » (John Keynes)

 

Story Points : mesure relative

 

Les Story Points sont une unité de mesure exprimant la taille globale d’une fonctionnalité ou d’une tâche.

Seule la valeur relative assignée à un objet compte : une US User Story valant 2 points nécessite deux fois plus d’effort qu’une US valant 1 point (inutile d’être précis !).

Le nombre de points assignés dépend de la quantité de travail nécessaire estimée, ajustée en fonction de la complexité, des risques, etc…

Partir d’une US de taille moyenne, puis en déduire la taille des autres.

Exemples…

 

Exemple simple: planifier le temps pour faire la vaisselle

 

Fin de soirée, 5 personnes à diner, il faut faire la vaisselle : combien de temps cela va-t-il prendre ?

5xFourchettes    5xCouteaux        5xVerres              5xAssiettes         2xCasseroles

Estimation. Hypothèse des story points assignés, d’après une demande autour de la table :

1SP                       1SP                       2SP                       2SP                      

Maintenant on assigne un temps à chaque Story point

1 storyPoint=15 secondes

Ce qui nous fait

5xFourchettes    5xCouteaux        5xVerres              5xAssiettes         2xCasseroles

5x15=75              5x15=75              5x2x15=150        5x2x15=150s      2x5x15=150

En tout on a 600 secondes, soit 10 minutes. On peut donc faire la vaisselle en 10 minutes.

On a perdu beaucoup de temps à assigner combien de SP par ustensile, alors qu’au final, meme en donnant des approximations, on arrive à un temps cohérent

Il faut utiliser la fibre de Fibonacci pour les US (1,2,3,5,8)

Plus on a d’US, plus le projet grossit

 

 

Une question? Posez-la ici

 

 

Effort d’estimation

 

  • Consacrer l’effort juste nécessaire à l’estimation :

ü  Quel que soit l’effort on n’atteindra jamais les 100% d’exactitude

ü  Un effort minimal permet déjà d’obtenir une estimation moyenne

ü  Pousser trop loin l’effort dégrade le résultat

 

 

         conduite de projets effort d estimation

 

 

Echelle d’estimation

 

  • Pour les US on peut utiliser la suite de Fibonacci (1, 2, 3, 5, 8)
  • Pour les fonctionnalités de haut niveau qui ne seront estimées en détail que plus tard (« Epics », « Themes ») : 13, 20, 40, 100

Techniques d’estimation

 

  • Opinion d’expert
  • Analogie avec des US réalisées antérieurement
  • Désagréger la US/Feature en ensembles plus petits è augmente largement l’effort
  • Planning poker : estimation collective

Ré-estimer

 

               On peut ré-estimer en cours de projet mais uniquement si la taille relative des US a changé. Sinon, ajuster via la vélocité.

 

Priorisation Agile

 

  • La priorisation des US se fait selon les critères suivants :
    • La valeur client (cf. section suivante)

ü  valeur financière apportée par la fonctionnalité (accroissement des ventes, économies en interne, …)

ü  « désirabilité » client

  • Le coût du développement de la fonctionnalité (cf. estimation taille)
  • Les risques levés par le développement de la fonctionnalité
  • La connaissance acquise au cours du développement de la fonctionnalité qui permet de réduire les incertitudes

ü  connaissance sur le besoin du client (via les revues et démonstrations)

connaissance sur la maîtrise de l’équipe (notamment la maîtrise de la technologie via les premiers développements)

 

Une question? Posez-la ici

 

 

Combiner les 4 critères

 

    • Exemples
  • application grand public
  • framework à technologie inconnue

conduite de projets combiner les 4 criteres

 

Désirabilité

 

               On peut classer la désirabilité des fonctionnalités selon les méthodes suivantes :

    • Moscow, Modèle de Kano
    • Modèle des poids relatifs

               Il est basé sur des estimations (en points relatifs, de 0 à 9) de la désirabilité des fonctionnalités obtenues par questionnaire ou jugement d’expert :

ü  Bénéfice apporté par la fonctionnalité

ü  Pénalité en cas d’absence de la fonctionnalité

 

conduite de projets desirabilite

 

 

Une question? Posez-la ici

 

 

Agile Scheduling

 

Product Roadmap

 

Premier niveau de planification, établi tout en amont du projet et révisé très occasionnellement

Etabli par des décideurs de haut niveau (direction), des product owners et des team managers (experts projets)  

On y planifie des releases :

 

releases externes

 

livrées à l’utilisateur final

 

releases internes

 

livrées à quelques key users qui l’utiliseront dans des conditions simulant la production è feedback

Périmètre : Les releases doivent correspondre à des ensembles de fonctions cohérents, exploitables et significatifs pour l’utilisateur (sauf « release » interne à l’équipe, comme un prototype architectural)

 

Exemple de Product Roadmap

 

A remplir par le product owner et on valide :

conduite de projets product roadmap

 

 

Fréquence et positionnement des releases

 

Mettre des releases de même temps.

Les releases doivent être assez fréquentes (et donc petites) afin d’apporter :

une réactivité importante au changement ou aux nouveaux besoins

une réduction rapide du risque « compréhension du besoin »

è déterminer la fréquence optimale en fonction du besoin de feedback, de la réactivité du marché, etc…

En général les dates sont fixées et le contenu de la release est estimé (parfois le contraire).

On place les releases à des dates régulières (ex: tous les 4 mois) ou bien selon le marché ou des évènements précis (salon, …).

 

 

Une question? Posez-la ici

 

 

Release Plan

 

               Session de 2 jours en début de Release, impliquant toute l’équipe.

 

conduite de projets release plan

 

Une question? Posez-la ici

 

 

Définir l’objectif de la release

 

Parmi les 3 éléments de l’objectif, on privilégie souvent :

Date de fin : « schedule driven ».

OU

Périmètre : « scope driven ».

Les ressources font l’objet d’hypothèses de départ qui peuvent être ajustées jusqu’à

un certain point.

Choisir la durée des itérations en fonction de :

ü  la durée de la release

ü  besoin de feedback et facilité pour l’obtenir

ü  besoin de reprioriser souvent

moins on a de certitudes sur :

ü  la stabilité du besoin client

ü  la compréhension de ce besoin par l’équipe projet

ü  la performance de l’équipe

               plus on raccourcit les cycles.

Une question? Posez-la ici

 

 

Identifier US

Décomposer les Fonctionnalités de haut niveau en US suffisamment petites pour tenir dans une itération.

Techniques de split :

splitter selon les étapes/activités du processus (ex : CRUD)

splitter selon les données manipulées

faire des contraintes de performance et des fonctionnalités transverses (sécurité, login, …) des US à part entièr

splitter en sous-US selon la priorité

Ajouter les Tâches Transverses et work items de haut niveau :

management (éventuellement)

divers spikes (surtout en cas de réflexion Up-Front)

travaux d’infrastructure

préparation de release (doc d’install, formation, …)

 

Une question? Posez-la ici

 

Décomposition des US en tâches

  • inclure toutes les tâches nécessaires pour la réalisation de la US.
  • n’inclure que les tâches à valeur ajoutée et en rapport direct avec le projet
  • une tâche doit pouvoir être effectuée en 1 ou 2 jours approximativement

 

 

US 6 : Tâches
Décrire les règles métier
Ecrire les acceptance tests
Concevoir l’IHM
Démontrer une maquette d’IHM au Product Owner
Coder l’IHM
Coder le middle tier
Mettre à jour la DB
Automatiser les tests unitaires

 

 

Une question? Posez-la ici

 

 

Des questions?