Introduction à l'Agilité
Upcoming SlideShare
Loading in...5
×
 

Introduction à l'Agilité

on

  • 7,121 views

Une première vue d'ensemble des méthodes agiles

Une première vue d'ensemble des méthodes agiles

Statistics

Views

Total Views
7,121
Views on SlideShare
7,091
Embed Views
30

Actions

Likes
4
Downloads
469
Comments
0

3 Embeds 30

http://actiskills.wordpress.com 18
http://www.slideshare.net 11
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

Introduction à l'Agilité Introduction à l'Agilité Presentation Transcript

  • 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
  • Junit : Ecriture du TestDOC import junit.framework.TestCase; public void testFibLimites(){ try{ public class TestFib extends TestCase { c.Fib(-1); fail(); private Calculette c ; }catch(Exception excpt){ assertTrue (excpt.getMessage().equals protected void setUp() throws Exception { ("Nb négatif interdit")); c = new Calculette(); //Acteur } } try{ public void testFibNominal(){ c.Fib(51); try{ fail(); int i = c.Fib(0); //Action }catch(Exception excpt){ assertTrue(i == 0); //Assertion assertTrue (excpt.getMessage().equals i = c.Fib(1); ("Nb superieur à 50 interdit")); assertEquals (i, 1); } i = c.Fib(2); } assertEquals (i, 1); i = c.Fib(21); assertEquals (i, 10946); Calculette Généré par Junit } catch(Exception excpt){fail();} +Fib(nb: int): int Avec un return 0; • } Rmq : un test peut avoir 5-20 Assertions et une dizaine de cas de tests 175
  • Junit : Passer le testNOK Rmq : Le cas de test s’arrête au premier assert en échec. Mais les autres tests sont exécutés 176
  • Junit : Ecrire le programme public class Calculette { public int Fib(int n) throws Exception { if (n<0) throw new Exception("Nb négatif interdit"); if (n>50) throw new Exception("Nb superieur à 50 interdit"); if (n <= 1) return n; return Fib(n-2) + Fib(n-1); } } RMQ : Commencer simplement (return 0, return 1, return n, ……) 177
  • Junit : Passer le testOK 178
  • Junit : TestSuite(1) import junit.framework.TestCase; import org.junit.Before; public class TestSomme extends TestCase { private Calculette c ; @Before Calculette public void setUp() throws Exception { +Fib(nb: int): int c = new Calculette(); +SommeN(n: int): int } public void testSommeNPremierNombre() { int i = c.SommeNPremierNombre(3); assertEquals (i, 6); i = c.SommeNPremierNombre(-10); assertEquals (i, -1); } 179
  • Junit : TestSuite(2) 180
  • TU : Bouchons & inversion des dépendances :A b:B A <<interface>> IB PA-IB +Fqq(b: B) +Fac() : qq Fqq(b): void Fac(): void B B +Fac() +Fac() A <<interface>> IB +Fqq(b: B) +Fac() A B +Fqq(b: B) +Fac() B Bouchon-TU +Fac() +Fac() 181
  • IHM IHM DOS <<entity>> E1 CTRL <<entity>> Blalal E2 Gfgd gghdghds 182
  • Test IHM Web : Selenium Selenium.mov (2mn) 183
  • Outil de test Temps réel Chess 184 TestTpsReel.wmv (5mn)
  • Visual Studio 2010 (Vidéo 1H) 185
  • L’Agilité Les outils agiles Voyager léger 186
  • Les outils • Gestion de la configuration • Script de fabrication • Des outils de DVP – avec du refactoring – TU • Des outils de tests (Selenium, Chess, visualStudio) • UML (reverse) • Gestion des changements Ne pas se faire ralentir par des • Gestion de projet outils. Jetez les 187
  • Script de fabrication • Make all : executable executable : file1.o file2.o gcc -o executable file1.o file2.o file1.o : file1.c file1.h gcc -c file1.c file2.o : file2.c file1.h file2.h gcc -c file2.c clean : rm file1.o file2.o executable core • Ant http://wiki.apache.org/ant/FrontPage - 188
  • Gestion de Configuration Test Check in Check out Mode : • lock Intégration DVP • merge 189
  • S1 R1 S2 Gestion conf : arborescence S1 S2 R1.1 S1.VF S1.VO S2.1 R1.2 S1.VF. S1.VF. 1 2 R2 S1.VF. 3 190
  • Gestion conf : Méthode de travail : System gest Conf : binomeA : binomeB 1 : CheckOut de la BD V1.0() 2 : Travail en local() 3 [mode != lock] : CheckOut de la BD V1.0() 5 : Consolidation() 4 : Travail en local() 6 : CheckIn de la BD V1.1() 7 : Consolidation() 8 : Integration du travail de A() V1.2 = V1.0 + WA + WB V1.2 = V1.1 + WB 9 : CheckIn V1.2() 191
  • Refactoring 100 fois sur le métier remettez votre ouvrage Architecture complexe Solution trop lourde •Réparer avant de continuer •Faire le ménage tous les jours, puis faire un nettoyage de printemps. •Ne pas le faire si il n’y a pas de tests automatisés OK 192
  • Refactoring • Supprimer le code mort (mettre en commentaire dans un 1° temps) • Rechercher les doublons (Equipe de base) – Regrouper du code dans des fonctions – Transformer les fonctions en méthodes de classe – Regrouper les méthodes par héritage ou agrégation – Faites des classes génériques (Template) • Remonter le niveau d’abstraction (classe abstraite et interface) • Utiliser les DP (Equipe moyenne) – Regrouper les classes dans des packages et encapsuler (Façade) – Regrouper du code dans des fonctions (Template méthode) – Supprimer les variables globales (Singleton) – Supprimer les Switchs (State-Stratégie-….) – Surveiller le couplage (Mediateur) – Garder tout private (Memento, Commande, Visiteur, ….) – Utiliser le configurateur (Fabrique) • Généraliser par fichier de configuration (.ini, XML) • Mais, Ne rien faire si pas de tests automatisés et complets OK – Ne pas toucher aux TR – Mais Il va falloir réécrire, modifier des TU, ne pas le faire tant que les TR ne passent pas. • Faites des mesures de la qualité (avant et après). Affichez les résultats • Passer à la programmation orientée aspect (Equipe de course) 193
  • Refactoring 194
  • Gestion des changements (1) Testeur Enregistrer un PB Utilisateur Login Configurer Admin Liste des utilisateurs Rechercher un PB Developpeur Corriger un PB S'approprier un PB Gerer un PB 195
  • Gestion des changements (2) Admin Client Bug MySQL Produit Developpeur DM Serveur Web Avec XP, il n’y a plus de Bug !!!!!! 196
  • Les Bugs • Un bug est un défaut • Les défauts sont rares en XP !!! • Il peut provenir: – Du client – Du programmeur • Mais il manque un test – Ecrire le test avant de corriger le défaut – Si nécessaire en faire une US (priorité urgente) pour le product backlog – …… Corriger le défaut • Et surtout, chercher l’origine de l’origine du défaut, puis y remédier. 197
  • Gestion des changements Bugzilla : Etats des DM Doit être intégré à la gestion de conf, doit contenir ce qu’il faut pour reproduire le Bug 198
  • Gestion de projet Excel/Gapps (gratuit) IceScrum (gratuit) http://www.extremeplanner.com/tour/ ScrumWorks (version gratuite et pro payante) GreenHopper - plugin JIRA (payant) Ice scrum Agilo (version gratuite et pro payante) Pivotal Tracker (payant) Mingle (Payant) Banana Scrum (Saas payant) TargetProcess (payant) VersionOne (payant) Confluence ? E Scum de Microsoft ? 199
  • L’Agilité Conclusions Applicabilité ROI Migration Forfait 200
  • Applicabilité de l’agilité 201
  • Agilité : Les avantages 202
  • Retours d’expérience(1) Chrysler (la paye) Métro de Newcastle Postes de supervision TGV Madrid-Barcelone 203
  • Qui http://blog.xebia.fr/2008/03/31/scrum-entretien-avec-jeff-sutherland-a-paris/ 204
  • Microsoft Visual studio 2010 – Agile •2500 ingénieurs • 4 ans • 1.500.000 fichiers-lignes sources • 61H pour Fabriquer le produit • Equipes de 10-20 personnes • Point de synchro toutes les 6 semaines  Jeff Beehler : VisualS tudio Chief of Staff 205
  • Qui : Et les systèmes critiques? • Un nouveau projet :Air Data Inertial Reference Unit. Ce dernier est un composant essentiel du système d'information (ADIRS), qui équipera les avions de la gamme A350 XWB. • Partenaire de longue date du groupe Thales, AdaCore affirme dans un communiqué que ce nouveau projet « doit permettre des avancées dans le domaine du développement de systèmes critiques à travers un certain nombre d'innovations, dont l'utilisation de méthodes de développement agiles et de techniques de programmation orientée objet. » 206
  • Retours d’expérience (2) Gains sensibles : • Diminution du volume de la documentation, • Diminution des coûts de pilotage du projet, • Diminution des efforts de validation des composants, • Une plus grande productivité, • Une capacité à intégrer beaucoup plus tardivement les changements demandés par la maîtrise d'ouvrage, et donc de livrer un produit plus proche du besoin du client. Michel Perron, responsable du SI . 207
  • Enquête(1) L’enquête de VersionOne (2008 sur 2319 entreprises dans 80 pays), 7 points d’amélioration conséquent : • Le changement est facilité • La productivité augmente • Les ressources humaines sont motivées • La qualité s’améliore • Les risques diminuent • Le « Time to market » se réduit • Cohérence entre développeur et utilisateur 208
  • Enquête(2) L’enquête du cabinet Forrester (2007, sur 70 entreprises ) 4 améliorations conséquentes: • 49% d’entre elles ont constaté une diminution des coûts d’opération • 83% d’entre elles ont constaté une amélioration de la satisfaction du client • 88% d’entre elles ont constaté une augmentation du niveau de qualité • 93% d’entre elles ont constaté une hausse de la productivité 209
  • Googlism (1) • 10 Choses que Google trouve vrai: – 1 : S’occuper des utilisateurs et le reste viendra • L’interface est claire et simple • Chargement instantané des pages • L’ordre des résultats n’est jamais vendu à personne • Les publicités doivent aider le client et ne pas lui être désagréable – 2: ……. Scrum A Scrum B Scrum C 210
  • Googlism (2) • Les gens ne doivent pas utiliser leur position hiérarchique pour obtenir ce qu’ils veulent. Ils doivent avoir de meilleurs arguments, basés sur des chiffres et l’expérience. La hiérarchie doit être utilisée en dernier ressort. • Nous détestons la bureaucratie dans toutes ses formes. Un process peut être une bonne chose, mais il doit accélérer les choses, si ce n’est pas le cas jeter le. – Dire Oui – Essayer – Si mauvais, refuser • 20% pour réfléchir, innover, …. • Petites équipes peuvent faire de grandes choses • Pas de polémiques, utiliser des chiffres • Mesurer tout • Un problème : ne pas se plaindre, mais le résoudre • Ne faites pas qq chose de mauvais parce que vous êtes pressé. Si vous pensez gagner du temps en faisant du moins bon, arrêtez vous (Que du bon!!!) 211
  • Googlism (3) • Affecter des priorités • Faire simple • Dire non • Ne pas propager : Ne créez pas des tâches, réunions ou email si ils vont couter aux autres plus que ce qu’ils valent (1000 personnes reçoivent 1 mail * 5 mn = ½ h*m) • Soyez concret rapidement (Commencez petit, Itérez souvent) • Don’t just kill project : learn from them • Travaillez ensemble • Soyez à l’écoute de ce qui se passe dans la compagnie (Zoogler) • Partagez toutes vos informations ( Idées, projets, délais, ….) • Les projets doivent être petits (4-6 personnes) • Personne ne travaille tout seul. Les solitaires sont rarement très productifs ni heureux. • Le plein temps est bien meilleur que le temps partiel. 212
  • Communication Ex : Comment communiquer sur un Wiki ou Zoogler 213
  • Que du bon !!! • Le syndrome de la décharge (idem pour le code) – ne pas commencer – ne pas continuer – Si qq commence, nettoyer tout de suite • Un bon code : 1. passe ses tests avec succès 2. ne peut être mal utilisé (code détrompé) • Programmation par contrat • LSD : Gestion préventive des défauts et Stop the line 3. ne contient pas de redondance 4. exprime clairement l'intention 5. est aussi court que possible (en dernier) 214
  • Retour d’expérience Migration 215
  • Migration vers agilité Prendre un coach • La migration dure Etudier l’existant S’appuyer sur les rôles • La migration douce Si nécessaire faire un trie dans les pratiques Affecter les personnes aux rôles Démarrer un projet pilote • La micro migration Monter en charge progressivement (une équipe de 4, puis rajouter un binôme…) S’adapter Augmenter le nb de projets Niveau 0 : Script de fabrication et gestion de configuration _______________________________________________ Niveau 1 : Tests automatisés Niveau 2 : Intégration continue Niveau 3 : Moins de code Niveau 4 : Itérations courtes Niveau 5 : Implication du client 216
  • Migration : Projet Scrum de transition Préparer Evaluer le Exécuter Diffuser ds Evaluer le l’application contexte projet pilote l’organisation niveau atteint de scrum Créer un projet Scrum de transition (sans Product Owner): • Les participants: – PDG (ou un dirigeant) – Des experts méthodes et processus – Le scrum master du premier projet pilote – Un ou plusieurs consultants externes experts de ces transitions • Les actions – Evaluer le contexte : Pourquoi faire du scrum (Vision) – Faire un Backlog d’amélioration des pratiques – Les prendre en compte, puis itérativement : Lever les obstacles: • Sur les pratiques scrum • Venant des personnes • Venant de l’organisation et de la gouvernance • Outil et matériel 217
  • Les 2 projets en // Projet Planifier Dernier Sprint1 Sprint2 Sprint3 pilote Release Sprint Projet Evaluer le Préparer Sprint1 Sprint2 Sprint3 Sprint4 Diffuser Migration contexte 218
  • Spécificité française • Culture des organisations – Langue – Esprit cartésien – Peur de l'incertitude • Gouvernance : séparation MOA/MOE • Modèle économique : grosses SSII sur des contrats au forfait • Puissance de la hiérarchie et des diplômes --------------------------- MAIS --------------------------------- • Capacité des équipes : formation, esprit d'initiative, aime la discussion et les contacts 219
  • Agilité & Forfait (Livre blanc Valtech) Pour Contre http://www.tv4it.net/contractualiser-les-projets-agiles-la-quadrature-du-cercle--permalink-4232.aspx 220
  • Bibliographie (livres) 221
  • Bibliographie (www) • http://www.extremeprogramming.org/e xample/stories.html • UML Laurent Audiber • http://www.agilealliance.org/ • http://www.aubryconseil.com/pages/Scr um • http://ayeba.fr/2010/04/09/les- methodes-agiles-ou-la-methode-agile/ 222
  • Cinéma Offshore TDD Est ce que cela marche en France ? TDR Architecture orientée service (SOA) Résumé scrum (1H15) 223
  • Conclusion 224
  • http://www.agiliste.fr/Home/bien-demarrer-avec-scrum 225