agile tour 2009: agilité et services

S.A.SS.A.SSoftware +

Agile +Service

1

my background

• Réalisation logicielle depuis 1981

•• Production depuis 1998

• 4 éditeurs logiciel

• sociétés de service

• S+S (Software+Service)

210/10/2009

Le contexte

•Fabriquer du logiciel•Travailler en équipe•Travailler en équipe•Satisfaire un client

3

Les ambitions de la production logicielle

• La QUALITE INTRINSEQUE

• La SATISFACTION UTILISATEURS• La SATISFACTION UTILISATEURS

• La REALISATION de l’EQUIPE

• La REDUCTION DES COUTS

• La PERTINENCE des EVALUATIONS

4

En ligne de mire

• L’industrialisation

• Le Processus Mature et Optimisé• Le Processus Mature et OptimiséoCMMI-4 et 5

oCMMI Agile

5

Restrospective

6

Débuts industrie automobile

7

Jusqu’à aujourd'hui

8

Début industrie industrie

logiciel

9

till today

10

Comparaison échelles de temps

12

Back to reality

• Les constats qui fâchent

13

L’estimation

•Les plans sont généraux et manquent de précisionmanquent de précision

14

Le suivi

• En informatique, il y a absence de métriques pour déterminer l'état métriques pour déterminer l'état d'avancement, la durée, et la qualité du logiciel.

• Méthodes empiriques

15

Les demandes du client

• Les spécifications sont au moins TOUJOURS glissantes

•• Et la plupart du temps incomplètes ou carrément inconnues

• Jamais les mêmes entre le début et la fin du projet (le temps passe…)

16

Adaptabilité

≠

prédictivité17

•Optimiser la granularité du changementdu changement

18

vecteurs d’ajustement

• Le niveau d’automatisation

• Les ressources humaines.

19

qualité =

agilité + agilité + industrialisation

20

Dualité

•NOUS COMMENCONS UN PROJETUN PROJET

•NOUS LIVRONS UN PRODUIT

21

GOUVERNANCE

• Ce que le client attend de la gouvernance:gouvernance:oQue le projet soit livré à la date

prévue!

oTous les moyens sont bons (?)

22

ALIGNEMENT

• Ce qui importe vraiment:oUn logiciel qui répondent aux vrais oUn logiciel qui répondent aux vrais

attentes

• du METIER (ou du domaine)

• Est-ce que au moins on sait quels sont les vraies attentes?

23

ALORS COMMENT ON FAIT?

24

ALORS COMMENT ON FAIT?

On « devient » On « devient »

agile?

25

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 »plus rigoureux qu’un cycle en « V »

o Le suivi est plus précis

o L’avancement connu à l’heure près à l’instant T

oMais pas à l’instant T - x

26

• Une méthode de «« hippieshippies »»

Ce que l'agilité Ce que l'agilité n'est pasn'est pas

27

Elle est industrielle

28

since………..1972!

29

COMMENT ON NE FAIT PAS!

• On ne fait pas de cycle de vie en V

• Pas d’effet tunnel• Pas d’effet tunnel

• On n’en veut pas…

•VRAIMENT PAS!

30

Concepteur /CP

Cahier des Charges /Exigences

Spécifications

Client /Utilisateurs

DELTA ++

31

Développeurs / Code

SpécificationsDétaillées

DELTA --

Deliveries

Le problèmeConcepteur /CP

Cahier des Charges /Exigences

Spécifications

Client /Utilisateurs

DELTA ++

32

Développeurs / Code

SpécificationsDétaillées

DELTA --

Deliveries

3325/02/2009

Reference: waterfall

34

Le problème

BLOQUANT

BLOQUANT

BLOQUANT

35

BLOQUANT

RETARD

TROP TARD!!!

BLOQUé!!!!!

COMMENT ON NE FAIT PAS(non plus)!

• On ne demande pas un crédit de temps illimité

• On ne livre pas un logiciel incomplet• On ne livre pas un logiciel incomplet

• On ne livre pas un logiciel de mauvaise qualitéo Au contraire, la qualité est plus importante que le

reste, mais aussi important que la tenue des délais

36

CE QU'ON NE FAIT PAS!

• Ignorer le client et se croise plus intelligent que lui

37

Pas d’informaticien à lunettePas de génie ou de diva

Pas de chef de projet guichetier On est pas à l’inspection des impots

On ne refuse pas le changement

• On est à l’écoute

38

COMMENT ON NE FAIT PAS!

• le projet AGILE n’est pas un FORFAITFORFAIT

oAu sens classique du terme

39

On ne fait plus…

4125/02/2009

COMMENT ON NE FAIT PAS!

• On ne planifie pas tous les détails du projeto On s’en tient aux jalons essentiels

o Personne n’a de boule de cristalo Personne n’a de boule de cristal

o On s’adapte au fur et à mesure plutôt que d’être rigide

o La satisfaction du client est notre seule priorité

o Soyons responsables

42

PAS DE BIG SPEC UPFRONT

4325/02/2009

Pas de big upfrontdesign

44

on travaille, on réalise,on travaille, on réalise,on montre, on adapte,

on itère, on ajuste

4525/02/2009

On a pas peur de montrer comment on travaille

• Donc on est 300% confiant dans la méthode

• On joue la transparence• On joue la transparence

• On écoute les retours du client

• On accepte les critiques et les demandes de changement

46

•On ne passe pas son temps à faire de la

COMMENT ON NE FAIT PAS!

temps à faire de la documentation que personne ne lira

47

COMMENT ON NE FAIT PAS!

•Oublier de faire de la gestion de risquegestion de risque

48

Au contraire, le risque est constamment cadré

• Backlog à chaque début de SPRINTSPRINT

• Mesure de la vélocité

• Rétrospective

4925/02/2009

On ne fait pas non plus

• On laisse travailler les développeurs sans surveillancesans surveillance

• On ne mesure/vérifie rien

• “the true measure of project progress is working software”

5025/02/2009

Mais que veut le client?Mais que veut le client?

5225/02/2009

TOUT!

changer la vision du

5425/02/2009

vision du projet

Les contraintes terrestres

•Quand savez vous ce que ca ce que ca va vous couter?

5725/02/2009

Le temps n’arrange rien

20

25

0

5

10

15

t1 t2 t3 t4

effort par fonctions

5810/10/2009

ALORS COMMENT ON FAIT?

ON FIGE LE TEMPSON FIGE LE TEMPS

60

• C’est le budget qui est fixe :

• Design-to-cost (l’équivalent du • Design-to-cost (l’équivalent du backlog en « Agile moderne »).

61

• Un délai fixe (dead line) est imposé :

• une Time-box pour limiter la durée • une Time-box pour limiter la durée des itérations

• Le nombre d’itérations est connu à l’avance

62

•Mais c’est de la régie?

www.agiletour.com22/10/09

•Mais c’est de la régie?

•NON!www.agiletour.com22/10/09

• S’engager uniquement sur du temps

• Est-ce satisfaisant pour le client?• Est-ce satisfaisant pour le client?

www.agiletour.com22/10/09

• S’engager uniquement sur du temps

• Est-ce satisfaisant pour le client?• Est-ce satisfaisant pour le client?

•NON!www.agiletour.com22/10/09

ON FIGE LA QUALITE

• zéro défaut!• zéro défaut!

6825/02/2009

7025/02/2009

Mais … ?QUALITE

7125/02/2009

TEMPS

FONCTIONS

Choisir les fonctions

• Seulement les bonnes!

• Comme on ne peut pas tout prédire…

• …on assume que la 1ère estimation sera globale• …on assume que la 1ère estimation sera globale

• On raffine pendant le projet

• L’art est de ne pas sortir du périmètre temps+ressources+qualité imposé

www.agiletour.com22/10/09

On donne des priorités

73

Back to basics

7425/02/2009

Le service

7525/02/2009

Rendre service

7625/02/2009

Pourquoi un meilleur service

• Un service qui comprend le besoin (adapté)(adapté)

• Une qualité de service … durable!

• Une vraie continuité de service

• Un vrai retour sur investissement (ROI)

• … pour les 2 parties!

7825/02/2009

Le client

• Le contrat agile repose sur un triple engagement mutuel du client et du fournisseurfournisseur

79

Collaboration

Visibilité

Flexibilité

Collaboration

Transparence

Adaptation

Le client

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

80

ACCOMPAGNER

8125/02/2009

Découper

•Avant projet•Pendant projet•Pendant projet

• = 2 projets•Permet de murir le besoin

• = 2 contrats

8225/02/2009

Phase d’avant projet• durée : ~ 2 mois

o - rédaction des use cases (AMOA / client)

o - construction du backlog produit (PO / client)

o - développement du story board fonctionnel : lowfidelity (PO / client)fidelity (PO / client)

o - développement des modèles et architecture : domaine, objets, cycles de vie, …

• le backlog, le story board et les modèles ont été faits à minima et ont évolué tout au long du projet

o - sprint 0 : réalisations de POCs (équipe / > 1 mois)

• - règles métier avec DSL ou RSPEC

• - composants graphiques évolués

ATTENTION: RISQUE DE BRUF!

84

ATTENTION: RISQUE DE BRUF!

• BigRequirements Up Front

• BRUF Leads to Significant WastageWastage

85

Plusieurs possibilités

projet en 2 parties

• Projet de préparation

• Chiffrage du projet de réalisation

• Acceptation => Projet de Réalisation

• TMA

• Appliquer un « Money for Free, changes for Nothing »

Money for Nothing

• Early Termination

• Engagement du client (comme les • Engagement du client (comme les opérateurs de téléphonie maismoins contraignant)

Change For Free•• Change ≠ Change ≠ AddAdd

LE PRIX CIBLE

Le prix est fixe

• Cotation à margesoOptimiste

RéalisteoRéaliste

oPessimiste

• Tient compte des aléas du projet

• Protège le client

• Gagnant-gagnant / partage des risques

L’ancien contrat

93

Savoir aller au delà du contrat

Tout prévoirTout prévoir

•Toujours dialoguer

94

Dans le contrat

client et fournisseur prévoient de définir PENDANT LE PROJET 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é.

95

Définir des indicateurs de pilotage communs

• indicateurs de qualité => productivité. oMesures des bugs et qualité du codeoMesures des bugs et qualité du code

oSeuils d'anomalies très faibles

oMesure de la couverture des fonctionnalités (Product Backlog)

oMesure de l’effort de développement permanent (Sprint Burndown chart).

96

Une approche gagnant-gagnant

• Itération => livraison

• Livraison => facture• Livraison => facture

• Liberté d’engagement

• Le client respecte son budget

• … ou le ré-attribue

• Le prestataire est payé pour son travail

97

• le client est d'abord libre de changer d'avisd'avisode faire évoluer le périmètre

fonctionnel selon son besoin

98

Engagements du fournisseur

• Réactivité

• Livraisons d’éléments finis (exploitables)

• Bonne pratiques• Bonne pratiqueso usine logicielle et tests

o architecture

o suivi de projet agiles

• Les impacts des évolutions sont partagés

99

ROI

•Valeur ajoutée• mesurée• mesurée

•Retour sur investissement•mesuré

100

Se co-évaluer

• Mesure•alignement•alignement

•qualité

•vitesse d'exécution

• Nouveaux objectifs• itération suivante

101

Adapté aux projets à risques

Imposer la flexibilité pour tenir compte des tenir compte des

changementsfonctionnels

102

MATURITE

• Prestataire

• Client• Client

• Mais grandir est un long processus…

•… grandissons ensemble!

Partenariat

Service

Service

LOGICIEL

AGILEAGILE

MANIFESTE AGILE

108

• Les process et les outils sont importants

• Les hommes et la communication le sont

• Encore plus• Encore plus

109

• Les process et les outils sont importants

• Les hommes et la communication le sontsont

• Encore plus

110

• Les process et les outils sont importants

• Les hommes et la communication le • Les hommes et la communication le sont

•Encore plus

111

GREEN-IT

• Agile = moins de gaspillage

• Spécifications itératives• Spécifications itérativesoUniquement les fonctionnalités utiles

• PriorisationoÉlimine le superflu

• TDDo Pas de code sans test = pas de ligne non couverte

112

IMPACTS CO2

• 1 ligne de code = ?o Exécution CPU

o Occupation Espace disque => Data Centerso Occupation Espace disque => Data Centers

o Temps passé à coder, tester

o Écrans non utilisés

o Écrans ou fonctions non ergonomique

• Pertes de temps

• Pertes énergétiques

• Gaspillages de l’utilisateur final

PAS CONVAINCU?

•2 recherches sur Google =•2 recherches sur Google =

114

Questions Réponses

116