| 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:26] – [Tableau des Principes XP] jcheron | eadl:bloc3:xp:chap1 [2025/11/23 14:48] (Version actuelle) – [Principes XP] jcheron |
|---|
| |
| |
| ===== 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. | | | | |
jcheron