REX Transformation Digitale Systèmes d'Informations

Support de la présentation effectuée au Transformer Day, organisée par SII le 4 Avril 2019.
Retour d'expériences de 10 axes à explorer pour réussir sa transformation digitale

Transcript

1. URBANISATION : COMMENT RENDRE SON SI DURABLE, AGILE ET ETENDU Fabien GRELLIER
2. Fabien Grellier Responsable Informatique Numérique 2016-2019 CTO PagesJaunes.fr
 2005 - 2016 @FabGrellier Fabien.grellier@gmail.com linkedin.com/in/fabiengrellier #TransformationDigitale #Agilité #DevOps
3. Les limites de l’artisanat
4. L’enjeu du DSI Comment passer à l’échelle tout en maintenant sa qualité de service et sa vélocité ?
5. Industrialisation Documentation Organisation Architecture Vision Management Pilotage Opérations Budget Delivery Recette
6. Vision « Il n’y a pas de bon vent pour celui qui ne sait où il va. » 
 -- Sénèque, philosophe Romain, 4 av JC - 65
7. Architecture « Les organisations qui définissent des systèmes sont contraintes de les produire sous des designs qui sont des copies de la structure de communication de leur organisation. » 
 -- Loi de Melvin Conway, 1968
8. Monolithe ou Micro-Services ?
9. MARTIN FOWLER -- https://martinfowler.com/bliki/MonolithFirst.html MICRO-SERVICES AND MONOLITH 1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up 2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile
10. Quelques pièges à éviter… • Avoir une granularité trop fine
 • Mettre en place des couplages et des dépendances entre API
 • Ne pas prendre en compte l’organisation associée ( Loi de Conway inversée )
 • Avoir une approche purement technique ( ne pas s’aligner avec les processus métiers )
11. Ce qu’on cherche à éviter … Equipe Equipe Equipe API
12. 5
 Organisation Organisation « La raison d'être d'une organisation est de permettre à des gens ordinaires de faire des choses extraordinaires. » — Peter Drucker Artiste, écrivain, Enseignant (1909 - 2005)
13. Les enjeux • Être le reflet de l’architecture du SI ( Loi de Conway inversée )
 
 • S’adapter aux priorités qui changent
 
 • Pérenniser le lien Managérial
 
 • Favoriser la stabilité des équipes
14. Mise en place de Features Teams Qualité
 Recette Infrastructure
 Opérations Team F Conception
 Fonctionnelle Pilotage Team B Team C Team D Team E Architecture
 Développement Team A
15. Il existe différents modèles d’équipe Agile Feature Team Product Team Component Team Team Team Team Métier 1 Métier 2 Production Release Train Team Métier Team Métier Team Métier Production Team Métier Team Métier Team Métier Production Production Production
16. Fonctionnement d’une Product Team • L’équipe gère le Build ET le run sur son périmètre ➡ Maintenance / Exploitation ➡ Petites évolutions fonctionnelles ➡ Modernisation technique ➡ Projets
 • Difficulté : comment prioriser des natures de travaux différentes ? Maintenance corrective / Exploitation 10% Maintenance évolutive 20% Modernisation Technique 20% Projets 50% Définir des capacités à faire par nature d’activité, et ré-évaluer les taux à fréquence régulière
17. Budget
18. Capacité lissée Délai de staffing Effectifs en mode projet La gestion des effectifs est différente selon un fonctionnement par projet ou par capacité Sur-effectifs Sous- effectifs Capacité lissée Effectifs en mode capacitaire
19. Passer d’un budget projet à un budget capacitaire … et prioriser les projets selon la valeur apportée Projet 2 Proje t 1 Projet 4 Proj et5 Projet8 Proj et6 Proje Adapter la capacité à faire selon l a c a p a c i t é b u d g é t a i r e prévisionnelle Capacité à faire Prioriser les projets
20. 20 3
 Delivery Delivery « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. » — 1er principe du Manifeste Agile
21. Les enjeux • Mettre fréquemment en production, en assurant la continuité de service et sans impact de qualité sur l’utilisateur final
 
 
 
 • Disposer d’un processus de déploiement fiable, robuste et reproductible sur n’importe quel environnement
22. Usine de déploiement API API API Tests Systèmes US Besoin US-21-18 US-21-18 US-21-18 US-21-18 Master Master Master Master Transverse 
 Merge Team A Team B
23. Usine de déploiement API API API Tests Systèmes Master Master Master Master Transverse 
 Merge Team A Team B US 2 Besoin 2 Transverse
 Merge
24. Intégration Intégration Usine de déploiement US A US C Production API Tests API API Merge OK Staging API Tests API API Intégration US B
25. Rétrospective • L’objectif était que les PO puissent valider la version avant qu’elle parte…
 • Ca a bien fonctionné au début
 • Mais progressivement, la machine s’est enrayée ➡ 1 mois sans faire de MEP ➡ Accumulation des branches ➡ Chaque équipe est bloquée par les autres ➡ La cause : un delivery en Monolithe basé sur des microservices
26. Passage au Continuous Delivery Pipeline API 1 Integration Staging Prod API 2 Integration Staging Prod API 3 Integration Staging Prod API 4 Integration Staging Prod
27. Recette « Un logiciel qui fonctionne plus qu’une documentation exhaustive » — 2ème valeur du Manifeste Agile
28. Quelques pièges à éviter… • Ne pas tenir compte de l’architecture, de l’organisation, du delivery
 • Trop automatiser • Vouloir être exhaustif
 • « La recette, c’est le problème des testeurs … »
29. 7
 Référentiel 
 Fonctionnel Documentation « Un logiciel qui fonctionne plus qu’une documentation exhaustive » — 2ème valeur du Manifeste Agile
30. De la doc … pour quoi faire ? • Disposer d’un référentiel de communication commun sur les règles implémentées dans le SI
 • Former de nouveaux arrivants
 • Ne pas tout ré-inventer en cas d’évolution
 • Communiquer vers les utilisateurs / clients ( Support client, … )
 • Factualiser la qualité ( lien avec la recette )
31. Plusieurs options … User Stories 
 + Tests d’acceptance A User Stories + Tests d’acceptance + Exigences + Tests Systèmes B User Stories + Behaviour Driven Development
 exécutable C
32. Quelques pièges à éviter… • Ne pas se faire accompagner
 • Tout documenter ➡ Ex : BDD ou Exigences par composants
 • Ne pas impliquer les métiers ( Proxy product Owner … )
 • Relier les exigences au Delivery
33. « You build it, You run it » — Werner Vogels, CTO d’Amazon Opérations
34. L’objectif • Chaque Product Team développe, déploie et gère le run sur ses produits ➡ Packaging et déploiement ➡ Plans de supervision ➡ Définition et suivi de métriques ➡ Suivi de production ➡ Gestion d’environnements ( idéalement, Infrastructure As Code )
35. Oui, Mais …
36. … Qui gère les astreintes ? Forces Faiblesses Equipe support N2 centralisée Chaque équipe gère ses astreintes • Mutualisation des couts des astreintes • Professionnalisation des opérations et du suivi de production • Permet l’externalisation ou la sous- traitance • Formalisation des procédures • L’OPS est dans l’équipe • Une équipe alignée et responsabilisée sur toute la chaine de production • Vélocité, réactivité • Sous-traitance Difficile • Moins de procédures, plus de risques d’erreurs en production • Coût des astreintes important • Nécessite une polyvalence de l’équipe • Recrutement • Quid du support niveau 3 ? • L’équipe n’est plus responsable de bout en bout • Conflits entre Dev et Ops
37. 37 8
 Pilotage Pilotage
 
 S’engager et tenir les délais “C'est le pilote qui voit loin qui ne fera pas chavirer son bateau.” — Aménémopé, scribe égyptien, -700 “L’adaptation au changement plus que le suivi d’un plan” — 4ème valeur du Manifeste Agile
38. Pilotage des équipes • Chaque équipe est responsable de la fourniture et du suivi d’indicateurs : ➡ Ambiance ➡ Vélocité ➡ Stock de User-Stories ➡ Taux de maintenance ➡ Nombre d’anomalies créées par semaine ➡ Stock d’anomalies à traiter ➡ Lead Time
39. Construction du planning • Objectif : vérifier l’adéquation entre Moyens / Périmètre / Délai
 • Découpage du périmètre en Storymap, puis en Feature / User Stories
 • Macro-Estimation de chaque US en JH par les PPO ➡ Ne pas sombrer dans le chiffrage détaillé
 • Construction du planning à partir : ‣ des charges ‣ des capacités à faire
40. Objectif : La route du Rhum • Délai max 4 Octobre !
 • Contribution de chaque équipe ➡ Identification des travaux ➡ Estimations
 • Planification par projection de vélocité vs objectif
 • Suivi transverse hebdomadaire
41. Exemple de burnup de suivi Jalon 5 - 31 Aout Jalon 7 - 23 Novembre
42. 42 En Agile, on ne s’engage pas sur un délai
43. 6
 Managemen t Management “Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés.” — 5ème principe du Manifeste Agile
44. Quelques bonnes pratiques • Ne pas grossir trop vite
 • Accompagner les équipes
 • Définir ( avec eux ! ) des objectifs collectifs
 • Favoriser l’autonomie … mais définir le cadre ! ➡ Pilotage transverse ➡ Technologies
 • Impliquer les équipes au plus tôt dans le processus de fabrication
45. 45 Bilan
46. Savez –vous comment on mange un éléphant ?
47. Une bouchée à la fois !
48. L’enjeu du DSI Comment passer à l’échelle tout en maintenant sa qualité de service et sa vélocité ?
49. En travaillant sur les 10 axes en cohérence, dans le bon ordre … Management – Accompagnement Définition du Processus 1. Vision 2. Architecture, Organisation & Budget 3. Delivery 4. Recette & Documentation 5. Opérations et Outils 6. Pilotage Boucle d’apprentissage / Itérations
50. … et par morceaux ! Monolithe 1. 2. 3.
51. Merci de votre attention ! @FabGrellier fabien.grellier@gmail.com