SlideShare une entreprise Scribd logo
B.Vinot
          Introduction aux
          méthodes agiles
Plan du cours
Les projets classiques
     Le gantt-Les méthodes d’estimation-Les cycles de développement
     Apports des technologies objet-La modélisation UML
     Unify Process
L’agilité
      Introduction
          Le manifeste agile
          Le lean
          Panorama des méthodes agiles
          Les rôles – les cycles
     Déroulement d’un projet
          Définition des besoins - Méthode de planification agile
          les itérations
              La modélisation agile -La mêlée scrum ou le stand up meeting XP - Burndown chart- Calcul de
              la vélocité de l’équipe
     Les outils agiles-TDD
     Conclusions
           Migration-Avantages-ROI- Les bilans
                                                                                                            2
Agilité : Définitions
• L’Agilité est l’habilité de créer et de répondre au
  changement dans le but d’avoir du succès dans un
  environnement d’affaires turbulent. - Jim Highsmith
• Certaines problématiques sont difficiles, certains
  individus sont difficiles. Les méthodes Agiles ne sont
  pas une garantie de succès. - Craig Larman
• Ce n’est pas la plus forte des espèces qui survit, ni la
  plus intelligente, mais celle qui s’adapte le mieux -
  Charles Darwin
• Intelligence = (2)Aptitude à s’adapter à une situation, à
  choisir en fonction des circonstances… - Larousse

                                                              3
Etes vous familier avec les cycles de dvp?




Les projets classiques

              Le gantt
    Les méthodes d’estimation
   Les cycles de développement




                                                          4
Les méthodes prédictives
                                                Et le
                                               client?
Découpe
Planifie
                                 Chef de
                                  projet
Distribue



Discute              Equipe1               Equipe2



 Réalise    Architecte         dev1         dev2



                                                         5
Estimer pour Planifier
• Ne pas faire tout seul
• Méthode des trois experts
   • (min + 2 * Moyen + Max) /4
• Méthode des trois wagons
• Faire participer l’équipe
• Tenir compte de la complexité - Fibonacci
• Hiérarchiser les fonctions
• Relativiser : Cocomo



                                              6
Planifier avec Fibonacci
                       F(n) = F(n-2) + F(n-1)




Plus c’est compliqué et plus ça …..
Et si c’est encore plus compliqué
alors ça ….. Encore plus
                                                7
Hiérarchiser les fonctions
•     Comparer 2 à 2 chaque fonction                                         F2   F3   F4   F5             F6
                                                                       F1   F2 1 F1 3 F4 2 F5 1           F1 3      6
•     A chaque comparaison est associé un poids variant entre 1 et 3         F2 F2 3 F4 2 F2 2            F6 1      6
      (1 signifiant peu de différence)
                                                                                  F3 F4 1 F5 1            F3 2      2
                                                                                       F4 F5 1            F4 3      8
•     Exemples :
        –   F2 est plus importante que F1 avec un poids relatif de 1                        F5            F5 1      4
        –   F4 est plus importante que F1 avec un poids relatif de 2                                       F6       1
                                                                                                                   27
•     Poids de la fonction 5 :
        –   Somme de toutes les cases orangées (1+1+1+1)


•     Poids de toutes les fonctions :                                  F6    3,70%
        –   Somme de tous les poids de fonction
                                                                       F3            7,40%

•     Poids relatif de la fonction 5 :                                 F5                    14,80%
        –   4 / 27 = 14,80 %
                                                                       F2                             22,22%

•     Hiérarchie des fonctions                                         F1                             22,22%

                                                                       F4                                        29,66%


    No. 8
                                                                                                                          8
Déterminer la valeur des fonctions
•     La fonction F6 représente 30 % du
      budget du projet pour un poids de 3,7                                         30%
                                                    F6   3,70%
      %
       –   Améliorer le coût de la solution, ou
       –   Supprimer la fonction du périmètre                  10%
                                                    F3      7,40%

                                                    F5               15%
                                            Coût                     14,80%

                                            Poids                        20%
                                                    F2                     22,22%

La fonction F4 représente 5 % du                    F1                   20%
budget pour un poids de 29,66 %
                                                                           22,22%

    Intégrer cette fonction dans le périmètre             5%
n
                                                    F4                              29,66%
    minimal



                                                                                             9
Le Gantt




Cocomo




                    10
Les cycles de DVP




             Winston Royce
                 1970
                                Addison Wesley
                                     1990
1980 : V
1990 : Itératif                                  11
Classique-Agile




                  12
Une arnaque ?
      Madame Soleil




« La logique est l’art de s’enfoncer dans l’erreur avec confiance ». Joseph Wood Krutch
                                                                                     13
UnifyProcess




               14
La gestion de projet
      Classique
Apports des technologies objet-Métriques
          La modélisation UML
              Unify Process



                                           15
Des preuves, des métriques(1)




                                               Des chiffres, oui mais:
     Ce qui compte ne peut pas toujours être
                                               • Simples
     compté, et ce qui peut être compté ne
                                               • Pas inventés mais mesurés
     compte pas forcément - Einstein
                                               • Beaucoup, mais pas trop
                                               • Choisi, pas imposé
                                                                   16
Apports des technologies Objet
                                      Increased
                                      Productivity

                       5              Cost savings

                   2
               2                      Improved
                                      interfaces
           6                17
       7                         11   Software reuse

      11
                                 8
           14              17         Improved
                                      application
                                      maintenance
                                      Encapsulate
                                      existing
                                      applications
                                      Develop strategic
                                      applications
                                      quickly
                                      Develop
                                      applications as
                                      revenue source      17
                                      Access new OS
Des preuves, des métriques(2)
            Les métriques de McCabe
                          C++     C++     C++      C       C       C
                          V0      V1      V2       V0      V1      V2
Average Function LOC       6,66     6,2    6,11    29,62    32,5   37,11
Min Function LOC              2       1        1       3       3       3
Avg Cyclomatic Complex     1,66    1,59    1,59     5,88    6,25    6,56
Avg Comparison Complex     0,25    0,24      0,3    1,38    1,62    2,22
Avg Logic Flow Complex     1,91    1,83    1,89     7,25    7,88    8,78
Avg Function Complexity    3,69    3,59      3,7       9    9,62   10,56
eLoc/100                   2,07     2,5    2,68     2,68    2,91    3,53
eLOC                        207     250     268      268    291      353




                                                                           18
Des preuves, des métriques(3)




                                19
Programmation fonctionnelle




                              20
Programmation objet




                      21
Les concepts Objet
• Abstraction : Classe                                           -nom
                                                                     Personne


                                                                 -age

• Encapsulation                                                  -poids
                                                                 +Manger()
                                                                 +Travailler()
                                                                 +Anniversaire()


• Héritage
                                                         Dentiste
                                                                                Boulanger


• Polymorphisme
                                                     -adresseCabinet
                                                     +Travailler()         +Travailler()



                                                    Arracher des dents      Faire du pain

// un petit pg   // un petit pg (suite)
Personne p       p=d
Dentiste d       p.Travailler()
Boulanger b      p=b
p.Travailler()   p.Travailler()                                 For each p in leSac
d.Travailler()                                                            p.Travailler()
b.Travailler()
                                          sac<Personne> leSac
                                                                                            22
La gestion de projet
     Classique
  Apports des technologies objet
      La modélisation UML
          Unify Process



                                   23
DOC-PDF UML1.3 = 4,7MB
DOC-PDF UML2.0 = 5.8 MB
                          UML : La genèse
                                   Nov-97         Sept-97             2000
             Janv-97                1.0          1.1 (OMG)             1.4
               1.0
                                   Juillet-96
                                       0.9                            2003
                                                                       2.0
                       Oct-95
                        0.8




                                                Jacobson (use case - sdl)


       Booch-93            Rumbaugh( OMT2)
                                                                             24
Un modèle : Définition



Ce qui sert ou doit servir d’objet d’imitation pour
faire ou reproduire quelque chose (petit robert)
                                                    UML Contient
                                    UML est un langage qui contient
                                    • Des éléments de modélisation:
                                      – Des classes
                                      – Des packages
                                      – Des méthodes
                                      – Des Acteurs…..
                                    • Des diagrammes
                                      – Classes, UC, Automate, Activité, …..




          Top Model                                                            25
Les diagrammes UML


• Diagramme de use case
• Diagramme de classes
• Diagramme de structure
• Diagramme d'objets
• Diagramme dynamique
    • Diagramme d'interaction
         • Diagramme de séquence
         • Diagramme de communication
    • Automates
    • Diagramme d'activité
• Autres diagrammes
    • Composants et Déploiement
                                            26
Les diagrammes UML




                 27
Diagramme de Use case
                       Les acteurs
Un acteur est un rôle d’un ou plusieurs objets
situés à l’extérieur du système et qui interagissent
avec lui pour remplir une fonctionnalité donnée
de ce système.
Un acteur caractérise le rôle joué par un objet à                   Utilisateur

l’extérieur du système.



         • Un acteur parle au système (Acteur principal)
         • Le système peut parler à un acteur (Acteur secondaire)
         • Un acteur est :
              • Un humain (via une IHM)
              • Du soft
              • Du hard
              • Le temps

                                                                                  28
Diagramme de Use case
                  Use Case
Un Cas d’utilisation ( use case ) est une
fonctionnalité remplie par le système et qui se
                                                                    faire qqchose
manifeste par un ensemble de messages échangés
entre le système et un ou plusieurs acteurs.




                                                    Protocole
                                                       API
                     IHM
                              VerifierBonneMarche
       Utilisateur                                          CapteurTemperat
                                                                  ure

   Acteur primaire         Une fonctionnalité interne       Acteur secondaire
                                  Au système
                                                                                    29
Diagramme de Use case
             Description d'un Use Case
                                    (3-5 pages)
•   Titre et numérotation        Ce n ’est pas une
•   Résumé                     description formelle
                             Mais doit être très détaillé
•   Les acteurs
     – Acteur principal
     – Acteurs secondaires     Ceci est l ’usage
•   Pré-conditions            mais ne fait partie
•   Description
                              de la norme UML
•   Exceptions
•   Post-conditions



          Scenario



                                                            30
Diagramme de Use Case
                       Appeler / numéro       <<include>>




                                                                GSM Envoyer
                                           <<include>>
  Utilisateur



                       Appeler / contact




                                                                                              Antenne HLR




                                                Recevoir appel




                   Gerer les contacts                             A1                                        B3
                                                                                         B2

                                                  <<include>>          <<include>>
                                                                                     <<include>>        <<include>>

Configurateur
                                                         A2                   A3                   B1
                       Préparer
                                                                                                                 31
Utilisation des Use case
    Manger




Descriptions




               Distribuer le comportement des fonctionnalités
               aux méthodes des objets


                                                                32
Des mauvais UC




Use cases are wonderful but confusing. People, when asked to write them, do not know
what to include or how to structure them. There is no published theory for them.
This paper introduces a theory based on a small model of communication,
distinguishing "goals" as a key element of use cases. The result is an easily used,
scaleable, recursive model that provides benefits outside requirements gathering:
goals and goal failures can be explicitly discussed and tracked; the goals structure
is useful for project management, project tracking, staffing, and business process
reengineering. The model and techniques described here have been applied and
evaluated on a relatively large (50 work-year, 200 use-case) project.
                                                                                  33
Use Case : Exercice
Une société de vente par correspondance vous demande de développer son
système informatique. Ce système doit pouvoir prendre en compte des
commandes passées par la poste et des commandes passées par internet. Il
doit suivre les expéditions qui ne sont effectuées que si le paiement est OK.
Les paiements se font par carte bancaire dans le cas d'internet et par chèque
dans le cas de la poste. Les paiements sont validés par un système bancaire
appartenant à la société et existant. Il faut récupérer ce système. Le
nouveau système est chargé aussi de la gestion de stocks, lorsqu'un article
atteint un seuil minimal, alors il faut passer une nouvelle commande au
fournisseur adéquat. A la réception de la commande, la mise à jour de la
base est faite par un employé. Dans le cas d'un paiement accepté et de stock
disponible, l'expédition est faite par un robot existant au quel il suffit de
passer les coordonnées du client, et la liste des produits achetés. En cas
d'indisponibilité, une lettre doit être envoyé au client.


                                                                                34
Notion de stéréotypes
     Un stéréotype est une nouvelle classe d’un élément de
     modélisation qui est introduit au moment de la
     modélisation. Cela représente une sous classe d’un élément
     de modélisation existant avec la même forme, mais avec
     une intention différente.



• Les stéréotypes font partie des mécanismes d’extensibilités, prévus
           par UML.
• Une interface est un stéréotype

• On peut stéréotyper les classes, les associations, les packages, …..
• On peut associer un nouvel icône pour chaque nouveau stéréotype.

                 <<nouveauStereotype>>
                           Z



                                                                         35
Diagramme de classe

         Un diagramme de classe montre la structure statique
         du modèle, les choses qui existent, leur structure
         interne et les relations aux autres choses.



•   Statique :
     – Ne pas utiliser de verbes d'action pour relier les classes
     – Une classe isolée est une classe inutile
     – Doit être vrai tout le temps                                 Les choses qui existent
     – Représente LE programme                                                  Maison




     – On ne peut pas tout montrer sur un seul schéma                                    Moto




                                                                                                Garage
                                                                       Personne




                                                                                                    Personne




                                                                     Tricycle




                                                                                                               36
Diagramme de classe
      Les classes

                    UneClasse
-attributPrive
+attributPublic
#attributProtected
+attributDeClasse
+attributTypé: int
+attributTypéInit: int = 56
+Operation()
+OperationDeClasse()
+OperationAvecParam(par1: int, par2: boolean): int
+OperationAbstraite()




                                                     37
L’héritage

                Vehicule                      L’héritage s ’appelle généralisation
               +carteGrise                    en UML
               -marque
               #nbPassagers
                                              EST UN



  Avion                         Bateau
+ailes                        +moteurDiesel
+reacteur[2]
Les interfaces
    Client          Client



                             Une interface permet à un objet (le Client)
                             De faire faire quelque chose (Fqq) à un
                             Objet de type A, sans savoir qu’il est un A.
<<interface>>                Il sait seulement qu’il est de type FqqAble
  FqqAble
                   FqqAble
+Fqq()
                             On a remonté le niveau d’abstraction.
                             On utilise une interface pour imposer à des
                             Classes différentes d’implémenter une ou
                             Plusieurs opérations.
     A               A

+Fqq()          +Fqq()




                                                                            39
Les associations
Les associations représentent des relations structurelles
entre classes d’objets. Une association symbolise une
information dont la durée de vie n’est pas négligeable par
rapport à la dynamique générale des objets instances des
classes associées. La plupart des associations sont binaires,
c’est-à-dire qu’elles connectent 2 classes. Certaines sont
refléxives.


                                              +h


                                              Personne

                                                         +f



              Voiture         4      Roue




                                                                40
Diagramme de classe : Associations
                             Est Employée par
     Personne                                            Societe                Nom d'association

                            Est Employée par
     Personne                                            Societe                Nom de rôle
                       -employe           -employeur




                1..*                        0..1
 Personne                                          Societe              Cardinalité-Multiplicité
               -employe              -employeur


      Personne                                             Societe
employeur : Societe                                 employe : ListeOfPersonne


               1..*
Personne                                           Societe              Navigabilité
               -employes

Personne                                           Societe
                                            employes : Personne


                                                                                                    41
Diagramme de classe
          Dépendance



Depenser
i = Banque::GetInstance()->DonnerSolde();
Acheter(i);
Voler
b = new Banque();
i = b->DonnerSolde();
Economiser (p : Banque)
p->Deposer(10000);




                                            42
Diagramme de classe : Exercice1
            Immeuble
                                                                   Gardemanger

                                     Appartement
          Lapin
                                                                                 Personne


                  Famille                     Pièce                Chien
                                                                                     Mariage


Cuisine                 CompteBanquaire               Nourriture
                                                                                   Animal



                                                       Bail
                            Whisky
                                          Salon                                    acte de propriété
     Chat




                                                                                                       43
Diagramme de classe : Exercice2




                                  44
Diagramme dynamique

• Diagrammes d'interaction (Séquence collaboration) servent à
     montrer comment les objets parlent les uns aux autres.
     Ils montrent le déroulement d'un ou d'une partie d'un Use case
     (cas nominal, cas des exceptions, …)
     Un objet (l’émetteur) envoi un message à un autre (le récepteur).
     Le récepteur doit avoir une opération correspondante au message.

• Automates servent à montrer le comportement d'une classe qui
    réagit différemment selon son état.

• Activités montrent le déroulement d'une méthode d'une classe ou
     celui d'un Use case




                                                                         45
Diagramme de Séquence
                 : C1                : C2             : C3


: A1

       Oper1()
                                                                           new : C3
                        Oper3()


                                            Oper2()




                        retour


                                  Oper1()

                                                             <<create>>
                                                                C3()


                                                                                      Oper2()


                                                             <<destroy>>
                                                               Delete()




                                                                                                46
Diagramme de Séquence (UML2.0)
                                                                                                    Entreprise                              Employe
                                                                                                                                *
                                                                                                                                        +salaire
                                                                                                  +CalculerSalaire()   -lesEmployes
                                                                                                                                        +CalculerSalaire()



                                                                                  : Commerciaux
                                                             : Employe
                          : Entreprise

                                                                                                                                        Commerciaux

      : FinMois                                                                                                                       +commission
                                                                                                                                      +CalculerCommission()
            CalculerSalaire()



  loop pour chaque employe

                                         CalculerSalaire()


                                    alt commercial


                                                                   CalculerCommission()




                                                                                                                                                              47
Automate
• Un automate est accroché à une classe et est composé d'états et
de transitions. Les transitions permettent de passer d'un état à
un autre …




                                      Off
                         Arret                    Marche
                                         On

                                 Casse
                                              Casse




                                                                    48
Automate
                        État & Transition
                                            Action en entrant dans l'état
        Etat
                                             Action en sortant de l'état
entry/ Action1
exit/ Action2                                Action déclenchée sur réception de Ev1
on Ev1/ Action2
do/ Activité                                   Activité

               Événement qui déclenche la transition
                             Garde

E1               Ev1( a1,a2 )[ i == 0 ] / ActionDeTransition ^Cible.SendEv2(a3, a4)   E2



                                         Action effectuée sur la transition
                                          Envoie de Ev2 à un objet Cible


Rmq : Le langage d’action (UML1.4) est remplacé par 50 types d’action
                                                                                           49
Automate imbriqué
                                                               After5
                      Arret

                                       Off
                                  On


                                                      Marche


Ouvrir[ cuve vide ]
                                       Lavage
                                                                              Essorage

                                                After15
PorteOuverte                                                        After10
                                                          Rinçage




         Fermer               H
Automate : exercice
                                          E1


         ST1             E1 / i++
                                                  ST2
                                                               E1
                                          entry: i++
 entry: i = 0
 exit: i++
                                          exit: i++            E3
                                          on E4: i ++
                                                               E1
                    E1                                         E3
                                                               E1
                                               E3[ i == 5 ]
                                                               E2
                                    E2
                                                               E1
                                                               E2
    ST4                                        ST3            E3
on E2: i = i - 2          E1

                   E3
                                     E3




                                                                    51
La gestion de projet
     Classique
  Apports des technologies objet
      La modélisation UML
          Unify Process




                                   52
UP : La base

PU est à base de composants
PU utilise UML
PU est piloté par les cas d’utilisation
PU est centré sur l’architecture
PU est itératif et incrémental

                                      53
UP & RUP
              Unify Process (Énorme process pour tous)




                      RUP Rational Unify Process
                      Process customisé à partir du UP
                      C'est un outil (site web, customisable)



  Custom




AirFranceUP     XUP

                                                                54
OpenUP
                            RUP : Principes
         7 rôles (environ 45 pour RUP)
         20 artefacts (plus de 80 pour RUP)
         18 tâches (plus de 150 pour RUP)




                                              55
Les artefacts
• Activité de gestion de projet
  – Comptes rendus, planning d’activité, ….
• Résultats
  –   Modèles
  –   Code source
  –   Spécifications
  –   …..


                                              56
Les rôles
•   Les analystes (exigences)
•   Les développeurs
•   Les testeurs
•   Les managers (gèrent le processus)
•   Le chef de projet
•   Les autres (Client, MOA, stakeholder, ….)



                                                57
Les activités
•   Modélisation métier
•   Les Besoins
•   Analyse et conception
•   Implémentation
•   Tests
•   Déploiement
•   Gestion de configuration   Etudié plus tard

•   Gestion du projet
•   Environnement

                                                  58
BPM




      59
Modélisation métier
                 Stéréotypes UP


Client                   business use case        Fournisseur




         Les objets de                       Les employés
         L’entreprise       Les process




                                                                60
Organisation des modèles (UP)
                                                               uc1
    Définition des besoins



                                             VOPC
              Les sources                           C1                     C2




                                                              Composant1

        Les UC realization (Documentation)
                                                              residents
                                                         C1
                                                         C2




    Les composants (physiques et logiques)                      PC

    Les machines                                          components
                                                          Composant1            61
Exemple d’un workflow




                        62
Processus traditionnel
• Gros classeur sur l’étagère des développeurs
• … Ramasse la poussière …
• Difficile à comprendre et à utiliser, vu comme
  une surcharge (gaspillage)




                                                   63
Motivation


70%            45%




                     64
Les bureaux Google




                FaceBook




*****google zurich****** http://www.dailymotion.com/video/x4zlcv_merci-google_lifestyle
                                                                                   65
Le processus comme un produit
• Pas un simple livre, pas une autre OOAD
  méthode
• Fourni comme un site web (avec les sources)
• Constamment amélioré
• Base de connaissances
  – Navigation graphique, moteur de recherche, index
  – Guides, templates de documentation, aide à
    l’utilisation des outils

                                                   66
67
RUP : Ses forces
•   Cadre générique
•   Référentiel de bonnes pratiques;
•   Gestion des risques dans les projets;
•   Cadre propice à la réutilisation;
•   Approche basée sur l’architecture;
•   Traçabilité à partir des Uses Cases jusqu’au
    déploiement.
                              Ex : IBM Tivoli ITUP

                                                     68
RUP : Ses faiblesses
• Coût de personnalisation souvent élevé;
  – Autres logiciels propriétaires (Rational)
    indispensables;
• Très axé processus :
  – peu de place pour le code et la technologie ;
• Vision non évidente ni immédiate

                                        DEVELAY Isabelle
                                        EDORH-A. Semeho
                                        GUIBOUT Nicolas
                                                           69
RUP : Conclusion
• RUP considéré comme:
   – un framework de processus génériques;
   – un métaprocessus;
• Démarche itérative
   – Réduction des risques;
• Facile à expliquer et à valider (les livrables);
• Finalement pas très populaire…
                                     DEVELAY Isabelle
                                     EDORH-A. Semeho
                                     GUIBOUT Nicolas
                                                        70
L’Agilité

     Introduction
Le lean software dvp



                       71
Une petite vidéo


            David Gageot –
            Directeur Technique –
            Valtech Technology




E:CoursAgilitéVideoValtech) 40mn
                                       72
Qu’est ce qu’une méthode agile(1)
Deux caractéristiques fondamentales
  – Adaptatives plutôt que prédictive
     • Favorables au changement
     • Planification plus souple
        – Faite par l’équipe et non imposée par le chef
  – Orientée vers les personnes plutôt que vers les
    processus
     • Travailler avec les spécifités de chacun
     • Responsabilité, confiance


                                                          73
Qu’est ce qu’une méthode agile(2)
• Délivrer rapidement et très fréquemment des versions
  opérationnelles, pour favoriser un feed-back client
  permanent
• Accueillir favorablement le changement
• Assurer une coopération forte entre client et développeurs
• Garder un haut niveau de motivation
• Le fonctionnement de l’application est le premier indicateur
  du projet
• Garder un rythme soutenable
• Viser l’excellence technique et la simplicité
• Se remettre en cause régulièrement
• Ecouter le client mais savoir dire non

                                                            74
Les bureaux agiles




  Important - Symbolique
                           75
Nous découvrons de meilleures
   façons de développer des
Logiciels en réalisant ce travail
                                     Le manifeste agile
et en aidant les autres à le faire         17 Personnes (2001)
                                           4 Valeurs
                                           12 principes




                                             Kent Beck XP-Junit
                                             Ward Cunningham wiki
                                             Jeff Sutherland scrum
                                             ………                   76
Manifeste agile : Les valeurs
•   L'équipe (« Personnes et interaction plutôt que processus et outils »)
    Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens
    plutôt qu'une équipe composée d'individualistes, même brillants.
    La communication est une notion fondamentale.
•   L'application (« Logiciel fonctionnel plutôt que documentation complète »)
    La documentation représente une charge de travail importante, mais peut pourtant être néfaste si
    elle n'est pas à jour.
    Transformer la question : « avez-vous de la documentation ? » en « mais que recherchez-vous
    comme information ? »
    Commenter abondamment le code lui-même (si besoin)
    Transférer les compétences au sein de l'équipe (communication).
•   La collaboration (« Collaboration avec le client plutôt que négociation de contrat »)
    Le client doit être impliqué dans le développement.
    On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes
    du client.
    Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à
    ses attentes.
•   L'acceptation du changement (« Réagir au changement plutôt que suivre un plan »)
    La planification initiale et la structure du logiciel doivent être flexibles.
     Les premières versions du logiciel vont souvent provoquer des demandes d'évolution.


                                                                                                        77
Manifeste agile : Les 12 principes
1.    Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels
      utiles.
2.    Le changement est bienvenu, même tardivement dans le développement. Les processus agiles
      exploitent le changement comme avantage compétitif pour le client.
3.    Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec
      une tendance pour la période la plus courte.
4.    Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet.
5.    Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont
      elles ont besoin, et croyez en leur capacité à faire le travail.
6.    La méthode la plus efficace de transmettre l'information est une conversation en face à face.
7.    Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
8.    Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires,
      développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
9.    Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.
10.   La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
11.   Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-
      organisent.
12.   À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste
      son comportement dans ce sens.



                                                                                                         78
Assemblé nationale (30-4-10)
• Ch. Vanneste (député du Nord)
  – Etude Sofres : pourquoi travailler?
     • Anglais    des sous
     • Allemands  Epanouissement
     • Français  Contacts humains
• Direction HSBC : ce qui manque aux
  entreprises françaises:
  – Innovation
  – Responsabiliser les salariés
                                          79
(1950)




              L’Agilité

              Introduction
         Le lean software dvp



                                80
Lean : Philosophie
Le LEAN est principalement une approche managériale pour
   optimiser le système de production
– Optimiser la chaîne de création de valeur ajoutée
   (sous-traitants compris)
– Eliminer les gaspillages du flux de production
   – Push-Pull
   – Just in time (pas de code avant que le test le demande)
–Etre discipliné sur les prises de décision (Le plus tard
   possible)
– Volonté de perfection à chaque étape (Stopper la chaîne)
– S’appuyer sur les facultés d’adaptation des individus (boite à
   idées)

                                                               81
Kanban




         82
Lean : Les 7 concepts
– Eliminer les gaspillages
– Améliorer le système
– La qualité de l’intérieur
– Reporter la décision
– Livrer rapidement
– Respecter les personnes
– Créer la connaissance
http://www.youtube.com/watch?v=Dl4dcLbNlgo&f
  eature=related
                                           83
Lean : Gaspillage
Shigeo Shingo (1950)
1.   Stock
2.   Surproduction
3.   Tâches inutiles
4.   Déplacement
5.   Transport
6.   Attente
7.   Défauts
http://www.tv4it.net/jusquou-le-lean-peutil-sappliquer-a-
     linformatique--permalink-8907.aspx                     84
Lean (LSD) : Gaspillage
Shigeo Shingo (1950) LSD : Mary Poppendieck (2003)
1.   Stock             1. Travail non terminé
2.   Surproduction     2. Sur spécifications
3.   Tâches inutiles   3. Processus…
                       4. Changements de priorité,
4.   Déplacement          changer de tâche
5.   Transport         5. Transmission d’informations
6.   Attente           6. Retards
7.   Défauts           7. Défauts
                                                     85
L’Agilité

Panorama des méthodes agiles




                               86
Les méthodes agiles : Panorama




                                 87
Taille des projets
1-2 ans & 6-12 personnes  Couper les projets




                                                88
Les méthodes agiles : Contraintes




                                    89
eXtremPrograming
• KentBeck (1996) Paye de Chrysler
• Les 4 valeurs de XP : CRSC
  – Communication
  – Retour-FeedBack
  – Simplicité
  – Courage




                                     90
CRSC
•   Communication
     – Client-Equipe
     – Programmeur-Programmeur
     – Equipe-Extérieure (indicateurs du projet)
•   Retour - Feedback
     – Livraison fréquente
     – VNR
     – Avancements objectifs
     – Le client est là
•   Simplicité
     – pas de sur spécifications
     – Code toujours aussi petit et simple que possible
•   Courage
     – De dire que on s’est trompé
     – De revenir en arrière
     – De faire du TU
     – D’annoncer les soucis


                                                          91
Les principes de base

      • Seul le code source fait foi, il possède une odeur,
              appartient à l’équipe, il contient la doc
      • L’important c’est le programmeur (ne pas dépasser 40H/S)
      • Faire le plus simple possible
      • Restructurer dès que nécessaire
      • Pratiquer la programmation par paire
      • Les spécifications sont des « histoires d’utilisateurs »
      • La planification est un jeu
      • Livrer fréquemment
      • Tester donc intégrer encore, toujours et tout le temps
      • Être courageux

B.Vinot
Les rôles ds XP(1)
• Développeur (100%)
      • travaille en binôme, communique
      • doit être autonome
      • a une double compétence : développeur – concepteur
• Client (25-75%)
      • doit apprendre à exprimer ses besoins sous forme de user stories
      • a à la fois le profil de l'utilisateur et une vision plus élevée sur le problème et
            l'environnement du business
      • doit apprendre à écrire les cas de tests fonctionnels
      • est dans la salle
• Testeur (50%-100%)
      • a pour rôle d'aider le client à choisir et à écrire ses tests fonctionnels
• Tracker – Rapporteur (10-20% = 30 mn par développeur tous les 2 jours + qq réunions)
      • aide l'équipe à mieux estimer le temps nécessaire à l'implémentation de chaque
            user story
      • contrôle la conformité de l'avancement au planning


                                                                                         93
Les rôles ds XP(2)
• Coach (100% au début, puis 50%, puis 10%)
     • recadre le projet
     • ajuster les procédures agiles
     • doit intervenir de la manière la moins intrusive possible
     • ne doit pas s’occuper du projet
     • n’est pas là tout le temps
• Consultant – Expert (0-100%)
     • n'apporte pas de solution toute faite
     • apporte à l'équipe les connaissances nécessaires pour qu'elle résolve elle-même les
           problèmes
     • doit être un formateur
• Manager (10-25%)
     • doit croire à l’agilité
     • apporte à l'équipe courage et confiance
     • C’est le chef hiérarchique
     • Demande des comptes


                                                                                       94
95
Combinaison des rôles ds XP




 Rmq : si plusieurs clients, Ils doivent parler d’une seule voie




                                                                   96
What is Scrum? Jeff Sutherland
                                                              Sutherland
                                                                 1993

         Qu’est ce que Scrum?
         • Pas une méthode
         • Pas un process
         • Pas un ensemble de procédures


         • C’est un framework ouvert de dvp
                comportant un ensemble de règles
         • The rules are constraints on behavior that cause
              a complex adaptative system to self organize
              into an intelligent state
         • Il permet à une équipe moyenne de s’organiser
                    pour travailler 10 fois mieux



                                                                  97
Scrum : Le cycle de vie
                            DVP
                            Tests




 UC
           Planning
User
             game
story
                                    98
Scrum : Backlog- BurnDown




                            99
Bob: « Voilà j’ai terminé de
                 développer ce module,

Scrum : Kanban   c’est déployé ! »
                 Gérard: « Ben je vois
                 rien…? »
                 Bob: « Ha en tout cas chez
                 moi ça marche… »
                                  DoD




                                      100
Definition Of Done
   Développement                            Migration des données (structures +
                                            données)

   Support IE7 + FF3                        Test Seleniums écrits

   Support IE6                              Test Seleniums passé avec succès

   Support “Navigateurs Home Page”          Test Unitaires écrits

   Déployé sur Staging                      Test Unitaires passé avec succès

   Tests de régression ok (tous les tests   Multilingue et traduction ok
   passent)

   Documentation (dossier                   Démarches à effectuer auprès de
   d’hébergement,…)                         l’infrastructure (pour la Prod ou autres.
                                            Ex: url, connexion db,ftp,…)

   Dépendance avec d’autres acteurs         Visualiser sur le mur


Si la définition de « terminé » vous semble confuse Mettez au début un champ
«définition de terminé» pour chaque US.
TODO : Exo
•   Aujourd’hui je décide de laver ma voiture
•   En allant vers le garage, je remarque qu’il y a du courrier sur la table d’entrée
•   Je décide de jeter un œil au courrier avant de laver la voiture, il contient des factures et des publicités
•   Je jette les publicités dans la corbeille à papier et réalise que la corbeille est pleine
•   Je repose les factures sur la table car il faut que je vide la corbeille
•   Mais comme la poubelle est proche de la boîte aux lettres, je me dis que je pourrais économiser un trajet
    en postant mes factures et je décide donc de préparer d’abord le règlement des factures
•   Je prends mon carnet de chèques et trouve sur le bureau la canette que j’avais commencé à boire.
•   Je me dis qu’il faut que j’enlève la canette pour ne pas la renverser accidentellement sur mes factures
•   Je remarque que la canette est tiède et qu’il vaudrait mieux la remettre au frigo pour la rafraîchir
•   En me dirigeant vers la cuisine, le vase sur le comptoir me saute aux yeux : les fleurs manquent d’eau
•   En posant la canette sur le comptoir, je manque d’écraser mes lunettes que je cherchais depuis ce matin
•   Je me dis que je devrais ranger mes lunettes … mais avant, j’ai le temps de donner à boire aux fleurs
•   Je repose mes lunettes sur le comptoir, remplis un pichet d’eau et soudain, j’aperçois la télécommande qui
    traîne sur la table de la cuisine
•   Je me dis que ce soir je vais la chercher partout et que je ne me souviendrais plus qu’elle est dans la
    cuisine
•   Je décide donc de la ranger au salon … mais avant, je vais donner à boire aux fleurs
•   Je remplis le vase au tiers car malheureusement je renverse beaucoup d’eau sur le sol
•   En allant chercher une serpillère, je remets la télécommande sur la table de la cuisine
•   Je nettoie le sol puis range la serpillère
•   De retour dans l’entrée … je me demande ce que j’avais l’intention de faire
•   Cela va ma revenir, en attendant, je vais lire mes mails
•   Mais avant je …
                                                                                                            102
Todo – encours - fini


TODO-> DoD : Exo


     Faire qq chose
     ------------------------
     Comment tester
     Le résultat
     ------------------------
     Valeur = 0 - 5O
      Urgent = 0 – 5
      Estimation = 0-40




                                             103
Planning Game


                                 Faire qq chose
                                 ------------------------
                                 Comment tester
                                 Le résultat
                                 ------------------------
                                 Valeur = 0 - 5O
                                  Urgent = 0 – 5
                                  Estimation = 0-40




                                                            104
Et Maintenant Estimer
Kanban & US & DoD
Laver voiture               Vider corbeil              Régler facture             Canette frigo
------------------------    ------------------------   ------------------------   ------------------------
Ma femme dit:               Corbeil vide               Chèques débités            Canette froide
« elle est propre »         Rien par terre
------------------------    ------------------------   ------------------------   ------------------------
Val= 50 Urg=2 E=25          Val= 2 Urg=2 E= 2          Val= 5 Urg=1 E=40          Val= 2 Urg=5 E= 5




Arroser fleurs              Ranger telecom.            Ranger lunettes            Lire mail
------------------------    ------------------------   ------------------------   ------------------------
Le vase est plein d’        La telecom. est sur        Les lunettes sont
     eau                    La table du salon          Dans la chambre
------------------------    ------------------------   ------------------------   ------------------------
Val= 3 Urg=4 E=3            Val= 5 Urg=4 E=1           Val= 1 Urg=2 E=1           Val= 2 Urg=2 E= 15
                                                                                                  105
Et Maintenant Planifier
Planification
Laver voiture              Vider corbeil              Régler facture             Canette frigo
------------------------   ------------------------   ------------------------   ------------------------
Ma femme dit:              Corbeil vide               Chèques débités            Canette froide
« elle est propre »        Rien par terre
------------------------   ------------------------   ------------------------   ------------------------
Val= 50 Urg=2 E=25         Val= 2 Urg=2 E= 2          Val= 5 Urg=1 E=40          Val= 2 Urg=5 E= 5

     50/25 = 2                   2/2 = 1                    5/40 = 0,125             2/5 = 0,4


Arroser fleurs             Ranger telecom.            Ranger lunettes            Lire mail
------------------------   ------------------------   ------------------------   ------------------------
Le vase est plein d’       La telecom. est sur        Les lunettes sont
     eau                   La table du salon          Dans la chambre
------------------------   ------------------------   ------------------------   ------------------------
Val= 3 Urg=4 E=3           Val= 5 Urg=4 E=1           Val= 1 Urg=2 E=1           Val= 2 Urg=2 E= 15

      3/3= 1                     5/1 = 5                    1/1 = 1                           106
                                                                                         2/15 = 0,13
Les rôles dans Scrum(1)
Directeur de produit : Client
• Le Directeur de produit, ou Product Owner en anglais, représente les clients et les
    utilisateurs. Ses responsabilités se bornent à l'établissement des limites du projets et de
    chaque itération.
• Il définit les fonctionnalités du produit. Voici une liste de ses responsabilités :
      – Choisit la date et le contenu de la release
      – Responsable du retour sur investissement
      – Définit les priorités dans le backlog en fonction de la valeur « métier »
      – Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire
SCRUM Master : Coach + Manager + tracker
• Le SCRUM Master représente le management du projet. Il interviens dans le cas ou une
    situation ou un événement peut empêcher ou retarder la progression du travail prévu. Ce
    n’est pas un maître.
• Voici quelques unes de ces caractéristiques :
      – Responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum
      – Résout des problèmes, remédier aux imprévus
      – S'assure que l'équipe est complètement fonctionnelle et productive
      – Facilite une coopération poussée entre tous les rôles et fonctions
      – Protège l'équipe des interférences extérieures                                            107
Les rôles dans Scrum(2)
Equipe SCRUM / SCRUM Team
• Une bonne équipe SCRUM est assez réduite et comporte finalement 5 à 10
   personnes. L'échange est un atout primordial dans l'utilisation de SCRUM, il faut
   donc garder l'aspect dialogue au sein de son équipe de développement.
• Les caractéristiques d'une bonne équipe :
    – Regroupant tous les rôles : Architecte, concepteur, développeur, spécialiste
       IHM, testeur, etc.
    – A plein temps sur le projet, de préférence
    – Exceptions possibles (administrateur, …)‫‏‬
    – Organisation autonome
    – Equipe cross-fonctionnelle
• La composition de l’équipe est fixe pendant un sprint

Il n’y a pas de chef de projet
• Le chef = PO + Equipe




                                                                                       108
Scrum : Une release



      Durée planif sprint:                   Time Boxing
      2*N (N = nb de semaines du sprint)



  • Un sprint n’est pas un sprint
  • Sprint de début de release
  • Sprint de stabilisation
  • Le PO doit anticiper le sprint suivant
  • Un sprint = 40 tâches
  • Une tâche = 1-2 jours max
  • Un backlog = 50 US
                                                      109
Scrum : sprint




http://www.axosoft.com/ontime/videos/scrum
                                             110
Le test Nokia
                                   % des personnes ayant trouvé une des
Q 1 : Itération
                                         deux meilleures réponses
Q 2 : Pratique des tests                    84

Q 3 : Spécifications                                                                                64                    67
                                                                                                              57,5
Q 4 : Product Owner
Q 5 : Backlog de produit                                          37,5
                                                      27,5
Q 6 : Estimation                                                              24,5
                                                                                          18
                                                                                                                                    14
Q 7 : Sprint Burdown Chart
Q 8 : Dérangement de l'équipe          Q1        Q2          Q3          Q4          Q5        Q6        Q7          Q8        Q9
Q 9 : Équipe
                                    Q 1 : Itération
                                    1. Pas d'itération
                                    2. Itération > 6 semaines
Bas Vode                            3. Durée variable < 6 semaines
Jeff Sutherland                     4. Itération de durée fixe 6 semaines
                                    5. Itération de durée fixe 5 semaines
                                    6. Itération de durée fixe 4 semaines ou moins
                     test nokia-ScrumBut
                                                                                                                                         111
Comparaison XP-Scrum
                             XP (programmation)            Scrum (process)
Client est ds la salle       Oui                           Non
                                                           Représenté par le product
                                                           Owner
Techniques de programmation Oui (Prog Objet)               Peu
                             Junit                        Test
 XP est le roi              Refactoring                  Génération automatique,
                             Binôme                       graphique, C , Javascript,….
                             Simple
Gestion de projet            Peu                           Oui
                             Tracker                       Velocité
 Scrum est le roi            Planing game                BurnDown chart
Durée des itérations         Autour de 2 semaines          Autour d’un mois (En baisse)

Adaptable                    Pas pendant les 3 premières   Oui
             H               itérations
       XP          SCR             Mélanger les deux
                                                                                  112
       O     RUP    P              Un scrum meeting
Feature Driven Development
        5 processes




       Inventée par Peter Coad
                                 113
FDD : Les rôles

Principaux rôles
                      Autres rôles
• Project manager
                      Release manager
• Chief architect     Language guru
                      Build engineer
• Domain experts      Tool smith
• Dev. manager        System admin
                      Testers
• Chief               Deployers
  programmers         Tech writers

• Class owners

                                        114
DSDM : Les principes
• implication active des utilisateurs
• équipes autorisées à prendre des décisions
• produit rendu tangible aussi souvent que possible
• L'adéquation au besoin métier est le critère essentiel
         pour l'acceptation des fournitures
• Un développement itératif et incrémental permet de
         converger vers une solution appropriée
• Toute modification pendant la réalisation est réversible
• besoins définis à un niveau de synthèse
• tests intégrés pendant tout le cycle de vie
• esprit de coopération entre tous


                                                             115
DSDM : Le cycle de vie




                         116
Les rôles ds DSDM

Sponsor exécutif : Manager
Visionnaire : Manager
Utilisateur ambassadeur : Client
Utilisateur conseiller : Client-Tracker
Chef de projet : Manager
Coordinateur technique : consultant - expert
Chef d’équipe : Manager
Développeur
Facilitateur : Coach
Rapporteur : Tracker

                                               117
Crystal

Méthodes créées par Alistair Cockburn (Expert UC)
• Importance de la Communication et du feed-back client
• Releases fréquentes
• Deux grandes phases
    • Conception et planning
    • Itérations
• Clear crystal : Adaptée à des équipes
         de 6-8 personnes maximum




                                                          118
Le chef de projet Agile




la qualité essentielle du leader sera le charisme plus que l’autorité.
                                                                         119
Le cycle de l’agilité
Les 3 rythmes :
• Le rythme du projet
• Le rythme de l’itération, qui définit les étapes de réalisation majeures du projet.
• Le rythme journalier, qui montre la progression au sein de l’itération.


Ces rythmes suivent la même progression :
• préparation,
      • Une idée claire (sinon précise) de l’objectif à atteindre.
      • Une façon de vérifier que la réalisation atteint l’objectif.
• réalisation (laisser faire l’équipe)
• retour d’expérience ,
• adaptation.




                                                                                        120
Mise en place du process
•   Version
     – Temps fixe : 2-6mois (Préféré)contenu à définir
     – Contenu fixe durée à définir
•   Itérations-Durée : fixe 1-6 semaines
     – Taille de l’équipe fixe
•   Choix des indicateurs
•   Méthode
     –   Tests automatisés, Intégration continue
     –   Moins de code, qualité, binôme, refactoring
     –   Itérations courtes, commencer par 4 semaines, puis finir par 2
     –   Implication du client , sur place à 25 ou 50%, représentant de la MOA
•   local, personnes, outils,…
•   Ce processus évoluera dans le futur (adaptable par l’équipe à la fin de chaque
    itération)

         Chaque équipe a un process différent  plus de process d’entreprise


Exemple : Une équipe de 5 personnes, des itérations de 10 jours, 5 itérations par Version

                                                                                     121
L’Agilité – Déroulement d’un
             projet
     Définition des besoins
         UC-User Story
          Planification

                               122
Un Problème sur deux!
                                Client
             Utilisateurs
Client

                                 MOA
                                (chefs)
                MOAD

                                 MOE
            Analystes       (Chef de projet)
           Architectes
Dev          Experts              Dev
         Programmeurs
             testeurs

                                               123
Une révolution
Ne pas tout étudier, mais commencer le plus
  vite possible
Faut-il toujours prendre un billet A-R?
40% à 70% des infos suffisent pour se lancer
• François 1° (Androuet du cerceau)
• Napoléon
• Colin Powell


                                               124
Définitions des besoins - DVP
                                    Besoin global (10%) : Liste des UC ou US + Planification


                                    Détail du 1° tiers : Scénario des UC – Discussion des US
                                              Réalisation du 1° tiers
   It1

                                           It2
Détail du 2° tiers
          Réalisation du 2° tiers
          Intégration continue                                           It3
          VNR

Détail du 3° tiers
          Réalisation et Fin
          Bilan

    Définition des besoins             Réalisation : les itérations
                                                                                     125
Principe : une version
•   Le client (ou PO) est dans la salle
     – Il propose une liste de fonctionnalités (Backlog)
           •   UC (sans donner les scénarios) ou User Story
           •   Chaque US ou UC a une priorité donnée par le client
•   Les programmeurs affectent un poids (en pt) à chacune des US (Backlog du
    produit)
     – Estimation des US en équipe (planning game)
     – Si estimation impossible, découper la US, ou bien discuter avec le client
     – Le client refait une passe sur les priorités
•   On fait une découpe de la version en itérations
•   Démarrage de l’itération
     –   Ecriture des scénarios ou détails des user story
     –   Découpe en tâches des US (Backlog du sprint)
     –   Estimation des tâches en heure
     –   Tests + Dvp + Tests
     –   Bilan + Demo
•   Maj du Backlog pour itération suivante



                                                                                   126
User story
             le client                                     L’équipe de dvp
                                                 • Phase de Définition des besoins
• Taille : carte postale
                                                      •Discussion avec le client
• Affecte un ID automatique
                                                      • Affectation d’un coût
• Ecrite par le client
                                                      • si estimation impossible
• N’est qu’un résumé
                                                            • Rediscuter avec le client
• Le reste est verbal
                                                            • la décomposer en n US
• Affectation d’une priorité (une valeur)
                                                            • la décomposer en tâches et estimer les
• Affectation sur une itération (voir partiel)
                                                            tâches (Voir la suite)
• Ecriture des tests finaux (TR)
                                                 • Phase de DVP (Iterations)
                                                      • Découpage en tâches er estimation (H)
  Les 3C                                              • Prise de responsabilité d’un développeur
  • Card : une ou deux phrases                        pour une tâche
                                                      • Réalisation en binôme
  • Conversation : verbale                            • Ecritures des TU
  • Confirmation : test                               • Réalisation
                                                      • Passage des TU
                                                      • Passage des tests finaux (TR)        127
US : Recto




             128
US : Verso




             129
Planification d’une version
• Calculer la vélocité de l’équipe
     – Prendre une moyenne des derniers sprints
     – Pour la première fois :
         • commencer l’estimation du sprint (ce qui nous donnera un nb de pt faisables en un sprint
           – voir plus loin)
         • Méthode des 3 experts
         • Pif
• Répartir les US ds les sprints en commençant par les plus prioritaires
• Ajustement des fins de sprint
• Rajouter du mou
     – 10% pour erreur d’estimation
     – 15% pour Bug, FeedBack des utilisateurs
•   Tenir compte du calendrier (prévisible)
•   Tenir compte des changements des effectifs de l’équipe si prévu à l’avance
•   Prendre en compte les points de synchro avec d’autres équipes
•   Planning orienté utilisateur, sans garantie car il va être remanié

                                                                                                130
BackLog de produit(1)




D’après la velocité : Une itération = 50 points  5 Itérations (sans engagement)

                                                                                   131
BackLog de produit(2)




                        132
BackLog de produit(3)
            Méthode classique 
            • RAF = Temps estimé – temps passé
            Agilité
            • RAF = Réestimation de la tâche
            • Simplement utiliser les états
                  (en cours-fini-…)


              Beurdone - burndown




                                            133
Ice Scrum 2
   Excel

Un planning de version
•Une version
•3 Itérations
•Chaque itération contient
       des US

Rmq : on ne voit pas les
      priorités (dommage)


                             134
Une variante : Feature




                         135
L’Agilité – Déroulement d’un
             projet
         Les itérations




                               136
Une itération
•   Découpe en tâches (Planning horizontal)
•   Estimation des tâches en heure
•   Planification du sprint (2-4H) : Equipe + PO
•   Rajouter du Mou (30%)
•   Affectation des tâches – Fabrication des binômes
•   1-2 jours de modélisation (toute l’équipe)
•   DVP
      –   Préparation des tests
      –   Coder en binôme et améliorer
      –   Tester
      –   Une réunion par jour (suivre ce que font les autres, …)
• Acceptation par le client
• Un bilan Améliorer le process
Rmq : à la fin de la réunion de la planification du sprint, on doit avoir : Un but pour le sprint,
Une liste des membres d'équipe (et de leur niveau d'engagement , si ce n'est pas 100%),
Un backlog de sprint , une date bien pour la démonstration et uUne heure et un lieu bien
                                                                                            137
définis pour la mêlée quotidienne.
Les principes
•   Modéliser agile ensemble
•   Se mettre en binôme
•   Ecrire les cas tests
•   Tester (NOK)
•   Coder
    – Faire simple
    – Suivre l’avancement
• Tester (OK)
• Une personne est responsable d’une tâche
• Le code appartient à tout le monde
                                             138
La modélisation agile
• Il faut modéliser (1 jour sur 10)
• Les modèles sont faux
• Un modèle agile est une peinture, pas une
  photographie
• Modéliser à plusieurs, jamais seul
• Moins de diagrammes de classe et plus de diagrammes
  d’interaction (et en //)
• Ne pas passer trop de temps avec les outils, faire du
  reverse après coup
• Modéliser pour soi même, pas pour faire de la
  documentation

                                                     139
Développement (1)
• Faire le plus simple possible
• Pas de conception  Conception émergeante
• Pas de Doc uniquement pour satisfaire le
  process
• 1-2 jour de modélisation sur 10
• Binômes
• Personne n’est propriétaire du code  Equipe
• CR journalier + le tracker

                                             140
Binômes
• Il y en a un qui fait le code pendant que l ’autre fait les
  tests
• Il y en a un qui code pendant que l’autre le surveille
• Il y en a un qui code pendant que l’autre se repose
• Il y en a un qui tient la souris, l ’autre a le clavier...
• Cela coûte forcément deux fois plus cher
• J ’ai mes habitudes de codage...
• J ’aime travailler tout seul
• Binômer, c’est multiplier les couts
        par 2
                                                            141
142
Binômes
• Deux personnes travaillant ensemble pour concevoir, tester, coder...
• Une seule machine (standardisée)
    – un conducteur: manipule la machine, réalise le travail
    – un observateur: propose, conseille, vérifie, et réfléchi à la stratégie globale
• Changements de conducteur fréquents
• Changements de binôme fréquents
• Travail dense, exigeant, productif et efficace
• L’un regarde le clavier, l’autre l’écran, et on discute
• Celui qui ne sait pas faire, fait, l’autre lui apprend
• TDD (l’un écrit un cas de test puis l’autre le programme, programmation
  ping-pong)
• La programmation en binôme est épuisante et ne devrait pas être
  pratiquée toute la journée
• Utiliser pour la montée en compétence des nouveaux entrants et pour les
  développements pointus

                                                                                        143
Qualités d’ ½ binôme
Ouverture d'esprit et remise en question
Courage (de se mettre à nu)
Communication active (pas de rétention d'information)
Respect de l'autre et de son travail
Capacité à tourner (tâches, fonctionnalités, personnes...)
A se rendre non indispensable
Durée d’un binôme = 1 jour, 1 tâche (pas toujours)
Travailler à deux
Savoir partager la gloire... Et les erreurs
il est « plus facile de former un débutant (à l'agilité) que de
    déformer un gourou ».

                                                                  144
Cycle de vie d’un binôme




                           145
Développement (2)
• Faire le plus simplement possible
   – Faire simple mais pas simpliste
   – Pas de savants
        • Ne pas prendre d’expert
        • Se méfier des architectes
   –   Problème des design patterns
   –   Homogénéité de l’équipe avant tout
   –   Les cimetières sont remplis de gens indispensables
   –   Faire de la réorganisation de code
        •   Revue (binômes)
        •   Une seule fois (DP Template method)
        •   Refactoring (séparation des idées)
        •   Interdit si pas de tests automatisés
        •   Quand?

                                                            146
Faire le plus simple possible (1)
•   Ne pas faire de conception
     (la bourseMauvaise spéculation)
•   Ecrire les tests d’abord
•   Ne pas faire de sur spécification, mais penser à demain
•   Ne pas choisir tout de suite une architecture
     – Cela permet d’en tester plusieurs
     – Mais, ne pas la choisir trop tard!!!
•   Ne pas mettre de commentaires, ni de lignes blanches de séparation
         mais couper en n parties
•   Compliquer le code (ex DP)
     –   Former, convaincre sinon ne pas faire
     –   Nivèlement par le bas, mais tout le monde comprend
•   Commencer simplement
•   Ecrire la solution la plus simple possible pour résoudre ce cas et que ce cas


« La vérité, ce n’est point ce qui démontre, mais ce qui simplifie »— Saint Exupéry.

                                                                                       147
Faire le plus simple possible (2)
If (n == 0) return 0;
If (n == 1) return 1;                             Cas 0 et 1
----------------------------------------------
 return n;                                        Cas 0 et 1 remanié
-----------------------------------------------
If (n<=1) return n;
Return 1;                                           Cas 0, 1, 2
-----------------------------------------------
If (n<=1) return n;                               Cas 0, 1, 2 remanié
Return F (n-2) + F (n-1);                         …Cas général…
-----------------------------------------------
If (n < 0) erreur (TBD)
If (n<=1) return n;                                Solution finale
Return F(n-2) + F(n-1);


                                                                        148
Conception émergeante
              Le Refactoring : la solution agile pour conserver un code évolutif

Exemple de conception émergeante sur un projet XP démarré en 2002, dans le cadre d’un grand
     projet télécom.
Lancé au départ avec une équipe de trois développeurs, il occupait en 2005 plus
    d’une vingtaine de développeurs, avec une application qui représentait quelques centaines
    de milliers de lignes de code, des milliers de classes, et environ 20.000 tests.
 En 2003, nous avons extrait une partie “plateforme” gérée par une équipe dédiée ……
La plateforme continue d’évoluer, et le nombre d’équipes utilisatrices augmente.
Après six ans d’évolution, le code de l’application est toujours jugé propre.

Des blocs de code  des fonctions,
des fonctions  classes,
des classes  modules,
 des interfaces sont apparues pour découpler des modules,
Certaines portions du code  “poussées” dans des fichiers de configuration, etc.

le meilleur moyen pour trouver ces erreurs est d’arrêter de penser au logiciel au niveau théorique
    de l’analyse et de la conception, mais plutôt de se lancer, de se salir les mains, et de
                                                                                                  149
    commencer à construire le produit. Mike Cohn
Stand up meeting

• Tous les jours 15 mn
• Toute l’équipe
• Chacun doit dire (15/6 = 2mn30s)
     • Les problèmes qu’il a eu la veille si ils ne sont pas résolus
     • Ce qu’il pense pouvoir faire aujourd’hui
     • Les problèmes rencontrés
• On est pas là pour résoudre les pb, mais
     • pour les faire connaitre, Les noter
     • prendre un RV ds la journée avec le sauveur
     • si il n’y a pas de sauveur, il faudra réestimer la tâche  US.
• Mise à jour du planning journalier (Sprint) et de la liste des PB
• Si plusieurs équipes scrum de scrum
                                                                        150
Stand up meeting : Objectifs

• Evaluer l'avancement du travail
• Identifier les obstacles(problèmes) nuisant à la
  progression: Quelque chose qui génère une perte
  de temps ou un gaspillage de ressources
• Garder l'équipe concentrée sur l'objectif du sprint
• Améliorer l'esprit d'équipe (cette réunion donne
  le sentiment commun de l’engagement)
• Permettre une communication objective sur
  l'avancement

                                                   151
Stand up meeting : Les erreurs
• La réunion n'a pas lieu tous les jours
• la réunion commence en retard
• Tout le monde ne s'exprime pas
• Des personnes bavardent en aparté
• Une personne interrompt les autres
• On s'adresse uniquement au ScrumMaster
• On parle de choses sans rapport avec les tâches
  du sprint
• Essayer de résoudre un pb compliqué
                                                    152
Les tâches à faire (le radiateur)




                                    153
Ice scrum : Kanban




                     154
Cycle de vie d’une User Story
                            Dvp                                                         Client




                                                                                         Phrase+Priorité




                                                                   Discussion


                              Estimation




                     ProductBacklog/iteration                   SprintBacklog

                                                                                Definition Test



                     Découpe en Tâches




                                                                                Ecriture du test
     Affectation des tâches            Affectation des tâches                                              [NOK]




       Réalisation tâches                  Réalisation tâches




              TU                                  TU




                                                                    TI                             [OK]




                                                                                                                   155
Déroulement du Sprint (Iter1)
                Rmq :
                Total priorité = 42
                Le premier jour on a de disponible 5/42
                           (10% du projet)
                Le 6° Jour on a de dispo 10/42
                           (25% du projet)




                                                  156
Vélocité
Vélocité = nb de points (estimation des US) réalisés pendant une itération




                                                                             157
BurnDown de Sprint (Iter1)




                    Vélocité = 48-34
                             =14 !!!


                                  158
Burndown du produit après Iter1
      Beurdone - burndown




                                                 Vélocité = 14 !!!




 Faire une démonstration au client de ce qui fonctionne (25% du projet)
 Faire un bilan de l’itération (Voir plus loin)
                                                                          159
Iteration2
                                                         Vélocité = 50


                                                         Beurdone - burndown




                                                                180
Supposition :
Pas de pb sur iter2 (50 points)
Gain priorité pour le client = 4+3*3 = 13
Total 10(iter1) + 13 = 23/42 (La moitié du projet)
et on avance de 9 points sur la US10
(reste 16-9= 7 points pour la finir)
                                                                               160
Gain total de l’iter2 = 50 points (RAF = 230-50 = 180)
Iteration3


                                                 Ré estimation




Supposition : Iter3
US11 est terminée (4 points cout de 55)
US10 est enfin OK (5 points cout 34)
           mais pas propre!!!
En avance us15 OK (4 points cout 21)
Velocité = 55 + 34 + 21 = 110
Total point 23(iter2) + 4 + 5 + 4= 36/42
                                                                 161
Total RAF 180 – (55 + 34 + 21) = 70
Fin du projet




Vélocité moyenne = 41

   Faire un bilan de fin de Version ou de fin de projet : IDEM (Voir plus loin)   162
Graphe : BurnDown & velocité
                          raf                                                            velocite
 300
                                                                   80
 250
 200                                                               60
 150
                                                                   40
                                                  raf
 100                                                                                                               velocite
  50                                                               20
      0                                                             0
              1       2   3       4       5                             1            2             3      4



300                                                              Rmq : Techn Story : Attention à garder le
250
                                                                 Backlog orienté métier (ex : Indexer une table)
200
                                                                        rafInitial             rafTotal
150                                                 rafTotal
                                                                                         244                   0
100                                                 rafInitial
                                                                                         136                  30
 50                                                                                       85                  30
  0                                                                                       50                  50
          1       2           3       4       5
                                                                                           0                  50
                                                                                                                          163
Les indicateurs
•   Feature et US (UC) : Estimation taille en points et Utilité (Valeur, priorité) en points ou en €
•   Tâches : Estimation en heures
•   Vélocité : nb de points réalisés en un sprint
•   Mesures quotidiennes
     –   Nb d’heures RAF pour les tâches du sprint non finies
     –   Nb de tâches et de US restant à finir pour ce sprint
     –   Nb de points de US restant à finir pour ce sprint
•   Mesures à chaque sprint
     –   Capacité estimée au début du sprint
     –   Vélocité réelle du sprint
     –   L’utilité ajoutée pendant le sprint
     –   Le Nb de US restant à faire ds le backlog (selon les états des US)
     –   La taille (en point) du restant à faire ds le backlog. Pour la release seulement
     –   Le nombre de points total ds le backlog, y compris ce qui est fini
     –   Les tests (nombre, OK, Echec, Ecrits mais pas encore passés, ….)
•   Mesure de fin de release
     –   Idem mesure de sprint, en en faisant la somme
•   Autres mesures
     –   Nombre d’obstacle (trouvé, résolus, …)
     –   Ressources consommées par le sprint
     –   Qualité du code


                                                                                                       164
Montrer des diagrammes simples (1)




                                     165
Montrer des diagrammes simples (2)




                                     166
Cycle scrum : résumé
• http://vimeo.com/4587652 scrum vivant
• Bruxellesmobilite
  http://www.bruxellesmobilite.irisnet.be/




                                             167
Les bilans
• Bilan itération : Réunion des questions QQ (2-4H , Toute l’équipe + des
  muets)
    –   Préparée par le scrum master
    –   Qu’est ce qui a bien marché ?
    –   Qu’est ce qui n’a pas marché ?
    –   A-t-on besoin de qq chose ?
    –   Que faut-il ne plus faire ?
    –   Comment ça va-t-il bien (Le moral)?
    –   Comment peut-on améliorer qq chose ?
    –   Qu’est ce que vous gardez sur le cœur ?

• Bilan de release : Réunion CC (1-2 Jours , Toute l’équipe + hiérarchie)
    –   Préparée par tous (montrer l’esprit d’équipe-ROI)
    –   IdemQQ + pompeuse Demo
    –   mais à la Campagne + Champagne
    –   Faire cette réunion même en cas d’échec du projet (sans champagne)

                                                                             168
XP-Game
                          Un projet
•   User story
•   Planning game
•   Product backlog
•   Itérations
    –   Sprint backlog
    –   Stand up meeting
    –   Calcul de la vélocité
    –   Calcul de la satisfaction client
• Bilan

                                           169
L’Agilité

Les tests
  TDD



            170
TDD          Client                                       Programmeur

Tester pour vérifier n’est pas judicieux!!!

Tester pour spécifier                                  Ecrire un Test
Spécifications executables
Programmation par contrat
                                                                           Ecrire un scénario
           (Bertrand Meyer)

Un test comprend plusieurs scénarios                                [OK]     Passer le test              Ecrire le pg
Cas nominal, cas aux limites,….
                                                                                          [NOK]
Le test remplace la documentation
                                                    [OK]
                                                                                                        Passer le test    [NOK]
TU (Programmeur+Outils+Tracker)
TR (Client + programmeur)
L’acceptation n’est faite que par le client
                                                                                                               [OK]
Tous les tests sont archivés et automatisés
                                                                                                    Remanier le code

                                                                                                [NOK]


                                                                                                         Passer le test



                                                                                                                        171
Qu’avez-vous testé aujourd’hui?
Valtech-Test (14mn)

   BOF                               Yahoo!!!
   Tester pour corriger              Tester pour spécifier
   Organiser des campagnes de        Tester en permanence IC
   test
   Spécialiser les métiers du test   Partager les responsabilités
                                     des tests




                                                                    172
Les tests Automatisés

     • TU1


TU
     • TU2
     • TU3
     • TU4
     • TU5


                                OK/NOK
     • tr1
                 TestSuite
TR
     • tr2
     • tr3
     • tr4




                                    173
Les types de tests
•   Tests unitaires (X-UNIT)
     – AAA : Acteurs, Action, Assertions (5-20 pour un scénario)
     – Ecrire le programme de test (cas par cas)
     – Générer les classes et les méthodes nécessaires
     – Lancer le programme de test  Echec
     – Ecrire le programme
     – Lancer le test jusqu’au  Succès
     – Archiver le test ( TestSuite )
     – Ecrits par le programmeur
•   Tests de recette
     – Des outils
     – IHM Textuelles (automatique)
     – Outils de test
     – Ecrits par le client (test de comportement, spécification exécutable)
•   Tests d’IHM
•   Tests de charge, Tests temps réel,….



         RMQ : Ecrire et tester le programme avant de l’écrire (TTD)
                                                                               174
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité
Introduction à l'Agilité

Contenu connexe

Plus de VINOT Bernard

Le robot agile
Le robot agileLe robot agile
Le robot agile
VINOT Bernard
 
Up1
Up1Up1
Un Sctroumph
Un SctroumphUn Sctroumph
Un Sctroumph
VINOT Bernard
 
Design Patterns Java
Design Patterns JavaDesign Patterns Java
Design Patterns Java
VINOT Bernard
 
Automate1 Correction
Automate1 CorrectionAutomate1 Correction
Automate1 Correction
VINOT Bernard
 
Definitiondesbesoinsuml
DefinitiondesbesoinsumlDefinitiondesbesoinsuml
Definitiondesbesoinsuml
VINOT Bernard
 
Uml
UmlUml
Mini Oo
Mini OoMini Oo
Mini Oo
VINOT Bernard
 

Plus de VINOT Bernard (8)

Le robot agile
Le robot agileLe robot agile
Le robot agile
 
Up1
Up1Up1
Up1
 
Un Sctroumph
Un SctroumphUn Sctroumph
Un Sctroumph
 
Design Patterns Java
Design Patterns JavaDesign Patterns Java
Design Patterns Java
 
Automate1 Correction
Automate1 CorrectionAutomate1 Correction
Automate1 Correction
 
Definitiondesbesoinsuml
DefinitiondesbesoinsumlDefinitiondesbesoinsuml
Definitiondesbesoinsuml
 
Uml
UmlUml
Uml
 
Mini Oo
Mini OoMini Oo
Mini Oo
 

Introduction à l'Agilité

  • 1. B.Vinot Introduction aux méthodes agiles
  • 2. Plan du cours Les projets classiques Le gantt-Les méthodes d’estimation-Les cycles de développement Apports des technologies objet-La modélisation UML Unify Process L’agilité Introduction Le manifeste agile Le lean Panorama des méthodes agiles Les rôles – les cycles Déroulement d’un projet Définition des besoins - Méthode de planification agile les itérations La modélisation agile -La mêlée scrum ou le stand up meeting XP - Burndown chart- Calcul de la vélocité de l’équipe Les outils agiles-TDD Conclusions Migration-Avantages-ROI- Les bilans 2
  • 3. Agilité : Définitions • L’Agilité est l’habilité de créer et de répondre au changement dans le but d’avoir du succès dans un environnement d’affaires turbulent. - Jim Highsmith • Certaines problématiques sont difficiles, certains individus sont difficiles. Les méthodes Agiles ne sont pas une garantie de succès. - Craig Larman • Ce n’est pas la plus forte des espèces qui survit, ni la plus intelligente, mais celle qui s’adapte le mieux - Charles Darwin • Intelligence = (2)Aptitude à s’adapter à une situation, à choisir en fonction des circonstances… - Larousse 3
  • 4. Etes vous familier avec les cycles de dvp? Les projets classiques Le gantt Les méthodes d’estimation Les cycles de développement 4
  • 5. Les méthodes prédictives Et le client? Découpe Planifie Chef de projet Distribue Discute Equipe1 Equipe2 Réalise Architecte dev1 dev2 5
  • 6. Estimer pour Planifier • Ne pas faire tout seul • Méthode des trois experts • (min + 2 * Moyen + Max) /4 • Méthode des trois wagons • Faire participer l’équipe • Tenir compte de la complexité - Fibonacci • Hiérarchiser les fonctions • Relativiser : Cocomo 6
  • 7. Planifier avec Fibonacci F(n) = F(n-2) + F(n-1) Plus c’est compliqué et plus ça ….. Et si c’est encore plus compliqué alors ça ….. Encore plus 7
  • 8. Hiérarchiser les fonctions • Comparer 2 à 2 chaque fonction F2 F3 F4 F5 F6 F1 F2 1 F1 3 F4 2 F5 1 F1 3 6 • A chaque comparaison est associé un poids variant entre 1 et 3 F2 F2 3 F4 2 F2 2 F6 1 6 (1 signifiant peu de différence) F3 F4 1 F5 1 F3 2 2 F4 F5 1 F4 3 8 • Exemples : – F2 est plus importante que F1 avec un poids relatif de 1 F5 F5 1 4 – F4 est plus importante que F1 avec un poids relatif de 2 F6 1 27 • Poids de la fonction 5 : – Somme de toutes les cases orangées (1+1+1+1) • Poids de toutes les fonctions : F6 3,70% – Somme de tous les poids de fonction F3 7,40% • Poids relatif de la fonction 5 : F5 14,80% – 4 / 27 = 14,80 % F2 22,22% • Hiérarchie des fonctions F1 22,22% F4 29,66% No. 8 8
  • 9. Déterminer la valeur des fonctions • La fonction F6 représente 30 % du budget du projet pour un poids de 3,7 30% F6 3,70% % – Améliorer le coût de la solution, ou – Supprimer la fonction du périmètre 10% F3 7,40% F5 15% Coût 14,80% Poids 20% F2 22,22% La fonction F4 représente 5 % du F1 20% budget pour un poids de 29,66 % 22,22% Intégrer cette fonction dans le périmètre 5% n F4 29,66% minimal 9
  • 11. Les cycles de DVP Winston Royce 1970 Addison Wesley 1990 1980 : V 1990 : Itératif 11
  • 13. Une arnaque ? Madame Soleil « La logique est l’art de s’enfoncer dans l’erreur avec confiance ». Joseph Wood Krutch 13
  • 15. La gestion de projet Classique Apports des technologies objet-Métriques La modélisation UML Unify Process 15
  • 16. Des preuves, des métriques(1) Des chiffres, oui mais: Ce qui compte ne peut pas toujours être • Simples compté, et ce qui peut être compté ne • Pas inventés mais mesurés compte pas forcément - Einstein • Beaucoup, mais pas trop • Choisi, pas imposé 16
  • 17. Apports des technologies Objet Increased Productivity 5 Cost savings 2 2 Improved interfaces 6 17 7 11 Software reuse 11 8 14 17 Improved application maintenance Encapsulate existing applications Develop strategic applications quickly Develop applications as revenue source 17 Access new OS
  • 18. Des preuves, des métriques(2) Les métriques de McCabe C++ C++ C++ C C C V0 V1 V2 V0 V1 V2 Average Function LOC 6,66 6,2 6,11 29,62 32,5 37,11 Min Function LOC 2 1 1 3 3 3 Avg Cyclomatic Complex 1,66 1,59 1,59 5,88 6,25 6,56 Avg Comparison Complex 0,25 0,24 0,3 1,38 1,62 2,22 Avg Logic Flow Complex 1,91 1,83 1,89 7,25 7,88 8,78 Avg Function Complexity 3,69 3,59 3,7 9 9,62 10,56 eLoc/100 2,07 2,5 2,68 2,68 2,91 3,53 eLOC 207 250 268 268 291 353 18
  • 19. Des preuves, des métriques(3) 19
  • 22. Les concepts Objet • Abstraction : Classe -nom Personne -age • Encapsulation -poids +Manger() +Travailler() +Anniversaire() • Héritage Dentiste Boulanger • Polymorphisme -adresseCabinet +Travailler() +Travailler() Arracher des dents Faire du pain // un petit pg // un petit pg (suite) Personne p p=d Dentiste d p.Travailler() Boulanger b p=b p.Travailler() p.Travailler() For each p in leSac d.Travailler() p.Travailler() b.Travailler() sac<Personne> leSac 22
  • 23. La gestion de projet Classique Apports des technologies objet La modélisation UML Unify Process 23
  • 24. DOC-PDF UML1.3 = 4,7MB DOC-PDF UML2.0 = 5.8 MB UML : La genèse Nov-97 Sept-97 2000 Janv-97 1.0 1.1 (OMG) 1.4 1.0 Juillet-96 0.9 2003 2.0 Oct-95 0.8 Jacobson (use case - sdl) Booch-93 Rumbaugh( OMT2) 24
  • 25. Un modèle : Définition Ce qui sert ou doit servir d’objet d’imitation pour faire ou reproduire quelque chose (petit robert) UML Contient UML est un langage qui contient • Des éléments de modélisation: – Des classes – Des packages – Des méthodes – Des Acteurs….. • Des diagrammes – Classes, UC, Automate, Activité, ….. Top Model 25
  • 26. Les diagrammes UML • Diagramme de use case • Diagramme de classes • Diagramme de structure • Diagramme d'objets • Diagramme dynamique • Diagramme d'interaction • Diagramme de séquence • Diagramme de communication • Automates • Diagramme d'activité • Autres diagrammes • Composants et Déploiement 26
  • 28. Diagramme de Use case Les acteurs Un acteur est un rôle d’un ou plusieurs objets situés à l’extérieur du système et qui interagissent avec lui pour remplir une fonctionnalité donnée de ce système. Un acteur caractérise le rôle joué par un objet à Utilisateur l’extérieur du système. • Un acteur parle au système (Acteur principal) • Le système peut parler à un acteur (Acteur secondaire) • Un acteur est : • Un humain (via une IHM) • Du soft • Du hard • Le temps 28
  • 29. Diagramme de Use case Use Case Un Cas d’utilisation ( use case ) est une fonctionnalité remplie par le système et qui se faire qqchose manifeste par un ensemble de messages échangés entre le système et un ou plusieurs acteurs. Protocole API IHM VerifierBonneMarche Utilisateur CapteurTemperat ure Acteur primaire Une fonctionnalité interne Acteur secondaire Au système 29
  • 30. Diagramme de Use case Description d'un Use Case (3-5 pages) • Titre et numérotation Ce n ’est pas une • Résumé description formelle Mais doit être très détaillé • Les acteurs – Acteur principal – Acteurs secondaires Ceci est l ’usage • Pré-conditions mais ne fait partie • Description de la norme UML • Exceptions • Post-conditions Scenario 30
  • 31. Diagramme de Use Case Appeler / numéro <<include>> GSM Envoyer <<include>> Utilisateur Appeler / contact Antenne HLR Recevoir appel Gerer les contacts A1 B3 B2 <<include>> <<include>> <<include>> <<include>> Configurateur A2 A3 B1 Préparer 31
  • 32. Utilisation des Use case Manger Descriptions Distribuer le comportement des fonctionnalités aux méthodes des objets 32
  • 33. Des mauvais UC Use cases are wonderful but confusing. People, when asked to write them, do not know what to include or how to structure them. There is no published theory for them. This paper introduces a theory based on a small model of communication, distinguishing "goals" as a key element of use cases. The result is an easily used, scaleable, recursive model that provides benefits outside requirements gathering: goals and goal failures can be explicitly discussed and tracked; the goals structure is useful for project management, project tracking, staffing, and business process reengineering. The model and techniques described here have been applied and evaluated on a relatively large (50 work-year, 200 use-case) project. 33
  • 34. Use Case : Exercice Une société de vente par correspondance vous demande de développer son système informatique. Ce système doit pouvoir prendre en compte des commandes passées par la poste et des commandes passées par internet. Il doit suivre les expéditions qui ne sont effectuées que si le paiement est OK. Les paiements se font par carte bancaire dans le cas d'internet et par chèque dans le cas de la poste. Les paiements sont validés par un système bancaire appartenant à la société et existant. Il faut récupérer ce système. Le nouveau système est chargé aussi de la gestion de stocks, lorsqu'un article atteint un seuil minimal, alors il faut passer une nouvelle commande au fournisseur adéquat. A la réception de la commande, la mise à jour de la base est faite par un employé. Dans le cas d'un paiement accepté et de stock disponible, l'expédition est faite par un robot existant au quel il suffit de passer les coordonnées du client, et la liste des produits achetés. En cas d'indisponibilité, une lettre doit être envoyé au client. 34
  • 35. Notion de stéréotypes Un stéréotype est une nouvelle classe d’un élément de modélisation qui est introduit au moment de la modélisation. Cela représente une sous classe d’un élément de modélisation existant avec la même forme, mais avec une intention différente. • Les stéréotypes font partie des mécanismes d’extensibilités, prévus par UML. • Une interface est un stéréotype • On peut stéréotyper les classes, les associations, les packages, ….. • On peut associer un nouvel icône pour chaque nouveau stéréotype. <<nouveauStereotype>> Z 35
  • 36. Diagramme de classe Un diagramme de classe montre la structure statique du modèle, les choses qui existent, leur structure interne et les relations aux autres choses. • Statique : – Ne pas utiliser de verbes d'action pour relier les classes – Une classe isolée est une classe inutile – Doit être vrai tout le temps Les choses qui existent – Représente LE programme Maison – On ne peut pas tout montrer sur un seul schéma Moto Garage Personne Personne Tricycle 36
  • 37. Diagramme de classe Les classes UneClasse -attributPrive +attributPublic #attributProtected +attributDeClasse +attributTypé: int +attributTypéInit: int = 56 +Operation() +OperationDeClasse() +OperationAvecParam(par1: int, par2: boolean): int +OperationAbstraite() 37
  • 38. L’héritage Vehicule L’héritage s ’appelle généralisation +carteGrise en UML -marque #nbPassagers EST UN Avion Bateau +ailes +moteurDiesel +reacteur[2]
  • 39. Les interfaces Client Client Une interface permet à un objet (le Client) De faire faire quelque chose (Fqq) à un Objet de type A, sans savoir qu’il est un A. <<interface>> Il sait seulement qu’il est de type FqqAble FqqAble FqqAble +Fqq() On a remonté le niveau d’abstraction. On utilise une interface pour imposer à des Classes différentes d’implémenter une ou Plusieurs opérations. A A +Fqq() +Fqq() 39
  • 40. Les associations Les associations représentent des relations structurelles entre classes d’objets. Une association symbolise une information dont la durée de vie n’est pas négligeable par rapport à la dynamique générale des objets instances des classes associées. La plupart des associations sont binaires, c’est-à-dire qu’elles connectent 2 classes. Certaines sont refléxives. +h Personne +f Voiture 4 Roue 40
  • 41. Diagramme de classe : Associations Est Employée par Personne Societe Nom d'association Est Employée par Personne Societe Nom de rôle -employe -employeur 1..* 0..1 Personne Societe Cardinalité-Multiplicité -employe -employeur Personne Societe employeur : Societe employe : ListeOfPersonne 1..* Personne Societe Navigabilité -employes Personne Societe employes : Personne 41
  • 42. Diagramme de classe Dépendance Depenser i = Banque::GetInstance()->DonnerSolde(); Acheter(i); Voler b = new Banque(); i = b->DonnerSolde(); Economiser (p : Banque) p->Deposer(10000); 42
  • 43. Diagramme de classe : Exercice1 Immeuble Gardemanger Appartement Lapin Personne Famille Pièce Chien Mariage Cuisine CompteBanquaire Nourriture Animal Bail Whisky Salon acte de propriété Chat 43
  • 44. Diagramme de classe : Exercice2 44
  • 45. Diagramme dynamique • Diagrammes d'interaction (Séquence collaboration) servent à montrer comment les objets parlent les uns aux autres. Ils montrent le déroulement d'un ou d'une partie d'un Use case (cas nominal, cas des exceptions, …) Un objet (l’émetteur) envoi un message à un autre (le récepteur). Le récepteur doit avoir une opération correspondante au message. • Automates servent à montrer le comportement d'une classe qui réagit différemment selon son état. • Activités montrent le déroulement d'une méthode d'une classe ou celui d'un Use case 45
  • 46. Diagramme de Séquence : C1 : C2 : C3 : A1 Oper1() new : C3 Oper3() Oper2() retour Oper1() <<create>> C3() Oper2() <<destroy>> Delete() 46
  • 47. Diagramme de Séquence (UML2.0) Entreprise Employe * +salaire +CalculerSalaire() -lesEmployes +CalculerSalaire() : Commerciaux : Employe : Entreprise Commerciaux : FinMois +commission +CalculerCommission() CalculerSalaire() loop pour chaque employe CalculerSalaire() alt commercial CalculerCommission() 47
  • 48. Automate • Un automate est accroché à une classe et est composé d'états et de transitions. Les transitions permettent de passer d'un état à un autre … Off Arret Marche On Casse Casse 48
  • 49. Automate État & Transition Action en entrant dans l'état Etat Action en sortant de l'état entry/ Action1 exit/ Action2 Action déclenchée sur réception de Ev1 on Ev1/ Action2 do/ Activité Activité Événement qui déclenche la transition Garde E1 Ev1( a1,a2 )[ i == 0 ] / ActionDeTransition ^Cible.SendEv2(a3, a4) E2 Action effectuée sur la transition Envoie de Ev2 à un objet Cible Rmq : Le langage d’action (UML1.4) est remplacé par 50 types d’action 49
  • 50. Automate imbriqué After5 Arret Off On Marche Ouvrir[ cuve vide ] Lavage Essorage After15 PorteOuverte After10 Rinçage Fermer H
  • 51. Automate : exercice E1 ST1 E1 / i++ ST2 E1 entry: i++ entry: i = 0 exit: i++ exit: i++ E3 on E4: i ++ E1 E1 E3 E1 E3[ i == 5 ] E2 E2 E1 E2 ST4 ST3 E3 on E2: i = i - 2 E1 E3 E3 51
  • 52. La gestion de projet Classique Apports des technologies objet La modélisation UML Unify Process 52
  • 53. UP : La base PU est à base de composants PU utilise UML PU est piloté par les cas d’utilisation PU est centré sur l’architecture PU est itératif et incrémental 53
  • 54. UP & RUP Unify Process (Énorme process pour tous) RUP Rational Unify Process Process customisé à partir du UP C'est un outil (site web, customisable) Custom AirFranceUP XUP 54
  • 55. OpenUP RUP : Principes 7 rôles (environ 45 pour RUP) 20 artefacts (plus de 80 pour RUP) 18 tâches (plus de 150 pour RUP) 55
  • 56. Les artefacts • Activité de gestion de projet – Comptes rendus, planning d’activité, …. • Résultats – Modèles – Code source – Spécifications – ….. 56
  • 57. Les rôles • Les analystes (exigences) • Les développeurs • Les testeurs • Les managers (gèrent le processus) • Le chef de projet • Les autres (Client, MOA, stakeholder, ….) 57
  • 58. Les activités • Modélisation métier • Les Besoins • Analyse et conception • Implémentation • Tests • Déploiement • Gestion de configuration Etudié plus tard • Gestion du projet • Environnement 58
  • 59. BPM 59
  • 60. Modélisation métier Stéréotypes UP Client business use case Fournisseur Les objets de Les employés L’entreprise Les process 60
  • 61. Organisation des modèles (UP) uc1 Définition des besoins VOPC Les sources C1 C2 Composant1 Les UC realization (Documentation) residents C1 C2 Les composants (physiques et logiques) PC Les machines components Composant1 61
  • 63. Processus traditionnel • Gros classeur sur l’étagère des développeurs • … Ramasse la poussière … • Difficile à comprendre et à utiliser, vu comme une surcharge (gaspillage) 63
  • 64. Motivation 70% 45% 64
  • 65. Les bureaux Google FaceBook *****google zurich****** http://www.dailymotion.com/video/x4zlcv_merci-google_lifestyle 65
  • 66. Le processus comme un produit • Pas un simple livre, pas une autre OOAD méthode • Fourni comme un site web (avec les sources) • Constamment amélioré • Base de connaissances – Navigation graphique, moteur de recherche, index – Guides, templates de documentation, aide à l’utilisation des outils 66
  • 67. 67
  • 68. RUP : Ses forces • Cadre générique • Référentiel de bonnes pratiques; • Gestion des risques dans les projets; • Cadre propice à la réutilisation; • Approche basée sur l’architecture; • Traçabilité à partir des Uses Cases jusqu’au déploiement. Ex : IBM Tivoli ITUP 68
  • 69. RUP : Ses faiblesses • Coût de personnalisation souvent élevé; – Autres logiciels propriétaires (Rational) indispensables; • Très axé processus : – peu de place pour le code et la technologie ; • Vision non évidente ni immédiate DEVELAY Isabelle EDORH-A. Semeho GUIBOUT Nicolas 69
  • 70. RUP : Conclusion • RUP considéré comme: – un framework de processus génériques; – un métaprocessus; • Démarche itérative – Réduction des risques; • Facile à expliquer et à valider (les livrables); • Finalement pas très populaire… DEVELAY Isabelle EDORH-A. Semeho GUIBOUT Nicolas 70
  • 71. L’Agilité Introduction Le lean software dvp 71
  • 72. Une petite vidéo David Gageot – Directeur Technique – Valtech Technology E:CoursAgilitéVideoValtech) 40mn 72
  • 73. Qu’est ce qu’une méthode agile(1) Deux caractéristiques fondamentales – Adaptatives plutôt que prédictive • Favorables au changement • Planification plus souple – Faite par l’équipe et non imposée par le chef – Orientée vers les personnes plutôt que vers les processus • Travailler avec les spécifités de chacun • Responsabilité, confiance 73
  • 74. Qu’est ce qu’une méthode agile(2) • Délivrer rapidement et très fréquemment des versions opérationnelles, pour favoriser un feed-back client permanent • Accueillir favorablement le changement • Assurer une coopération forte entre client et développeurs • Garder un haut niveau de motivation • Le fonctionnement de l’application est le premier indicateur du projet • Garder un rythme soutenable • Viser l’excellence technique et la simplicité • Se remettre en cause régulièrement • Ecouter le client mais savoir dire non 74
  • 75. Les bureaux agiles Important - Symbolique 75
  • 76. Nous découvrons de meilleures façons de développer des Logiciels en réalisant ce travail Le manifeste agile et en aidant les autres à le faire 17 Personnes (2001) 4 Valeurs 12 principes Kent Beck XP-Junit Ward Cunningham wiki Jeff Sutherland scrum ……… 76
  • 77. Manifeste agile : Les valeurs • L'équipe (« Personnes et interaction plutôt que processus et outils ») Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu'une équipe composée d'individualistes, même brillants. La communication est une notion fondamentale. • L'application (« Logiciel fonctionnel plutôt que documentation complète ») La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Transformer la question : « avez-vous de la documentation ? » en « mais que recherchez-vous comme information ? » Commenter abondamment le code lui-même (si besoin) Transférer les compétences au sein de l'équipe (communication). • La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes. • L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») La planification initiale et la structure du logiciel doivent être flexibles. Les premières versions du logiciel vont souvent provoquer des demandes d'évolution. 77
  • 78. Manifeste agile : Les 12 principes 1. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles. 2. Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client. 3. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte. 4. Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet. 5. Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail. 6. La méthode la plus efficace de transmettre l'information est une conversation en face à face. 7. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet. 8. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment. 9. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité. 10. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle. 11. Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto- organisent. 12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens. 78
  • 79. Assemblé nationale (30-4-10) • Ch. Vanneste (député du Nord) – Etude Sofres : pourquoi travailler? • Anglais  des sous • Allemands  Epanouissement • Français Contacts humains • Direction HSBC : ce qui manque aux entreprises françaises: – Innovation – Responsabiliser les salariés 79
  • 80. (1950) L’Agilité Introduction Le lean software dvp 80
  • 81. Lean : Philosophie Le LEAN est principalement une approche managériale pour optimiser le système de production – Optimiser la chaîne de création de valeur ajoutée (sous-traitants compris) – Eliminer les gaspillages du flux de production – Push-Pull – Just in time (pas de code avant que le test le demande) –Etre discipliné sur les prises de décision (Le plus tard possible) – Volonté de perfection à chaque étape (Stopper la chaîne) – S’appuyer sur les facultés d’adaptation des individus (boite à idées) 81
  • 82. Kanban 82
  • 83. Lean : Les 7 concepts – Eliminer les gaspillages – Améliorer le système – La qualité de l’intérieur – Reporter la décision – Livrer rapidement – Respecter les personnes – Créer la connaissance http://www.youtube.com/watch?v=Dl4dcLbNlgo&f eature=related 83
  • 84. Lean : Gaspillage Shigeo Shingo (1950) 1. Stock 2. Surproduction 3. Tâches inutiles 4. Déplacement 5. Transport 6. Attente 7. Défauts http://www.tv4it.net/jusquou-le-lean-peutil-sappliquer-a- linformatique--permalink-8907.aspx 84
  • 85. Lean (LSD) : Gaspillage Shigeo Shingo (1950) LSD : Mary Poppendieck (2003) 1. Stock 1. Travail non terminé 2. Surproduction 2. Sur spécifications 3. Tâches inutiles 3. Processus… 4. Changements de priorité, 4. Déplacement changer de tâche 5. Transport 5. Transmission d’informations 6. Attente 6. Retards 7. Défauts 7. Défauts 85
  • 87. Les méthodes agiles : Panorama 87
  • 88. Taille des projets 1-2 ans & 6-12 personnes  Couper les projets 88
  • 89. Les méthodes agiles : Contraintes 89
  • 90. eXtremPrograming • KentBeck (1996) Paye de Chrysler • Les 4 valeurs de XP : CRSC – Communication – Retour-FeedBack – Simplicité – Courage 90
  • 91. CRSC • Communication – Client-Equipe – Programmeur-Programmeur – Equipe-Extérieure (indicateurs du projet) • Retour - Feedback – Livraison fréquente – VNR – Avancements objectifs – Le client est là • Simplicité – pas de sur spécifications – Code toujours aussi petit et simple que possible • Courage – De dire que on s’est trompé – De revenir en arrière – De faire du TU – D’annoncer les soucis 91
  • 92. Les principes de base • Seul le code source fait foi, il possède une odeur, appartient à l’équipe, il contient la doc • L’important c’est le programmeur (ne pas dépasser 40H/S) • Faire le plus simple possible • Restructurer dès que nécessaire • Pratiquer la programmation par paire • Les spécifications sont des « histoires d’utilisateurs » • La planification est un jeu • Livrer fréquemment • Tester donc intégrer encore, toujours et tout le temps • Être courageux B.Vinot
  • 93. Les rôles ds XP(1) • Développeur (100%) • travaille en binôme, communique • doit être autonome • a une double compétence : développeur – concepteur • Client (25-75%) • doit apprendre à exprimer ses besoins sous forme de user stories • a à la fois le profil de l'utilisateur et une vision plus élevée sur le problème et l'environnement du business • doit apprendre à écrire les cas de tests fonctionnels • est dans la salle • Testeur (50%-100%) • a pour rôle d'aider le client à choisir et à écrire ses tests fonctionnels • Tracker – Rapporteur (10-20% = 30 mn par développeur tous les 2 jours + qq réunions) • aide l'équipe à mieux estimer le temps nécessaire à l'implémentation de chaque user story • contrôle la conformité de l'avancement au planning 93
  • 94. Les rôles ds XP(2) • Coach (100% au début, puis 50%, puis 10%) • recadre le projet • ajuster les procédures agiles • doit intervenir de la manière la moins intrusive possible • ne doit pas s’occuper du projet • n’est pas là tout le temps • Consultant – Expert (0-100%) • n'apporte pas de solution toute faite • apporte à l'équipe les connaissances nécessaires pour qu'elle résolve elle-même les problèmes • doit être un formateur • Manager (10-25%) • doit croire à l’agilité • apporte à l'équipe courage et confiance • C’est le chef hiérarchique • Demande des comptes 94
  • 95. 95
  • 96. Combinaison des rôles ds XP Rmq : si plusieurs clients, Ils doivent parler d’une seule voie 96
  • 97. What is Scrum? Jeff Sutherland Sutherland 1993 Qu’est ce que Scrum? • Pas une méthode • Pas un process • Pas un ensemble de procédures • C’est un framework ouvert de dvp comportant un ensemble de règles • The rules are constraints on behavior that cause a complex adaptative system to self organize into an intelligent state • Il permet à une équipe moyenne de s’organiser pour travailler 10 fois mieux 97
  • 98. Scrum : Le cycle de vie DVP Tests UC Planning User game story 98
  • 99. Scrum : Backlog- BurnDown 99
  • 100. Bob: « Voilà j’ai terminé de développer ce module, Scrum : Kanban c’est déployé ! » Gérard: « Ben je vois rien…? » Bob: « Ha en tout cas chez moi ça marche… » DoD 100
  • 101. Definition Of Done Développement Migration des données (structures + données) Support IE7 + FF3 Test Seleniums écrits Support IE6 Test Seleniums passé avec succès Support “Navigateurs Home Page” Test Unitaires écrits Déployé sur Staging Test Unitaires passé avec succès Tests de régression ok (tous les tests Multilingue et traduction ok passent) Documentation (dossier Démarches à effectuer auprès de d’hébergement,…) l’infrastructure (pour la Prod ou autres. Ex: url, connexion db,ftp,…) Dépendance avec d’autres acteurs Visualiser sur le mur Si la définition de « terminé » vous semble confuse Mettez au début un champ «définition de terminé» pour chaque US.
  • 102. TODO : Exo • Aujourd’hui je décide de laver ma voiture • En allant vers le garage, je remarque qu’il y a du courrier sur la table d’entrée • Je décide de jeter un œil au courrier avant de laver la voiture, il contient des factures et des publicités • Je jette les publicités dans la corbeille à papier et réalise que la corbeille est pleine • Je repose les factures sur la table car il faut que je vide la corbeille • Mais comme la poubelle est proche de la boîte aux lettres, je me dis que je pourrais économiser un trajet en postant mes factures et je décide donc de préparer d’abord le règlement des factures • Je prends mon carnet de chèques et trouve sur le bureau la canette que j’avais commencé à boire. • Je me dis qu’il faut que j’enlève la canette pour ne pas la renverser accidentellement sur mes factures • Je remarque que la canette est tiède et qu’il vaudrait mieux la remettre au frigo pour la rafraîchir • En me dirigeant vers la cuisine, le vase sur le comptoir me saute aux yeux : les fleurs manquent d’eau • En posant la canette sur le comptoir, je manque d’écraser mes lunettes que je cherchais depuis ce matin • Je me dis que je devrais ranger mes lunettes … mais avant, j’ai le temps de donner à boire aux fleurs • Je repose mes lunettes sur le comptoir, remplis un pichet d’eau et soudain, j’aperçois la télécommande qui traîne sur la table de la cuisine • Je me dis que ce soir je vais la chercher partout et que je ne me souviendrais plus qu’elle est dans la cuisine • Je décide donc de la ranger au salon … mais avant, je vais donner à boire aux fleurs • Je remplis le vase au tiers car malheureusement je renverse beaucoup d’eau sur le sol • En allant chercher une serpillère, je remets la télécommande sur la table de la cuisine • Je nettoie le sol puis range la serpillère • De retour dans l’entrée … je me demande ce que j’avais l’intention de faire • Cela va ma revenir, en attendant, je vais lire mes mails • Mais avant je … 102
  • 103. Todo – encours - fini TODO-> DoD : Exo Faire qq chose ------------------------ Comment tester Le résultat ------------------------ Valeur = 0 - 5O Urgent = 0 – 5 Estimation = 0-40 103
  • 104. Planning Game Faire qq chose ------------------------ Comment tester Le résultat ------------------------ Valeur = 0 - 5O Urgent = 0 – 5 Estimation = 0-40 104 Et Maintenant Estimer
  • 105. Kanban & US & DoD Laver voiture Vider corbeil Régler facture Canette frigo ------------------------ ------------------------ ------------------------ ------------------------ Ma femme dit: Corbeil vide Chèques débités Canette froide « elle est propre » Rien par terre ------------------------ ------------------------ ------------------------ ------------------------ Val= 50 Urg=2 E=25 Val= 2 Urg=2 E= 2 Val= 5 Urg=1 E=40 Val= 2 Urg=5 E= 5 Arroser fleurs Ranger telecom. Ranger lunettes Lire mail ------------------------ ------------------------ ------------------------ ------------------------ Le vase est plein d’ La telecom. est sur Les lunettes sont eau La table du salon Dans la chambre ------------------------ ------------------------ ------------------------ ------------------------ Val= 3 Urg=4 E=3 Val= 5 Urg=4 E=1 Val= 1 Urg=2 E=1 Val= 2 Urg=2 E= 15 105 Et Maintenant Planifier
  • 106. Planification Laver voiture Vider corbeil Régler facture Canette frigo ------------------------ ------------------------ ------------------------ ------------------------ Ma femme dit: Corbeil vide Chèques débités Canette froide « elle est propre » Rien par terre ------------------------ ------------------------ ------------------------ ------------------------ Val= 50 Urg=2 E=25 Val= 2 Urg=2 E= 2 Val= 5 Urg=1 E=40 Val= 2 Urg=5 E= 5 50/25 = 2 2/2 = 1 5/40 = 0,125 2/5 = 0,4 Arroser fleurs Ranger telecom. Ranger lunettes Lire mail ------------------------ ------------------------ ------------------------ ------------------------ Le vase est plein d’ La telecom. est sur Les lunettes sont eau La table du salon Dans la chambre ------------------------ ------------------------ ------------------------ ------------------------ Val= 3 Urg=4 E=3 Val= 5 Urg=4 E=1 Val= 1 Urg=2 E=1 Val= 2 Urg=2 E= 15 3/3= 1 5/1 = 5 1/1 = 1 106 2/15 = 0,13
  • 107. Les rôles dans Scrum(1) Directeur de produit : Client • Le Directeur de produit, ou Product Owner en anglais, représente les clients et les utilisateurs. Ses responsabilités se bornent à l'établissement des limites du projets et de chaque itération. • Il définit les fonctionnalités du produit. Voici une liste de ses responsabilités : – Choisit la date et le contenu de la release – Responsable du retour sur investissement – Définit les priorités dans le backlog en fonction de la valeur « métier » – Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire SCRUM Master : Coach + Manager + tracker • Le SCRUM Master représente le management du projet. Il interviens dans le cas ou une situation ou un événement peut empêcher ou retarder la progression du travail prévu. Ce n’est pas un maître. • Voici quelques unes de ces caractéristiques : – Responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum – Résout des problèmes, remédier aux imprévus – S'assure que l'équipe est complètement fonctionnelle et productive – Facilite une coopération poussée entre tous les rôles et fonctions – Protège l'équipe des interférences extérieures 107
  • 108. Les rôles dans Scrum(2) Equipe SCRUM / SCRUM Team • Une bonne équipe SCRUM est assez réduite et comporte finalement 5 à 10 personnes. L'échange est un atout primordial dans l'utilisation de SCRUM, il faut donc garder l'aspect dialogue au sein de son équipe de développement. • Les caractéristiques d'une bonne équipe : – Regroupant tous les rôles : Architecte, concepteur, développeur, spécialiste IHM, testeur, etc. – A plein temps sur le projet, de préférence – Exceptions possibles (administrateur, …)‫‏‬ – Organisation autonome – Equipe cross-fonctionnelle • La composition de l’équipe est fixe pendant un sprint Il n’y a pas de chef de projet • Le chef = PO + Equipe 108
  • 109. Scrum : Une release Durée planif sprint: Time Boxing 2*N (N = nb de semaines du sprint) • Un sprint n’est pas un sprint • Sprint de début de release • Sprint de stabilisation • Le PO doit anticiper le sprint suivant • Un sprint = 40 tâches • Une tâche = 1-2 jours max • Un backlog = 50 US 109
  • 111. Le test Nokia % des personnes ayant trouvé une des Q 1 : Itération deux meilleures réponses Q 2 : Pratique des tests 84 Q 3 : Spécifications 64 67 57,5 Q 4 : Product Owner Q 5 : Backlog de produit 37,5 27,5 Q 6 : Estimation 24,5 18 14 Q 7 : Sprint Burdown Chart Q 8 : Dérangement de l'équipe Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q 9 : Équipe Q 1 : Itération 1. Pas d'itération 2. Itération > 6 semaines Bas Vode 3. Durée variable < 6 semaines Jeff Sutherland 4. Itération de durée fixe 6 semaines 5. Itération de durée fixe 5 semaines 6. Itération de durée fixe 4 semaines ou moins test nokia-ScrumBut 111
  • 112. Comparaison XP-Scrum XP (programmation) Scrum (process) Client est ds la salle Oui Non Représenté par le product Owner Techniques de programmation Oui (Prog Objet) Peu  Junit Test  XP est le roi  Refactoring Génération automatique,  Binôme graphique, C , Javascript,….  Simple Gestion de projet Peu Oui Tracker  Velocité  Scrum est le roi  Planing game BurnDown chart Durée des itérations Autour de 2 semaines Autour d’un mois (En baisse) Adaptable Pas pendant les 3 premières Oui H itérations XP SCR Mélanger les deux 112 O RUP P Un scrum meeting
  • 113. Feature Driven Development 5 processes Inventée par Peter Coad 113
  • 114. FDD : Les rôles Principaux rôles Autres rôles • Project manager Release manager • Chief architect Language guru Build engineer • Domain experts Tool smith • Dev. manager System admin Testers • Chief Deployers programmers Tech writers • Class owners 114
  • 115. DSDM : Les principes • implication active des utilisateurs • équipes autorisées à prendre des décisions • produit rendu tangible aussi souvent que possible • L'adéquation au besoin métier est le critère essentiel pour l'acceptation des fournitures • Un développement itératif et incrémental permet de converger vers une solution appropriée • Toute modification pendant la réalisation est réversible • besoins définis à un niveau de synthèse • tests intégrés pendant tout le cycle de vie • esprit de coopération entre tous 115
  • 116. DSDM : Le cycle de vie 116
  • 117. Les rôles ds DSDM Sponsor exécutif : Manager Visionnaire : Manager Utilisateur ambassadeur : Client Utilisateur conseiller : Client-Tracker Chef de projet : Manager Coordinateur technique : consultant - expert Chef d’équipe : Manager Développeur Facilitateur : Coach Rapporteur : Tracker 117
  • 118. Crystal Méthodes créées par Alistair Cockburn (Expert UC) • Importance de la Communication et du feed-back client • Releases fréquentes • Deux grandes phases • Conception et planning • Itérations • Clear crystal : Adaptée à des équipes de 6-8 personnes maximum 118
  • 119. Le chef de projet Agile la qualité essentielle du leader sera le charisme plus que l’autorité. 119
  • 120. Le cycle de l’agilité Les 3 rythmes : • Le rythme du projet • Le rythme de l’itération, qui définit les étapes de réalisation majeures du projet. • Le rythme journalier, qui montre la progression au sein de l’itération. Ces rythmes suivent la même progression : • préparation, • Une idée claire (sinon précise) de l’objectif à atteindre. • Une façon de vérifier que la réalisation atteint l’objectif. • réalisation (laisser faire l’équipe) • retour d’expérience , • adaptation. 120
  • 121. Mise en place du process • Version – Temps fixe : 2-6mois (Préféré)contenu à définir – Contenu fixe durée à définir • Itérations-Durée : fixe 1-6 semaines – Taille de l’équipe fixe • Choix des indicateurs • Méthode – Tests automatisés, Intégration continue – Moins de code, qualité, binôme, refactoring – Itérations courtes, commencer par 4 semaines, puis finir par 2 – Implication du client , sur place à 25 ou 50%, représentant de la MOA • local, personnes, outils,… • Ce processus évoluera dans le futur (adaptable par l’équipe à la fin de chaque itération) Chaque équipe a un process différent  plus de process d’entreprise Exemple : Une équipe de 5 personnes, des itérations de 10 jours, 5 itérations par Version 121
  • 122. L’Agilité – Déroulement d’un projet Définition des besoins UC-User Story Planification 122
  • 123. Un Problème sur deux! Client Utilisateurs Client MOA (chefs) MOAD MOE Analystes (Chef de projet) Architectes Dev Experts Dev Programmeurs testeurs 123
  • 124. Une révolution Ne pas tout étudier, mais commencer le plus vite possible Faut-il toujours prendre un billet A-R? 40% à 70% des infos suffisent pour se lancer • François 1° (Androuet du cerceau) • Napoléon • Colin Powell 124
  • 125. Définitions des besoins - DVP Besoin global (10%) : Liste des UC ou US + Planification Détail du 1° tiers : Scénario des UC – Discussion des US Réalisation du 1° tiers It1 It2 Détail du 2° tiers Réalisation du 2° tiers Intégration continue It3 VNR Détail du 3° tiers Réalisation et Fin Bilan Définition des besoins Réalisation : les itérations 125
  • 126. Principe : une version • Le client (ou PO) est dans la salle – Il propose une liste de fonctionnalités (Backlog) • UC (sans donner les scénarios) ou User Story • Chaque US ou UC a une priorité donnée par le client • Les programmeurs affectent un poids (en pt) à chacune des US (Backlog du produit) – Estimation des US en équipe (planning game) – Si estimation impossible, découper la US, ou bien discuter avec le client – Le client refait une passe sur les priorités • On fait une découpe de la version en itérations • Démarrage de l’itération – Ecriture des scénarios ou détails des user story – Découpe en tâches des US (Backlog du sprint) – Estimation des tâches en heure – Tests + Dvp + Tests – Bilan + Demo • Maj du Backlog pour itération suivante 126
  • 127. User story le client L’équipe de dvp • Phase de Définition des besoins • Taille : carte postale •Discussion avec le client • Affecte un ID automatique • Affectation d’un coût • Ecrite par le client • si estimation impossible • N’est qu’un résumé • Rediscuter avec le client • Le reste est verbal • la décomposer en n US • Affectation d’une priorité (une valeur) • la décomposer en tâches et estimer les • Affectation sur une itération (voir partiel) tâches (Voir la suite) • Ecriture des tests finaux (TR) • Phase de DVP (Iterations) • Découpage en tâches er estimation (H) Les 3C • Prise de responsabilité d’un développeur • Card : une ou deux phrases pour une tâche • Réalisation en binôme • Conversation : verbale • Ecritures des TU • Confirmation : test • Réalisation • Passage des TU • Passage des tests finaux (TR) 127
  • 128. US : Recto 128
  • 129. US : Verso 129
  • 130. Planification d’une version • Calculer la vélocité de l’équipe – Prendre une moyenne des derniers sprints – Pour la première fois : • commencer l’estimation du sprint (ce qui nous donnera un nb de pt faisables en un sprint – voir plus loin) • Méthode des 3 experts • Pif • Répartir les US ds les sprints en commençant par les plus prioritaires • Ajustement des fins de sprint • Rajouter du mou – 10% pour erreur d’estimation – 15% pour Bug, FeedBack des utilisateurs • Tenir compte du calendrier (prévisible) • Tenir compte des changements des effectifs de l’équipe si prévu à l’avance • Prendre en compte les points de synchro avec d’autres équipes • Planning orienté utilisateur, sans garantie car il va être remanié 130
  • 131. BackLog de produit(1) D’après la velocité : Une itération = 50 points  5 Itérations (sans engagement) 131
  • 133. BackLog de produit(3) Méthode classique  • RAF = Temps estimé – temps passé Agilité • RAF = Réestimation de la tâche • Simplement utiliser les états (en cours-fini-…) Beurdone - burndown 133
  • 134. Ice Scrum 2 Excel Un planning de version •Une version •3 Itérations •Chaque itération contient des US Rmq : on ne voit pas les priorités (dommage) 134
  • 135. Une variante : Feature 135
  • 136. L’Agilité – Déroulement d’un projet Les itérations 136
  • 137. Une itération • Découpe en tâches (Planning horizontal) • Estimation des tâches en heure • Planification du sprint (2-4H) : Equipe + PO • Rajouter du Mou (30%) • Affectation des tâches – Fabrication des binômes • 1-2 jours de modélisation (toute l’équipe) • DVP – Préparation des tests – Coder en binôme et améliorer – Tester – Une réunion par jour (suivre ce que font les autres, …) • Acceptation par le client • Un bilan Améliorer le process Rmq : à la fin de la réunion de la planification du sprint, on doit avoir : Un but pour le sprint, Une liste des membres d'équipe (et de leur niveau d'engagement , si ce n'est pas 100%), Un backlog de sprint , une date bien pour la démonstration et uUne heure et un lieu bien 137 définis pour la mêlée quotidienne.
  • 138. Les principes • Modéliser agile ensemble • Se mettre en binôme • Ecrire les cas tests • Tester (NOK) • Coder – Faire simple – Suivre l’avancement • Tester (OK) • Une personne est responsable d’une tâche • Le code appartient à tout le monde 138
  • 139. La modélisation agile • Il faut modéliser (1 jour sur 10) • Les modèles sont faux • Un modèle agile est une peinture, pas une photographie • Modéliser à plusieurs, jamais seul • Moins de diagrammes de classe et plus de diagrammes d’interaction (et en //) • Ne pas passer trop de temps avec les outils, faire du reverse après coup • Modéliser pour soi même, pas pour faire de la documentation 139
  • 140. Développement (1) • Faire le plus simple possible • Pas de conception  Conception émergeante • Pas de Doc uniquement pour satisfaire le process • 1-2 jour de modélisation sur 10 • Binômes • Personne n’est propriétaire du code  Equipe • CR journalier + le tracker 140
  • 141. Binômes • Il y en a un qui fait le code pendant que l ’autre fait les tests • Il y en a un qui code pendant que l’autre le surveille • Il y en a un qui code pendant que l’autre se repose • Il y en a un qui tient la souris, l ’autre a le clavier... • Cela coûte forcément deux fois plus cher • J ’ai mes habitudes de codage... • J ’aime travailler tout seul • Binômer, c’est multiplier les couts par 2 141
  • 142. 142
  • 143. Binômes • Deux personnes travaillant ensemble pour concevoir, tester, coder... • Une seule machine (standardisée) – un conducteur: manipule la machine, réalise le travail – un observateur: propose, conseille, vérifie, et réfléchi à la stratégie globale • Changements de conducteur fréquents • Changements de binôme fréquents • Travail dense, exigeant, productif et efficace • L’un regarde le clavier, l’autre l’écran, et on discute • Celui qui ne sait pas faire, fait, l’autre lui apprend • TDD (l’un écrit un cas de test puis l’autre le programme, programmation ping-pong) • La programmation en binôme est épuisante et ne devrait pas être pratiquée toute la journée • Utiliser pour la montée en compétence des nouveaux entrants et pour les développements pointus 143
  • 144. Qualités d’ ½ binôme Ouverture d'esprit et remise en question Courage (de se mettre à nu) Communication active (pas de rétention d'information) Respect de l'autre et de son travail Capacité à tourner (tâches, fonctionnalités, personnes...) A se rendre non indispensable Durée d’un binôme = 1 jour, 1 tâche (pas toujours) Travailler à deux Savoir partager la gloire... Et les erreurs il est « plus facile de former un débutant (à l'agilité) que de déformer un gourou ». 144
  • 145. Cycle de vie d’un binôme 145
  • 146. Développement (2) • Faire le plus simplement possible – Faire simple mais pas simpliste – Pas de savants • Ne pas prendre d’expert • Se méfier des architectes – Problème des design patterns – Homogénéité de l’équipe avant tout – Les cimetières sont remplis de gens indispensables – Faire de la réorganisation de code • Revue (binômes) • Une seule fois (DP Template method) • Refactoring (séparation des idées) • Interdit si pas de tests automatisés • Quand? 146
  • 147. Faire le plus simple possible (1) • Ne pas faire de conception (la bourseMauvaise spéculation) • Ecrire les tests d’abord • Ne pas faire de sur spécification, mais penser à demain • Ne pas choisir tout de suite une architecture – Cela permet d’en tester plusieurs – Mais, ne pas la choisir trop tard!!! • Ne pas mettre de commentaires, ni de lignes blanches de séparation mais couper en n parties • Compliquer le code (ex DP) – Former, convaincre sinon ne pas faire – Nivèlement par le bas, mais tout le monde comprend • Commencer simplement • Ecrire la solution la plus simple possible pour résoudre ce cas et que ce cas « La vérité, ce n’est point ce qui démontre, mais ce qui simplifie »— Saint Exupéry. 147
  • 148. Faire le plus simple possible (2) If (n == 0) return 0; If (n == 1) return 1; Cas 0 et 1 ---------------------------------------------- return n; Cas 0 et 1 remanié ----------------------------------------------- If (n<=1) return n; Return 1; Cas 0, 1, 2 ----------------------------------------------- If (n<=1) return n; Cas 0, 1, 2 remanié Return F (n-2) + F (n-1); …Cas général… ----------------------------------------------- If (n < 0) erreur (TBD) If (n<=1) return n; Solution finale Return F(n-2) + F(n-1); 148
  • 149. Conception émergeante Le Refactoring : la solution agile pour conserver un code évolutif Exemple de conception émergeante sur un projet XP démarré en 2002, dans le cadre d’un grand projet télécom. Lancé au départ avec une équipe de trois développeurs, il occupait en 2005 plus d’une vingtaine de développeurs, avec une application qui représentait quelques centaines de milliers de lignes de code, des milliers de classes, et environ 20.000 tests. En 2003, nous avons extrait une partie “plateforme” gérée par une équipe dédiée …… La plateforme continue d’évoluer, et le nombre d’équipes utilisatrices augmente. Après six ans d’évolution, le code de l’application est toujours jugé propre. Des blocs de code  des fonctions, des fonctions  classes, des classes  modules,  des interfaces sont apparues pour découpler des modules, Certaines portions du code  “poussées” dans des fichiers de configuration, etc. le meilleur moyen pour trouver ces erreurs est d’arrêter de penser au logiciel au niveau théorique de l’analyse et de la conception, mais plutôt de se lancer, de se salir les mains, et de 149 commencer à construire le produit. Mike Cohn
  • 150. Stand up meeting • Tous les jours 15 mn • Toute l’équipe • Chacun doit dire (15/6 = 2mn30s) • Les problèmes qu’il a eu la veille si ils ne sont pas résolus • Ce qu’il pense pouvoir faire aujourd’hui • Les problèmes rencontrés • On est pas là pour résoudre les pb, mais • pour les faire connaitre, Les noter • prendre un RV ds la journée avec le sauveur • si il n’y a pas de sauveur, il faudra réestimer la tâche  US. • Mise à jour du planning journalier (Sprint) et de la liste des PB • Si plusieurs équipes scrum de scrum 150
  • 151. Stand up meeting : Objectifs • Evaluer l'avancement du travail • Identifier les obstacles(problèmes) nuisant à la progression: Quelque chose qui génère une perte de temps ou un gaspillage de ressources • Garder l'équipe concentrée sur l'objectif du sprint • Améliorer l'esprit d'équipe (cette réunion donne le sentiment commun de l’engagement) • Permettre une communication objective sur l'avancement 151
  • 152. Stand up meeting : Les erreurs • La réunion n'a pas lieu tous les jours • la réunion commence en retard • Tout le monde ne s'exprime pas • Des personnes bavardent en aparté • Une personne interrompt les autres • On s'adresse uniquement au ScrumMaster • On parle de choses sans rapport avec les tâches du sprint • Essayer de résoudre un pb compliqué 152
  • 153. Les tâches à faire (le radiateur) 153
  • 154. Ice scrum : Kanban 154
  • 155. Cycle de vie d’une User Story Dvp Client Phrase+Priorité Discussion Estimation ProductBacklog/iteration SprintBacklog Definition Test Découpe en Tâches Ecriture du test Affectation des tâches Affectation des tâches [NOK] Réalisation tâches Réalisation tâches TU TU TI [OK] 155
  • 156. Déroulement du Sprint (Iter1) Rmq : Total priorité = 42 Le premier jour on a de disponible 5/42 (10% du projet) Le 6° Jour on a de dispo 10/42 (25% du projet) 156
  • 157. Vélocité Vélocité = nb de points (estimation des US) réalisés pendant une itération 157
  • 158. BurnDown de Sprint (Iter1) Vélocité = 48-34 =14 !!! 158
  • 159. Burndown du produit après Iter1 Beurdone - burndown Vélocité = 14 !!! Faire une démonstration au client de ce qui fonctionne (25% du projet) Faire un bilan de l’itération (Voir plus loin) 159
  • 160. Iteration2 Vélocité = 50 Beurdone - burndown 180 Supposition : Pas de pb sur iter2 (50 points) Gain priorité pour le client = 4+3*3 = 13 Total 10(iter1) + 13 = 23/42 (La moitié du projet) et on avance de 9 points sur la US10 (reste 16-9= 7 points pour la finir) 160 Gain total de l’iter2 = 50 points (RAF = 230-50 = 180)
  • 161. Iteration3 Ré estimation Supposition : Iter3 US11 est terminée (4 points cout de 55) US10 est enfin OK (5 points cout 34) mais pas propre!!! En avance us15 OK (4 points cout 21) Velocité = 55 + 34 + 21 = 110 Total point 23(iter2) + 4 + 5 + 4= 36/42 161 Total RAF 180 – (55 + 34 + 21) = 70
  • 162. Fin du projet Vélocité moyenne = 41 Faire un bilan de fin de Version ou de fin de projet : IDEM (Voir plus loin) 162
  • 163. Graphe : BurnDown & velocité raf velocite 300 80 250 200 60 150 40 raf 100 velocite 50 20 0 0 1 2 3 4 5 1 2 3 4 300 Rmq : Techn Story : Attention à garder le 250 Backlog orienté métier (ex : Indexer une table) 200 rafInitial rafTotal 150 rafTotal 244 0 100 rafInitial 136 30 50 85 30 0 50 50 1 2 3 4 5 0 50 163
  • 164. Les indicateurs • Feature et US (UC) : Estimation taille en points et Utilité (Valeur, priorité) en points ou en € • Tâches : Estimation en heures • Vélocité : nb de points réalisés en un sprint • Mesures quotidiennes – Nb d’heures RAF pour les tâches du sprint non finies – Nb de tâches et de US restant à finir pour ce sprint – Nb de points de US restant à finir pour ce sprint • Mesures à chaque sprint – Capacité estimée au début du sprint – Vélocité réelle du sprint – L’utilité ajoutée pendant le sprint – Le Nb de US restant à faire ds le backlog (selon les états des US) – La taille (en point) du restant à faire ds le backlog. Pour la release seulement – Le nombre de points total ds le backlog, y compris ce qui est fini – Les tests (nombre, OK, Echec, Ecrits mais pas encore passés, ….) • Mesure de fin de release – Idem mesure de sprint, en en faisant la somme • Autres mesures – Nombre d’obstacle (trouvé, résolus, …) – Ressources consommées par le sprint – Qualité du code 164
  • 165. Montrer des diagrammes simples (1) 165
  • 166. Montrer des diagrammes simples (2) 166
  • 167. Cycle scrum : résumé • http://vimeo.com/4587652 scrum vivant • Bruxellesmobilite http://www.bruxellesmobilite.irisnet.be/ 167
  • 168. Les bilans • Bilan itération : Réunion des questions QQ (2-4H , Toute l’équipe + des muets) – Préparée par le scrum master – Qu’est ce qui a bien marché ? – Qu’est ce qui n’a pas marché ? – A-t-on besoin de qq chose ? – Que faut-il ne plus faire ? – Comment ça va-t-il bien (Le moral)? – Comment peut-on améliorer qq chose ? – Qu’est ce que vous gardez sur le cœur ? • Bilan de release : Réunion CC (1-2 Jours , Toute l’équipe + hiérarchie) – Préparée par tous (montrer l’esprit d’équipe-ROI) – IdemQQ + pompeuse Demo – mais à la Campagne + Champagne – Faire cette réunion même en cas d’échec du projet (sans champagne) 168
  • 169. XP-Game Un projet • User story • Planning game • Product backlog • Itérations – Sprint backlog – Stand up meeting – Calcul de la vélocité – Calcul de la satisfaction client • Bilan 169
  • 171. TDD Client Programmeur Tester pour vérifier n’est pas judicieux!!! Tester pour spécifier Ecrire un Test Spécifications executables Programmation par contrat Ecrire un scénario (Bertrand Meyer) Un test comprend plusieurs scénarios [OK] Passer le test Ecrire le pg Cas nominal, cas aux limites,…. [NOK] Le test remplace la documentation [OK] Passer le test [NOK] TU (Programmeur+Outils+Tracker) TR (Client + programmeur) L’acceptation n’est faite que par le client [OK] Tous les tests sont archivés et automatisés Remanier le code [NOK] Passer le test 171
  • 172. Qu’avez-vous testé aujourd’hui? Valtech-Test (14mn) BOF Yahoo!!! Tester pour corriger Tester pour spécifier Organiser des campagnes de Tester en permanence IC test Spécialiser les métiers du test Partager les responsabilités des tests 172
  • 173. Les tests Automatisés • TU1 TU • TU2 • TU3 • TU4 • TU5 OK/NOK • tr1 TestSuite TR • tr2 • tr3 • tr4 173
  • 174. Les types de tests • Tests unitaires (X-UNIT) – AAA : Acteurs, Action, Assertions (5-20 pour un scénario) – Ecrire le programme de test (cas par cas) – Générer les classes et les méthodes nécessaires – Lancer le programme de test  Echec – Ecrire le programme – Lancer le test jusqu’au  Succès – Archiver le test ( TestSuite ) – Ecrits par le programmeur • Tests de recette – Des outils – IHM Textuelles (automatique) – Outils de test – Ecrits par le client (test de comportement, spécification exécutable) • Tests d’IHM • Tests de charge, Tests temps réel,…. RMQ : Ecrire et tester le programme avant de l’écrire (TTD) 174