of 225/225
Introduction aux méthodes agiles B.Vinot

Introduction à l'Agilité

  • View
    19

  • Download
    1

Embed Size (px)

DESCRIPTION

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

Text of Introduction à l'Agilité

  • 1. B.Vinot Introduction aux mthodes agiles

2. Plan du cours Les projets classiquesLe gantt-Les mthodes destimation-Les cycles de dveloppementApports des technologies objet-La modlisation UMLUnify Process Lagilit Introduction Le manifeste agile Le lean Panorama des mthodes agiles Les rles les cyclesDroulement dun projet Dfinition des besoins - Mthode de planification agile les itrations La modlisation agile -La mle scrum ou le stand up meeting XP - Burndown chart- Calcul de la vlocit de lquipeLes outils agiles-TDDConclusionsMigration-Avantages-ROI- Les bilans 2 3. Agilit : Dfinitions LAgilit est lhabilit de crer et de rpondre au changement dans le but davoir du succs dans un environnement daffaires turbulent. - Jim Highsmith Certaines problmatiques sont difficiles, certains individus sont difficiles. Les mthodes Agiles ne sont pas une garantie de succs. - Craig Larman Ce nest pas la plus forte des espces qui survit, ni la plus intelligente, mais celle qui sadapte le mieux - Charles Darwin Intelligence = (2)Aptitude sadapter une situation, choisir en fonction des circonstances - Larousse3 4. Etes vous familier avec les cycles de dvp? Les projets classiquesLe gantt Les mthodes destimationLes cycles de dveloppement 4 5. Les mthodes prdictives Et leclient? Dcoupe PlanifieChef de projet DistribueDiscuteEquipe1 Equipe2 RaliseArchitecte dev1 dev2 5 6. Estimer pour Planifier Ne pas faire tout seul Mthode des trois experts (min + 2 * Moyen + Max) /4 Mthode des trois wagons Faire participer lquipe Tenir compte de la complexit - Fibonacci Hirarchiser les fonctions Relativiser : Cocomo6 7. Planifier avec FibonacciF(n) = F(n-2) + F(n-1) Plus cest compliqu et plus a .. Et si cest encore plus compliqu alors a .. Encore plus 7 8. Hirarchiser les fonctions Comparer 2 2 chaque fonction F2 F3 F4 F5 F6F1 F2 1 F1 3 F4 2 F5 1 F1 36 A chaque comparaison est associ un poids variant entre 1 et 3 F2 F2 3 F4 2 F2 2F6 16 (1 signifiant peu de diffrence) F3 F4 1 F5 1F3 22F4 F5 1F4 38 Exemples : F2 est plus importante que F1 avec un poids relatif de 1F5F5 14 F4 est plus importante que F1 avec un poids relatif de 2 F6 127 Poids de la fonction 5 : Somme de toutes les cases oranges (1+1+1+1) Poids de toutes les fonctions :F63,70% Somme de tous les poids de fonctionF37,40% Poids relatif de la fonction 5 : F514,80% 4 / 27 = 14,80 %F2 22,22% Hirarchie des fonctions F1 22,22% F429,66% No. 8 8 9. Dterminer la valeur des fonctions La fonction F6 reprsente 30 % du budget du projet pour un poids de 3,7 30% F6 3,70% % Amliorer le cot de la solution, ou Supprimer la fonction du primtre10% F37,40%F5 15% Cot 14,80%Poids20% F2 22,22%La fonction F4 reprsente 5 % duF1 20% budget pour un poids de 29,66 %22,22%Intgrer cette fonction dans le primtre 5% n F429,66% minimal 9 10. Le Gantt Cocomo 10 11. Les cycles de DVPWinston Royce1970 Addison Wesley1990 1980 : V 1990 : Itratif11 12. Classique-Agile 12 13. Une arnaque ? Madame Soleil La logique est lart de senfoncer dans lerreur avec confiance . Joseph Wood Krutch13 14. UnifyProcess14 15. La gestion de projet Classique Apports des technologies objet-Mtriques La modlisation UML Unify Process 15 16. Des preuves, des mtriques(1)Des chiffres, oui mais:Ce qui compte ne peut pas toujours tre Simplescompt, et ce qui peut tre compt ne Pas invents mais mesurscompte pas forcment - Einstein Beaucoup, mais pas trop Choisi, pas impos16 17. Apports des technologies Objet Increased Productivity 5Cost savings 22Improved interfaces6177 11 Software reuse1181417 Improved application maintenance Encapsulate existing applications Develop strategic applications quickly Develop applications as revenue source17 Access new OS 18. Des preuves, des mtriques(2) Les mtriques de McCabe C++ C++ C++C C C V0V1V2 V0V1V2 Average Function LOC 6,66 6,26,1129,6232,5 37,11 Min Function LOC2 11 3 3 3 Avg Cyclomatic Complex 1,661,591,59 5,886,256,56 Avg Comparison Complex 0,250,240,31,381,622,22 Avg Logic Flow Complex 1,911,831,89 7,257,888,78 Avg Function Complexity3,693,593,7 99,62 10,56 eLoc/100 2,07 2,52,68 2,682,913,53 eLOC207 250 26826829135318 19. Des preuves, des mtriques(3) 19 20. Programmation fonctionnelle 20 21. Programmation objet 21 22. Les concepts Objet Abstraction : Classe -nomPersonne-age Encapsulation-poids+Manger()+Travailler()+Anniversaire() HritageDentiste Boulanger Polymorphisme-adresseCabinet+Travailler() +Travailler()Arracher des dentsFaire du pain// un petit pg // un petit pg (suite) Personne p p=d Dentiste d p.Travailler() Boulanger bp=b p.Travailler() p.Travailler() For each p in leSac d.Travailler()p.Travailler() b.Travailler() sac leSac 22 23. La gestion de projetClassique Apports des technologies objet La modlisation UML Unify Process 23 24. DOC-PDF UML1.3 = 4,7MB DOC-PDF UML2.0 = 5.8 MB UML : La genseNov-97 Sept-97 2000Janv-971.01.1 (OMG) 1.41.0Juillet-960.920032.0Oct-95 0.8 Jacobson (use case - sdl)Booch-93Rumbaugh( OMT2)24 25. Un modle : DfinitionCe qui sert ou doit servir dobjet dimitation pour faire ou reproduire quelque chose (petit robert) UML Contient UML est un langage qui contient Des lments de modlisation: Des classes Des packages Des mthodes Des Acteurs.. Des diagrammes Classes, UC, Automate, Activit, .. Top Model25 26. Les diagrammes UML Diagramme de use case Diagramme de classes Diagramme de structure Diagramme d'objets Diagramme dynamique Diagramme d'interaction Diagramme de squence Diagramme de communication Automates Diagramme d'activit Autres diagrammes Composants et Dploiement 26 27. Les diagrammes UML27 28. Diagramme de Use caseLes acteurs Un acteur est un rle dun ou plusieurs objets situs lextrieur du systme et qui interagissent avec lui pour remplir une fonctionnalit donne de ce systme. Un acteur caractrise le rle jou par un objet Utilisateurlextrieur du systme. Un acteur parle au systme (Acteur principal) Le systme peut parler un acteur (Acteur secondaire) Un acteur est : Un humain (via une IHM) Du soft Du hard Le temps28 29. Diagramme de Use case Use Case Un Cas dutilisation ( use case ) est une fonctionnalit remplie par le systme et qui se faire qqchose manifeste par un ensemble de messages changs entre le systme et un ou plusieurs acteurs. ProtocoleAPIIHM VerifierBonneMarcheUtilisateurCapteurTemperat ure Acteur primaire Une fonctionnalit interne Acteur secondaire Au systme 29 30. Diagramme de Use caseDescription d'un Use Case (3-5 pages) Titre et numrotationCe n est pas une Rsum description formelleMais doit tre trs dtaill Les acteurs Acteur principal Acteurs secondaires Ceci est l usage Pr-conditionsmais ne fait partie Description de la norme UML Exceptions Post-conditionsScenario30 31. Diagramme de Use CaseAppeler / numro GSM Envoyer Utilisateur Appeler / contact Antenne HLR Recevoir appelGerer les contacts A1B3B2ConfigurateurA2 A3 B1Prparer31 32. Utilisation des Use case Manger DescriptionsDistribuer le comportement des fonctionnalitsaux mthodes 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 socit de vente par correspondance vous demande de dvelopper son systme informatique. Ce systme doit pouvoir prendre en compte des commandes passes par la poste et des commandes passes par internet. Il doit suivre les expditions qui ne sont effectues que si le paiement est OK. Les paiements se font par carte bancaire dans le cas d'internet et par chque dans le cas de la poste. Les paiements sont valids par un systme bancaire appartenant la socit et existant. Il faut rcuprer ce systme. Le nouveau systme est charg aussi de la gestion de stocks, lorsqu'un article atteint un seuil minimal, alors il faut passer une nouvelle commande au fournisseur adquat. A la rception 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'expdition est faite par un robot existant au quel il suffit de passer les coordonnes du client, et la liste des produits achets. En cas d'indisponibilit, une lettre doit tre envoy au client. 34 35. Notion de strotypesUn strotype est une nouvelle classe dun lment demodlisation qui est introduit au moment de lamodlisation. Cela reprsente une sous classe dun lmentde modlisation existant avec la mme forme, mais avecune intention diffrente. Les strotypes font partie des mcanismes dextensibilits, prvuspar UML. Une interface est un strotype On peut strotyper les classes, les associations, les packages, .. On peut associer un nouvel icne pour chaque nouveau strotype. Z 35 36. Diagramme de classe Un diagramme de classe montre la structure statiquedu modle, les choses qui existent, leur structureinterne et les relations aux autres choses. Statique : Ne pas utiliser de verbes d'action pour relier les classes Une classe isole est une classe inutile Doit tre vrai tout le temps Les choses qui existent Reprsente LE programmeMaison On ne peut pas tout montrer sur un seul schmaMoto GaragePersonne PersonneTricycle36 37. Diagramme de classe Les classesUneClasse -attributPrive +attributPublic #attributProtected +attributDeClasse +attributTyp: int +attributTypInit: int = 56 +Operation() +OperationDeClasse() +OperationAvecParam(par1: int, par2: boolean): int +OperationAbstraite()37 38. LhritageVehiculeLhritage s appelle gnralisation+carteGriseen UML-marque#nbPassagers EST UNAvion Bateau +ailes+moteurDiesel +reacteur[2] 39. Les interfaces ClientClient Une interface permet un objet (le Client)De faire faire quelque chose (Fqq) unObjet de type A, sans savoir quil est un A. Il sait seulement quil est de type FqqAble FqqAbleFqqAble +Fqq()On a remont le niveau dabstraction.On utilise une interface pour imposer desClasses diffrentes dimplmenter une ouPlusieurs oprations.A A+Fqq()+Fqq() 39 40. Les associations Les associations reprsentent des relations structurelles entre classes dobjets. Une association symbolise une information dont la dure de vie nest pas ngligeable par rapport la dynamique gnrale des objets instances des classes associes. La plupart des associations sont binaires, cest--dire quelles connectent 2 classes. Certaines sont reflxives. +h Personne +fVoiture 4Roue 40 41. Diagramme de classe : AssociationsEst Employe parPersonneSocieteNom d'associationEst Employe parPersonneSocieteNom de rle-employe -employeur 1..*0..1PersonneSocieteCardinalit-Multiplicit-employe-employeur Personne Societe employeur : Societe employe : ListeOfPersonne1..* Personne SocieteNavigabilit-employesPersonne Societe employes : Personne 41 42. Diagramme de classe DpendanceDepenser 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 ImmeubleGardemanger Appartement LapinPersonne Famille PiceChienMariage Cuisine CompteBanquaire NourritureAnimal Bail Whisky Salonacte de propritChat43 44. Diagramme de classe : Exercice2 44 45. Diagramme dynamique Diagrammes d'interaction (Squence collaboration) servent montrer comment les objets parlent les uns aux autres.Ils montrent le droulement d'un ou d'une partie d'un Use case(cas nominal, cas des exceptions, )Un objet (lmetteur) envoi un message un autre (le rcepteur).Le rcepteur doit avoir une opration correspondante au message. Automates servent montrer le comportement d'une classe qui ragit diffremment selon son tat. Activits montrent le droulement d'une mthode d'une classe oucelui d'un Use case45 46. Diagramme de Squence: C1: C2 : C3 : A1 Oper1()new : C3 Oper3() Oper2() retour Oper1() C3() Oper2()Delete() 46 47. Diagramme de Squence (UML2.0) EntrepriseEmploye * +salaire +CalculerSalaire() -lesEmployes +CalculerSalaire(): Commerciaux: Employe : EntrepriseCommerciaux: FinMois +commission +CalculerCommission() CalculerSalaire()loop pour chaque employe CalculerSalaire() alt commercialCalculerCommission() 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 OffArretMarcheOn Casse Casse 48 49. Automate tat & Transition Action en entrant dans l'tat EtatAction en sortant de l'tat entry/ Action1 exit/ Action2Action dclenche sur rception de Ev1 on Ev1/ Action2 do/ Activit Activit vnement qui dclenche la transitionGardeE1 Ev1( a1,a2 )[ i == 0 ] / ActionDeTransition ^Cible.SendEv2(a3, a4) E2 Action effectue sur la transition Envoie de Ev2 un objet Cible Rmq : Le langage daction (UML1.4) est remplac par 50 types daction49 50. Automate imbriquAfter5 Arret Off On Marche Ouvrir[ cuve vide ]Lavage EssorageAfter15 PorteOuverteAfter10 RinageFermer H 51. Automate : exercice E1ST1 E1 / i++ ST2E1 entry: i++entry: i = 0exit: i++ exit: i++E3 on E4: i ++E1 E1 E3E1E3[ i == 5 ]E2 E2E1E2 ST4ST3E3 on E2: i = i - 2E1 E3E3 51 52. La gestion de projetClassique Apports des technologies objet La modlisation UML Unify Process52 53. UP : La basePU est base de composants PU utilise UML PU est pilot par les cas dutilisation PU est centr sur larchitecture PU est itratif et incrmental53 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 XUP54 55. OpenUP RUP : Principes7 rles (environ 45 pour RUP)20 artefacts (plus de 80 pour RUP)18 tches (plus de 150 pour RUP) 55 56. Les artefacts Activit de gestion de projet Comptes rendus, planning dactivit, . Rsultats Modles Code source Spcifications .. 56 57. Les rles Les analystes (exigences) Les dveloppeurs Les testeurs Les managers (grent le processus) Le chef de projet Les autres (Client, MOA, stakeholder, .)57 58. Les activits Modlisation mtier Les Besoins Analyse et conception Implmentation Tests Dploiement Gestion de configuration Etudi plus tard Gestion du projet Environnement58 59. BPM 59 60. Modlisation mtierStrotypes UP Client business use caseFournisseurLes objets de Les employsLentreprise Les process 60 61. Organisation des modles (UP)uc1 Dfinition des besoins VOPC Les sources C1 C2 Composant1Les UC realization (Documentation) residentsC1C2 Les composants (physiques et logiques)PCLes machinescomponents Composant161 62. Exemple dun workflow 62 63. Processus traditionnel Gros classeur sur ltagre des dveloppeurs Ramasse la poussire 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_lifestyle65 66. Le processus comme un produit Pas un simple livre, pas une autre OOAD mthode Fourni comme un site web (avec les sources) Constamment amlior Base de connaissances Navigation graphique, moteur de recherche, index Guides, templates de documentation, aide lutilisation des outils 66 67. 67 68. RUP : Ses forces Cadre gnrique Rfrentiel de bonnes pratiques; Gestion des risques dans les projets; Cadre propice la rutilisation; Approche base sur larchitecture; Traabilit partir des Uses Cases jusquau dploiement. Ex : IBM Tivoli ITUP 68 69. RUP : Ses faiblesses Cot de personnalisation souvent lev; Autres logiciels propritaires (Rational) indispensables; Trs ax processus : peu de place pour le code et la technologie ; Vision non vidente ni immdiateDEVELAY Isabelle EDORH-A. Semeho GUIBOUT Nicolas69 70. RUP : Conclusion RUP considr comme: un framework de processus gnriques; un mtaprocessus; Dmarche itrative Rduction des risques; Facile expliquer et valider (les livrables); Finalement pas trs populaireDEVELAY IsabelleEDORH-A. SemehoGUIBOUT Nicolas 70 71. LAgilit Introduction Le lean software dvp 71 72. Une petite vido David Gageot Directeur Technique Valtech Technology E:CoursAgilitVideoValtech) 40mn72 73. Quest ce quune mthode agile(1) Deux caractristiques fondamentales Adaptatives plutt que prdictive Favorables au changement Planification plus souple Faite par lquipe et non impose par le chef Oriente vers les personnes plutt que vers les processus Travailler avec les spcifits de chacun Responsabilit, confiance 73 74. Quest ce quune mthode agile(2) Dlivrer rapidement et trs frquemment des versions oprationnelles, pour favoriser un feed-back client permanent Accueillir favorablement le changement Assurer une coopration forte entre client et dveloppeurs Garder un haut niveau de motivation Le fonctionnement de lapplication est le premier indicateur du projet Garder un rythme soutenable Viser lexcellence technique et la simplicit Se remettre en cause rgulirement Ecouter le client mais savoir dire non74 75. Les bureaux agiles Important - Symbolique75 76. Nous dcouvrons de meilleuresfaons de dvelopper des Logiciels en ralisant ce travailLe manifeste agile et en aidant les autres le faire 17 Personnes (2001)4 Valeurs12 principesKent Beck XP-JunitWard Cunningham wikiJeff Sutherland scrum 76 77. Manifeste agile : Les valeurs L'quipe ( Personnes et interaction plutt que processus et outils ) Il est prfrable d'avoir une quipe soude et qui communique compose de dveloppeurs moyens plutt qu'une quipe compose d'individualistes, mme brillants. La communication est une notion fondamentale. L'application ( Logiciel fonctionnel plutt que documentation complte ) La documentation reprsente une charge de travail importante, mais peut pourtant tre nfaste 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-mme (si besoin) Transfrer les comptences au sein de l'quipe (communication). La collaboration ( Collaboration avec le client plutt que ngociation de contrat ) Le client doit tre impliqu dans le dveloppement. On ne peut se contenter de ngocier un contrat au dbut du projet, puis de ngliger 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 ( Ragir au changement plutt que suivre un plan ) La planification initiale et la structure du logiciel doivent tre flexibles.Les premires versions du logiciel vont souvent provoquer des demandes d'volution. 77 78. Manifeste agile : Les 12 principes 1.Notre premire priorit est de satisfaire le client en livrant tt et rgulirement des logiciels utiles. 2.Le changement est bienvenu, mme tardivement dans le dveloppement. Les processus agiles exploitent le changement comme avantage comptitif pour le client. 3.Livrer frquemment une application fonctionnelle, toutes les deux semaines deux mois, avec une tendance pour la priode la plus courte. 4.Les gens de l'art et les dveloppeurs doivent collaborer quotidiennement au projet. 5.Btissez le projet autour de personnes motives. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacit faire le travail. 6.La mthode 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 dveloppement soutenable. Commanditaires, dveloppeurs et utilisateurs devraient pouvoir maintenir le rythme indfiniment. 9.Une attention continue l'excellence technique et la qualit de la conception amliore l'agilit. 10. La simplicit - l'art de maximiser la quantit de travail ne pas faire - est essentielle. 11. Les meilleures architectures, spcifications et conceptions sont issues d'quipes qui s'auto- organisent. 12. intervalle rgulier, l'quipe rflchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens. 78 79. Assembl nationale (30-4-10) Ch. Vanneste (dput du Nord) Etude Sofres : pourquoi travailler? Anglais des sous Allemands Epanouissement FranaisContacts humains Direction HSBC : ce qui manque aux entreprises franaises: Innovation Responsabiliser les salaris 79 80. (1950) LAgilitIntroductionLe lean software dvp80 81. Lean : Philosophie Le LEAN est principalement une approche managriale pouroptimiser le systme de production Optimiser la chane de cration de valeur ajoute(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 dcision (Le plus tardpossible) Volont de perfection chaque tape (Stopper la chane) Sappuyer sur les facults dadaptation des individus (boite ides) 81 82. Kanban82 83. Lean : Les 7 concepts Eliminer les gaspillages Amliorer le systme La qualit de lintrieur Reporter la dcision Livrer rapidement Respecter les personnes Crer la connaissance http://www.youtube.com/watch?v=Dl4dcLbNlgo&f eature=related83 84. Lean : Gaspillage Shigeo Shingo (1950) 1. Stock 2. Surproduction 3. Tches inutiles 4. Dplacement 5. Transport 6. Attente 7. Dfauts 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 spcifications 3. Tches inutiles 3. Processus4. Changements de priorit, 4. Dplacementchanger de tche 5. Transport 5. Transmission dinformations 6. Attente 6. Retards 7. Dfauts 7. Dfauts85 86. LAgilitPanorama des mthodes agiles86 87. Les mthodes agiles : Panorama87 88. Taille des projets 1-2 ans & 6-12 personnes Couper les projets 88 89. Les mthodes agiles : Contraintes 89 90. eXtremPrograming KentBeck (1996) Paye de Chrysler Les 4 valeurs de XP : CRSC Communication Retour-FeedBack Simplicit Courage90 91. CRSC Communication Client-Equipe Programmeur-Programmeur Equipe-Extrieure (indicateurs du projet) Retour - Feedback Livraison frquente VNR Avancements objectifs Le client est l Simplicit pas de sur spcifications Code toujours aussi petit et simple que possible Courage De dire que on sest tromp De revenir en arrire De faire du TU Dannoncer les soucis 91 92. Les principes de base Seul le code source fait foi, il possde une odeur, appartient lquipe, il contient la doc Limportant cest le programmeur (ne pas dpasser 40H/S) Faire le plus simple possible Restructurer ds que ncessaire Pratiquer la programmation par paire Les spcifications sont des histoires dutilisateurs La planification est un jeu Livrer frquemment Tester donc intgrer encore, toujours et tout le temps tre courageuxB.Vinot 93. Les rles ds XP(1) Dveloppeur (100%) travaille en binme, communique doit tre autonome a une double comptence : dveloppeur 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 leve sur le problme et l'environnement du business doit apprendre crire les cas de tests fonctionnels est dans la salle Testeur (50%-100%) a pour rle d'aider le client choisir et crire ses tests fonctionnels Tracker Rapporteur (10-20% = 30 mn par dveloppeur tous les 2 jours + qq runions) aide l'quipe mieux estimer le temps ncessaire l'implmentation de chaque user story contrle la conformit de l'avancement au planning93 94. Les rles ds XP(2) Coach (100% au dbut, puis 50%, puis 10%) recadre le projet ajuster les procdures agiles doit intervenir de la manire la moins intrusive possible ne doit pas soccuper du projet nest pas l tout le temps Consultant Expert (0-100%) n'apporte pas de solution toute faite apporte l'quipe les connaissances ncessaires pour qu'elle rsolve elle-mme lesproblmes doit tre un formateur Manager (10-25%) doit croire lagilit apporte l'quipe courage et confiance Cest le chef hirarchique Demande des comptes94 95. 95 96. Combinaison des rles ds XPRmq : si plusieurs clients, Ils doivent parler dune seule voie96 97. What is Scrum? Jeff Sutherland Sutherland1993 Quest ce que Scrum? Pas une mthode Pas un process Pas un ensemble de procdures Cest un framework ouvert de dvp comportant un ensemble de rgles 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 sorganiser pour travailler 10 fois mieux97 98. Scrum : Le cycle de vie DVP TestsUCPlanning Usergame story 98 99. Scrum : Backlog- BurnDown 99 100. Bob: Voil jai termin dedvelopper ce module,Scrum : Kanban cest dploy ! Grard: Ben je voisrien? Bob: Ha en tout cas chezmoi a marche DoD 100 101. Definition Of DoneDveloppementMigration des donnes (structures + donnes) Support IE7 + FF3Test Seleniums crits Support IE6Test Seleniums pass avec succs Support Navigateurs Home PageTest Unitaires crits Dploy sur StagingTest Unitaires pass avec succs Tests de rgression ok (tous les tests Multilingue et traduction okpassent) Documentation (dossier Dmarches effectuer auprs dedhbergement,) linfrastructure (pour la Prod ou autres. Ex: url, connexion db,ftp,) Dpendance avec dautres acteurs Visualiser sur le mur Si la dfinition de termin vous semble confuse Mettez au dbut un champ dfinition de termin pour chaque US. 102. TODO : Exo Aujourdhui je dcide de laver ma voiture En allant vers le garage, je remarque quil y a du courrier sur la table dentre Je dcide de jeter un il au courrier avant de laver la voiture, il contient des factures et des publicits Je jette les publicits dans la corbeille papier et ralise 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 bote aux lettres, je me dis que je pourrais conomiser un trajet en postant mes factures et je dcide donc de prparer dabord le rglement des factures Je prends mon carnet de chques et trouve sur le bureau la canette que javais commenc boire. Je me dis quil faut que jenlve la canette pour ne pas la renverser accidentellement sur mes factures Je remarque que la canette est tide et quil vaudrait mieux la remettre au frigo pour la rafrachir En me dirigeant vers la cuisine, le vase sur le comptoir me saute aux yeux : les fleurs manquent deau En posant la canette sur le comptoir, je manque dcraser mes lunettes que je cherchais depuis ce matin Je me dis que je devrais ranger mes lunettes mais avant, jai le temps de donner boire aux fleurs Je repose mes lunettes sur le comptoir, remplis un pichet deau et soudain, japerois la tlcommande qui trane sur la table de la cuisine Je me dis que ce soir je vais la chercher partout et que je ne me souviendrais plus quelle est dans la cuisine Je dcide 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 deau sur le sol En allant chercher une serpillre, je remets la tlcommande sur la table de la cuisine Je nettoie le sol puis range la serpillre De retour dans lentre je me demande ce que javais lintention de faire Cela va ma revenir, en attendant, je vais lire mes mails Mais avant je 102 103. Todo encours - fini TODO-> DoD : ExoFaire qq chose------------------------Comment testerLe rsultat------------------------Valeur = 0 - 5O Urgent = 0 5 Estimation = 0-40103 104. Planning GameFaire qq chose------------------------Comment testerLe rsultat------------------------Valeur = 0 - 5O Urgent = 0 5 Estimation = 0-40 104 Et Maintenant Estimer 105. Kanban & US & DoD Laver voiture Vider corbeilRgler facture Canette frigo ------------------------------------------------ ------------------------ ------------------------ Ma femme dit: Corbeil vide Chques dbitsCanette froide elle est propre Rien par terre ------------------------------------------------ ------------------------ ------------------------ Val= 50 Urg=2 E=25Val= 2 Urg=2 E= 2Val= 5 Urg=1 E=40Val= 2 Urg=5 E= 5 Arroser fleursRanger telecom.Ranger lunettesLire mail ------------------------------------------------ ------------------------ ------------------------ Le vase est plein dLa telecom. est surLes lunettes sonteauLa table du salonDans la chambre ------------------------------------------------ ------------------------ ------------------------ Val= 3 Urg=4 E=3Val= 5 Urg=4 E=1 Val= 1 Urg=2 E=1 Val= 2 Urg=2 E= 15 105 Et Maintenant Planifier 106. Planification Laver voitureVider corbeilRgler facture Canette frigo ------------------------ ------------------------ ------------------------ ------------------------ Ma femme dit:Corbeil vide Chques dbitsCanette froide elle est propre Rien par terre ------------------------ ------------------------ ------------------------ ------------------------ Val= 50 Urg=2 E=25 Val= 2 Urg=2 E= 2Val= 5 Urg=1 E=40Val= 2 Urg=5 E= 5 50/25 = 2 2/2 = 15/40 = 0,125 2/5 = 0,4 Arroser fleurs Ranger telecom.Ranger lunettesLire mail ------------------------ ------------------------ ------------------------ ------------------------ Le vase est plein d La telecom. est surLes lunettes sonteau La table du salonDans 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= 153/3= 1 5/1 = 51/1 = 1 1062/15 = 0,13 107. Les rles dans Scrum(1) Directeur de produit : Client Le Directeur de produit, ou Product Owner en anglais, reprsente les clients et les utilisateurs. Ses responsabilits se bornent l'tablissement des limites du projets et de chaque itration. Il dfinit les fonctionnalits du produit. Voici une liste de ses responsabilits : Choisit la date et le contenu de la release Responsable du retour sur investissement Dfinit les priorits dans le backlog en fonction de la valeur mtier Ajuste les fonctionnalits et les priorits chaque sprint si ncessaire SCRUM Master : Coach + Manager + tracker Le SCRUM Master reprsente le management du projet. Il interviens dans le cas ou une situation ou un vnement peut empcher ou retarder la progression du travail prvu. Ce nest pas un matre. Voici quelques unes de ces caractristiques : Responsable de faire appliquer par lquipe les valeurs et les pratiques de Scrum Rsout des problmes, remdier aux imprvus S'assure que l'quipe est compltement fonctionnelle et productive Facilite une coopration pousse entre tous les rles et fonctions Protge l'quipe des interfrences extrieures107 108. Les rles dans Scrum(2) Equipe SCRUM / SCRUM Team Une bonne quipe SCRUM est assez rduite et comporte finalement 5 10personnes. L'change est un atout primordial dans l'utilisation de SCRUM, il fautdonc garder l'aspect dialogue au sein de son quipe de dveloppement. Les caractristiques d'une bonne quipe : Regroupant tous les rles : Architecte, concepteur, dveloppeur, spcialisteIHM, testeur, etc. A plein temps sur le projet, de prfrence Exceptions possibles (administrateur, ) Organisation autonome Equipe cross-fonctionnelle La composition de lquipe est fixe pendant un sprintIl ny a pas de chef de projet Le chef = PO + Equipe108 109. Scrum : Une releaseDure planif sprint: Time Boxing 2*N (N = nb de semaines du sprint) Un sprint nest pas un sprint Sprint de dbut de release Sprint de stabilisation Le PO doit anticiper le sprint suivant Un sprint = 40 tches Une tche = 1-2 jours max Un backlog = 50 US 109 110. Scrum : sprint http://www.axosoft.com/ontime/videos/scrum110 111. Le test Nokia% des personnes ayant trouv une des Q 1 : Itrationdeux meilleures rponses Q 2 : Pratique des tests84Q 3 : Spcifications6467 57,5 Q 4 : Product Owner Q 5 : Backlog de produit37,5 27,5 Q 6 : Estimation24,5 18 14 Q 7 : Sprint Burdown Chart Q 8 : Drangement de l'quipeQ1Q2Q3Q4Q5Q6Q7Q8Q9 Q 9 : quipe Q 1 : Itration 1. Pas d'itration 2. Itration > 6 semaines Bas Vode3. Dure variable < 6 semaines Jeff Sutherland 4. Itration de dure fixe 6 semaines 5. Itration de dure fixe 5 semaines 6. Itration de dure fixe 4 semaines ou moinstest nokia-ScrumBut111 112. Comparaison XP-ScrumXP (programmation)Scrum (process) Client est ds la salle Oui NonReprsent par le productOwner Techniques de programmation Oui (Prog Objet) Peu JunitTest XP est le roi RefactoringGnration automatique, Binme graphique, C , Javascript,. Simple Gestion de projetPeu OuiTracker Velocit Scrum est le roi Planing gameBurnDown chart Dure des itrations Autour de 2 semainesAutour dun mois (En baisse)AdaptablePas pendant les 3 premires OuiH itrationsXPSCR Mlanger les deux 112O RUPPUn scrum meeting 113. Feature Driven Development 5 processesInvente par Peter Coad113 114. FDD : Les rlesPrincipaux rles Autres rles Project manager Release manager Chief architect Language guru Build engineer Domain expertsTool smith Dev. managerSystem admin Testers Chief Deployers programmers Tech writers Class owners114 115. DSDM : Les principes implication active des utilisateurs quipes autorises prendre des dcisions produit rendu tangible aussi souvent que possible L'adquation au besoin mtier est le critre essentielpour l'acceptation des fournitures Un dveloppement itratif et incrmental permet deconverger vers une solution approprie Toute modification pendant la ralisation est rversible besoins dfinis un niveau de synthse tests intgrs pendant tout le cycle de vie esprit de coopration entre tous115 116. DSDM : Le cycle de vie116 117. Les rles ds DSDMSponsor excutif : Manager Visionnaire : Manager Utilisateur ambassadeur : Client Utilisateur conseiller : Client-Tracker Chef de projet : Manager Coordinateur technique : consultant - expert Chef dquipe : Manager Dveloppeur Facilitateur : Coach Rapporteur : Tracker 117 118. CrystalMthodes cres par Alistair Cockburn (Expert UC) Importance de la Communication et du feed-back client Releases frquentes Deux grandes phases Conception et planning Itrations Clear crystal : Adapte des quipesde 6-8 personnes maximum 118 119. Le chef de projet Agile la qualit essentielle du leader sera le charisme plus que lautorit.119 120. Le cycle de lagilit Les 3 rythmes : Le rythme du projet Le rythme de litration, qui dfinit les tapes de ralisation majeures du projet. Le rythme journalier, qui montre la progression au sein de litration. Ces rythmes suivent la mme progression : prparation, Une ide claire (sinon prcise) de lobjectif atteindre. Une faon de vrifier que la ralisation atteint lobjectif. ralisation (laisser faire lquipe) retour dexprience , adaptation. 120 121. Mise en place du process Version Temps fixe : 2-6mois (Prfr)contenu dfinir Contenu fixe dure dfinir Itrations-Dure : fixe 1-6 semaines Taille de lquipe fixe Choix des indicateurs Mthode Tests automatiss, Intgration continue Moins de code, qualit, binme, refactoring Itrations courtes, commencer par 4 semaines, puis finir par 2 Implication du client , sur place 25 ou 50%, reprsentant de la MOA local, personnes, outils, Ce processus voluera dans le futur (adaptable par lquipe la fin de chaque itration) Chaque quipe a un process diffrent plus de process dentreprise Exemple : Une quipe de 5 personnes, des itrations de 10 jours, 5 itrations par Version 121 122. LAgilit Droulement dunprojetDfinition des besoinsUC-User Story Planification 122 123. Un Problme sur deux! ClientUtilisateurs Client MOA (chefs) MOAD MOE Analystes (Chef de projet)Architectes DevExpertsDevProgrammeurstesteurs 123 124. Une rvolution 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 Franois 1 (Androuet du cerceau) Napolon Colin Powell124 125. Dfinitions des besoins - DVP Besoin global (10%) : Liste des UC ou US + Planification Dtail du 1 tiers : Scnario des UC Discussion des US Ralisation du 1 tiersIt1 It2 Dtail du 2 tiers Ralisation du 2 tiers Intgration continue It3 VNRDtail du 3 tiers Ralisation et Fin BilanDfinition des besoins Ralisation : les itrations125 126. Principe : une version Le client (ou PO) est dans la salle Il propose une liste de fonctionnalits (Backlog) UC (sans donner les scnarios) ou User Story Chaque US ou UC a une priorit donne 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, dcouper la US, ou bien discuter avec le client Le client refait une passe sur les priorits On fait une dcoupe de la version en itrations Dmarrage de litration Ecriture des scnarios ou dtails des user story Dcoupe en tches des US (Backlog du sprint) Estimation des tches en heure Tests + Dvp + Tests Bilan + Demo Maj du Backlog pour itration suivante 126 127. User storyle client Lquipe de dvp Phase de Dfinition des besoins Taille : carte postale Discussion avec le client Affecte un ID automatique Affectation dun cot Ecrite par le client si estimation impossible Nest quun rsum Rediscuter avec le client Le reste est verbal la dcomposer en n US Affectation dune priorit (une valeur) la dcomposer en tches et estimer les Affectation sur une itration (voir partiel) tches (Voir la suite) Ecriture des tests finaux (TR) Phase de DVP (Iterations) Dcoupage en tches er estimation (H) Les 3C Prise de responsabilit dun dveloppeur Card : une ou deux phrasespour une tche Ralisation en binme Conversation : verbale Ecritures des TU Confirmation : test Ralisation Passage des TU Passage des tests finaux (TR)127 128. US : Recto128 129. US : Verso129 130. Planification dune version Calculer la vlocit de lquipe Prendre une moyenne des derniers sprints Pour la premire fois : commencer lestimation du sprint (ce qui nous donnera un nb de pt faisables en un sprint voir plus loin) Mthode des 3 experts Pif Rpartir les US ds les sprints en commenant par les plus prioritaires Ajustement des fins de sprint Rajouter du mou 10% pour erreur destimation 15% pour Bug, FeedBack des utilisateurs Tenir compte du calendrier (prvisible) Tenir compte des changements des effectifs de lquipe si prvu lavance Prendre en compte les points de synchro avec dautres quipes Planning orient utilisateur, sans garantie car il va tre remani130 131. BackLog de produit(1) Daprs la velocit : Une itration = 50 points 5 Itrations (sans engagement) 131 132. BackLog de produit(2) 132 133. BackLog de produit(3) Mthode classique RAF = Temps estim temps pass Agilit RAF = Restimation de la tche Simplement utiliser les tats (en cours-fini-) Beurdone - burndown 133 134. Ice Scrum 2ExcelUn planning de version Une version 3 Itrations Chaque itration contientdes USRmq : on ne voit pas les priorits (dommage)134 135. Une variante : Feature135 136. LAgilit Droulement dunprojetLes itrations136 137. Une itration Dcoupe en tches (Planning horizontal) Estimation des tches en heure Planification du sprint (2-4H) : Equipe + PO Rajouter du Mou (30%) Affectation des tches Fabrication des binmes 1-2 jours de modlisation (toute lquipe) DVP Prparation des tests Coder en binme et amliorer Tester Une runion par jour (suivre ce que font les autres, ) Acceptation par le client Un bilan Amliorer le process Rmq : la fin de la runion 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 dmonstration et uUne heure et un lieu bien 137 dfinis pour la mle quotidienne. 138. Les principes Modliser agile ensemble Se mettre en binme Ecrire les cas tests Tester (NOK) Coder Faire simple Suivre lavancement Tester (OK) Une personne est responsable dune tche Le code appartient tout le monde138 139. La modlisation agile Il faut modliser (1 jour sur 10) Les modles sont faux Un modle agile est une peinture, pas une photographie Modliser plusieurs, jamais seul Moins de diagrammes de classe et plus de diagrammes dinteraction (et en //) Ne pas passer trop de temps avec les outils, faire du reverse aprs coup Modliser pour soi mme, pas pour faire de la documentation 139 140. Dveloppement (1) Faire le plus simple possible Pas de conception Conception mergeante Pas de Doc uniquement pour satisfaire le process 1-2 jour de modlisation sur 10 Binmes Personne nest propritaire du code Equipe CR journalier + le tracker 140 141. Binmes 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 lautre le surveille Il y en a un qui code pendant que lautre se repose Il y en a un qui tient la souris, l autre a le clavier... Cela cote forcment deux fois plus cher J ai mes habitudes de codage... J aime travailler tout seul Binmer, cest multiplier les couts par 2 141 142. 142 143. Binmes Deux personnes travaillant ensemble pour concevoir, tester, coder... Une seule machine (standardise) un conducteur: manipule la machine, ralise le travail un observateur: propose, conseille, vrifie, et rflchi la stratgie globale Changements de conducteur frquents Changements de binme frquents Travail dense, exigeant, productif et efficace Lun regarde le clavier, lautre lcran, et on discute Celui qui ne sait pas faire, fait, lautre lui apprend TDD (lun crit un cas de test puis lautre le programme, programmation ping-pong) La programmation en binme est puisante et ne devrait pas tre pratique toute la journe Utiliser pour la monte en comptence des nouveaux entrants et pour les dveloppements pointus143 144. Qualits d binme Ouverture d'esprit et remise en question Courage (de se mettre nu) Communication active (pas de rtention d'information) Respect de l'autre et de son travail Capacit tourner (tches, fonctionnalits, personnes...) A se rendre non indispensable Dure dun binme = 1 jour, 1 tche (pas toujours) Travailler deux Savoir partager la gloire... Et les erreurs il est plus facile de former un dbutant ( l'agilit) que de dformer un gourou .144 145. Cycle de vie dun binme145 146. Dveloppement (2) Faire le plus simplement possible Faire simple mais pas simpliste Pas de savants Ne pas prendre dexpert Se mfier des architectes Problme des design patterns Homognit de lquipe avant tout Les cimetires sont remplis de gens indispensables Faire de la rorganisation de code Revue (binmes) Une seule fois (DP Template method) Refactoring (sparation des ides) Interdit si pas de tests automatiss Quand?146 147. Faire le plus simple possible (1) Ne pas faire de conception(la bourseMauvaise spculation) Ecrire les tests dabord Ne pas faire de sur spcification, mais penser demain Ne pas choisir tout de suite une architecture Cela permet den tester plusieurs Mais, ne pas la choisir trop tard!!! Ne pas mettre de commentaires, ni de lignes blanches de sparationmais couper en n parties Compliquer le code (ex DP) Former, convaincre sinon ne pas faire Nivlement par le bas, mais tout le monde comprend Commencer simplement Ecrire la solution la plus simple possible pour rsoudre ce cas et que ce cas La vrit, ce nest point ce qui dmontre, mais ce qui simplifie Saint Exupry. 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