• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
AGILE TOUR 2009:   agilité et services
 

AGILE TOUR 2009: agilité et services

on

  • 843 views

 

Statistics

Views

Total Views
843
Views on SlideShare
843
Embed Views
0

Actions

Likes
0
Downloads
19
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    AGILE TOUR 2009:   agilité et services AGILE TOUR 2009: agilité et services Presentation Transcript

    • S.A.S Software + 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) 10/10/2009 2
    • Le contexte • Fabriquer du logiciel • Travailler en équipe • Satisfaire un client 3
    • 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
    • En ligne de mire • L’industrialisation • 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 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écision 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
    • 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 changement 18
    • vecteurs d’ajustement • Le niveau d’automatisation • Les ressources humaines. 19
    • qualité = agilité + industrialisation 20
    • Dualité • NOUS COMMENCONS UN PROJET • NOUS LIVRONS UN PRODUIT 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
    • 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
    • ALORS COMMENT ON FAIT? 24
    • ALORS COMMENT ON FAIT? On « devient » agile? 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
    • Ce que l'agilité n'est pas • Une méthode de « hippies » 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 • On n’en veut pas… • VRAIMENT PAS! 30
    • Client /Utilisateurs Concepteur /CP Cahier des Charges /Exigences DELTA ++ Spécifications Détaillées Deliveries DELTA -- Développeurs / Code 31
    • Le problème Client /Utilisateurs Concepteur /CP Cahier des Charges /Exigences DELTA ++ Spécifications Détaillées Deliveries DELTA -- Développeurs / Code 32
    • 25/02/2009 33
    • Reference: waterfall 34
    • Le problème BLOQUANT BLOQUANT BLOQUANT RETARD TROP TARD!!! BLOQUé!!!!! 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
    • 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
    • On ne refuse pas le changement • On est à l’écoute 38
    • COMMENT ON NE FAIT PAS! • le projet AGILE n’est pas un FORFAIT oAu sens classique du terme 39
    • On ne fait plus…
    • 25/02/2009 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
    • PAS DE BIG SPEC UPFRONT 25/02/2009 43
    • Pas de big upfront design 44
    • on travaille, on réalise, on montre, on adapte, on itère, on ajuste 25/02/2009 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
    • COMMENT ON NE FAIT PAS! • On ne passe pas son temps à faire de la documentation que personne ne lira 47
    • COMMENT ON NE FAIT PAS! • Oublier de faire de la gestion de risque 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
    • 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
    • Mais que veut le client? 25/02/2009 52
    • TOUT!
    • changer la vision du projet 25/02/2009 54
    • Les contraintes terrestres
    • • Quand savez vous ce que ca va vous couter? 25/02/2009 57
    • Le temps n’arrange rien 25 20 15 effort par fonctions 10 5 0 t1 t2 t3 t4 10/10/2009 58
    • ALORS COMMENT ON FAIT?
    • ON FIGE LE TEMPS 60
    • • C’est le budget qui est fixe : • 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 des itérations • Le nombre d’itérations est connu à l’avance 62
    • • Mais c’est de la régie? 22/10/09 www.agiletour.com
    • • Mais c’est de la régie? • NON! 22/10/09 www.agiletour.com
    • • S’engager uniquement sur du temps • Est-ce satisfaisant pour le client? 22/10/09 www.agiletour.com
    • • S’engager uniquement sur du temps • Est-ce satisfaisant pour le client? •NON! 22/10/09 www.agiletour.com
    • ON FIGE LA QUALITE • zéro défaut! 25/02/2009 68
    • 25/02/2009 70
    • Mais … ? QUALITE TEMPS 25/02/2009 FONCTIONS 71
    • 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
    • On donne des priorités 73
    • Back to basics 25/02/2009 74
    • Le service 25/02/2009 75
    • Rendre service 25/02/2009 76
    • 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
    • Le client • Le contrat agile repose sur un triple engagement mutuel du client et du fournisseur Collaboration Collaboration Visibilité Transparence Flexibilité Adaptation 79
    • Le client • Créer un climat de confiance durable avec le client 80
    • ACCOMPAGNER 25/02/2009 81
    • Découper •Avant projet •Pendant projet • = 2 projets •Permet de murir le besoin • = 2 contrats 25/02/2009 82
    • 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
    • ATTENTION: RISQUE DE BRUF! 84
    • ATTENTION: RISQUE DE BRUF! • Big Requirements Up Front • BRUF Leads to Significant Wastage 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 opérateurs de téléphonie mais moins contraignant)
    • Change For Free • Change ≠ Add
    • LE PRIX CIBLE
    • 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
    • L’ancien contrat 93
    • Savoir aller au delà du contrat Tout prévoir •Toujours dialoguer 94
    • 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
    • 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
    • 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
    • • le client est d'abord libre de changer d'avis o de faire évoluer le périmètre fonctionnel selon son besoin 98
    • 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
    • ROI • Valeur ajoutée • mesurée • Retour sur investissement •mesuré 100
    • Se co-évaluer • Mesure • alignement • qualité • vitesse d'exécution • Nouveaux objectifs • itération suivante 101
    • Adapté aux projets à risques Imposer la flexibilité pour tenir compte des changements fonctionnels 102
    • MATURITE • Prestataire • Client • Mais grandir est un long processus… • … grandissons ensemble!
    • Partenariat
    • Service
    • Service LOGICIEL
    • AGILE
    • MANIFESTE AGILE 108
    • • Les process et les outils sont importants • Les hommes et la communication le sont • Encore plus 109
    • • Les process et les outils sont importants • Les hommes et la communication le sont • Encore plus 110
    • • Les process et les outils sont importants • Les hommes et la communication le sont •Encore plus 111
    • 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
    • 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
    • PAS CONVAINCU? • 2 recherches sur Google = 114
    • Questions Réponses 116