AGILE TOUR 2009: agilité et services

971 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
971
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

AGILE TOUR 2009: agilité et services

  1. 1. S.A.S Software + Agile + Service 1
  2. 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
  3. 3. Le contexte • Fabriquer du logiciel • Travailler en équipe • Satisfaire un client 3
  4. 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. 5. En ligne de mire • L’industrialisation • Le Processus Mature et Optimisé oCMMI-4 et 5 oCMMI Agile 5
  6. 6. Restrospective 6
  7. 7. Débuts industrie automobile 7
  8. 8. Jusqu’à aujourd'hui 8
  9. 9. Début industrie logiciel 9
  10. 10. till today 10
  11. 11. Comparaison échelles de temps 12
  12. 12. Back to reality • Les constats qui fâchent 13
  13. 13. L’estimation • Les plans sont généraux et manquent de précision 14
  14. 14. 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
  15. 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
  16. 16. Adaptabilité ≠ prédictivité 17
  17. 17. • Optimiser la granularité du changement 18
  18. 18. vecteurs d’ajustement • Le niveau d’automatisation • Les ressources humaines. 19
  19. 19. qualité = agilité + industrialisation 20
  20. 20. Dualité • NOUS COMMENCONS UN PROJET • NOUS LIVRONS UN PRODUIT 21
  21. 21. GOUVERNANCE • Ce que le client attend de la gouvernance: oQue le projet soit livré à la date prévue! oTous les moyens sont bons (?) 22
  22. 22. 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
  23. 23. ALORS COMMENT ON FAIT? 24
  24. 24. ALORS COMMENT ON FAIT? On « devient » agile? 25
  25. 25. 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
  26. 26. Ce que l'agilité n'est pas • Une méthode de « hippies » 27
  27. 27. Elle est industrielle 28
  28. 28. since………..1972! 29
  29. 29. 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! 30
  30. 30. Client /Utilisateurs Concepteur /CP Cahier des Charges /Exigences DELTA ++ Spécifications Détaillées Deliveries DELTA -- Développeurs / Code 31
  31. 31. Le problème Client /Utilisateurs Concepteur /CP Cahier des Charges /Exigences DELTA ++ Spécifications Détaillées Deliveries DELTA -- Développeurs / Code 32
  32. 32. 25/02/2009 33
  33. 33. Reference: waterfall 34
  34. 34. Le problème BLOQUANT BLOQUANT BLOQUANT RETARD TROP TARD!!! BLOQUé!!!!! 35
  35. 35. 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
  36. 36. 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
  37. 37. On ne refuse pas le changement • On est à l’écoute 38
  38. 38. COMMENT ON NE FAIT PAS! • le projet AGILE n’est pas un FORFAIT oAu sens classique du terme 39
  39. 39. On ne fait plus…
  40. 40. 25/02/2009 41
  41. 41. 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
  42. 42. PAS DE BIG SPEC UPFRONT 25/02/2009 43
  43. 43. Pas de big upfront design 44
  44. 44. on travaille, on réalise, on montre, on adapte, on itère, on ajuste 25/02/2009 45
  45. 45. 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
  46. 46. COMMENT ON NE FAIT PAS! • On ne passe pas son temps à faire de la documentation que personne ne lira 47
  47. 47. COMMENT ON NE FAIT PAS! • Oublier de faire de la gestion de risque 48
  48. 48. Au contraire, le risque est constamment cadré • Backlog à chaque début de SPRINT • Mesure de la vélocité • Rétrospective 25/02/2009 49
  49. 49. 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
  50. 50. Mais que veut le client? 25/02/2009 52
  51. 51. TOUT!
  52. 52. changer la vision du projet 25/02/2009 54
  53. 53. Les contraintes terrestres
  54. 54. • Quand savez vous ce que ca va vous couter? 25/02/2009 57
  55. 55. Le temps n’arrange rien 25 20 15 effort par fonctions 10 5 0 t1 t2 t3 t4 10/10/2009 58
  56. 56. ALORS COMMENT ON FAIT?
  57. 57. ON FIGE LE TEMPS 60
  58. 58. • C’est le budget qui est fixe : • Design-to-cost (l’équivalent du backlog en « Agile moderne »). 61
  59. 59. • 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 62
  60. 60. • Mais c’est de la régie? 22/10/09 www.agiletour.com
  61. 61. • Mais c’est de la régie? • NON! 22/10/09 www.agiletour.com
  62. 62. • S’engager uniquement sur du temps • Est-ce satisfaisant pour le client? 22/10/09 www.agiletour.com
  63. 63. • S’engager uniquement sur du temps • Est-ce satisfaisant pour le client? •NON! 22/10/09 www.agiletour.com
  64. 64. ON FIGE LA QUALITE • zéro défaut! 25/02/2009 68
  65. 65. 25/02/2009 70
  66. 66. Mais … ? QUALITE TEMPS 25/02/2009 FONCTIONS 71
  67. 67. 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
  68. 68. On donne des priorités 73
  69. 69. Back to basics 25/02/2009 74
  70. 70. Le service 25/02/2009 75
  71. 71. Rendre service 25/02/2009 76
  72. 72. 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
  73. 73. Le client • Le contrat agile repose sur un triple engagement mutuel du client et du fournisseur Collaboration Collaboration Visibilité Transparence Flexibilité Adaptation 79
  74. 74. Le client • Créer un climat de confiance durable avec le client 80
  75. 75. ACCOMPAGNER 25/02/2009 81
  76. 76. Découper •Avant projet •Pendant projet • = 2 projets •Permet de murir le besoin • = 2 contrats 25/02/2009 82
  77. 77. 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
  78. 78. ATTENTION: RISQUE DE BRUF! 84
  79. 79. ATTENTION: RISQUE DE BRUF! • Big Requirements Up Front • BRUF Leads to Significant Wastage 85
  80. 80. Plusieurs possibilités
  81. 81. 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 »
  82. 82. Money for Nothing • Early Termination • Engagement du client (comme les opérateurs de téléphonie mais moins contraignant)
  83. 83. Change For Free • Change ≠ Add
  84. 84. LE PRIX CIBLE
  85. 85. 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
  86. 86. L’ancien contrat 93
  87. 87. Savoir aller au delà du contrat Tout prévoir •Toujours dialoguer 94
  88. 88. 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
  89. 89. 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
  90. 90. 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
  91. 91. • le client est d'abord libre de changer d'avis o de faire évoluer le périmètre fonctionnel selon son besoin 98
  92. 92. 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
  93. 93. ROI • Valeur ajoutée • mesurée • Retour sur investissement •mesuré 100
  94. 94. Se co-évaluer • Mesure • alignement • qualité • vitesse d'exécution • Nouveaux objectifs • itération suivante 101
  95. 95. Adapté aux projets à risques Imposer la flexibilité pour tenir compte des changements fonctionnels 102
  96. 96. MATURITE • Prestataire • Client • Mais grandir est un long processus… • … grandissons ensemble!
  97. 97. Partenariat
  98. 98. Service
  99. 99. Service LOGICIEL
  100. 100. AGILE
  101. 101. MANIFESTE AGILE 108
  102. 102. • Les process et les outils sont importants • Les hommes et la communication le sont • Encore plus 109
  103. 103. • Les process et les outils sont importants • Les hommes et la communication le sont • Encore plus 110
  104. 104. • Les process et les outils sont importants • Les hommes et la communication le sont •Encore plus 111
  105. 105. 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
  106. 106. 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
  107. 107. PAS CONVAINCU? • 2 recherches sur Google = 114
  108. 108. Questions Réponses 116

×