Services & Contrats Agiles

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


• 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


DELTA --

DELTA ++

Deliveries

Raccourcir les cycles, Rapprochez les hommes,

faire des économies


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


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 ?


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


le CONTRATListe des fonctionsPrédiction

de réalisatio

ngaranties

Avant


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


le CONTRAT

prix

qualité

mesures

périmètre

Livraison


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

Technology

Services & Contrats Agiles