1. Contractualiser un projet Agile
Greg Hutchings, le 04 aout 2008
Greg.Hutchings@valtech.fr
Comment s’engager
sans forfait global?

2. 2
Distributed Agile Teams and Contractual Forms
About the author…
Greg Hutchings
I live in Paris and work for Valtech,
proposing, negotiating, managing and
living with large distributed agile projects.
I travel often to Bangalore and within
Europe. I am originally from the SF Bay
area, where I was a client partner for
ThoughtWorks, after spending years in
software product development.
I’ve been involved with software teams
since the early 80’s, and have been using
Agile and XP practices with teams formally
since 2003 and informally since the early
90’s.

3. 3
Sommaire
 Le contrat au forfait : objectifs et limites
 Les critères de choix d’un fournisseur
 Les trois engagements incontournables d’un fournisseur agile
 L’offre de contractualisation agile de Valtech : Software On Demand
 2 exemples de projets non forfaitaires

4. 4
Préambule : Le manifeste Agile,
les 4 valeurs clé pour réussir un projet
 La priorité aux personnes et aux interactions,
 plutôt qu’au processus et aux outils.
 Des applications qui fonctionnent,
 plutôt qu’une documentation pléthorique.
 La collaboration avec le client,
 plutôt que la négociation du contrat.
 La réactivité au changement,
 plutôt que le suivi d’un plan prédéfini.

5. 5
La nécessité d’un contrat
 Pour gérer les risques
 Partager des risques entre le fournisseur et le client
 Se protéger des tentatives de l’un pour exploiter l’autre
 Pour formaliser des choix et des exigences
 Solution technique
 Méthodes
 Outils de suivi
• Suivi d’avancement
• Indicateurs
 Par obligation
 Par exemple pour un Appel d’offre public

6. 6
Le contrat au forfait : objectifs
 Tout prévoir dès le départ !
 Figer les 4 paramètres du projet !
Périmètre
Délai
Qualité
CoûtProjet

7. 7
Le contrat au forfait : limites
 Freins aux changements
 Périmètre figé dans des environnements métiers évolutifs
 Le fournisseur annonce un prix bas pour remporter le marché puis fait sa marge sur
les changements de périmètre
 Focus contractuel plutôt qu’opérationnel
 Renégociations fréquentes qui détournent les intervenants de l’objectif opérationnel
 Tensions entre client et fournisseurs => baisse de confiance => Contre-productif
 Frein à la qualité
 La qualité n’est pas négociable !
Client Fournisseur
Elle sera
donc
minimale !
Elle sera
donc
minimale !
La qualité
n’est pas
négociable
!
La qualité
n’est pas
négociable
!
Périmètre
CoûtDélai
Qualité

8. 8
Sommaire
 Le contrat au forfait : objectifs et limites
 Les critères de choix d’un fournisseur
 Les trois engagements incontournables d’un fournisseur agile
 L’offre de contractualisation agile de Valtech : Software On Demand
 2 exemples de projets non forfaitaires

9. 9
Les critères de choix d’un fournisseur (1/2)
 Quels sont les critères que le client doit mesurer pour choisir un fournisseur ?
 Niveau de qualité proposé
• Nombre d’anomalies, couverture de tests, audit de code, intégration continue
 Quantité et fréquence des feedbacks
• Développement itératif, démonstrations de fin d’itération
 Expérience des ressources
• En général masqué par le forfait
 Capacité à s'adapter en cours de projet
• Prise en compte des changements de contenus et de priorités fonctionnels
 Qualité de la communication
• Développement sur site, outillage (wiki), réunions à fréquences prédéfinies
 Maturité de la relation client
• Pilotage du fournisseur, Implication du client

10. 10
Les critères de choix d’un fournisseur (2/2)
Qualité
Communication
Relation client
Expérience
Feedback
Adaptabilité
1
5
4
3
2

11. 11
Sommaire
 Le contrat au forfait : objectifs et limites
 Les critères de choix d’un fournisseur
 Les trois engagements incontournables d’un fournisseur agile
 L’offre de contractualisation agile de Valtech : Software On Demand
 2 exemples de projets non forfaitaires

12. 12
L’engagement de collaboration
 Etablir le product backlog en commun
 Lister les fonctionnalités attendues
 Prioriser par valeur métier ajoutée
 Estimer l’effort relatif nécessaire à la réalisation de chaque fonctionnalité
 Faire une estimation détaillée pour une ou deux fonctionnalités en jour/homme
 En déduire une estimation globale
 Faire du co-sourcing
 Product Owner client
 Développeurs clients
 Impliquer le client dans la sélection des ressources
 Identification des besoins
 Recrutement des ressources
 Droit de regard sur le maintien ou non des ressources
Relation
client
Expérience
1
5
4
3
2
Fournisseur
Je comprends
mieux ce que
vous voulez
Je comprends
mieux ce que
vous voulez
Je vois ce
que vous
faites
Je vois ce
que vous
faites
Client

13. 13
L’engagement de transparence
 Livraison de fonctionalités utilisables à chaque fin d’itération
 Démonstration et recette partielle
 Suivi de projet partagé
 Product backlog
 Itération backlog
 Indicateurs : qualité, productivité, prédictibilité
 Cycle apprenant
 Rétrospective
Qualité
Communication
1
5
4
3
2

14. 14
Un exemple de visibilité : le bilan d’itération
nom du projet / Bilan Itération x Faits Marquants
Date début - Date Fin • Les calculs dynamiques n'avaient pas été
prévus dans le Backlog original
Avancement projet • Le module 'consultation d'offre' non plus
• Nous avons un module national minimal testable • Abdel va être arrété 2 à 3 semaines
Points positifs
• Les calculs sont bien avancés
• Leur complexité est maîtrisée
• Les premiers écrans sont montrés lors de la
rétrospective
Axes d'amélioration
• S'assurer du périmêtre des fonctionnalités
demandées
• Les membres de l'équipe ne sont pas tous
compétents sur les calculs. A tenir en compte lors
du planning meeting
Actions pour la prochaine itération
• Bien découper les fonctionnalités en sous-ftés
• Enlever les datasets de la mesure de couverture
de code par les tests
• Nettoyer/MAJ la base de données de test
• Mettre au point des jeux de test du calcul
Product Burndown Chart
0
10
20
30
40
50
60
70
80
90
0 1 2 3 4 5 6
Iterations
StoryPoints
Iteration x - Burndown Chart
0
10
20
30
40
50
60
0 1 2 3 4 5 6 7 8 9 10 11
Jours
Charges
Anomalies
0
10
20
30
40
50
60
70
80
1 2 3 4 5
Détectées
Corrigées
Validées
Restantes
Evolutions
Couverture de Tests
0%
10%
20%
30%
40%
50%
60%
70%
80%
1 2 3 4 5
Tests Unitaires
Tests Fonctionnels
Tests Fonctionnels automatisés
Prédictibilité
0
10
20
30
40
50
60
70
80
1 2 3 4 5
Jour-homme
Vélocité
(nombre de SP réalisés par itération)
0
1
2
3
4
5
6
7
8
9
10
11
1 2 3 4 5
Storypoints
Cas de Tests Fonctionnels
0
200
400
600
800
1000
1200
1 2 3 4 5
Rédigés (total)
Passés (dans l'itération)
En échec

15. 15
L’engagement d’adaptabilité
 Accepter le changement de périmètre
 Livrer en priorité les fonctionnalités à forte valeur ajouté pour le client
 Se baser sur des pratiques agiles pour maîtriser la prise en compte des
changements
Client Fournisseur
Faisons le en
premier
Faisons le en
premier
Voilà ce qui
est le plus
important
pour moi
Voilà ce qui
est le plus
important
pour moi
Périmètre
Délai Coût
ProjetProjetProjetProjet
1
5
4
3
2
Adaptabilité

16. 16
Sommaire
 Le contrat au forfait : objectifs et limites
 Les critères de choix d’un fournisseur
 Les trois engagements incontournables d’un fournisseur agile
 L’offre de contractualisation agile de Valtech : Software On Demand
 2 exemples de projets non forfaitaires

17. 17
L’offre Valtech - Software On Demand
Initiation On-Boarding Performance
Itération 0 Itération 1 Itération 2 Itération 3 Itération 4
Qualibrage du projet
• product backlog V1
• priorités
•story points
• critères d’acceptation
•Qualité
•Productivité
Qualibrage du processus et des itérations
• livraison de fonctionnalités utilisables
• raffinement du product backlog
• suivi et ajustement des critères d’acceptation
•Qualité
•Productivité
Réalisation forfaitaire par itération
• pricing par story point
• atteinte des critères d’acceptation
• système de bonus-malus
Régie Forfait par itération Forfait par itération
Itération 5+

18. 18
Exemple 1 : projet contractualisé
en mode forfait par itération
 Projet de refonte
 Ré-écriture en Java d’une application Forté, iso fonctionnelle et iso ergonomique
 Projet mené avec un processus agile en offshore avec équipe local chez le client
 Taille du projet : 6 500 hommes.jour
 Durée : 24 mois
 Application de gestion des candidats intérimaires (1000 agences avec plus de 5000 utilisateurs)
 Critères d’acceptation : qualité
 Déclenchement de la facturation : acceptation d’itération
 Résultats :
 2% d’anomalies en phase de recette (14000 cas de tests fonctionnel)
 Mise en site pilote en septembre 2007 et en production décembre 2007
Forfait
Juin 2005 Décembre 2005 Juin 2007 Aôut 2007
Forfaits par itération / recettes partielles Recette
Négociation

19. 19
Exemple 2 : projet contractualisé
en mode forfait par itération avec bonus/malus (1)
 Projet de refonte des systèmes magasins (220 magasins)
 Ré-écriture Java / WebSphere Commerce Server de 7 applications
 Projet mené avec un processus agile en offshore
 Taille du projet : 15 000 hommes.jour, Durée : 3 ans
 3 lots :
• V1-Refonte catalogue produit
• V2-Refonte système vente pour 1 magasin pilote
• V3-Refonte système vente pour 220 magasins
Forfait global - mode duoshore
Juin 2005 Décembre 2005 Juin 2006
Régie contrôlée par le processus - mode offshore Recette en régie
Négociation
•Changement des têtes du projet
•Changement de périmètre
•Communication directe Client/Inde
•Mise en place d’indicateurs : qualité et productivité
Lot V1

20. 20
Exemple 2 : projet contractualisé
en mode forfait par itération avec bonus/malus (2)
Forfait global
Janvier 2006 Mai 2006 Novembre 2006
Forfait par itération bonus/malus
Négociation
•Communication directe Client/Inde
•Suivi d’indicateurs : qualité et productivité
Lot V2 Lot V3
Forfait par itération
Négociation

21. 21
qualité productivité
0,22 ucp/jour
0,41 ucp/jour
Quality
Productivity
OK 2.5%
Malus
5.0%
Malus
5% Bonus +5% +2.5% 0
Neutral 0 -2.5% -5%
5% Malus -5% -5% -5%
Formule de calcul :
∑ ((UC A / (UC A+UC Raf)) x UC Init)
V1A =
∑ (UC Init)
Exemple 2 : projet contractualisé
en mode forfait par itération avec bonus/malus (3)

22. 22
What did the manifesto say about contracts?
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
© 2001 http://agilemanifesto.org

23. 23
Discussion

24. 24
Thanks!
Greg Hutchings
E-mail gregoryhutchings@gmail.com
Ligne directe +33 (0)1 53 57 73 56
Mobile +33 (0)6 87 25 00 58
Greg Hutchings
E-mail gregoryhutchings@gmail.com
Ligne directe +33 (0)1 53 57 73 56
Mobile +33 (0)6 87 25 00 58