Compétence clé : projets full stack pratiques
Maîtrisez l’ensemble du processus, des besoins à la livraison, comprenez la méthodologie du développement piloté par les spécifications, apprenez la décomposition WBS et la définition du DoD, et acquérez des compétences de gestion de projet et de contrôle qualité de niveau entreprise.
Méthodologie de clarification des besoins
La clarification des exigences est le fondement de la réussite d’un projet. Grâce à une approche systématique, assurez-vous de comprendre les besoins réels et d’éviter les retouches et les malentendus.
Technique d’entretien inversé
Le Reverse Interview est une technique de questionnement active qui permet de faire émerger les besoins réels en demandant « pourquoi » :
Demandez « pourquoi » plutôt que « quoi »
Mauvaise façon de poser une question：« De quelles fonctionnalités avez-vous besoin ? »
Comment poser la bonne question: « Pourquoi avez-vous besoin de cette fonctionnalité ? Quel problème résout-elle ? »
En posant la question « pourquoi », comprenez les véritables motivations et les objectifs commerciaux derrière le besoin.
Demandez « quand » et « qui »
- • Cas d’utilisation：« Quand utilisera-t-on cette fonctionnalité ? À quelle fréquence ? »
- • Utilisateurs cibles: « Qui utilisera cette fonctionnalité ? Quel est leur niveau technique ? »
- • Environnement d’utilisation : « Dans quel environnement l’utiliser ? Quelles sont les limites ? »
Demander « et si... ? »
- • Cas limites: « Que se passerait-il si cette fonctionnalité n’existait pas ? »
- • Gestion des exceptions：「Que se passe-t-il si les données sont anormales ?"
- • Évolutivité：« Que se passe-t-il si les exigences changent ? »
Rédaction d’histoires utilisateur
Une user story est l’unité minimale d’une exigence et comprend trois éléments : rôle, objectif et valeur :
Modèle de user story :
Je veux [objectif],
Afin de [valeur/raison].
Caractéristiques d’une bonne user story
- • Indépendance：peut être développé et testé de manière autonome
- • Négociable: Peut être discuté et ajusté
- • Utile: Apporte une valeur réelle aux utilisateurs
- • Estimable: Peut estimer le temps de développement
- • Petit: peut être terminé en une itération
- • Testable : Il existe des critères d’acceptation clairs
Critères d’acceptation
Chaque user story doit avoir des critères d’acceptation clairs, en utilisant le format Given-When-Then :
When: lorsque l’utilisateur clique sur le bouton « Créer une tâche »
Then : afficher le formulaire de création de tâche
And: L’utilisateur peut saisir un titre et une description de tâche
And : les utilisateurs peuvent enregistrer des tâches
Hiérarchisation des exigences
Méthode MoSCoW
- • Must have: indispensable, une fonctionnalité clé pour la réussite du projet
- • Should have: Devrait exister ; important mais pas essentiel
- • Could have: Cela peut exister ; à faire si le temps le permet
- • Won't have: Si nous ne le faisons pas cette fois, il est possible que nous le fassions plus tard
Matrice valeur-complexité
En fonction de la valeur et de la complexité des fonctionnalités, privilégier le développement des fonctionnalités à forte valeur et faible complexité.
Cas pratique : clarification des besoins pour une plateforme e-commerce
Exigences initiales
« Nous avons besoin d’une fonctionnalité de panier d’achat »
Processus d’entretien inversé
- Q : "Pourquoi faut-il un panier d’achat ?" A : "Les utilisateurs doivent pouvoir sélectionner plusieurs produits en même temps"
- Q : "Quand l’utiliser ?" A : "Lorsque vous parcourez les produits, ajoutez au panier ceux qui vous plaisent"
- Q : « Qui l’utilisera ? » R : « Tous les utilisateurs enregistrés »
- Q : "Que se passe-t-il si l’utilisateur n’est pas connecté ?" R : "Il peut ajouter des articles au panier, mais il doit se connecter au moment du paiement"
Exigences clarifiées
- • Les utilisateurs peuvent ajouter des produits au panier (connectés/non connectés)
- • Les utilisateurs peuvent consulter les articles dans le panier
- • Les utilisateurs peuvent modifier la quantité des produits
- • Les utilisateurs peuvent supprimer des produits
- • Le panier des utilisateurs non connectés est stocké dans le stockage local
- • Fusionner le panier local et le panier serveur après connexion
Développement piloté par les spécifications
Le développement piloté par les Spec transforme les besoins en spécifications exécutables, et l'IA peut générer directement du code à partir de la Spec, améliorant ainsi l'efficacité du développement et la qualité du code.
Rédaction du PRD
Structure du PRD
- • Présentation du produit: Positionnement du produit, utilisateurs cibles, valeur fondamentale
- • Exigences fonctionnelles: Descriptions détaillées des fonctionnalités et user stories
- • Exigences non fonctionnelles : performances, disponibilité, sécurité, évolutivité
- • Interface utilisateur: Conception d’interface et flux d’interaction
- • Modèle de données: Structures de données et relations
- • Critères d’acceptation：Recette fonctionnelle, recette de performance, recette de sécurité
Principes de rédaction du PRD
- • Clair et explicite : utilisez un langage clair et évitez l’ambiguïté
- • Exécutable：L’IA peut générer directement du code à partir du PRD
- • Testable: chaque exigence a des critères d’acceptation clairs
- • Traçable : les exigences peuvent être rattachées aux objectifs commerciaux
Spécification API (OpenAPI)
Avantages de la spécification OpenAPI
- • Standardisation: Norme industrielle avec une prise en charge logicielle complète
- • Exécutable：L’IA peut générer directement du code à partir d’OpenAPI
- • Testable: Peut générer automatiquement des cas de test API
- • Documentable：Génération automatique de la documentation API
Exemple de spécification API
openapi: 3.0.0
info:
title: Task Management API
version: 1.0.0
paths:
/api/tasks:
get:
summary: Obtenir la liste des tâches
parameters:
- name: status
in: query
schema:
type: string
enum: [pending, in-progress, completed]
responses:
'200':
description: Succès
content:
application/json:
schema:
type: object
properties:
tasks:
type: array
items:
$ref: '#/components/schemas/Task'
post:
summary: Créer une tâche
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateTaskRequest'
responses:
'201':
description: Création réussie
components:
schemas:
Task:
type: object
properties:
id:
type: string
title:
type: string
status:
type: string
enum: [pending, in-progress, completed]UI Spec
Contenu de la UI Spec
- • Mise en page: structure de la page, emplacement des composants
- • Conception de composants: types de composants, styles, interactions
- • Flux d'interaction: flux des opérations utilisateur, changements d’état
- • Conception responsive：Adaptation à différentes tailles d’écran
Astuces pour rédiger des UI Specs
- • Utiliser Figma ou des outils similaires pour concevoir les interfaces
- • Décrire en détail l’état et les interactions de chaque composant
- • Utiliser des outils d’IA (comme v0) pour générer du code à partir de descriptions
- • Fournir des systèmes de design et des bibliothèques de composants
Cas pratique : flux complet du PRD au code
Étape 1 : Rédiger le PRD
Définir les objectifs du produit, les exigences fonctionnelles et les exigences non fonctionnelles
Étape 2 : Rédiger la spécification de l’API
Utilisez la spécification OpenAPI pour définir les interfaces API, et l’IA peut générer le code API à partir de la Spec
Étape 3 : rédiger la spécification UI
Décrivez en détail la conception de l’interface et utilisez des outils comme v0 pour générer le code UI
Étape 4 : utiliser Cursor pour générer du code
Fournissez le PRD, l’API Spec et le UI Spec à Cursor Agent pour générer le code complet
Étape 5 : tests et optimisation
Rédigez des cas de test basés sur la Spec afin de vérifier si la fonctionnalité répond aux exigences de la Spec
Décomposition WBS
La WBS (Work Breakdown Structure) décompose les grandes tâches en petites tâches exécutables, clarifie les dépendances entre les tâches et facilite la gestion de projet ainsi que le suivi de l’avancement.
Principes de décomposition des tâches
Contrôle de la granularité
- • Règle des 2 à 4 heures: chaque tâche doit être terminée en 2 à 4 heures
- • Testabilité: chaque tâche a des critères d’acceptation clairs
- • Indépendance: Réduire autant que possible les dépendances entre les tâches
- • Estimable : peut estimer avec précision le temps d’achèvement
Dépendances
- • Identifier les dépendances：Clarifier les dépendances entre les tâches
- • Chemin critique: Identifier le chemin critique du projet et le terminer en priorité
- • Tâches parallèles : identifier les tâches pouvant être exécutées en parallèle
- • Gestion des dépendances: utiliser des outils (comme GitHub Projects) pour gérer les dépendances
Estimation du temps
Estimation en trois points
Formule d’estimation :(temps optimiste + 4×temps le plus probable + temps pessimiste) / 6
Exemple : optimiste 2 heures, très probable 4 heures, pessimiste 8 heures → estimation = (2 + 4×4 + 8) / 6 = 4,3 heures
Estimation par analogie
Référez-vous au temps d’achèvement de tâches similaires et ajustez en fonction de la complexité de la tâche actuelle.
Estimation assistée par l’IA
Utiliser des outils d’IA pour analyser la complexité des tâches et combiner les données historiques afin d’estimer le temps.
Répartition des ressources
Répartition du personnel
- • Répartir les tâches en fonction des compétences et de l’expérience
- • Tenir compte de la charge de travail des personnes
- • Veiller à disposer de personnel de secours pour les tâches critiques
Attribution des outils
- • S’assurer de disposer de suffisamment d’outils et de ressources de développement
- • Tenir compte de la licence et du coût de l’outil
- • Préparer une solution de secours
Répartition du temps
- • Tenir compte de la date limite du projet
- • Prévoir une marge de temps pour faire face aux risques
- • Équilibrer les tâches parallèles et les tâches séquentielles
Cas pratique : exemple de décomposition WBS
Chemin critique: 1 → 2.1 → 3.2 → 4.2 → 5 (durée totale d’environ 34 heures)
Définition du DoD
Le DoD (Definition of Done) définit les critères d’achèvement des tâches, garantit la qualité des livrables et évite les situations où « cela semble terminé, mais ne l’est pas vraiment ».
Normes de qualité
Qualité du code
- • Passer les vérifications ESLint, sans avertissements majeurs
- • Le code est conforme aux normes de l’équipe
- • Le code a passé la revue de code
- • Aucun bug connu
Couverture des tests
- • Couverture des tests unitaires >80%
- • Les fonctionnalités clés disposent de tests d’intégration
- • Tous les tests ont réussi
- • La qualité du code de test répond aux exigences
Documentation complète
- • La documentation de l’API est complète
- • Les commentaires du code sont suffisants
- • Mise à jour du manuel utilisateur
- • Mise à jour du journal des modifications
Indicateurs de performance
- • Temps de chargement de la page <2 secondes
- • Temps de réponse de l’API <500 ms
- • Optimisation des requêtes de base de données
- • Aucune fuite de mémoire
Critères d’acceptation
Acceptation des fonctionnalités
- • Implémenter toutes les fonctionnalités selon la Spec
- • Les critères d’acceptation des user stories sont satisfaits
- • La gestion des cas limites est correcte
- • Gestion des erreurs renforcée
Recette des performances
- • Les indicateurs de performance atteignent les exigences
- • Test de charge réussi
- • Test de résistance réussi
- • La surveillance des performances est normale
Tests d’acceptation de sécurité
- • Grâce à une analyse de sécurité
- • Aucune vulnérabilité critique
- • Le chiffrement des données est correct
- • Contrôle des autorisations correct
Cas pratique : checklist DoD
Résultats d’apprentissage
À la fin de ce chapitre, vous pourrez :
- 1Maîtriser les méthodes de clarification des besoins (Reverse Interview, user stories, priorisation) et être capable de découvrir les besoins réels
- 2Comprendre les pratiques d’ingénierie du développement piloté par les spécifications et être capable de rédiger des PRD, des API Specs et des UI Specs clairs
- 3Maîtrisez la méthode de décomposition WBS et sachez découper raisonnablement les tâches, estimer le temps et allouer les ressources
- 4Comprendre les normes de qualité du DoD, définir des critères d’acceptation et garantir la qualité de livraison
- 5Dispose de capacités de gestion de projet et de contrôle qualité de niveau entreprise, permettant d’assurer la livraison réussie des projets