1.
Services &
Contrats
Agiles 1

2.
my background
• Réalisation logicielle
depuis 1981
• Artisan depuis 1998
• 5 éditeurs logiciel
• sociétés de service
• S+S (Software+Service)
2

3.
Le contexte
• Fabriquer du logiciel
• Travailler en équipe
• Satisfaire un client
• Rendre un service
3

4.
rendre service

5.
Les ambitions de la
production logicielle
• La QUALITE INTRINSEQUE
• La SATISFACTION UTILISATEURS
• La REALISATION de l’EQUIPE
• La REDUCTION DES COUTS
• La PERTINENCE des EVALUATIONS
5

6.
Restrospective
Comparative
Automobile
vs.
informatique
6

7.
Débuts industrie
automobile
7

8.
Jusqu’à aujourd'hui
8

9.
Début
industrie
logiciel
9

10.
Echelle de temps
1673
1936
1/5e
10

11.
Back to reality
Les constats qui fâchent...
taux de réussite dans les
projets S.I.
1998 2004
16% 29%
11

12.
L’estimation
• Les plans sont généraux et
manquent de précision
12

13.
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

14.
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

15.
Adaptabilité
≠
prédictivité
15

16.
Dualité
• NOUS COMMENCONS
UN PROJET
• NOUS LIVRONS UN
PRODUIT
16

17.
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

18.
ALIGNEMENT
• Ce qui importe vraiment:
o Un 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?
19

20.
ALORS COMMENT FAIT- ON?
On «offre» un
service agile?
20

21.
Ce que l'agilité
n'est pas
• Une absence de méthode
oBien au contraire, le cadre de
conduite est plus rigoureux qu’un
cycle en « V »
oLe suivi est plus précis
21

22.
Elle est industrielle
22

23.
since………..1972!
23

24.
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!
o Soyons responsables
24

25.
Mais vraiment si
vous insistez, on
peut vous faire
un planning

26.
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.
Client /Utilisateurs
Concepteur /CP
Cahier des Charges /Exigences
Spécifications
Détaillées
Deliveries
Développeurs / Code
27

28.
Le problème
Client /Utilisateurs
Concepteur /CP
Cahier des Charges /Exigences
DELTA ++
Spécifications
Détaillées
Deliveries
DELTA --
Développeurs / Code
28

29.
Raccourcir les cycles,
Rapprochez les hommes,
faire des économies
Client /Utilisateurs
MOA/CP
Développeurs
/Testeurs

30.
Reference: waterfall
30

31.
Le problème
BLOQUANT
BLOQUANT
BLOQUANT
RETARD
TROP TARD!!!
BLOQUé!!!!!
31

32.
CE QU'ON N' EST PAS!
• ni génie, ni fonctionnaire
• Nous ne voulons plus de
« fracture » informatique
32

33.
changer!
• On est à
l’écoute
33

34.
On ne veux plus…

35.
ni de big upfront design
35

36.
On veut
travailler, réaliser,
montrer, écouter,
adapter, itèrer,
ajuster, livrer
36

37.
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

38.
COMMENT ON NE FAIT PAS!
Ne jamais oublier de faire
de la gestion de risque...
38

39.
Au contraire, le risque est
constamment cadré
• Backlog à chaque début de
SPRINT
• Mesure de la vélocité
• Rétrospective
25/02/2009 39

40.
C’est bien…
25/02/2009 40

41.
…mais que veut le client?
41

42.
TOUT!

43.
changer la
vision du
projet
43

44.
Partager la vision

45.
Les contraintes terrestres

46.
• Quand savez
vous
combien
cela va vous
couter?
47

47.
Le temps
n’arrange rien
48

48.
ALORS COMMENT
FAIT- ON?

49.
ON FIGE LE TEMPS
50

50.
22/10/09 www.agiletour.com

51.
• 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

52.
www.agiletour.com

53.
Nxt=T
www.agiletour.com

54.
•Mais c’est du forfait?
www.agiletour.com

55.
•Mais c’est du forfait?
•NON!
www.agiletour.com

56.
•Les itérations ne sont
pas des phases
•Elles ont toutes la
même durée
www.agiletour.com

57.
www.agiletour.com

58.
• C’est le budget qui est fixe :
• Design-to-cost (l’équivalent du
backlog en « Agile moderne »).
59

59.
• S’engager uniquement sur
du temps…
• …est-ce satisfaisant pour
le client?
www.agiletour.com

60.
•NON!
www.agiletour.com

61.
ON FIGE LA QUALITE
• zéro défaut!
63

62.
qualité
=
agilité + outils
efficaces
64

63.
agilité
=
qualité + outils
efficaces
65

64.
outils efficaces
=
agilité +qualité
66

65.
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

66.
On donne des priorités
70

67.
Etablir les fonctions
• Ensemble
• Progressivement
• Itérativement
• De manière contrôlée et contrôlable
o Avec des TESTS!
• Ce travail fait partie du projet
• …et non plus de l’avant vente
www.agiletour.com

68.
Quelle
Confiance!!
22/10/09

69.
On va le faire
ensemble!!!

70.
Le contrat
Un palliatif à la
confiance ?
74

71.
chaque partie doit
être responsable et
respectueuse
si le climat est au conflit avant la signature du
contrat, abandonnez!
22/10/09 www.agiletour.com

72.
Le client
•Créer un climat de
confiance durable avec
le client
76

73.
L’ancien contrat
77

74.
Avant
le CONTRAT
Liste des
fonctions
Prédiction de
réalisation
garanties
22/10/09 www.agiletour.com

75.
Avant
le CONTRAT
Liste des
fonctions
Prédiction de
réalisation
garanties
22/10/09 www.agiletour.com

76.
Le contrat agile
• Le contrat agile repose sur un triple
engagement mutuel du client et du
fournisseur
Collaboration Collaboration
Visibilité Transparence
Flexibilité Adaptation
80

77.
Signature
le CONTRAT
prix
mesures
qualité
périmètre
22/10/09 www.agiletour.com

78.
Livraison
le CONTRAT
prix
mesures
Liste des
qualité fonctions
+ tests !
périmètre
22/10/09 www.agiletour.com

79.
•des fonctionnalités sans
qualité : NON
•de la qualité dans les
fonctionnalités: OUI
22/10/09 www.agiletour.com

80.
imaginer des solutions
25/02/2009 84

81.
Découper
Plusieurs
orientations
85

82.
Des contrats
• 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
86

83.
FOCUS
•1 projet = 2 projets
o le « Avant projet »
o le « Pendant projet »
• Permet de murir le besoin
• = 2 contrats
87

84.
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

85.
projet en 2 parties
• 1) Projet de Préparation
• Chiffrage du projet de Réalisation
• Acceptation
• 2) Projet de Réalisation
• TMA

86.
ATTENTION:
RISQUE DE BRUF!
90

87.
ATTENTION: RISQUE DE BRUF!
• Big
Requirements
Up Front
• BRUF Leads
to Significant
Wastage
91

88.
Mélange forfait-régie
Temps estimé = TE (en jours x homme)
Taux journalier: TJ
Montant estimé dans le contrat ME = TE x TJ
Temps 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!

89.
Changement à discrétion
• Changer ≠ Rajouter

90.
les fonctionnalités
sont ajustables
pour le client c'est une preuve de votre capacité
d'adaptation et non une tentative de livrer moins

91.
le client doit
maîtriser ses
exigences
il doit être Product Owner ou en désigner un

92.
Sans Product Owner,
pas de produit
Sans produit , pas de
projet.

93.
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

94.
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.

95.
Variations sur le thème
facturation

96.
Play the game

97.
Itérations forfaitaires
U.S #1
Vélocité Initiale 20 pts
U.S #3
connue 10 pts
50 U.S #2
#1
20 pts
pour Sprints de 2 semaines
Le client achète une série fixée de 10 semaines

98.
Itérations de valeurs
U.S #1
20 pts
Vélocité Initiale valeur : 5 U.S #3
connue 10 pts
valeur : 15
50 U.S #2
U.S #1
20 pts
20 pts
pour Sprints de 2 semaines valeur : 10
Le client paye la valeur de chaque itération

99.
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é

100.
Bonus / Malus

101.
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 travail
105

102.
• le client est d'abord libre de changer
d'avis
o de faire évoluer le périmètre
fonctionnel selon son besoin
106

103.
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

104.
Définir des indicateurs
de pilotage
• indicateurs de qualité => productivité.
o Mesures des bugs et qualité du code
o Seuils d'anomalies très faibles
o Mesure de la couverture des
fonctionnalités (Product Backlog)
o Mesure de l’effort de développement
permanent (Sprint Burndown chart).
108

105.
Savoir aller au delà du
contrat
109

106.
Engagements du
fournisseur
• Réactivité
• Livraisons d’éléments finis (exploitables)
• Bonne pratiques
o usine logicielle et tests
o architecture
o suivi de projet agiles
• Les impacts des évolutions sont partagés
110

107.
Engagements du
client
• Disponibilité / Implication
• Vision
• Retours (feedback)
o rapides
o constructifs
o suivi de projet agiles
• Mesurer la valeur ajoutée de ce qu'il veut
111

108.
Tout se mesure
• Valeur ajoutée
• mesurée
• Retour sur investissement
•mesuré
112

109.
Adapté aux
projets à risques
Imposer la flexibilité pour
tenir compte des
changements
fonctionnels
113

110.
Le contrat
Un allié à la confiance !
114

111.
Questions Réponses
115