Stratégie pour le projet de développement du nouveau produit de Docapost DPS
Julien LefebvreDominique Méra
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
VISEO BUSINESS TECHNOLOGIES
= Novedia + Objet Direct
400Spécialistes Agile, Java, Web, mobile
Groupe VISEO : 1000 collaborateurs 100 m€ de CA
Novedia a rejoint
le groupe VISEO
le 9 février 2014
Objet Direct a
rejoint le groupe
VISEO en 2010
4
VISEO Business TechnologiesNous sommes des ingénieurs logiciels spécialistes du développement agile web et mobile
Build
Mobilité
HTML5JS
JEE & Web
No SQL / search
Productivité Web
Rec
uei
l, a
nal
yse
et
con
cep
tio
n
Pil
ota
ge
pro
jet
Dev
Op
s
Fo
rmat
ion
Arc
hit
ectu
re
Mai
nte
nan
ce,
su
pp
ort
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Prédictibilité
Confiance
Cycle en V
Démarche agile
Sprints 3 à 6
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
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
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
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
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
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
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
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
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
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
Implication des équipes de Docapost dans le projet
Démonstrations internes à Docapost par le PO et la R&D DPS
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
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
Equipe Scrum
35
Credits
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 !