2. my background
• Réalisation logicielle
depuis 1981
• Production depuis 1998
• 4 éditeurs logiciel
• sociétés de service
• S+S (Software+Service)
10/10/2009 2
4. 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
4
5. En ligne de mire
• L’industrialisation
• Le Processus Mature et Optimisé
oCMMI-4 et 5
oCMMI Agile
5
15. 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
15
16. 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
22. GOUVERNANCE
• Ce que le client attend de la
gouvernance:
oQue le projet soit livré à la date
prévue!
oTous les moyens sont bons (?)
22
23. ALIGNEMENT
• Ce qui importe vraiment:
o Un 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
26. Ce que l'agilité
n'est pas
• Une absence de méthode
o Bien au contraire, le cadre de conduite est
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
o Mais pas à l’instant T - x
26
36. 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 de mauvaise
qualité
o Au contraire, la qualité est plus importante que le
reste, mais aussi important que la tenue des
délais
36
37. CE QU'ON NE FAIT PAS!
• Ignorer le client et se croise plus intelligent
que lui
Pas d’informaticien à lunette Pas de chef de projet guichetier
Pas de génie ou de diva On est pas à l’inspection des impots
37
38. On ne refuse pas le
changement
• On est à l’écoute
38
39. COMMENT ON NE FAIT PAS!
• le projet AGILE n’est pas un
FORFAIT
oAu sens classique du terme
39
42. COMMENT ON NE FAIT PAS!
• On ne planifie pas tous les détails du projet
o On s’en tient aux jalons essentiels
o 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
45. on travaille, on réalise,
on montre, on adapte,
on itère, on ajuste
25/02/2009 45
46. 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
46
47. COMMENT ON NE FAIT PAS!
• On ne passe pas son
temps à faire de la
documentation que
personne ne lira
47
48. COMMENT ON NE FAIT PAS!
• Oublier de faire de la
gestion de risque
48
49. Au contraire, le risque est
constamment cadré
• Backlog à chaque début de
SPRINT
• Mesure de la vélocité
• Rétrospective
25/02/2009 49
50. On ne fait pas non plus
• On laisse travailler les développeurs
sans surveillance
• On ne mesure/vérifie rien
• “the true measure of project
progress is working software”
25/02/2009 50
71. Mais … ?
QUALITE
TEMPS
25/02/2009
FONCTIONS 71
72. Choisir les fonctions
• Seulement les bonnes!
• Comme on ne peut pas tout prédire…
• …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é
22/10/09 www.agiletour.com
78. Pourquoi un meilleur
service
• Un service qui comprend le besoin
(adapté)
• Une qualité de service … durable!
• Une vraie continuité de service
• Un vrai retour sur investissement (ROI)
• … pour les 2 parties!
25/02/2009 78
79. Le client
• Le contrat agile repose sur un triple
engagement mutuel du client et du
fournisseur
Collaboration Collaboration
Visibilité Transparence
Flexibilité Adaptation
79
82. Découper
•Avant projet
•Pendant projet
• = 2 projets
•Permet de murir le besoin
• = 2 contrats
25/02/2009 82
83. 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 : low
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
88. 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 »
89. Money for Nothing
• Early Termination
• Engagement du client (comme les
opérateurs de téléphonie mais
moins contraignant)
92. Le prix est fixe
• Cotation à marges
o Optimiste
o Réaliste
o Pessimiste
• Tient compte des aléas du projet
• Protège le client
• Gagnant-gagnant / partage des risques
94. Savoir aller au delà du
contrat
Tout prévoir
•Toujours dialoguer
94
95. 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é.
95
96. Définir des indicateurs de
pilotage communs
• 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).
96
97. 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
97
98. • le client est d'abord libre de changer
d'avis
o de faire évoluer le périmètre
fonctionnel selon son besoin
98
99. 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
99
109. • Les process et les outils sont importants
• Les hommes et la communication le sont
• Encore plus
109
110. • Les process et les outils sont importants
• Les hommes et la communication le
sont
• Encore plus
110
111. • Les process et les outils sont importants
• Les hommes et la communication le
sont
•Encore plus
111
112. GREEN-IT
• Agile = moins de gaspillage
• Spécifications itératives
o Uniquement les fonctionnalités utiles
• Priorisation
o Élimine le superflu
• TDD
o Pas de code sans test = pas de ligne non couverte
112
113. IMPACTS CO2
• 1 ligne de code = ?
o Exécution CPU
o 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
