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
Scrumday 2014 - Pollinisation croisée avec la communauté des designers par Pi...
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit de Docapost DPS par Dominique Mera
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
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 !
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 !