Services & Contrats Agiles
1
my background
• Réalisation logicielle depuis 1981
• Artisan depuis 1998
• 5 éditeurs logiciel• sociétés de service• S+S
(Software+Service) 2
Le contexte
•Fabriquer du logiciel•Travailler en équipe•Satisfaire un client•Rendre un service
3
rendre service
Restrospective
6
Comparative
Automobilevs.
informatique
Débuts industrie automobile
7
Jusqu’à aujourd'hui
8
Début industrie
logiciel
9
Echelle de temps
10
1673
1936
1/5e
Back to reality
Les constats qui fâchent...
taux de réussite dans les projets S.I.
1998 2004
16%
29%
11
L’estimation
•Les plans sont généraux et manquent de précision
12
Le suivi
•En informatique, il y a absence de métriques pour déterminer l'état d'avancement, la durée, et la qualité du logiciel.•Méthodes empiriques
13
Les demandes du client
• Les spécifications sont au moins TOUJOURS glissantes• Et la plupart du temps
incomplètes ou trop interprétables• Jamais les mêmes entre le
début et la fin du projet (le temps passe…)
14
Adaptabilité ≠
prédictivité15
Dualité
•NOUS COMMENCONS UN PROJET•NOUS LIVRONS UN PRODUIT
16
GOUVERNANCE en 2010
•Ce que le client attend de la gouvernance:oQue le projet soit livré à la date prévue!
oVaut-il mieux gouverner ou prendre part au travail?
17
ALIGNEMENT
• Ce qui importe vraiment:oUn logiciel qui répondent aux vraies attentes
du METIER (ou du domaine)• Est-ce que au moins on sait quelles sont les vraies attentes?
18
19
ALORS COMMENT FAIT- ON?
ALORS COMMENT FAIT- ON?
On «offre» un service
agile?20
Ce que l'agilité n'est pas
•Une absence de méthodeoBien au contraire, le cadre de conduite est plus rigoureux qu’un cycle en « V »
oLe suivi est plus précis
21
Elle est industrielle
22
since………..1972!
23
COMMENT ON NE FAIT PAS!
• Pas de planification hasardeuse• Ce qu’on ne sait pas prédire
avec exactitude n’est pas à planifier• Fabriquer un logiciel est une
somme de procédés humains• Restons toujours réalistes!oSoyons responsables
24
Mais vraiment si
vous insistez, on
peut vous faire un
planning
COMMENT ON NE FAIT PAS!
• On ne fait pas de cycle de vie en V• Pas d’effet tunnel• On n’en veut pas…
•VRAIMENT PAS!26
27
Concepteur /CP
Cahier des Charges /Exigences
Développeurs / Code
SpécificationsDétaillées
Client /Utilisateurs
Deliveries
Le problème
28
Concepteur /CP
Cahier des Charges /Exigences
Développeurs / Code
SpécificationsDétaillées
Client /Utilisateurs
DELTA --
DELTA ++
Deliveries
Raccourcir les cycles, Rapprochez les hommes,
faire des économies
Client /Utilisateurs
Développeurs/Testeurs
MOA/CP
Reference: waterfall
30
Le problème
31
BLOQUANT
BLOQUANT
BLOQUANT
RETARD
TROP TARD!!!
BLOQUé!!!!!
CE QU'ON N' EST PAS!
• ni génie, ni fonctionnaire•Nous ne voulons plus de « fracture » informatique
32
changer!
•On est à l’écoute
33
On ne veux plus…
ni de big upfront design
35
travailler, réaliser, montrer, écouter,
adapter, itèrer, ajuster, livrer
36
On veut
On a pas peur de montrer comment on travaille
• Donc on est 300% confiant dans la méthode• On joue la transparence• On écoute les retours du client• On accepte les critiques et les
demandes de changement
37
COMMENT ON NE FAIT PAS!
Ne jamais oublier de faire de la gestion de risque...
38
Au contraire, le risque est constamment
cadré•Backlog à chaque début de SPRINT•Mesure de la vélocité•Rétrospective
3925/02/2009
4025/02/2009
C’est bien…
…mais que veut le client?
41
TOUT!
43
changer la vision
du projet
Partager la vision
Les contraintes terrestres
•Quand savez vous combien cela va vous couter? 47
Le temps n’arrange rien
48
ALORS COMMENT FAIT-
ON?
50
ON FIGE LE TEMPSON FIGE LE TEMPS
www.agiletour.com22/10/09
• Un délai fixe (dead line) est imposé : • une Time-box pour limiter la
durée des itérations• Le nombre d’itérations est
connu à l’avance
52
www.agiletour.com
N x t = T www.agiletour.com
•Mais c’est du forfait?
www.agiletour.com
•Mais c’est du forfait?
•NON!www.agiletour.com
www.agiletour.com
•Les itérations ne sont pas des phases•Elles ont toutes la même durée
www.agiletour.com
• C’est le budget qui est fixe : • Design-to-cost (l’équivalent du backlog en « Agile moderne »).
59
•S’engager uniquement sur du temps…•…est-ce satisfaisant pour le client?
www.agiletour.com
•NON!www.agiletour.com
ON FIGE LA QUALITE
• zéro défaut!
63
Choisir les fonctions
• Seulement les bonnes!• Comme on ne peut pas tout
prédire…• …on assume que la 1ère estimation
sera globale• On raffinera pendant le projet
• L’art est de ne pas sortir du périmètre
temps+ressources+qualité imposéwww.agiletour.com
On donne des priorités
70
• Ensemble• Progressivement • Itérativement• De manière contrôlée et
contrôlableoAvec des TESTS!
• Ce travail fait partie du projet• …et non plus de l’avant vente
www.agiletour.com
Etablir les fonctions
Quelle Confiance
!!
22/10/09
On va le faireOn va le faire
ensemble!!!
Le contrat
74
Un palliatif à la confiance ?
www.agiletour.com22/10/09
chaque partie doit être
responsable et respectueuse
si le climat est au conflit avant la signature du contrat, abandonnez!
Le client
•Créer un climat de confiance durable avec le client
76
L’ancien contrat
77
Avant
www.agiletour.com22/10/09
le CONTRATListe des fonctionsPrédiction
de réalisatio
ngaranties
Avant
www.agiletour.com22/10/09
le CONTRATListe des fonctionsPrédiction
de réalisatio
ngaranties
Le contrat agile
• Le contrat agile repose sur un triple engagement mutuel du client et du fournisseur
80
CollaborationVisibilitéFlexibilité
CollaborationTransparence Adaptation
Signature
www.agiletour.com22/10/09
le CONTRAT
prix
qualité
mesures
périmètre
Livraison
www.agiletour.com22/10/09
le CONTRAT
prix
qualité
mesures
périmètre
Liste des
fonctions+
tests !
imaginer des solutions
8425/02/2009
Découper
85
Plusieurs orientations
Des contrats
86
• 1. le contrat au sprint
• 2. le forfait / périmètre figé
• 3. l’assistance technique
• 4. l’assistance technique avec un périmètre figé et un budget limité
• 5. l’assistance technique avec un périmètre variable et un budget limité
• 6. le développement par phase
• 7. les clauses de bonus / pénalités
• 8. le bénéfice fixé à l’avance
• 9. le profit pour rien, les changements à discrétion
• 10. le projet commun
FOCUS
•1 projet = 2 projetso le « Avant projet »o le « Pendant projet »•Permet de murir le besoin
•= 2 contrats87
Phase d’avant projet
• durée : max. 2 mois o - rédaction des use cases (AMOA / client)o - construction du backlog produit (PO /
client)o - développement du story board
fonctionnel : low fidelity (PO / client)o - sprint 0 : réalisations de POCs• - règles métier avec DSL ou RSPEC• - composants graphiques évolués
90
ATTENTION: RISQUE DE BRUF!
ATTENTION: RISQUE DE BRUF!
• Big Requirements Up Front
• BRUF Leads to Significant Wastage
91
Mélange forfait-régie
Temps estimé = TE (en jours x homme)Taux journalier: TJMontant estimé dans le contrat ME = TE
x TJTemps réel = TR, Montant Facturé = MF• Si ( TR > TE), MF = ME + ( (TR-TE) x TJ
/ 2)• Si ( TR < TE), MF = ME - ( (TE-TR) x
TJ / 2)
Gagnant - Gagnant!
les fonctionnalités sont ajustables
pour le client c'est une preuve de votre capacité d'adaptation et non une tentative de livrer moins
le client doit maîtriser ses
exigencesil doit être Product Owner ou en désigner
un
Sans Product Owner, pas de
produitSans produit , pas de projet.
Il est préférable que
le Client admette que la recette dure toute la durée du projet
les fins d'itérations sont autant de recettes nécessaires au succès du projet
mieux vaut un client présent 1 jour par semaine,
plutôt que 2 mois par an
cycle itératifs d'une semaine si le client ne peut être avec l'équipe.
Variations sur le thème
facturation
Play the game
Itérations forfaitaires
Vélocité Initiale connue
50pour Sprints de 2
semaines
U.S #120 ptsU.S #220 pts
U.S #120 pts U.S
#310 pts
Le client achète une série fixée de 10 semaines
Itérations de valeurs
Vélocité Initiale connue
50pour Sprints de 2
semaines
U.S #120 pts
U.S #220 ptsvaleur : 10
U.S #120 ptsvaleur : 5 U.S #3
10 ptsvaleur : 15
Le client paye la valeur de chaque itération
Paiements à la livraison
• Le client paie pour ce qu'il a• Possibilité de prévoir un crédit initial pour éviter les multiples factures•Ce qui n'est pas dépensé est remboursé
Bonus / Malus
Une approche gagnant-gagnant
• Itération => livraison• Livraison => facture• Liberté d’engagement• Le client respecte son budget• … ou le ré-attribue• Le prestataire est payé pour
son travail105
• le client est d'abord libre de changer d'avisode faire évoluer le périmètre fonctionnel selon son besoin
106
Dans le contrat
client et fournisseur prévoient de définir PENDANT LE PROJET l'ordre de priorité de chaque fonctionnalité basée sur sa valeur ajoutée métier et étude de sa complexité.
107
Définir des indicateurs de
pilotage
• indicateurs de qualité => productivité. oMesures des bugs et qualité du
codeoSeuils d'anomalies très faiblesoMesure de la couverture des
fonctionnalités (Product Backlog)oMesure de l’effort de
développement permanent (Sprint Burndown chart).
108
Savoir aller au delà du contrat
109
Engagements du fournisseur
• Réactivité• Livraisons d’éléments finis
(exploitables)• Bonne pratiqueso usine logicielle et testso architecture o suivi de projet agiles
• Les impacts des évolutions sont partagés 110
Engagements du client
• Disponibilité / Implication• Vision• Retours (feedback)o rapideso constructifs o suivi de projet agiles
• Mesurer la valeur ajoutée de ce qu'il veut
111
Tout se mesure
•Valeur ajoutée• mesurée
•Retour sur investissement•mesuré
112
Le contrat
114
Un allié à la confiance !
Questions Réponses
115
Top Related