Développement de Fonctionnalités en Parallèle

Stratégies pour décomposer les fonctionnalités en flux de travail parallèles, établir des limites de propriété des fichiers, éviter les conflits et intégrer les résultats de plusieurs agents implémenteurs.

Quand utiliser cette compétence

• Décomposer une fonctionnalité pour une implémentation parallèle
• Établir des limites de propriété des fichiers entre les agents
• Concevoir des contrats d'interface entre les flux de travail parallèles
• Choisir les stratégies d'intégration (vertical slice vs couche horizontale)
• Gérer les workflows de branche et fusion pour le développement parallèle

Stratégies de Propriété des Fichiers

Par Répertoire

Attribuer à chaque implémenteur la propriété de répertoires spécifiques :

implementer-1: src/components/auth/
implementer-2: src/api/auth/
implementer-3: tests/auth/

Meilleur pour : Les bases de code bien organisées avec des limites de répertoire claires.

Par Module

Attribuer la propriété de modules logiques (qui peuvent s'étendre sur plusieurs répertoires) :

implementer-1: Authentication module (login, register, logout)
implementer-2: Authorization module (roles, permissions, guards)

Meilleur pour : Les architectures orientées fonctionnalités, la conception orientée domaine.

Par Couche

Attribuer la propriété des couches architecturales :

implementer-1: UI layer (components, styles, layouts)
implementer-2: Business logic layer (services, validators)
implementer-3: Data layer (models, repositories, migrations)

Meilleur pour : Les architectures traditionnelles MVC/en couches.

Règles d'Évitement des Conflits

La Règle Cardinale

Un propriétaire par fichier. Aucun fichier ne doit être assigné à plusieurs implémenteurs.

Quand les Fichiers Doivent Être Partagés

Si un fichier a vraiment besoin de modifications de plusieurs implémenteurs :

1. Désigner un propriétaire unique — Un implémenteur possède le fichier
2. Les autres implémenteurs demandent des modifications — Envoyer un message au propriétaire avec des demandes de modification spécifiques
3. Le propriétaire applique les modifications séquentiellement — Prévient les conflits de fusion
4. Alternative : Extraire les interfaces — Créer un fichier d'interface séparé que le non-propriétaire peut importer sans modifier

Contrats d'Interface

Quand les implémenteurs doivent se coordonner aux limites :

// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)
export interface AuthResponse {
  token: string;
  user: UserProfile;
  expiresAt: number;
}

export interface AuthService {
  login(email: string, password: string): Promise<AuthResponse>;
  register(data: RegisterData): Promise<AuthResponse>;
}

Les deux implémenteurs importent depuis le fichier de contrat mais aucun ne le modifie.

Modèles d'Intégration

Vertical Slice

Chaque implémenteur construit une tranche de fonctionnalité complète (UI + API + tests) :

implementer-1: Login feature (login form + login API + login tests)
implementer-2: Register feature (register form + register API + register tests)

Avantages : Chaque tranche est testable indépendamment, intégration minimale requise. Inconvénients : Peut dupliquer les utilitaires partagés, plus difficile avec les fonctionnalités fortement couplées.

Couche Horizontale

Chaque implémenteur construit une couche sur toutes les fonctionnalités :

implementer-1: All UI components (login form, register form, profile page)
implementer-2: All API endpoints (login, register, profile)
implementer-3: All tests (unit, integration, e2e)

Avantages : Modèles cohérents dans chaque couche, spécialisation naturelle. Inconvénients : Plus de points d'intégration, la couche 3 dépend des couches 1 et 2.

Hybride

Mélanger vertical et horizontal en fonction du couplage :

implementer-1: Login feature (vertical slice — UI + API + tests)
implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)

Meilleur pour : La plupart des fonctionnalités réelles avec une infrastructure partagée.

Gestion des Branches

Stratégie de Branche Unique

Tous les implémenteurs travaillent sur la même branche de fonctionnalité :

• Configuration simple, pas de surcharge de fusion
• Nécessite une propriété stricte des fichiers pour éviter les conflits
• Meilleur pour : les petites équipes (2-3), les limites bien définies

Stratégie Multi-Branche

Chaque implémenteur travaille sur une sous-branche :

feature/auth
  ├── feature/auth-login      (implementer-1)
  ├── feature/auth-register    (implementer-2)
  └── feature/auth-tests       (implementer-3)

• Plus d'isolement, points de fusion explicites
• Surcharge plus élevée, les conflits de fusion sont toujours possibles dans les fichiers partagés
• Meilleur pour : les équipes plus grandes (4+), les fonctionnalités complexes

Dépannage

Les implémenteurs se bloquent mutuellement en attendant du code partagé. Extraire la partie partagée dans son propre fichier de contrat d'interface détenu par le responsable d'équipe et faire importer les implémenteurs depuis celui-ci. Aucun implémenteur ne modifie le contrat — ils l'implémentent simplement.

Des conflits de fusion apparaissent même avec des règles de propriété claires. Un fichier a été assigné à deux agents, ou un fichier de configuration/index (par exemple, index.ts, __init__.py) qui importe automatiquement tout a été modifié par les deux. Désigner un propriétaire unique pour tous les fichiers barrel/index, ou faire fusionner le responsable à la fin.

Un implémenteur termine tôt mais l'étape d'intégration est bloquée. Utiliser une interface intermédiaire : l'implémenteur terminé écrit un stub ou un mock de la dépendance en aval afin que l'autre implémenteur puisse continuer à travailler. Remplacer par l'implémentation réelle au moment de l'intégration.

La décomposition de la fonctionnalité s'est avérée mauvaise en cours de route. Arrêter les nouveaux travaux, faire redistribuer les fichiers par le responsable et communiquer le changement par diffusion. Le coût irrécupérable du code partiellement écrit est acceptable — continuer avec une division mauvaise est pire.

Les tests écrits par un implémenteur échouent contre le code écrit par un autre. Les contrats d'interface se sont écartés : l'implémenteur propriétaire de l'API a modifié une signature sans notifier l'implémenteur des tests. Appliquer la règle que les fichiers de contrat nécessitent une diffusion avant modification.

Compétences Connexes

• team-composition-patterns — Choisir la bonne taille d'équipe et les types d'agents avant de décomposer le travail
• team-communication-protocols — Coordonner les remises d'intégration et planifier les approbations entre implémenteurs