SlideShare une entreprise Scribd logo
1  sur  116
Télécharger pour lire hors ligne
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

Contenu connexe

Tendances

Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionTremeur Balbous
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesSirine Barguaoui
 
Contractualisation agile : Saison 2 (atm)
Contractualisation agile :  Saison 2 (atm)Contractualisation agile :  Saison 2 (atm)
Contractualisation agile : Saison 2 (atm)Michel Lejeune
 
Présentation de l’agilité
Présentation de l’agilitéPrésentation de l’agilité
Présentation de l’agilitéJean Yves Klein
 
Trois petites histoires de dette avec notes de la présentation
Trois petites histoires de dette   avec notes de la présentationTrois petites histoires de dette   avec notes de la présentation
Trois petites histoires de dette avec notes de la présentationBruno MOREL
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsPierre E. NEIS
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de ScrumPyxis Technologies
 
2001-03-29 Renée Thibeault Terminer vos projets en beauté
2001-03-29 Renée Thibeault Terminer vos projets en beauté2001-03-29 Renée Thibeault Terminer vos projets en beauté
2001-03-29 Renée Thibeault Terminer vos projets en beautéPMI Lévis-Québec
 
Processus de gestion de projets «agile» et émergents
Processus de gestion de projets «agile» et émergentsProcessus de gestion de projets «agile» et émergents
Processus de gestion de projets «agile» et émergentsClaude Emond
 
Architecture express pour petits projets
Architecture express pour petits projetsArchitecture express pour petits projets
Architecture express pour petits projetsCGI Québec Formation
 
AgileTour Toulouse 2012 : adopter l’agilité
AgileTour Toulouse 2012 : adopter l’agilitéAgileTour Toulouse 2012 : adopter l’agilité
AgileTour Toulouse 2012 : adopter l’agilitéAgile Toulouse
 
Les Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileLes Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileAgileCoach.net
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slidesNicolas Deverge
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVPierre
 
Introduction à l'agilité
Introduction à l'agilitéIntroduction à l'agilité
Introduction à l'agilitéJonas Vonlanthen
 

Tendances (20)

Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - Introduction
 
Methodes agile
Methodes agileMethodes agile
Methodes agile
 
Genielogiciel
GenielogicielGenielogiciel
Genielogiciel
 
Pour un développement durable (DevoxxFr)
Pour un développement durable (DevoxxFr)Pour un développement durable (DevoxxFr)
Pour un développement durable (DevoxxFr)
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiques
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
 
Contractualisation agile : Saison 2 (atm)
Contractualisation agile :  Saison 2 (atm)Contractualisation agile :  Saison 2 (atm)
Contractualisation agile : Saison 2 (atm)
 
Présentation de l’agilité
Présentation de l’agilitéPrésentation de l’agilité
Présentation de l’agilité
 
Trois petites histoires de dette avec notes de la présentation
Trois petites histoires de dette   avec notes de la présentationTrois petites histoires de dette   avec notes de la présentation
Trois petites histoires de dette avec notes de la présentation
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskills
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de Scrum
 
2001-03-29 Renée Thibeault Terminer vos projets en beauté
2001-03-29 Renée Thibeault Terminer vos projets en beauté2001-03-29 Renée Thibeault Terminer vos projets en beauté
2001-03-29 Renée Thibeault Terminer vos projets en beauté
 
Processus de gestion de projets «agile» et émergents
Processus de gestion de projets «agile» et émergentsProcessus de gestion de projets «agile» et émergents
Processus de gestion de projets «agile» et émergents
 
Architecture express pour petits projets
Architecture express pour petits projetsArchitecture express pour petits projets
Architecture express pour petits projets
 
AgileTour Toulouse 2012 : adopter l’agilité
AgileTour Toulouse 2012 : adopter l’agilitéAgileTour Toulouse 2012 : adopter l’agilité
AgileTour Toulouse 2012 : adopter l’agilité
 
Les Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileLes Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/Agile
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slides
 
Initiation Scrum
Initiation ScrumInitiation Scrum
Initiation Scrum
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEV
 
Introduction à l'agilité
Introduction à l'agilitéIntroduction à l'agilité
Introduction à l'agilité
 

En vedette

En vedette (7)

Tdd vs SQL
Tdd vs SQLTdd vs SQL
Tdd vs SQL
 
Clean architectures
Clean architecturesClean architectures
Clean architectures
 
Agile pour le web
Agile pour le webAgile pour le web
Agile pour le web
 
Electronic Music and Software Craftsmanship: analogue patterns.
Electronic Music and Software Craftsmanship: analogue patterns.Electronic Music and Software Craftsmanship: analogue patterns.
Electronic Music and Software Craftsmanship: analogue patterns.
 
to Test or not to Test?
to Test or not to Test?to Test or not to Test?
to Test or not to Test?
 
Design applicatif avec symfony2
Design applicatif avec symfony2Design applicatif avec symfony2
Design applicatif avec symfony2
 
Study: The Future of VR, AR and Self-Driving Cars
Study: The Future of VR, AR and Self-Driving CarsStudy: The Future of VR, AR and Self-Driving Cars
Study: The Future of VR, AR and Self-Driving Cars
 

Similaire à AGILE TOUR 2009: agilité et services

Exemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUMExemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUMAgile Tour 2009 Québec
 
Surmonter les anti-patrons culturels nuisant à DevOps
Surmonter les anti-patrons culturels nuisant à DevOpsSurmonter les anti-patrons culturels nuisant à DevOps
Surmonter les anti-patrons culturels nuisant à DevOpsAgile Montréal
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileNormandy JUG
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileLaurent Deséchalliers
 
Recherche lead technique désespérément
Recherche lead technique désespérémentRecherche lead technique désespérément
Recherche lead technique désespérémentAgile Montréal
 
Scrum : les sujets qui fâchent
Scrum : les sujets qui fâchentScrum : les sujets qui fâchent
Scrum : les sujets qui fâchentBruno Borghi
 
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...DC CONSULTANTS
 
AT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillagesAT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillagesJérôme Avoustin
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelAgile Montréal
 
Le Burn-Out Agile - Devoxx MA
Le Burn-Out Agile - Devoxx MALe Burn-Out Agile - Devoxx MA
Le Burn-Out Agile - Devoxx MACedric Moulard
 
Tour d'horizon des méthodes agiles
Tour d'horizon des méthodes agilesTour d'horizon des méthodes agiles
Tour d'horizon des méthodes agilesChristophe Addinquy
 
Lean Product Development
Lean Product DevelopmentLean Product Development
Lean Product DevelopmentXL Groupe
 
Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite...
Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite...Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite...
Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite...OCTO Technology
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgileAgile Tour 2009 Québec
 

Similaire à AGILE TOUR 2009: agilité et services (20)

Agile pour l'echafaud ATT2020.pptx
Agile pour l'echafaud ATT2020.pptxAgile pour l'echafaud ATT2020.pptx
Agile pour l'echafaud ATT2020.pptx
 
Exemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUMExemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUM
 
Surmonter les anti-patrons culturels nuisant à DevOps
Surmonter les anti-patrons culturels nuisant à DevOpsSurmonter les anti-patrons culturels nuisant à DevOps
Surmonter les anti-patrons culturels nuisant à DevOps
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet Agile
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agile
 
L'Agilité chez GEE Montréal
L'Agilité chez GEE MontréalL'Agilité chez GEE Montréal
L'Agilité chez GEE Montréal
 
Recherche lead technique désespérément
Recherche lead technique désespérémentRecherche lead technique désespérément
Recherche lead technique désespérément
 
Scrum : les sujets qui fâchent
Scrum : les sujets qui fâchentScrum : les sujets qui fâchent
Scrum : les sujets qui fâchent
 
Borghi scrum day-s
Borghi scrum day-sBorghi scrum day-s
Borghi scrum day-s
 
Large Scale Scrum
Large Scale ScrumLarge Scale Scrum
Large Scale Scrum
 
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
 
AT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillagesAT Marseille 2011 - Réduisons les gaspillages
AT Marseille 2011 - Réduisons les gaspillages
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
 
1 Le Cadre General
1 Le Cadre General1 Le Cadre General
1 Le Cadre General
 
Le Burn-Out Agile - Devoxx MA
Le Burn-Out Agile - Devoxx MALe Burn-Out Agile - Devoxx MA
Le Burn-Out Agile - Devoxx MA
 
Tour d'horizon des méthodes agiles
Tour d'horizon des méthodes agilesTour d'horizon des méthodes agiles
Tour d'horizon des méthodes agiles
 
Lean Product Development
Lean Product DevelopmentLean Product Development
Lean Product Development
 
Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite...
Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite...Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite...
Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite...
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
 
Le tableau de bord de pilotage
Le tableau de bord de pilotageLe tableau de bord de pilotage
Le tableau de bord de pilotage
 

Plus de Guillaume Saint Etienne

Ecologie du Logiciel (Craft Luxembourg 2022).pdf
Ecologie du Logiciel (Craft Luxembourg 2022).pdfEcologie du Logiciel (Craft Luxembourg 2022).pdf
Ecologie du Logiciel (Craft Luxembourg 2022).pdfGuillaume Saint Etienne
 
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...Guillaume Saint Etienne
 
des algoritmes et des hommes (ethique et code).pdf
des algoritmes et des hommes (ethique et code).pdfdes algoritmes et des hommes (ethique et code).pdf
des algoritmes et des hommes (ethique et code).pdfGuillaume Saint Etienne
 
La crise Agile chez les Developpeurs (AGrenoble2019) (1).pdf
La crise Agile chez les Developpeurs (AGrenoble2019) (1).pdfLa crise Agile chez les Developpeurs (AGrenoble2019) (1).pdf
La crise Agile chez les Developpeurs (AGrenoble2019) (1).pdfGuillaume Saint Etienne
 
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptxGuillaume Saint Etienne
 
Il n’y a pas de bons développeurs.pptx
Il n’y a pas de bons développeurs.pptxIl n’y a pas de bons développeurs.pptx
Il n’y a pas de bons développeurs.pptxGuillaume Saint Etienne
 
10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptxGuillaume Saint Etienne
 
Vendredi Tech_ la programmation fonctionnelle.pptx
Vendredi Tech_ la programmation fonctionnelle.pptxVendredi Tech_ la programmation fonctionnelle.pptx
Vendredi Tech_ la programmation fonctionnelle.pptxGuillaume Saint Etienne
 
Feedback on DDD Europe - short -event storming.pptx
Feedback on DDD Europe - short -event storming.pptxFeedback on DDD Europe - short -event storming.pptx
Feedback on DDD Europe - short -event storming.pptxGuillaume Saint Etienne
 
Crise agile chez les développeurs (frug agile 2020)
Crise agile chez les développeurs (frug agile 2020)Crise agile chez les développeurs (frug agile 2020)
Crise agile chez les développeurs (frug agile 2020)Guillaume Saint Etienne
 

Plus de Guillaume Saint Etienne (16)

Ecologie du Logiciel (Craft Luxembourg 2022).pdf
Ecologie du Logiciel (Craft Luxembourg 2022).pdfEcologie du Logiciel (Craft Luxembourg 2022).pdf
Ecologie du Logiciel (Craft Luxembourg 2022).pdf
 
musique electronique au cinéma.pptx
musique electronique au cinéma.pptxmusique electronique au cinéma.pptx
musique electronique au cinéma.pptx
 
DDD FOR POs.pdf
DDD FOR POs.pdfDDD FOR POs.pdf
DDD FOR POs.pdf
 
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
Tout ce que vous avez voulu savoir sur les Doublures sans jamais oser le dema...
 
des algoritmes et des hommes (ethique et code).pdf
des algoritmes et des hommes (ethique et code).pdfdes algoritmes et des hommes (ethique et code).pdf
des algoritmes et des hommes (ethique et code).pdf
 
La crise Agile chez les Developpeurs (AGrenoble2019) (1).pdf
La crise Agile chez les Developpeurs (AGrenoble2019) (1).pdfLa crise Agile chez les Developpeurs (AGrenoble2019) (1).pdf
La crise Agile chez les Developpeurs (AGrenoble2019) (1).pdf
 
How we can BUILD.pdf
How we can BUILD.pdfHow we can BUILD.pdf
How we can BUILD.pdf
 
des mutants dans le code.pdf
des mutants dans le code.pdfdes mutants dans le code.pdf
des mutants dans le code.pdf
 
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
 
Il n’y a pas de bons développeurs.pptx
Il n’y a pas de bons développeurs.pptxIl n’y a pas de bons développeurs.pptx
Il n’y a pas de bons développeurs.pptx
 
Living Documentation (TDD, BDD).pptx
Living Documentation (TDD, BDD).pptxLiving Documentation (TDD, BDD).pptx
Living Documentation (TDD, BDD).pptx
 
10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx
 
Vendredi Tech_ la programmation fonctionnelle.pptx
Vendredi Tech_ la programmation fonctionnelle.pptxVendredi Tech_ la programmation fonctionnelle.pptx
Vendredi Tech_ la programmation fonctionnelle.pptx
 
Feedback on DDD Europe - short -event storming.pptx
Feedback on DDD Europe - short -event storming.pptxFeedback on DDD Europe - short -event storming.pptx
Feedback on DDD Europe - short -event storming.pptx
 
Crise agile chez les développeurs (frug agile 2020)
Crise agile chez les développeurs (frug agile 2020)Crise agile chez les développeurs (frug agile 2020)
Crise agile chez les développeurs (frug agile 2020)
 
My feedback on ddd europe
My feedback on ddd europeMy feedback on ddd europe
My feedback on ddd europe
 

AGILE TOUR 2009: agilité et services

  • 1. S.A.S Software + Agile + Service 1
  • 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. Le contexte • Fabriquer du logiciel • Travailler en équipe • Satisfaire un client 3
  • 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
  • 7. Débuts industrie automobile 7
  • 11.
  • 13. Back to reality • Les constats qui fâchent 13
  • 14. L’estimation • Les plans sont généraux et manquent de précision 14
  • 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
  • 17. Adaptabilité ≠ prédictivité 17
  • 18. • Optimiser la granularité du changement 18
  • 19. vecteurs d’ajustement • Le niveau d’automatisation • Les ressources humaines. 19
  • 20. qualité = agilité + industrialisation 20
  • 21. Dualité • NOUS COMMENCONS UN PROJET • NOUS LIVRONS UN PRODUIT 21
  • 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
  • 24. ALORS COMMENT ON FAIT? 24
  • 25. ALORS COMMENT ON FAIT? On « devient » agile? 25
  • 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
  • 27. Ce que l'agilité n'est pas • Une méthode de « hippies » 27
  • 30. 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
  • 31. Client /Utilisateurs Concepteur /CP Cahier des Charges /Exigences DELTA ++ Spécifications Détaillées Deliveries DELTA -- Développeurs / Code 31
  • 32. Le problème Client /Utilisateurs Concepteur /CP Cahier des Charges /Exigences DELTA ++ Spécifications Détaillées Deliveries DELTA -- Développeurs / Code 32
  • 35. Le problème BLOQUANT BLOQUANT BLOQUANT RETARD TROP TARD!!! BLOQUé!!!!! 35
  • 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
  • 40. On ne fait plus…
  • 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
  • 43. PAS DE BIG SPEC UPFRONT 25/02/2009 43
  • 44. Pas de big upfront design 44
  • 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
  • 51.
  • 52. Mais que veut le client? 25/02/2009 52
  • 53. TOUT!
  • 54. changer la vision du projet 25/02/2009 54
  • 56.
  • 57. • Quand savez vous ce que ca va vous couter? 25/02/2009 57
  • 58. Le temps n’arrange rien 25 20 15 effort par fonctions 10 5 0 t1 t2 t3 t4 10/10/2009 58
  • 59. ALORS COMMENT ON FAIT?
  • 60. ON FIGE LE TEMPS 60
  • 61. • C’est le budget qui est fixe : • Design-to-cost (l’équivalent du backlog en « Agile moderne »). 61
  • 62. • 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
  • 63. • Mais c’est de la régie? 22/10/09 www.agiletour.com
  • 64. • Mais c’est de la régie? • NON! 22/10/09 www.agiletour.com
  • 65. • S’engager uniquement sur du temps • Est-ce satisfaisant pour le client? 22/10/09 www.agiletour.com
  • 66. • S’engager uniquement sur du temps • Est-ce satisfaisant pour le client? •NON! 22/10/09 www.agiletour.com
  • 67.
  • 68. ON FIGE LA QUALITE • zéro défaut! 25/02/2009 68
  • 69.
  • 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
  • 73. On donne des priorités 73
  • 77.
  • 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
  • 80. Le client • Créer un climat de confiance durable avec le client 80
  • 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
  • 85. ATTENTION: RISQUE DE BRUF! • Big Requirements Up Front • BRUF Leads to Significant Wastage 85
  • 86.
  • 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)
  • 90. Change For Free • Change ≠ Add
  • 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
  • 100. ROI • Valeur ajoutée • mesurée • Retour sur investissement •mesuré 100
  • 101. Se co-évaluer • Mesure • alignement • qualité • vitesse d'exécution • Nouveaux objectifs • itération suivante 101
  • 102. Adapté aux projets à risques Imposer la flexibilité pour tenir compte des changements fonctionnels 102
  • 103. MATURITE • Prestataire • Client • Mais grandir est un long processus… • … grandissons ensemble!
  • 107. AGILE
  • 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
  • 114. PAS CONVAINCU? • 2 recherches sur Google = 114
  • 115.