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