eadl:bloc3:xp:chap1

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
eadl:bloc3:xp:chap1 [2025/11/23 12:28] – [Tableau des Principes XP] jcheroneadl:bloc3:xp:chap1 [2025/11/23 14:48] (Version actuelle) – [Principes XP] jcheron
Ligne 55: Ligne 55:
  
  
-===== Principes XP – Fondations pour les Pratiques Agiles =====+==== Principes XP ====
  
 Les **principes XP** servent de **pont entre les valeurs et les pratiques**. Ils expliquent **pourquoi** certaines pratiques (comme le TDD ou le pair programming) sont efficaces, et comment les adapter à différents contextes techniques. Les **principes XP** servent de **pont entre les valeurs et les pratiques**. Ils expliquent **pourquoi** certaines pratiques (comme le TDD ou le pair programming) sont efficaces, et comment les adapter à différents contextes techniques.
  
---- +---- 
-==== Tableau des Principes XP ====+ 
 +=== 1. Humanity === 
 +**Pourquoi ?** Des développeurs épanouis = code de meilleure qualité. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Aspect**               ^ **Définition**                                                                 ^ **Impact Concret**                                  ^ **Outils/Pratiques**                     ^ 
 +| **Sécurité psychologique** | Environnement où on ose poser des questions sans jugement.               | ➔ -30% de *knowledge loss* (turnover réduit).       | - **1:1s réguliers** (template structuré).       | 
 +| **Autonomie**            | Liberté de choisir comment résoudre un problème technique.               | ➔ +25% de productivité (moins de micro-management). | - **Objectifs SMART** (OKRs techniques).         | 
 +| **Reconnaissance**      | Visibilité des contributions techniques (ex : refactor, tests).         | ➔ +40% d'engagement (enquêtes internes).          | - **Kudos Slack** / **Bonus techniques**.        | 
 + 
 +=== 2. Economics === 
 +**Pourquoi ?** Toute décision technique doit se justifier par sa **valeur business**. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Critère**             ^ **Exemple Technique**                                                 ^ **Bénéfice Business**                          ^ **Outils**                          ^ 
 +| **Coût vs. Valeur**     | Migration vers Kubernetes : 3 sprints vs. gain de scalabilité.      | ➔ ROI calculé : économie de 20% sur les coûts cloud. | - **Business Case Template**.          | 
 +| **Dette Technique**     | Refactor d'un module legacy (5j) vs. risque de *firefighting*.       | ➔ Évite 10j de hotfixes/an.                   | - **SonarQube** (coût de la dette).     | 
 +| **Priorisation**        | Feature A (valeur client élevée) vs. Feature B (technically cool).   | ➔ Focus sur ce qui génère du revenue.         | - **User Story Mapping** (Miro).        | 
 + 
 +=== 3. Mutual Benefit === 
 +**Pourquoi ?** Les pratiques XP doivent avantage **à la fois les devs et le business**. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Pratique**          ^ **Bénéfice Devs**                          ^ **Bénéfice Business**               ^ **Exemple**                          ^ 
 +| **TDD**              | Code plus simple à maintenir.              | ➔ -40% de bugs en production.       | - **JUnit** / **pytest**.             | 
 +| **CI/CD**            | Feedback immédiat sur les changements.     | ➔ Livraisons 5x plus fréquentes.    | - **GitHub Actions**.                 | 
 +| **Clean Code**       | Onboarding des nouveaux plus rapide.       | ➔ -30% de temps passé en reviews.   | - **ESLint** / **Prettier**.         | 
 + 
 +=== 4. Self-Similarity === 
 +**Pourquoi ?** Réutiliser des solutions éprouvées, mais **adapter au contexte**. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Contexte**          ^ **Solution Réutilisable**                   ^ **Adaptation Nécessaire**                     ^ **Outil**                     ^ 
 +| **Microservices**     | Pattern *Strangler Fig* pour découper un monolithe. | Vérifier la compatibilité avec le legacy.      | - **ADR (Architecture Decision Records)**. | 
 +| **Tests**            | Structure *Given/When/Then* pour les tests.         | Adapter aux spécificités métiers.              | - **Cucumber** / **SpecFlow**.         | 
 +| **Code Reviews**     | Checklist standardisée.                          | Ajouter des critères projet-spécifiques.       | - **GitHub PR Templates**.            | 
 + 
 +=== 5. Improvement (Kaizen) === 
 +**Pourquoi ?** L'excellence vient de **petites améliorations continues**. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Niveau**            ^ **Action**                                  ^ **Impact**                              ^ **Metric**                     ^ 
 +| **Code**             | +1% de couverture de tests par sprint.      | ➔ -15% de régressions.                | - **SonarQube**.                     | 
 +| **Processus**        | Réduire le *lead time* de 10%.               | ➔ Livraisons plus prévisibles.        | - **DORA Metrics**.                   | 
 +| **Équipe**           | Rétrospective hebdomadaire.                 | ➔ +20% de satisfaction d'équipe.      | - **Officevibe**.                    | 
 + 
 +=== 6. Diversity === 
 +**Pourquoi ?** Des équipes diversifiées = **meilleures solutions techniques**. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Type de Diversité** ^ **Exemple**                                  ^ **Bénéfice Technique**                     ^ **Pratique**                     ^ 
 +| **Compétences**       | Backend + DevOps dans la même équipe.        | ➔ Solutions full-stack optimisées.       | - **Pair Programming rotatif**.      | 
 +| **Expérience**        | Juniors + Seniors sur un spike technique.    | ➔ Innovation + rigueur.                | - **Mentorat inverse**.              | 
 +| **Perspectives**      | Brainstorming avec des non-techniques.       | ➔ UX/UI plus réalistes.                | - **Workshops cross-fonctionnels**.   | 
 + 
 +=== 7. Reflection === 
 +**Pourquoi ?** Apprendre de chaque action pour **s'améliorer**. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Type**              ^ **Format**                                  ^ **Exemple**                              ^ **Outil**                     ^ 
 +| **Rétrospective**     | Mad/Sad/Glad.                                | "Pourquoi ce bug a passé les tests ?"   | - **Retrium**.                     | 
 +| **Postmortem**        | Blameless (sans culpabilité).                | Analyse d'un incident de prod.          | - **Google Docs Template**.         | 
 +| **Code Review**       | Feedback structuré.                         | "Pourquoi ce PR a pris 3 jours ?"       | - **GitHub PR Comments**.           | 
 + 
 +=== 8. Flow === 
 +**Pourquoi ?** Un flux de travail fluide = **livraisons plus rapides**. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Obstacle**          ^ **Solution**                                ^ **Impact**                              ^ **Outil**                     ^ 
 +| **Blocages**          | WIP Limits (max 2 tâches en cours).          | ➔ -50% de *context switching*.        | - **Kanban Board**.                  | 
 +| **Dépendances**       | User stories plus petites.                 | ➔ Livraisons incrémentales.            | - **Story Splitting Techniques**.     | 
 +| **Feedback Lent**     | CI/CD avec tests automatisés.               | ➔ Feedback en <10 min.                  | - **GitHub Actions**.                | 
 + 
 +=== 9. Opportunity === 
 +**Pourquoi ?** Transformer les problèmes en **opportunités d'apprentissage**. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Problème**          ^ **Opportunité**                             ^ **Action**                              ^ **Exemple**                     ^ 
 +| **Bug Critique**      | Améliorer la suite de tests.               | Ajouter des tests E2E.                  | - **Cypress**.                     | 
 +| **Dette Technique**   | Moderniser le code.                        | Spike pour évaluer les options.         | - **Tech Radar**.                   | 
 +| **Conflit d'équipe**  | Renforcer la collaboration.                | Atelier de team building technique.     | - **Mob Programming**.              | 
 + 
 +=== 10. Redundancy === 
 +**Pourquoi ?** Certaines redondances sont **utiles**, pas du *waste*. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Type**              ^ **Exemple**                                ^ **Bénéfice**                          ^ **Outil**                     ^ 
 +| **Tests**            | Tests unitaires + intégration pour un module critique. | ➔ Couverture à 95%.               | - **Jest** / **Pytest**.               | 
 +| **Documentation**    | README + docs dans le code + wiki.          | ➔ Onboarding en 1j vs 1 semaine.  | - **Markdown** / **Confluence**.       | 
 +| **Reviews**          | 2 approvers pour les PRs critiques.         | ➔ 0 bug en prod sur 6 mois.       | - **GitHub Protected Branches**.      | 
 + 
 +=== 11. Failure === 
 +**Pourquoi ?** L'échec est une **source d'apprentissage**, pas une honte. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Type d'Échec**      ^ **Leçon Apprise**                          ^ **Action Corrective**                  ^ **Outil**                     ^ 
 +| **Déploiement Raté**  | Pipeline CI/CD trop lent.                  | Optimiser les étapes de build.         | - **GitHub Actions Cache**.           | 
 +| **Bug en Prod**       | Tests E2E manquants.                       | Ajouter des tests de non-régression.   | - **Selenium**.                       | 
 +| **Estimation Fausse** | User story mal découpée.                   | Utiliser le *Story Splitting*.         | - **Planning Poker**.                 | 
 + 
 +=== 12. Quality === 
 +**Pourquoi ?** La qualité n'est **pas négociable** - c'est un multiplicateur. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Pratique**          ^ **Critère**                                ^ **Impact**                              ^ **Outil**                     ^ 
 +| **Clean Code**        | Fonctions <20 lignes, noms explicites.      | ➔ -40% de temps en reviews.           | - **ESLint** / **SonarQube**.          | 
 +| **TDD**              | 100% de couverture pour le code critique.   | ➔ 0 régression sur les features core. | - **JUnit** / **pytest**.             | 
 +| **Definition of Done**| Checklist stricte (tests, docs, reviews).   | ➔ Livraisons prévisibles.             | - **Jira DoD**.                       | 
 + 
 +=== 13. Baby Steps === 
 +**Pourquoi ?** Des petites étapes = **moins de risques**, plus de succès. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Contexte**          ^ **Action**                                ^ **Bénéfice**                          ^ **Exemple**                     ^ 
 +| **Legacy Code**       | Ajouter des tests sur 1 module à la fois.   | ➔ Refactor sécurisé.                | - **Approach: Strangler Fig**.        | 
 +| **Nouvelle Feature**  | Découper en sous-tâches <1j.               | ➔ Livraison en 3 sprints vs 1.      | - **User Story Splitting**.           | 
 +| **Apprentissage**     | Spike de 2h pour évaluer une techno.       | ➔ Décision éclairée.                | - **Timeboxed Research**.             | 
 + 
 +=== 14. Accepted Responsibility === 
 +**Pourquoi ?** La responsabilité **se prend**, ne s'assigne pas. 
 + 
 +|< 100% 10% 30% 30% - >| 
 +^ **Pratique**          ^ **Responsabilité**                        ^ **Impact**                              ^ **Outil**                     ^ 
 +| **TDD**              | Le dev écrit **aussi** les tests.           | ➔ Code testé à 100%.                | - **JUnit** / **pytest**.             | 
 +| **On-Call**          | Rotation volontaire.                       | ➔ Résolution plus rapide des incidents. | - **PagerDuty**.                     | 
 +| **Code Ownership**   | Un dev "possède" une feature de bout en bout. | ➔ Moins de *handovers* problématiques. | - **Feature Flags**.                 |
  
-^ **Principe**          ^ **Définition Technique**                                                                                     ^ **Applications Concrètes**                                                                                     ^ **Outils/Exemples**                          ^ 
-| **Humanity**          | **Bien-être et croissance des devs** :                                                                         | ➔ **Réduit le turnover** (équipes stables = moins de *knowledge loss*).                                      | - **1:1s réguliers** (feedback constructif).               | 
-| :::                   |- Sécurité psychologique (*psychological safety*) pour oser poser des questions.                              | ➔ **Améliore la collaboration** (moins de *silos*).                                                        | - **Retrospectives anonymes** (ex : Toolbox).              | 
-| :::                   |- Satisfaction via l’autonomie et l’impact visible du travail.                                                 | ➔ **Boost la productivité** (devs engagés = moins de *procrastination*).                                  | - **Tableaux de reconnaissance** (ex : kudos Slack).       | 
-| **Economics**         | **Alignement avec la valeur métier** :                                                                         | ➔ **Priorise les features à fort ROI** (évite le *waste*).                                                  | - **User Story Mapping** (ex : Miro).                      | 
-| :::                   |- Toute décision technique doit être évaluée en termes de **coût vs. valeur business**.                     | ➔ **Optimise les coûts d’infrastructure** (ex : serverless vs. bare metal).                                | - **Coût de la dette technique** (ex : SonarQube).         | 
-| :::                   |- Exemple : *"Ce refactor vaut-il 2 sprints si le gain métier est nul ?"*.                                    | ➔ **Justifie les investissements techniques** (ex : migration vers Kubernetes).                            | - **Business Case Templates**.                             | 
-| **Mutual Benefit**    | **Pratiques gagnant-gagnant** pour l’équipe **et** le business :                                              | ➔ **Code plus maintenable** = moins de *firefighting*.                                                      | - **TDD** (JUnit, pytest).                                  | 
-| :::                   |- Exemples :                                                                                                   | ➔ **Livraisons plus fréquentes** = feedback client plus rapide.                                            | - **CI/CD** (GitHub Actions, GitLab CI).                   | 
-| :::                   |- *Tests automatisés* : gain temps pour les devs **et** qualité pour le client.                             | ➔ **Réduction des bugs en prod** = moins de *hotfixes*.                                                   | - **Clean Code** (ESLint, Prettier).                       | 
-| :::                   |- *Code simple et lisible* : maintenabilité **et** onboarding facilité.                                      |                                                                                                             |                                                             | 
-| **Self-similarity**   | **Réutilisation des solutions** avec adaptation contextuelle :                                                 | ➔ **Accélère le développement** (moins de *reinventing the wheel*).                                         |- **Design Patterns** (ex : Strategy, Adapter).             | 
-| :::                   |- Un pattern qui marche dans un micro-service peut inspirer une solution dans un autre.                       | ➔ **Standardise les bonnes pratiques** (ex : conventions de nommage).                                       |- **Architecture Decision Records** (ADR).                 | 
-| :::                   |- **Mais** : chaque contexte est unique (ex : *legacy code* vs. *greenfield*).                                | ➔ **Évite les *cargo cults*** (copier-coller sans comprendre).                                             |- **Spikes techniques** pour valider l’adéquation.         | 
-| **Improvement**       | **Amélioration continue** (kaizen) via des itérations courtes :                                               | ➔ **Qualité incrémentale** (ex : couverture de tests +1% par sprint).                                       |- **TDD** (red-green-refactor).                             | 
-| :::                   |- Pas de perfectionnisme, mais des **petites améliorations régulières**.                                       | ➔ **Processus optimisés** (ex : réduction du *lead time*).                                                 |- **Rétrospectives** (Mad/Sad/Glad).                        | 
-| :::                   |- Exemple : refactoring de 10% du code à chaque PR.                                                           | ➔ **Culture d’apprentissage** (ex : *blameless postmortems*).                                             |- **Metrics DevOps** (DORA).                                | 
-| **Diversity**         | **Hétérogénéité des profils** comme force :                                                                  | ➔ **Solutions plus innovantes** (ex : approche *junior* vs. *senior*).                                      |- **Pair Programming** (rotatif).                          | 
-| :::                   |- Compétences complémentaires (ex : *backend* + *DevOps*).                                                   | ➔ **Moins de *groupthink*** (biais de conformité).                                                          |- **Workshops cross-fonctionnels**.                        | 
-| :::                   |- Respect des opinions divergentes (ex : *"Pourquoi pas Serverless ?"*).                                      | ➔ **Meilleure résolution de problèmes** (ex : *brainstorming technique*).                                   |- **Tools collaboratifs** (Miro, Mural).                    | 
-| **Reflection**        | **Analyse post-action** pour capitaliser sur les expériences :                                                 | ➔ **Évite de répéter les mêmes erreurs** (ex : *post-incident reviews*).                                    |- **Rétrospectives** (Start/Stop/Continue).                 | 
-| :::                   |- Exemples :                                                                                                   | ➔ **Améliore les processus** (ex : ajustement des *DoD*).                                                  | - **Journaux techniques** (ex : Notion, Confluence).         | 
-| :::                   |- *Rétrospectives* : "Pourquoi ce bug a-t-il passé les tests ?".                                            | ➔ **Renforce la résilience d’équipe**.                                                                       |- **Metrics de qualité** (ex : Sentry pour les erreurs).    | 
-| :::                   |- *Code reviews* : "Pourquoi ce PR a pris 3 jours ?".                                                       |                                                                                                             |                                                             | 
-| **Flow**             | **Fluidité du travail** pour minimiser les interruptions :                                                   | ➔ **Réduit le *cycle time*** (ex : de l’idée à la prod).                                                    |- **Kanban** (Jira, Trello).                                | 
-| :::                   |- Exemples :                                                                                                   | ➔ **Limite le *multitasking*** (moins de *context switching*).                                              |- **WIP Limits**.                                           | 
-| :::                   |- *Intégration continue* : feedback en minutes.                                                             | ➔ **Livraisons plus prévisibles**.                                                                          |- **CI/CD pipelines**.                                      | 
-| :::                   |- *Petites user stories* : évite les blocages longs.                                                        |                                                                                                             |                                                             | 
-| **Opportunity**      | **Transformer les problèmes en leviers** :                                                                   | ➔ **Innovation technique** (ex : migration vers un nouveau langage).                                        |- **Spikes d’exploration**.                                 | 
-| :::                   |- Exemples :                                                                                                   | ➔ **Amélioration des compétences** (ex : formation sur un nouveau tool).                                    |- **Hackathons internes**.                                  | 
-| :::                   |- Un *bug critique* → opportunité pour améliorer les tests.                                                 | ➔ **Renforce la cohésion d’équipe** (résolution collaborative).                                            |- **Blameless Postmortems**.                                | 
-| :::                   |- Une *dette technique* → occasion de refactor.                                                             |                                                                                                             |                                                             | 
-| **Redundancy**       | **Duplication utile** (vs. *waste*) :                                                                         | ➔ **Résilience du système** (ex : réplicas de bases de données).                                            |- **Backup automatiques**.                                   | 
-| :::                   |- Exemples :                                                                                                   | ➔ **Sécurité** (ex : double vérification des PRs).                                                          |- **Linters/Formatters** (redondance des checks).          | 
-| :::                   |- *Tests redondants* : couverture multi-niveaux (unitaires + intégration).                                  | ➔ **Onboarding facilité** (ex : docs répétées dans plusieurs formats).                                      |- **Documentation as Code** (ex : Markdown + CI).           | 
-| :::                   |- *Pair programming* : 2 paires d’yeux sur le même code.                                                   |                                                                                                             |                                                             | 
-| **Failure**          | **Apprentissage via l’échec** :                                                                               | ➔ **Culture de l’expérimentation** (ex : *feature flags* pour tester en prod).                              |- **Feature Toggles** (LaunchDarkly).                       | 
-| :::                   |- Exemples :                                                                                                   | ➔ **Solutions plus robustes** (ex : *chaos engineering*).                                                  |- **Chaos Monkey** (Netflix).                               | 
-| :::                   |- Un *déploiement raté* → amélioration du pipeline CI/CD.                                                   | ➔ **Équipe plus résiliente** (moins de peur de l’échec).                                                   |- **Postmortem Templates**.                                 | 
-| :::                   |- Un *bug en prod* → renforcement des tests E2E.                                                           |                                                                                                             |                                                             | 
-| **Quality**          | **Non-négociable** : la qualité est un **multiplicateur de productivité**.                                   | ➔ **Moins de *technical debt*** (ex : code propre = moins de *firefighting*).                                |- **SonarQube** (qualité de code).                          | 
-| :::                   |- Exemples :                                                                                                   | ➔ **Meilleure vélocité à long terme** (moins de régressions).                                              |- **TDD/BDD**.                                              | 
-| :::                   |- *Clean Code* : noms de variables explicites, fonctions courtes.                                           | ➔ **Fierté du travail** (motivation accrue).                                                               |- **Code Reviews strictes**.                                | 
-| :::                   |- *Tests automatisés* : 100% de couverture pour le code critique.                                          |                                                                                                             |                                                             | 
-| **Baby Steps**       | **Petites itérations** pour éviter les erreurs coûteuses :                                                    | ➔ **Réduit les risques** (ex : *big bang refactor* → *incremental changes*).                                  |- **TDD** (petits tests → petit code).                      | 
-| :::                   |- Exemples :                                                                                                   | ➔ **Livraisons plus fréquentes** (ex : *trunk-based development*).                                          |- **Feature Branches courtes**.                             | 
-| :::                   |- *Test-First Programming* : écrire un test avant le code.                                                 | ➔ **Feedback immédiat** (ex : *red-green-refactor*).                                                        |- **Git hooks** (pre-commit tests).                         | 
-| :::                   |- *Petites PRs* : max 200 lignes de code.                                                                   |                                                                                                             |                                                             | 
-| **Accepted Responsibility** | **Responsabilité active** (vs. assignée) :                                                                    | ➔ **Ownership accru** (ex : un dev *possède* une feature de bout en bout).                                  |- **User Story Assignment** (volontariat).                  | 
-| :::                   |- Exemples :                                                                                                   | ➔ **Qualité accrue** (ex : *"Si je code la feature, je teste aussi ses edge cases"*).                        | - **Definition of Done (DoD) stricte**.                      | 
-| :::                   |- *TDD* : le dev qui écrit le code écrit aussi les tests.                                                   | ➔ **Moins de *handovers* problématiques**.                                                                 |- **Pair Programming** (responsabilité partagée).          | 
-| :::                   |- *On-call* : rotation volontaire pour la prod.                                                             |                                                                                                             |                                                             | 
  • eadl/bloc3/xp/chap1.1763897333.txt.gz
  • Dernière modification : il y a 2 mois
  • de jcheron