Stratégie pour le projet de
développement du nouveau produit de
Docapost DPS
Julien Lefebvre
Dominique Méra
2
DOCAPOST AU SEIN DU GROUPE LA POSTE
LE COURRIERL’ENSEIGNELE COLISLA BANQUE POSTALE
LA POSTE
VIAPOSTMEDIAPOST
LA POSTE
GL...
3
VISEO BUSINESS TECHNOLOGIES
= Novedia + Objet Direct
400
Spécialistes Agile,
Java, Web, mobile
Groupe VISEO : 1000 colla...
4
VISEO Business Technologies
Nous sommes des ingénieurs logiciels spécialistes du développement agile web et mobile
Build...
Préparation
• Ouverture
• Mise à plat
LAD / RAD
• Rapprochement
automatique avec le
Référentiel
Archivage
Physique
Images ...
6
Contexte du projet
 Editeur de services d’archivage électronique
 Deux produits « historiques »
● Issus de rachats
 D...
7
Présentation du projet
 Solution d’archivage électronique en SaaS
 S’appuie sur un coffre fort électronique
● Confère ...
8
Genèse
 Discussion de couloir
On a du mal à s’organiser pour
lancer le projet tout en assurant le
service. Tu pourrais ...
9
Comment concilier l’inconciliable ?
 Produit à développer
 Charges estimées à + de 1500 jh
 90% du cahier des charges...
10
La stratégie
 Une contractualisation agile
 Et gérer le risque
● Principal risque : manquer le RDV de la première mis...
11
Un nouveau mode d’engagement à part entière
Régie
Focus
ressources
Risque côté
client
Engagement
prestataire
limité
Del...
12
Un partage précis et clair des responsabilités
 Docapost DPS est responsable
● du budget
● de l’expression des besoins...
13
Un sprint 0
 Pour prendre en main le projet
● Equivalent de la phase d’inception du Processus Unifié
 Mise en place d...
14
Savoir dès le départ que l’on ne pourra pas
tout faire ….
 Macro-chiffrage obtenu
● Deux fois plus élevé que la capaci...
15
A quoi sert une GED ?
 A quoi sert une GED ?
● Consulter des documents
● Déposer des documents
● Le tout de manière sé...
16
Comment cloner un Product Owner peu
disponible ?
 Le Product Owner
● Auteur principal du cahier des charges
● Disponib...
17
Sans ce dispositif ?
 L’équipe de réalisation ne serait pas alimentée en
spécifications
● Même avec un Proxy Product O...
18
Initialisation du Backlog
 Accompagnement du Product Owner pour la définition des
principaux items : Epics (voir théma...
19
Maturation du Backlog
 Analyse détaillée des Epics/thématiques décrits
 Découpage en user stories éligibles au dévelo...
20
Prédictibilité
Confiance
Sprints 3 à 6
21
REX sur la vie du « Backlog Produit »
pendant les sprints
 Réunion de macro-chiffrage
● Prise de connaissance au plus ...
22
Comment ralentir efficacement une équipe
de développeurs ?
 Très facile : mettre 7 développeurs sur un même écran !
● ...
23
Un bon réflexe
 Le besoin
● Recherches dans des meta-données
● Volume : jusqu’à plusieurs milliards de meta-données
● ...
24
Un bon réflexe
 Le risque
● L’équipe projet n’a pas d’expertise sur Elastic Search
● Comment s’assurer que le produit ...
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é...
26
Comment concilier un environnement agile
avec un environnement normatif ?
 Que demande la norme ?
● De la documentatio...
27
Une équipe hybride est plus efficace
 Le produit est la propriété de Docapost
 Les équipes de Docapost vont l’exploit...
28
Une équipe hybride est plus efficace
 Intégration d’un développeur de Docapost dans l’équipe
projet
 Tout en conserva...
29
Kit prêt à l’emploi généralisable
 Transfert de compétences
● En cours de définition
 Basé sur un biseau
 Concerne
●...
30
Implication des équipes de Docapost dans le
projet
 Prise en main du produit par l’équipe R&D de Docapost DPS
● Instal...
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...
33
Le pragmatisme plus important que la
méthode
 Des adaptations à la méthode ont été faites
● Format des user stories
● ...
34
Equipe
Scrum
35
Credits
36
Conclusions
 Les principaux objectifs ont été respectés
● Une application fonctionnelle
● En mars 2014
● Impossible av...
Prochain SlideShare
Chargement dans…5
×

Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit de Docapost DPS par Dominique Mera

1 019 vues

Publié le

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

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 019
Sur SlideShare
0
Issues des intégrations
0
Intégrations
9
Actions
Partages
0
Téléchargements
16
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit de Docapost DPS par Dominique Mera

  1. 1. Stratégie pour le projet de développement du nouveau produit de Docapost DPS Julien Lefebvre Dominique Méra
  2. 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. 3 VISEO BUSINESS TECHNOLOGIES = Novedia + Objet Direct 400 Spécialistes Agile, Java, Web, mobile Groupe VISEO : 1000 collaborateurs 100 m€ de CA
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20 Prédictibilité Confiance Sprints 3 à 6
  21. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31 Implication des équipes de Docapost dans le projet  Démonstrations internes à Docapost par le PO et la R&D DPS
  32. 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. 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. 34 Equipe Scrum
  35. 35. 35 Credits
  36. 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 !

×