---
# System prepended metadata

title: Réorganisation de l’amélioration continue

---

Roadmap
-
- L'AC vient de la technique et remonte à la direction
- Choisir un ProductOwner-StackTechnique
- Prendre conseil auprès 
    - Florian
        - Done: Il faut désigner un ProductOwner de la stack technique, qui sera chargé de défendre les intérêts de l'amélioration technique toutes les semaines devant les PO/CP. Considérer la StackTechnique comme un produit, et les devs comme ces utilisateurs, et le métier comme des clients. Exprimer les risques et bénéfices de mener ou non les sujets d'AC. But concrêt: backlog métier et AC sont mis sur un pied d'égalité.
    - Clémence
        - Rdv gitlab-ci ce soir 17h
    - Quentin
    - Edith
# Réorganisation de l’amélioration continue
La cible est de légitimer l'amélioration continue au sein de la DSI

Le problème actuel
- 
- **Personne ne défend officiellement l'AC**
- Fatalisme des équipes techniques: leurs propositions sont toujours dépriorisées
    - l'AC est passée "sous le manteau"
    - Renforce la défiance équipe technique VS management
- la rédaction de ticket d'AC est rare 
    - car leur planification est rare
- la valorisation des AC n'est jamais faites
    - la modélisation des risques à *ne pas améliorer* n'est pas calculée
- Ne pas faire d'AC
    - démotive les tech
    - freine le recrutement
        - *"Bienvenue, vous allez travailler sur des projets java 1.7 avec des frameworks de plus de 10 ans qui ne sont plus maintenus"*

Les éléments de solution
-
- l'AC **passionne** les équipes techniques:
    - challenge intellectuel supérieur
    - alimente constament les conversations entre technicien
    - génère même des travaux personnels !
- Scrum 
    - Respecter 20% de story point en amélioration continue
    - Légitimer l'AC grace à des rôles de ProductOwner-StackTechnique (PO-ST)
        - ils DOIVENT défendre les tickets d'AC devant les PO/CP
    - Prévoir/Défendre 1 sprint d'AC sur N sprint ?
- Comment valoriser
    - Rédiger des tickets de **POC courts** permettant un **gain rapide** pour démontrer l'intérêt
        - puis s'attaquer à des sujets longs si/quand la pratique est acquise
    - puis gains exponentiels:
        - économie de temps homme
            - simplification du code
            - simplification de la maintenance
            - simplification de l'ajout de fonctionnalité
        - économie d'infra
            - facture d'hébergement réduisible !
            - recul du risque de saturation
    - trouver des success stories (Début de google)
    - trouver des failures stories (Crash temps fort ?)
    - les tickets de réalisation d'AC doivent être précédés d'un POC.
    - Avec ce POC on vérifie et on s'engage sur le gain
