Différences

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

--- eadl:bloc3:xp:chap1 [2025/11/23 02:38] – [Introduction] jcheron
+++ eadl:bloc3:xp:chap1 [2025/11/23 14:48] (Version actuelle) – [Principes XP] jcheron
@@ Ligne 24: / Ligne 24: @@
   * La maturité technique (legacy code vs. greenfield).
-{{tag>XP Agile DevOps TDD CleanCode}}
+<label type="success">XP</label>  <label type="success" icon="fa fa-user">Agile</label>  <label type="success">DevOps</label>  <label type="success">TDD</label>  <label type="success">Clean code</label>
-<label type="success" icon="user">XP</label>  <label type="success" icon="fas fa-user">XP</label>  <label type="success" icon="user">XP</label>  <label type="success" icon="user">XP</label>
 ==== Valeurs XP ====
@@ Ligne 54: / Ligne 53: @@
 | :::               | - *Code reviews* : **Focus sur l’amélioration**, pas la critique.                                           | ➔ **Environnement *psychologically safe***.
 | :::               | - *Retros actionables* : **Écoute active** des feedbacks.                                                   |
+==== 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.
+----
+=== 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**.                 |