Reposant initialement sur un cocktail explosif, avec un Time To Market de 9 mois seulement, un premier chiffrage de plus de 1000 jours et un manque de disponibilité des métiers pour la rédaction du cahier des charges, le lancement du projet « nouvelle GED » pour docapost DPS paraissait de plus en plus difficile à mettre en oeuvre. Un engagement fort du prestataire inscrit dans une démarche agile (Scrum/XP), nous a permis de rendre possible la mise en oeuvre de la refonte en se concentrant sur le produit et d’éviter les dérives contractuelles classiques du cycle en V . Les difficultés rencontrées lors du déroulement du projet sont abordées, ainsi que les succès rencontrés, notamment : - Du pilotage par les risques - De l’intérêt du proxy product owner - De la manière dont le backlog a été constitué puis suivi - Doubler la taille d’une équipe sans dégrader la productivité - Equipe de développement focalisée sur les tâches de développement, les tâches d’intégration, tests de charge et de sécurité étant réalisées par les équipes de Docapost - Les bienfaits du sprint 0, notamment pour qu’il soit porté à la connaissance du sponsor des informations et définir la meilleure stratégie produit

1. Stratégie pour le projet de
développement du nouveau produit de
Docapost DPS
Julien Lefebvre
Dominique Méra

2. 2
DOCAPOST AU SEIN DU GROUPE LA POSTE
LE COURRIERL’ENSEIGNELE COLISLA BANQUE POSTALE
LA POSTE
VIAPOSTMEDIAPOST
LA POSTE
GLOBAL MAIL
» 30 ans d’expérience
» 4 600 spécialistes de la gestion documentaire
» 40 millions de flux échangés par an
» 10 000 clients des PME aux plus grands groupes
» 50% des entreprises du CAC 40 clientes
» + 10% de croissance
c’est :

3. 3
VISEO BUSINESS TECHNOLOGIES
= Novedia + Objet Direct
400
Spécialistes Agile,
Java, Web, mobile
Groupe VISEO : 1000 collaborateurs 100 m€ de CA

4. 4
VISEO Business Technologies
Nous sommes des ingénieurs logiciels spécialistes du développement agile web et mobile
Build
Mobilité
HTML5JS
JEE & Web
No SQL / search
Productivité Web
Recueil,analyseetconception
Pilotageprojet
DevOps
Formation
Architecture
Maintenance,support

5. Préparation
• Ouverture
• Mise à plat
LAD / RAD
• Rapprochement
automatique avec le
Référentiel
Archivage
Physique
Images &
métadonnées
Archivage
Électronique
Consultation
Vidéo
codage
Référentiel
Arrivée
TSA
WorkFlow
Numérisation Images
SI
Le processus de numérisation industriel

6. 6
Contexte du projet
 Editeur de services d’archivage électronique
 Deux produits « historiques »
● Issus de rachats
 Décision de faire un produit moderne
● Plutôt que de refondre l’un des deux produits existants
● En capitalisant sur le savoir-faire accumulé
● En travaillant sur les points faibles identifiés des produits existants

7. 7
Présentation du projet
 Solution d’archivage électronique en SaaS
 S’appuie sur un coffre fort électronique
● Confère une valeur juridique aux documents archivés
● Certifié FNTC-CFE
● Compatible AFNOR Z42 020
 Objectifs
● Time to market court (6-8 mois)
● Paramétrable pour une mise en œuvre rapide
● Moderne et ergonomique
● Architecture évolutive et robuste
● Capable de gérer un nombre de documents très variable (jusqu’à plusieurs
milliards)
 Environnement normatif

8. 8
Genèse
 Discussion de couloir
On a du mal à s’organiser pour
lancer le projet tout en assurant le
service. Tu pourrais monter une
équipe ? Oui, bien sûr, combien de
personnes, quel périmètre, pour
quand et jusqu’à quand ?
Une équipe de 5/6 personnes
pour début juillet jusqu’à la fin
de l’année. Il existe un cahier
des charges
Heu …
On est déjà à fin juin …
Tu me laisses un sursis ?

9. 9
Comment concilier l’inconciliable ?
 Produit à développer
 Charges estimées à + de 1500 jh
 90% du cahier des charges est prioritaire
 Le projet démarre au mois d’août …
 Deadline inchangée : première production en mars
● Il faudrait aligner 15 développeurs en suivant l’arithmétique !

10. 10
La stratégie
 Une contractualisation agile
 Et gérer le risque
● Principal risque : manquer le RDV de la première mise en production en mars
2014
 Prioriser !
 Une équipe de 8 personnes max
● Avec une montée en puissance progressive
● Mise à disposition d’une salle dédiée au projet
● Le Scrum Master est membre de l’équipe à temps complet
 Méthode itérative : Scrum avec pratiques XP & UP

11. 11
Un nouveau mode d’engagement à part entière
Régie
Focus
ressources
Risque côté
client
Engagement
prestataire
limité
Delivery-CDS
agile
Focus produit
Partage des
risques
Forfait
Focus contrat
Risque côté
prestataire
Négociations
de périmètres
ou d’avenants

12. 12
Un partage précis et clair des responsabilités
 Docapost DPS est responsable
● du budget
● de l’expression des besoins (User Stories)
● des échéances de livraison
● de la priorisation
● de la validation
 VISEO est responsable
● des chiffrages de ses équipes,
● d’organiser et de piloter ses équipes
● de délivrer au coût estimé par ses équipes
● de délivrer aux normes de qualité de Docapost DPS
● de fournir sans réserve toutes les informations dont Docapost DPS a besoin

13. 13
Un sprint 0
 Pour prendre en main le projet
● Equivalent de la phase d’inception du Processus Unifié
 Mise en place de l’équipe
● Taille réduite au départ : 4 personnes
 Mise en place de l’architecture
● Et des environnements
 Macro-estimations
● Pour aider à la priorisation

14. 14
Savoir dès le départ que l’on ne pourra pas
tout faire ….
 Macro-chiffrage obtenu
● Deux fois plus élevé que la capacité de production !
 Tentatives de définir un périmètre prévisionnel
● Pour la première version
● Pas forcément un succès !
● Nécessité de conserver une cohérence fonctionnelle
 Analyse de la valeur des fonctionnalités
● Pour en déduire un ordre de priorité
● Approche tout aussi délicate
 Au final : un mixte des deux
● Très empirique
● Malheureusement proche d’un lotissement …
● Et non respecté !

15. 15
A quoi sert une GED ?
 A quoi sert une GED ?
● Consulter des documents
● Déposer des documents
● Le tout de manière sécurisée
 Tout le reste
● Est très important
● Mais un peu moins prioritaire !
● En particulier les écrans de paramétrage, malgré un ROI important sur
l’accroissement des possibilités de paramétrage
 Etude d’une solution de génération des écrans de
paramétrage
● Ergonomiquement dégradé par rapport à des écrans « faits main »
● Mais permet de respecter l’échéance

16. 16
Comment cloner un Product Owner peu
disponible ?
 Le Product Owner
● Auteur principal du cahier des charges
● Disponible moins de deux jours par semaine
● Ne connaissait pas les méthodes agiles au départ
 Un proxy !
● Temps plein dans l’équipe projet
● Rédige les spécifications et les cas de tests
● Aide le product owner à gérer le backlog
● Coache le Product Owner sur les aspects méthodologiques

17. 17
Sans ce dispositif ?
 L’équipe de réalisation ne serait pas alimentée en
spécifications
● Même avec un Proxy Product Owner, le flux est très tendu
 Il eut fallu attendre deux ou trois mois avant de
commencer les développements
● Peu compatible avec l’échéance principale !

18. 18
Initialisation du Backlog
 Accompagnement du Product Owner pour la définition des
principaux items : Epics (voir thématique)
● Cela passe par :
• Des ateliers de travail : échange avec le PO sur la base du Cahier des charges
• Rédaction des éléments du backlog et premier niveau de priorisation
 Chiffrage macroscopique à l’aide d’une échelle arbitraire
 Définition de la vision projet et trajectoire à prendre
● vis-à-vis des priorités,
● de la capacité de production,
● et des délais contraints.

19. 19
Maturation du Backlog
 Analyse détaillée des Epics/thématiques décrits
 Découpage en user stories éligibles au développement
● descriptif, scénario et « tests d’acceptance »
● validation par le Product Owner
 Réévaluation des priorités à chaque sprint
● fonction des développements réalisés,
● des décisions prises en COPIL, confrontation au réel
● et/ou de la difficulté technique rencontrée
 Chiffrage macroscopique (mise à jour)
● à l’aide de la même échelle
● mais sur la base de stories déjà réalisées (méthode comparative)
 Implication des parties prenantes

20. 20
Prédictibilité
Confiance
Sprints 3 à 6

21. 21
REX sur la vie du « Backlog Produit »
pendant les sprints
 Réunion de macro-chiffrage
● Prise de connaissance au plus tôt par l’équipe des prochaines stories du
backlog (niveau de maturité de la story plutôt faible)
● Vision projet et trajectoire mieux comprise par l’équipe
 Réunion de pré-chiffrage : évaluation de stories matures et
déjà portées à la connaissance de l’équipe (listing des
tâches et évaluations déjà faits)
● Sprint planning simplifié et raccourci
 Ateliers de conception technique et fonctionnelle pendant
le sprint
● Anticipation sur la complexité fonctionnelle et les problèmes techniques
associés
● Proposition de solutions en amont et mise à jour du Backlog

22. 22
Comment ralentir efficacement une équipe
de développeurs ?
 Très facile : mettre 7 développeurs sur un même écran !
● Découpage en tâches difficile
● Tâches fortement inter-dépendantes
● Perte d’efficacité garantie !
 Pour un produit les fonctionnalités doivent être cohérentes
● Difficultés à concilier avec la répartition du travail sur plusieurs pans
fonctionnels
● Deux « grosses fonctionnalités » à réaliser rapidement : consultation et
injection
 Moralité
● Des User Stories de taille modeste, portant sur des cas d’utilisation distincts
dans un même sprint

23. 23
Un bon réflexe
 Le besoin
● Recherches dans des meta-données
● Volume : jusqu’à plusieurs milliards de meta-données
● Sans pénaliser les performances
 La solution retenue
● Elastic Search http://www.elasticsearch.org/

24. 24
Un bon réflexe
 Le risque
● L’équipe projet n’a pas d’expertise sur Elastic Search
● Comment s’assurer que le produit est utilisé correctement ?
 Sollicitation d’un expert
● Pour conseiller l’équipe sur la meilleure manière d’utiliser le produit
● Feedback très positif de cette intervention

25. 25
Montée en puissance de l’équipe
 Au Sprint 4 : taille d’équipe doublée
 Capacité du sprint en points adaptée en conséquence
● Les nouveaux membre du projet sont comptés comme 50% sur leur premier
sprint, puis 75% le suivant
 Mise en place d’un cursus de formation étalé sur le sprint
● Sur un plan technique
● Mais aussi fonctionnel
 Beaucoup de séances de pair-programming !
● Qui ont perduré depuis

26. 26
Comment concilier un environnement agile
avec un environnement normatif ?
 Que demande la norme ?
● De la documentation principalement
● Sur comment le produit et l’organisation répondent aux exigences
● Pas de contrainte particulière sur le moment où cette documentation est
produite dans le processus de réalisation
 Les normes portant sur les processus sont compatibles
avec une démarche agile
● Dès lors qu’une maîtrise des risques est démontrée !
● Inversement, dire de ne pas faire de doc inutile ne veut pas dire que l’on ne
fait pas de doc du tout !

27. 27
Une équipe hybride est plus efficace
 Le produit est la propriété de Docapost
 Les équipes de Docapost vont l’exploiter, le maintenir et le
faire évoluer pendant de nombreuses années !
 La contribution de Viseo est de mettre à disposition
temporairement une démarche et une équipe

28. 28
Une équipe hybride est plus efficace
 Intégration d’un développeur de Docapost dans l’équipe
projet
 Tout en conservant l’engagement de résultat par Viseo
 Relation de confiance indispensable

29. 29
Kit prêt à l’emploi généralisable
 Transfert de compétences
● En cours de définition
 Basé sur un biseau
 Concerne
● Le code
● Le fonctionnel
● Mais aussi – et surtout - la démarche projet complète !

30. 30
Implication des équipes de Docapost dans le
projet
 Prise en main du produit par l’équipe R&D de Docapost DPS
● Installation dans les environnements
● Intégration dans le SI
● Réalisation de quelques fonctionnalités (en doublon)

31. 31
Implication des équipes de Docapost dans le
projet
 Démonstrations internes à Docapost par le PO et la R&D
DPS

32. 32
Implication des équipes de Docapost dans le
projet
 Implication des exploitants et du service développement :
prise en compte de leurs feedbacks
● Technique DevOps !

33. 33
Le pragmatisme plus important que la
méthode
 Des adaptations à la méthode ont été faites
● Format des user stories
● Comités de pilotage !
● Allongement des sprints en août et à noël
● L’équipe contrainte en termes de choix techniques
● Priorisation par domaine fonctionnel plutôt que user story
 Pour la bonne cause !

34. 34
Equipe
Scrum

35. 35
Credits

36. 36
Conclusions
 Les principaux objectifs ont été respectés
● Une application fonctionnelle
● En mars 2014
● Impossible avec un cycle en V
 Une relation préservée
● Sur la base d’une stratégie gagnant/gagnant
● Une nouvelle illustration du savoir-faire Objet Direct pour réaliser des projets
en contrat agile
● Consensus obtenu entre l’IT et le marketing !