Session animée par Guillaume SAINT ETIENNE qui, passionné pour le Web, tente aujourd'hui de faire adopter les bonnes pratiques issues des meilleurs départements R&D logiciels français au monde des sociétés de services. La production ou réalisation de logiciel n'est pas la science exacte que l'on aurait aimé qu'elle soit. Il convient donc de faire des ajustements. Les Sociétés de Services Logiciel sont une constituante majeure de cet univers et relient les hommes, du passeur d'ordre au réalisateur en passant par tous les intermédiaires possibles et imaginables. C'est donc avec eux, chez eux, que les démarches Agiles prendront tout leur sens. Pour autant, sont-ils prêts à entrer dans cette nouvelle ère, quel est l'état des lieux, et quels sont les obstacles qui nous attendent ?

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

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

48. Le temps
n’arrange rien
48

49. ALORS COMMENT
FAIT- ON?

50. ON FIGE LE TEMPS
50

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

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

53. www.agiletour.com

54. Nxt=T
www.agiletour.com

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

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

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

58. www.agiletour.com

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

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

61. •NON!
www.agiletour.com

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

64. qualité
=
agilité + outils
efficaces
64

65. agilité
=
qualité + outils
efficaces
65

66. outils efficaces
=
agilité +qualité
66

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

70. On donne des priorités
70

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

72. Quelle
Confiance!!
22/10/09

73. On va le faire
ensemble!!!

74. Le contrat
Un palliatif à la
confiance ?
74

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

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

77. L’ancien contrat
77

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

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

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

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

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

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

84. imaginer des solutions
25/02/2009 84

85. Découper
Plusieurs
orientations
85

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

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

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

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

90. ATTENTION:
RISQUE DE BRUF!
90

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

92. 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!

93. Changement à discrétion
• Changer ≠ Rajouter

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

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

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

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

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

99. Variations sur le thème
facturation

100. Play the game

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

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

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

104. Bonus / Malus

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

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

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

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

109. Savoir aller au delà du
contrat
109

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

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

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

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

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

115. Questions Réponses
115