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 14:46] – [Principes XP] jcheroneadl:bloc3:xp:chap1 [2025/11/23 14:48] (Version actuelle) – [Principes XP] jcheron
Ligne 64: Ligne 64:
 **Pourquoi ?** Des développeurs épanouis = code de meilleure qualité. **Pourquoi ?** Des développeurs épanouis = code de meilleure qualité.
  
-|< 100% 10% - - 20% >|+|< 100% 10% 30% 30% - >|
 ^ **Aspect**               ^ **Définition**                                                                 ^ **Impact Concret**                                  ^ **Outils/Pratiques**                     ^ ^ **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é).       | | **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é).       |
Ligne 73: Ligne 73:
 **Pourquoi ?** Toute décision technique doit se justifier par sa **valeur business**. **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**                          ^ ^ **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**.          | | **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**.          |
Ligne 81: Ligne 82:
 **Pourquoi ?** Les pratiques XP doivent avantage **à la fois les devs et le business**. **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**                          ^ ^ **Pratique**          ^ **Bénéfice Devs**                          ^ **Bénéfice Business**               ^ **Exemple**                          ^
 | **TDD**              | Code plus simple à maintenir.              | ➔ -40% de bugs en production.       | - **JUnit** / **pytest**.             | | **TDD**              | Code plus simple à maintenir.              | ➔ -40% de bugs en production.       | - **JUnit** / **pytest**.             |
Ligne 89: Ligne 91:
 **Pourquoi ?** Réutiliser des solutions éprouvées, mais **adapter au contexte**. **Pourquoi ?** Réutiliser des solutions éprouvées, mais **adapter au contexte**.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Contexte**          ^ **Solution Réutilisable**                   ^ **Adaptation Nécessaire**                     ^ **Outil**                     ^ ^ **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)**. | | **Microservices**     | Pattern *Strangler Fig* pour découper un monolithe. | Vérifier la compatibilité avec le legacy.      | - **ADR (Architecture Decision Records)**. |
Ligne 97: Ligne 100:
 **Pourquoi ?** L'excellence vient de **petites améliorations continues**. **Pourquoi ?** L'excellence vient de **petites améliorations continues**.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Niveau**            ^ **Action**                                  ^ **Impact**                              ^ **Metric**                     ^ ^ **Niveau**            ^ **Action**                                  ^ **Impact**                              ^ **Metric**                     ^
 | **Code**             | +1% de couverture de tests par sprint.      | ➔ -15% de régressions.                | - **SonarQube**.                     | | **Code**             | +1% de couverture de tests par sprint.      | ➔ -15% de régressions.                | - **SonarQube**.                     |
Ligne 105: Ligne 109:
 **Pourquoi ?** Des équipes diversifiées = **meilleures solutions techniques**. **Pourquoi ?** Des équipes diversifiées = **meilleures solutions techniques**.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Type de Diversité** ^ **Exemple**                                  ^ **Bénéfice Technique**                     ^ **Pratique**                     ^ ^ **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**.      | | **Compétences**       | Backend + DevOps dans la même équipe.        | ➔ Solutions full-stack optimisées.       | - **Pair Programming rotatif**.      |
Ligne 113: Ligne 118:
 **Pourquoi ?** Apprendre de chaque action pour **s'améliorer**. **Pourquoi ?** Apprendre de chaque action pour **s'améliorer**.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Type**              ^ **Format**                                  ^ **Exemple**                              ^ **Outil**                     ^ ^ **Type**              ^ **Format**                                  ^ **Exemple**                              ^ **Outil**                     ^
 | **Rétrospective**     | Mad/Sad/Glad.                                | "Pourquoi ce bug a passé les tests ?"   | - **Retrium**.                     | | **Rétrospective**     | Mad/Sad/Glad.                                | "Pourquoi ce bug a passé les tests ?"   | - **Retrium**.                     |
Ligne 121: Ligne 127:
 **Pourquoi ?** Un flux de travail fluide = **livraisons plus rapides**. **Pourquoi ?** Un flux de travail fluide = **livraisons plus rapides**.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Obstacle**          ^ **Solution**                                ^ **Impact**                              ^ **Outil**                     ^ ^ **Obstacle**          ^ **Solution**                                ^ **Impact**                              ^ **Outil**                     ^
 | **Blocages**          | WIP Limits (max 2 tâches en cours).          | ➔ -50% de *context switching*.        | - **Kanban Board**.                  | | **Blocages**          | WIP Limits (max 2 tâches en cours).          | ➔ -50% de *context switching*.        | - **Kanban Board**.                  |
Ligne 129: Ligne 136:
 **Pourquoi ?** Transformer les problèmes en **opportunités d'apprentissage**. **Pourquoi ?** Transformer les problèmes en **opportunités d'apprentissage**.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Problème**          ^ **Opportunité**                             ^ **Action**                              ^ **Exemple**                     ^ ^ **Problème**          ^ **Opportunité**                             ^ **Action**                              ^ **Exemple**                     ^
 | **Bug Critique**      | Améliorer la suite de tests.               | Ajouter des tests E2E.                  | - **Cypress**.                     | | **Bug Critique**      | Améliorer la suite de tests.               | Ajouter des tests E2E.                  | - **Cypress**.                     |
Ligne 137: Ligne 145:
 **Pourquoi ?** Certaines redondances sont **utiles**, pas du *waste*. **Pourquoi ?** Certaines redondances sont **utiles**, pas du *waste*.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Type**              ^ **Exemple**                                ^ **Bénéfice**                          ^ **Outil**                     ^ ^ **Type**              ^ **Exemple**                                ^ **Bénéfice**                          ^ **Outil**                     ^
 | **Tests**            | Tests unitaires + intégration pour un module critique. | ➔ Couverture à 95%.               | - **Jest** / **Pytest**.               | | **Tests**            | Tests unitaires + intégration pour un module critique. | ➔ Couverture à 95%.               | - **Jest** / **Pytest**.               |
Ligne 145: Ligne 154:
 **Pourquoi ?** L'échec est une **source d'apprentissage**, pas une honte. **Pourquoi ?** L'échec est une **source d'apprentissage**, pas une honte.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Type d'Échec**      ^ **Leçon Apprise**                          ^ **Action Corrective**                  ^ **Outil**                     ^ ^ **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**.           | | **Déploiement Raté**  | Pipeline CI/CD trop lent.                  | Optimiser les étapes de build.         | - **GitHub Actions Cache**.           |
Ligne 153: Ligne 163:
 **Pourquoi ?** La qualité n'est **pas négociable** - c'est un multiplicateur. **Pourquoi ?** La qualité n'est **pas négociable** - c'est un multiplicateur.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Pratique**          ^ **Critère**                                ^ **Impact**                              ^ **Outil**                     ^ ^ **Pratique**          ^ **Critère**                                ^ **Impact**                              ^ **Outil**                     ^
 | **Clean Code**        | Fonctions <20 lignes, noms explicites.      | ➔ -40% de temps en reviews.           | - **ESLint** / **SonarQube**.          | | **Clean Code**        | Fonctions <20 lignes, noms explicites.      | ➔ -40% de temps en reviews.           | - **ESLint** / **SonarQube**.          |
Ligne 161: Ligne 172:
 **Pourquoi ?** Des petites étapes = **moins de risques**, plus de succès. **Pourquoi ?** Des petites étapes = **moins de risques**, plus de succès.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Contexte**          ^ **Action**                                ^ **Bénéfice**                          ^ **Exemple**                     ^ ^ **Contexte**          ^ **Action**                                ^ **Bénéfice**                          ^ **Exemple**                     ^
 | **Legacy Code**       | Ajouter des tests sur 1 module à la fois.   | ➔ Refactor sécurisé.                | - **Approach: Strangler Fig**.        | | **Legacy Code**       | Ajouter des tests sur 1 module à la fois.   | ➔ Refactor sécurisé.                | - **Approach: Strangler Fig**.        |
Ligne 169: Ligne 181:
 **Pourquoi ?** La responsabilité **se prend**, ne s'assigne pas. **Pourquoi ?** La responsabilité **se prend**, ne s'assigne pas.
  
 +|< 100% 10% 30% 30% - >|
 ^ **Pratique**          ^ **Responsabilité**                        ^ **Impact**                              ^ **Outil**                     ^ ^ **Pratique**          ^ **Responsabilité**                        ^ **Impact**                              ^ **Outil**                     ^
 | **TDD**              | Le dev écrit **aussi** les tests.           | ➔ Code testé à 100%.                | - **JUnit** / **pytest**.             | | **TDD**              | Le dev écrit **aussi** les tests.           | ➔ Code testé à 100%.                | - **JUnit** / **pytest**.             |
  • eadl/bloc3/xp/chap1.1763905617.txt.gz
  • Dernière modification : il y a 2 mois
  • de jcheron