Gestion de projet classique

cycle en 'V', waterfall...

Étapes traditionnelles

1. Expression de besoin détaillée & validée
2. Réalisation
3. Recette client
4. Déploiement

Contractualisation via : un Cahier des Charges

• de la taille d'une encyclopédie
• pas de changements possibles
• avec de multiples avenants

1 - Expression de besoin

le client rédige un cahier des charges décrivant TOUT

• Détaillée

  • production lourde pour le client
  • peu de place laissée au changement
  • prévision de tous les cas d'utilisation possibles
  • contractualisation & protectionnisme
     

• Validée

  • ​​coût de validation chiffrage par le fournisseur
  • prévision de toutes les difficultés techniques
  • figeage de nombreuses décisions techniques en amont

2 - Phase de réalisation

l'équipe s'isole pendant des mois pour déchiffrer le CdC et produire ce qu'ils ont compris

• Effet "tunnel"​

  • car la réalisation dure le temps nécessaire
  • RDV fin de réalisation avec le client
  • pas (ou peu) de changement sur le plan établi
           protection contractuelle (validée!)
     

• Conséquences :

  • déphasage entre le besoin initial et le produit
    (mauvaise interprétation des documents client)
  • certaines fonctionnalités finalement inutiles...
    ou pire : d'autres à forte valeur non implémentées
  • le marché (concurrence, technologie...) lui, a évolué!

3 - Phase de recette

le client réceptionne le produit et s'étonne de la non conformité de ses attentes

• Seul réel aller-retour avec la demande

  • en réalité, de nombreux avenants se sont surement ajoutés au CdC initial
  • le besoin a probablement évolué
  • découverte de l'interprétation faite du CdC
  • protection des 2 parties par le contrat :
    • fournisseur : faire au moins coûteux pour le remplir
    • client : exiger l'intégralité des travaux demandés

• Conséquences :

  • stade bien trop avancé changer de cap
  • relation néfaste et conflictuelle avec le client

4 - Déploiement

plus on attend pour trouver un problème, plus il est onéreux de le corriger...

• Découverte des problématiques techniques :

  • intégration de l'application
  • limite d'infrastructure, etc...
     

• Confrontation avec l'utilisateur final

  • le produit rencontre-t-il vraiment son public ?

Enquête Standish Group 

(Réalisée en 1994, puis renouvelée en 2008)

• 31 % des projets informatiques sont arrêtés en cours de route
• 52 % n’aboutissent qu’au prix d’un important dépassement des délais et du budget tout en offrant moins de fonctionnalités qu’il n’en était demandé
• 16 % des projets peuvent être considérés comme des succès

L'approche Agile

...plus qu'une méthode

Historique

• 1986 : première tentative de réalisation itérative

• 1993 : première mise en oeuvre de Scrum

• 2000 : eXtreme Programming : l'agilité pour le développement

• 2001 : naissance du Manifeste Agile, et du terme Agile

• 2010 : Devops : dépasse les frontières du développement

• 2012 : le Gartner invite à l'abandon total du Cycle en 'V'
• 2013 : IT et même entreprises passent à l'Agile

Différentes "méthodes" :

Scrum, eXtreme Programming, Kanban, FDD, RAD, Crystal Clear...

Produit plutôt que Projet

• le produit ne s'arrête pas à la fin d'un projet

• réaliser un projet : quid de la remise en question de celui-ci ?      les fameux 80% / 20% qui coûtent 20% / 80%

Suppression/réduction de "l'effet Tunnel" :

- donner de la visibilité

- impliquer le client du début à la fin du projet

Approche Agile

Manifeste Agile

Nous découvrons comment mieux développer des logiciels
par la pratique et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments,
mais privilégions les premiers.

Manifeste Agile

12 principes sous-jacents

Itération

portion de temps courte (< 4 semaines)

1. Le client élabore sa vision produit, et liste les fonctionnalités nécessaires à celui-ci.
    
2. Le client les priorise en terme de valeur métier
    
3. Le client soumet cette liste à l'équipe et échange avec elle directement (pas d'outil!). L'équipe peut à ce moment estimer le coût de chaque élément de la liste.
    
4. Itérations : l'équipe réalise une partie des fonctionnalités, s'assure de sa qualité, déploie le produit, ré-estime, etc...

Inspect & Adapt

A chaque itération :

• le produit partiel mais utilisable est montré au client qui :
  • se rend compte du travail réalisé
  • permet de valider l’alignement sur le besoin
  • "TTM" faible, et possibilité de ROI rapide
• le client peut reprioriser les fonctionnalités en fonction :
  • de leur maturité
  • de leur complexité de réalisation (ré-estimation)
  • de la découverte de nouveaux besoins
• "apprendre en faisant" - valable pour l'équipe et le client
  • "fail fast" : démarrer rapidement le projet
  • augmentation de la connaissance métier globale
  • accroissement de la maîtrise technique
  • reflexion régulière sur le cap à suivre et les moyens d'y arriver

Culte de la transparence

Forte visibilité offerte

le client final peut rapidement émettre des feedback qui pourraient se révéler cruciaux pour la suite

La Méthodologie

Scrum

3 piliers de Scrum

• Transparence

  • un langage commun, des rôles identifiés
  • une "définition de fait" partagée
  • métriques et fonctionnement interne "exposé"
     

• Inspection

  • revue régulière des artéfacts et de l'état d'avancement pour détecter les écarts 
     

• Adaptation

  • dès qu'un écart est détecter, prendre des mesures pour ajuster au plus tôt et limiter d'autres écarts

Rôles

4 cérémonies Scrum

prescrites pour pousser l'inspection et l'adaptation

• Sprint Planning - 2 parties : 

  • SP1 - "ce qu'on va accomplir durant le sprint" : le PO présente à l'équipe les fonctionnalités à venir, l'équipe s'engage sur une quantité de travail dépendant des Sprints précédents
  • SP2 - "comment accomplir le travail" : l'équipe de réalisation décompose en tâches raisonnable (< 1 jour) tous les items du Sprint, et s'organise pour atteindre son objectif

• Daily Scrum (Stand-up meeting...)

  • PDCA (Plan-Do-Act-Chek) quotidien de l'équipe
  • time-boxée par le SM
  • parle du travail réalisé, prévu, et des problèmes rencontrés

4 cérémonies Scrum (suite)

prescrites pour pousser l'inspection et l'adaptation

• Démo (Sprint Review) - en fin de sprint

  • lister ce qui a été terminé ou pas

  • expliquer les problèmes rencontrés

  • démontrer les fonctionnalités terminées

  • le PO discute de sa vision produit, des MAJ de jalons/dates...

  • discuter les prochains items qui pourront être faits

• Retrospective

  • inspecter le Sprint terminé en ce qui concerne les 
    personnes, les relations, les processus et les outils
  • est l'occasion d'améliorer : productivité, qualité, efficacité, conditions de travail, etc
  • décider d'un plan d'action commun, concis et atteignable

Cérémonie Bonus

dans la suite : US = User Story

• Grooming

  • l'équipe "raffine" le Product Backlog :

    • suppression d'US plus pertinentes

    • ajustement de la priorité des US

    • correction de la complexité de certaines US

    • estimation de la complexité des US "prêtes"

    • création de nouvelles US liées à de nouveaux besoins

    • split / merge d'US en fonction des besoins (INVEST)

  • le PO transmet à l'équipe de réalisation la connaissance métier, et par là même, sa vision produit.

Artefacts Agiles

et autres définitions...

User Stories

les spécifications fonctionnelles de l'agilité

Tout ce qui est à réaliser doit être : INVEST

Independent : The user story should be self-contained, in a way that there is no inherent dependency on another user story.

Negotiable : User stories, up until they are part of an iteration, can always be changed and rewritten.

Valuable : A user story must deliver value to the end user.

Estimable : You must always be able to estimate the size of a user story.

Sized appropriately or Small : User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.

Testable : The user story or its related description must provide the necessary information to make test development possible.
 

L'agilité via des exemples de pratiques

Description des US

écrites par le PO

• Énoncé de l'US

  • IN ORDER TO souscrire une offre
    AS utilisateur web (Utilisateurs autorisés à réaliser cet acte)
    I WANT TO voir la liste des offres auxquelles je suis éligible

• Descriptions des US

  • à l'aide de scénarios avec le formalisme BDD :

    • GIVEN je suis sur l'interface d'inscription
      AND je me suis authentifié
      WHEN je clique sur « Voir les offres »
      THEN j'ai accès à la liste des offres auxquelles je suis éligible

BACs du Backlog

ou comment maturer vos US

• le bac à sable pour y proposer toutes les idées,
• le bac de culture pour faire pousser les stories,
• le bac de départ pour les stories prêtes,
• le bac de sprint (avec éventuellement un bac de démo pour les stories finies pendant le sprint),
• le bac de récolte pour les stories à déployer.

cf blog de Claude Aubry

Board de l'équipe

A faire   |   En cours   |      Fait      |     Clos  

Organisation classique du board de travail :

A faire   |   En cours   |   A valider|   Validé

ou :

• Limitation du "En cours" (WIP max de Kanban)
• importance de la validation
  • au niveau US : PO
  • au niveau tâche : pair de l'équipe

Pratique XP

empruntée à l'eXtreme Programming