Méthodes Agiles Plus de maîtrise, plus de valeur, plus tôt et plus vite
David GAGEOT Directeur Technique Valtech Technology
[email protected]
Changement de Paradigme
Le développement de nouveaux logiciels
% Changement d’exigences
60 50 40 30 20 10 0 0
10
100
1000
10000
Taille du projet en points de fonction
100000
Estimé / Réel [DeMarco82, Little04]
Statistiques : p50 réel = 2x estimé p90 réel = 3,25x estimé La meilleure estimation initiale à 10% de chances de se réaliser
Fonctionnalités inutiles ? Taux d’utilisation des fonctionnalités développées [Johnson02] sur des projets développés en méthodes classiques :
Historique
Lean Software Development, 2002 Agile UP, 1999 Adaptive Software Development, 1998 xBreed, 1998 Feature-Driven Development, 1997 Crystal, 1997 XP, 1995 DSDM, 1992 Scrum, 1992 Spiral Model, 1987 Lean Thinking, 1950s
Les objectifs des méthodes agiles
ur
r+
e Livr r+ e r v Li + de
tris î a M
e
tôt
ale v e d
Une meilleure maîtrise du projet
ur
r+
e Livr r+ e r v Li + de
tris î a M
e
tôt
ale v e d
Scrum - Le cycle de développement
Eviter le fameux effet tunnel
Préparer
Développer quelques fonctionnalités
Adapter
Préparer
Faire
Développer quelques fonctionnalités
Adapter
Préparer
Faire
Développer quelques fonctionnalités
Adapter
Faire
Meilleure gestion de la pression
Pression
Temps
Product Backlog
Product Burn Down Chart
700
Reste à faire en jours
525 350 175 0
1
2
3
4 Itération
5
6
7
8
4 manières de maîtriser un projet
Fonctionnalités
Temps
Projet
Tests
Ressources
4 manières de maîtriser un projet
Fonctionnalités
Temps
Projet
Tests
Ressources
Une fois une itération commencée, ne JAMAIS changer la date de fin On peut par contre enlever des fonctionnalités
Bilan de fin d’itération
Livrer plus tôt
ur
r+
e Livr r+ e r v Li + de
tris î a M
e
tôt
ale v e d
Limiter la latence des premières livraisons utiles
Le cycle en « V » génère une latence importante
Avec UP, les livraisons sont subordonnées aux phases préparatoires
Livrer plus tôt en évitant l’inutile
Nous voulons tout ! Débrouillez-vous...
Utilisateur
MOA
S’ils n’ont pas ce qu’ils veulent, ce n’est pas de ma faute !
Pourvu que je n’oublie rien
MOE
« Nous voulons tout » Peur d’avoir un système partiel que l’on n’aura plus l’opportunité de faire évoluer… … ou refus d’évaluer la pertinence économique des fonctions « Un cahier des charges complet » Les rédacteurs sont jugés sur leur capacité à ne rien oublier, non sur la pertinence de leurs demandes
Livrer des fonctionnalités dès les premières itérations
Nous savons ce que nous voulons en premier
Utilisateur + MOA
MOE
Faisons le, puis utilisons le feedback pour adapter le plan
Communication directe ou Passage de relais ?
Intégration continue
Livrer plus de valeur utilisateur
ur
r+
e Livr r+ e r v Li + de
tris î a M
e
tôt
ale v e d
Eviter les fonctionnalités inutiles
Le coût de la complexité
Coût
n no é t t ali s e n n le tio ntiel xes c n e Fo esse mpl co
ntielles
lités esse Fonctionna
Temps
Productivité
Productivité de développements logiciels
Temps
Effet du refactoring et des tests automatisés L’objectif premier n’est pas d'accroître la productivité mais déjà d’éviter qu’elle ne baisse
Productivité
Avec
Sans
Temps
Harnais de tests Les tests unitaires et fonctionnels automatiques permettent de réduire les régressions : En cas d’ajout de fonctionnalité En cas de Refactoring Sans automatisation des tests : L’ajout d’une fonctionnalité est de plus en plus complexe L’architecture peut vite devenir obsolète La maintenance est plus complexe Approche TDD : Ecrire les tests, puis le code
Autres pistes : les 13 pratiques XP
Comment démarrer ?
Obstacles La mise en oeuvre concrète de Scrum n’est pas simple : Changement de mentalité et d’habitudes : Ex: Commencer à développer tout de suite, Ex: Obtenir le feedback des utilisateurs finaux, Ex: Accompagner le changement sans changer d’avis tout le temps, Ex: Faire des choix le plus tard possible mais jamais trop tard, Ex: Faire des estimations tous les jours, Ex: Piloter par le Reste à Faire et non par le consommé, Ex: Estimer la valeur ajoutée de chaque fonctionnalité, Ex: Travailler à plusieurs pour aller plus vite, Ex: Sortir du mode de recherche de bouc émissaire, Ex: Faire travailler tout le monde au même rythme, ...
Commencer simplement par une itération
Préparer
Développer quelques fonctionnalités
Adapter
Faire
Quelle organisation adopter ? Sélectionner un ou deux projet(s) pilote(s) : De préférence avec la MOA, Projet à fort enjeu métier, Pas les plus complexes pour commencer, Former les équipes : Formation de 2 jours, Désigner les acteurs clefs : Un Product Owner et un Scrum Master pour chaque projet, Un coach à temps partiel pour maintenir les projets sur la bonne voie, Prévoir du mentoring technique ciblé : Estimations, Usine Logicielle, TDD, Refactoring, Automatisation, TDR, ...
Process Agile : Solution miracle ? L’agilité n’est pas une solution miracle Les règles sont simples, Les combinaisons sont infinies : Fort impact de l’environnement : Personnes Expérience Produit “Process is a second-order effect” Alistair Cockburn Analogie avec le jeu d’échec
Externalisation
Périmètre Variable / Coût fixe
Périmètre
Voilà ce qui est le plus important pour moi
Projet Budget
Client
Délai
Faisons le en premier
Sous-traitant
Co-sourcing Contrat avec une équipe mixte : Client / Fournisseur, Sur le site du client. Avantages : Transfert de compétences, Coût réduit, Très grande visibilité, Risque partagé de fait. Solution préconisée par Valtech.
Je vois ce que vous faites
Client
Je comprends mieux ce que vous voulez
Sous-traitant
Livres
Livres
Merci David GAGEOT Directeur Technique Valtech Technology
[email protected]
