Développement agile. Modèles de développement

Transcription

1 IFT3912 Développement et maintenance de logiciels Développement agile Bruno Dufour Université de Montréal Modèles de développement Développement en cascade: modèle séquenhel Développement itérahf: modèle cyclique, incrémental Développement par réuhlisahon: basé sur la réuhlisahon massive de composants existants Peut être combiné aux autres modèles de développement Ex: Composants COTS (commercial off- the- shelf), J2EE, intergiciels, services web, etc. 2 1

2 Processus de développement tradihonnel Analyse ConcepHon ImplémentaHon Tests InstallaHon Maintenance 3 Développement en cascade Modèle de développement séquenhel basé sur les documents (document- driven) Analyse: clarifier et établir un ensemble de besoins ConcepHon: concevoir un système basé sur ces besoins ImplémentaHon: programmer conformément à la spécificahon résultant de l analyse et de la concephon Tests: évaluer la qualité du logiciel produit InstallaHon: livraison / déploiment du logiciel chez le client 4 2

3 Problèmes du modèle en cascade Rigidité du processus Analyse: le processus fait l hypothèse que les besoins peuvent être complètement précisés et capturés au début du projet Les changements aux besoins sont très communs Le client peut changer d avis après avoir uhlisé le logiciel ConcepHon: le processus fait l hypothèse que la concephon peut être complétée avant de débuter l implémentahon Irréaliste dans les cas où la soluhon n est pas bien comprise Un changement des besoins peu invalider la concephon 5 Problèmes du modèle en cascade Difficulté à s adapter aux changements Les changements imprévus peuvent invalider beaucoup de travail des phases antérieures Le client ne voit que le système final La quasi- totalité du développement s effectue sans commentaires du client Le développement peut facilement dévier des besoins réels du client Le client modifie souvent sa percephon du problème et par conséquent ses besoins après avoir uhlisé le système Les problèmes difficiles ne sont pas afaqués en premier Peut mener à l abandon de certains projets 6 3

4 45% 19% 16% 13% 7% UHlisaHon des fonchonnalités demandées 13% 7% 16% 45% 19% Jamais Rarement Parfois Souvent Toujours 7 Le changement dans le développement 40" Changements des besoins (%)" 35" 30" 25" 20" 15" 10" 5" 0" 10" 100" 1000" 10000" Taille du projet (en FP)" Source: Craig Larman, Applying UML and Paferns, PrenHce Hall

5 Coût des changements Les changements sont coûteux puisque qu ils nécessitent de refaire une parhe du travail 2 stratégies principales pour réduire ce coût Éviter les changements: on inclut des achvités au projet qui permefent d anhciper les changements avant que beaucoup de travail ne soit à refaire Ex: uhlisahon d un prototype Tolérer les changements: on uhlise un processus de développement qui permet de s adapter facilement aux changements qui surviennent Ex: développement itérahf 9 Faire face aux changements Prototype: une version du système parhel ou complet développé rapidement Permet d obtenir les commentaires du client très rapidement, et de réduire le risque de changements des besoins (évite les changements) Permet d explorer des soluhons spécifiques et d évaluer leur faisabilité Facilite la concephon des interfaces graphiques Le prototype est généralement composé de code jetable qui ne sera pas intégré au système final 10 5

6 Faire face aux changements Livraison incrémentale: des versions successives et parhelles du système sont livrées au client pour permefre l expérimentahon et recueillir ses commentaires Le processus facilite l apport de changements au système Les fonchonnalités du noyau sont implémentées rapidement et donc testées de manière plus approfondie Les uhlisateurs peuvent se familiariser avec le système plus rapidement (contrairement au prototype, le système parhel sera intégré au système final) Le client peut bénéficier rapidement d un système parhel 11 Développement itérahf & méthodologies agiles 12 6

7 Développement itérahf Le cycle de vie du logiciel est conshtué de mini- projets appelés itéra3ons Chaque itérahon inclut des achvités d analyse, de concephon, d implémentahon et de test Le but d une itérahon est de produire une version stable, testée et par3elle d un logiciel Le résultat d une itérahon n est pas un prototype, mais une version incomplète du système final Le résultat de la dernière itérahon est le logiciel complété. Les versions intermédiaires peuvent être internes ou externes Chaque itérahon ajoute des fonchonnalités au logiciel Occasionnellement, une itérahon peut être consacrée à l améliorahon (ex: performance), sans ajout de fonchonnalité 13 Développement itérahf et évoluhon Le système s agrandit progressivement, itérahon par itérahon Le système peut ne devenir convenable pour un environnement de produchon qu après plusieurs itérahons Le cycle de vie du logiciel est basé sur le raffinement successif et l évoluhon du système à travers une série d itérahons avec rétroachon et adaptahon Les besoins doivent être stables à l intérieur d une itérahon pour éviter le chaos Aucune achvité ne devrait être ajoutée ou modifiée au cours d une itérahon Des achvités peuvent être remises à d autres itérahons si le travail ne peut être complété à temps 14 7

8 ÉvoluHon et convergence Early Les premières iterations itérahons are farther s éloignent from the "true du path" «vrai of système the system.». À travers Via feedback la rétroachon and adaptation, et l adaptahon, the system le système converges towards vers the les most besoins appropriate et la concephon requirements la plus and design. appropriée. In Un late changement iterations, majeur a significant est rare change dans les in requirements itérahons finales, is rare, mais but peut can tout occur. de Such late même changes se produire may give (peut an conshtuer organization un a competitive avantage d affaires). business advantage. one iteration of design, Une itérahon de concephon, implement, integrate, and test implémentahon, intégrahon et test Source: Craig Larman, Applying UML and Paferns, PrenHce Hall Durée des itérahons Chaque projet doit fixer une durée pour les itérahons La durée typique d une itérahon est 2-6 semaines Une durée de 2-3 semaine est très répandue Des itérahons courtes permefent la rétroachon et l adaptahon rapide aux changements Des itérahons longues augmentent les risques Les itérahons ont toutes la même durée (4meboxing) Si certaines tâches ne peuvent être effectuées à temps, elle sont remises à une itérahon ultérieure Une itérahon ne doit jamais se terminer en retard 16 8

9 Avantages du développement itérahf Permet les changements Le développement peut s adapter aux changements au cours des itérahons subséquentes. Permet l évoluhon des besoins Les uhlisateurs peuvent donner leurs commentaires suite à l uhlisahon du système opérahonnel Les nouveaux besoins peuvent être pris en compte de façon incrémentale RéducHon des risques Les risques sont idenhfiés rapidement Architecture robuste L architecture peut être évaluée et améliorée très tôt 17 Méthodologies agiles 18 9

10 19 CaractérisHques des méthodologies agiles Agilité : réponse rapide et flexible aux changements Plusieurs méthodologies existent, mais ont des caractérishques communes ItéraHons à durée fixe Développement évoluhf Raffinement progressif des besoins et de la concephon PlanificaHon adaphve Livraisons incrémentales 20 10

11 Analyse et concephon évoluhves 20 itérahons requirements workshops Imagine this will ultimately be a 20- iteration project. Les besoins évoluent In evolutionary au cours iterative development, the requirements evolve des premières over a set of the early iterations, through a itérahons. Par series of requirements workshops (for exemple, après 4 example). Perhaps after four iterations and itérahons, 90% workshops, 90% of the requirements are des besoins sont defined and refined. Nevertheless, only définis 10% ou of the software is built. redéfinis, alors que seulement 10% du logiciel a été implémenté. requirements software requirements software 90% 90% 50% 20% 30% 20% 2% 5% 8% 10% Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 a 3-week iteration week 1 week 2 week 3 M T W Th F M T W Th F M T W Th F kickoff meeting clarifying iteration goals with the team. 1 hour Source: Craig Larman, Applying UML and Paferns, PrenHce Hall team agile modeling & design, UML whiteboard sketching. 5 hours start coding & testing Most OOA/D and applying UML during this period de-scope iteration goals if too much work final check-in and codefreeze for the iteration baseline Use-case modeling during the workshop demo and 2-day requirements workshop next iteration planning meeting; 2 hours 21 Le manifeste Agile «Nous découvrons de meilleurs façons de développer des logiciels en faisant et en aidant d autres à le faire. Par ce travail, nous en sommes venus à préférer:» Les individus et interachons Les logiciels fonchonnels La collaborahon avec le client Répondre aux changements aux processus et ouhls à la documentahon complète à la négociahon de contrat à suivre un plan «Bien que nous reconnaissons la valeur des items de droite, vous valorisons les items de gauche.» 22 11

12 Les principes agiles 1. Notre priorité la plus importante est de sahsfaire le client grâce à la livraison rapide et conhnue de logiciels uhles 2. Accueillez l évoluhon des besoins, même tard dans le développement. Les processus agiles exploitent les changements pour l'avantage concurrenhel du client. 3. Livrez des logiciels fonchonnels fréquemment, de quelques semaines à quelques mois, avec une préférence pour les échelles de temps courtes. 4. Les gens d affaires et les développeurs doivent travailler ensemble à chaque jour au cours du projet. 5. Construisez des projets autour d'individus mohvés. Donnez- leur l'environnement et le souhen dont ils ont besoin, et faites- leur confiance pour effectuer le travail. 23 Les principes agiles 6. La méthode la plus efficace de transmefre des informahons vers et au sein d'une équipe de développement est la conversahon face- à- face. 7. Un logiciel fonchonnel est la principale mesure de progrès. 8. Les processus agiles font la promohon du développement durable. 9. Les promoteurs, les développeurs et les uhlisateurs devraient être en mesure de maintenir un rythme constant indéfiniment. 10. Une afenhon conhnue à l'excellence technique et à la bonne concephon améliore l'agilité

13 Les principes agiles 11. La simplicité l'art de maximiser la quanhté de travail non effectué, est essenhelle. 12. Les meilleures architectures, exigences, et concephons émergent des équipes qui s auto- organisent. 13. À intervalles réguliers, l'équipe réfléchit sur la façon de devenir plus efficace, puis ajuste son comportement en conséquence. 25 Priorités du mouvement agile CommunicaHon et rétroachon Dans l équipe et avec le client Individus et équipe Le développement est une achvité humaine Des développeurs heureux sont plus produchfs Simplicité Processus et ouhls Processus empirique Modifié dynamiquement en se basant sur des mesures État d esprit Le développement agile est plus qu un processus 26 13

14 GesHon de projet agile La planificahon et le contrôle sont effectués en équipe, et non par un chef de projet Inclut le WBS, échéancier, eshmés, etc. Le chef de projet ne dit (généralement) aux autres membres de l équipe quoi faire Le chef de projet n assigne pas les rôles et les responsabilités Le rôle du chef de projet inclut l entraîner le personnel, fournir les ressources nécessaires, éliminer les obstacles, maintenir la vision, promouvoir la méthodologie agile, etc. 27 Les méthodes agiles en prahque La recherche montre que les projets ayant le plus de succès possèdent certaines caractérishques favorisées par les méthodes agiles : Cycle de vie itérahf IntégraHon quohdienne Beaucoup de rétroachon et de parhcipahon des uhlisateurs/clients Courte durée / taille du projet Livraisons incrémentales 28 14

15 Méthodologies agiles Processus unifié ([R]UP) agile Scrum Extreme Programming (XP) Et bien d autres Crystal Evo etc. 29 Processus Unifié 30 15

16 Processus Unifié Processus de développement itérahf qui vise la produchon d un système de haute qualité qui rencontre les besoins du client selon un budget et un échéancier prévisibles Un cadre flexible plutôt qu un processus rigide Peut être adapté et personnalisé par une entreprise ou une équipe selon leurs besoins spécifiques Presque tous les artéfacts (documents, modèles, etc.) et achvités sont ophonnels Pas de plan détaillé Un plan de phase (haut niveau): date de fin de projet, jalons Plan d itérahon: développé pour la prochaine itérahon 31 Phases du processus unifié 1. CréaHon (Incep4on) Vision approximahve, définihon de l étendue du projet, eshmés vagues Le projet est- il réalisable? 2. ÉlaboraHon Vision raffinée, développement itérahf de l architecture de base, résoluhon des risques les plus élevés, idenhficahon de la plupart des besoins, eshmés plus réalistes 3. ConstrucHon ImplémentaHon itérahve des éléments plus simples / à plus faible risque, préparahon pour le déploiement 4. TransiHon Tests «béta», déploiement 32 16

17 Phases et itérahons development cycle iteration phase inc. elaboration construction transition milestone An iteration endpoint when some significant decision or evaluation occurs. release A stable executable subset of the final product. The end of each iteration is a minor release. increment The difference (delta) between the releases of 2 subsequent iterations. final production release At this point, the system is released for production use. Source: Craig Larman, Applying UML and Paferns, PrenHce Hall Phase de créahon La créahon vise à répondre à plusieurs queshons : Quelle est la vision du projet? Le projet est- il réalisable? Que doit- on construire et/ou acheter? Quel est le coût eshmé du projet? Devrait- on aller de l avant? Si le projet a suffisamment de valeur, une analyse plus approfondie sera menée durant l élaborahon Plusieurs artéfacts peuvent être produits: exposé général du projet, cas d uhlisahon, analyse de risques, prototypes, etc. Les artéfacts seront complétés lors des phases subséquentes 34 17

18 Phase d élaborahon Au cours de l élaborahon, la plupart des besoins deviennent bien compris et définis L implémentahon est concentrée sur deux principaux aspects : Les parhes du systèmes qui présentent plus de risques Les parhes centrales de l architecture du système (noyau) 35 Phases de construchon et de transihon La construchon vise a terminer implémentahon du système Peut inclure l analyse des besoins restants à définir Inclut souvent des tests de système (alpha- tes4ng) La construchon se termine lorsque le système est prêt pour le déploiement tout le matériel de support est prêt (manuel d uhlisahon, matériel d entraînement, etc.) La transihon vise à implanter le système dans un environnement de produchon Peut inclure des tests addihonnels (beta- tes4ng) 36 18

19 Disciplines du PU Disciplines d ingénierie ModélisaHon du processus d affaires: permet de visualiser et définir les concepts importants du domaine de l applicahon Analyse des besoins ConcepHon ImplémentaHon (inclut les tests unitaires) Test Déploiement Disciplines de support GesHon des configurahons et des changements GesHon de projet Environnement: mise en place des ouhls nécessaires et personnalisahon du processus (souvent en conhnu) 37 Disciplines du PU Focus of this book Sample UP Disciplines Business Modeling Requirements Design Implementation Test Deployment Configuration & Change Management Project Management Environment Une itérahon inclut du travail dans plusieurs disciplines. A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable. Iterations Note that although an iteration includes work in most disciplines, the relative effort and emphasis change over time. This example is suggestive, not literal. Source: Craig Larman, Applying UML and Paferns, PrenHce Hall

20 Disciplines et phases Sample UP Disciplines Business Modeling elaboration construction inception transition The relative effort in disciplines shifts across the phases. Requirements Design This example is suggestive, not literal. Implementation L effort associé à chaque discipline varie selon la phase du développement. Source: Craig Larman, Applying UML and Paferns, PrenHce Hall Autres prahques du PU BâHr un noyau uni durant les premières itérahons ConHnuellement vérifier la qualité Tester tôt, souvent et de façon réaliste Appliquer les cas d uhlisahon lorsqu ils sont appropriés UHliser la modélisahon visuelle (UML) 40 20

21 PU vs modèle tradihonnel Le modèle en cascade ne doit pas être superposé au PU : CréaHon analyse, élaborahon concephon, etc. La majorité de l analyse est effectuée durant l élaborahon L analyse, la concephon et l implémentahon font parhe de chaque phase, à différents degrés Les itérahons sont nefement plus courtes (mois vs semaines) Le PU n impose pas d achvités ou d artéfacts 41 ProgrammaHon extrême 42 21

22 IntroducHon La programmahon extrême (Extreme Programming, XP) est une méthodologie agile très répandue Idée principale: pousser à l extrême les bonne prahques et valeurs de développement Par exemple: les tests sont uhles donc les tests seront effectués chaque jour les tests seront développés avant de coder XP uhlise un modèle de développement itérahf avec itérahons très courtes (1-3 semaines). 43 PraHques Client membre de l équipe Jeu de la planificahon / histoires d uhlisateurs ProgrammaHon en paires Développement piloté par les tests Réusinage fréquent Propriété collechve du code IntégraHon conhnue (et quelques autres prahques qui ne seront pas abordées dans le cours) 44 22

23 Client membre de l équipe Le client est considéré comme un membre de l équipe à part enhère Le client est ulhmement la personne qui devra uhliser le système. Un représentant du client devrait être disponible en tout temps pour répondre aux queshons. Rôles du client Écrire les histoires d uhlisateurs Écrire les tests d acceptahon Choisir les histoires lors du jeu de la planificahon 45 Histoires d uhlisateurs XP exprime les besoins sous forme d histoires d u3lisateurs Les histoires ne conhennent que suffisamment d informahon pour pouvoir eshmer l effort requis pour développer une fonchonnalité L eshmé est produit rapidement pour permefre à l équipe de prendre des décisions Les histoires sont généralement inscrites sur des cartes qui peuvent être manipulées et placées sur un mur ou tableau 46 23

24 Exemple Carte d histoire d uhlisateur Enregistrement!avec!compression 8!hrs Présentement,!les!options!de!compressions se!trouvent!dans!une!boîte!de!dialogue! subséquente!à!celle!de!la!sauvegarde.!il!faut!les! déplacer!vers!le!dialogue!d'enregistrement!luimême. 47 Exemple DisposiHon des cartes Source: Kent Beck, Extreme Programming Explained: Embrace Change, Addison- Wesley

25 Jeu de la planificahon Pour une itérahon : But : choisir les histoires à implémenter, planifier et allouer les tâches à effectuer Le client choisit les cartes pour la prochaine itérahon, les développeurs créent les tâches. Une tâche qui est eshmée à > 2 jours est divisée à nouveau. Pour la livraison d une version du logiciel But : définir la portée de la prochaine version opérahonnelle Typiquement, le client écrit les histoires et les développeurs en font l eshmahon au cours d un atelier d une demi- journée Les cartes peuvent être choisie en fonchon d une fixe, ou la date peut être déterminée en fonchon des cartes sélechonnées

26 ProgrammaHon en paires Tout le code est écrit par une paire de programmeurs travaillant ensemble sur une même machine Un programmeur écrit le code et les tests pendant que l autre observe dans le but d idenhfier les erreurs et les améliorahons potenhelles Les rôles sont inversés fréquemment Les paires sont redistribuées fréquemment (ex: une fois par jour) Cefe prahque permet de distribuer les connaissances du code rapidement à travers l équipe En prahque, le code produit conhent moins d erreur sans affecter la produchvité de façon mesurable

27 Développement piloté par les tests Le code de produchon est écrit de façon à faire réussir des tests unitaires Avant d implémenter une fonchonnalité, un test est ajouté. Ce test échoue lorsque la fonchonnalité n est pas présente. Le code qui fait réussir le test est écrit. Le code est développé en itérahons successives d écriture de tests et de code. L uhlisahon d ouhls de test automahsés est essenhelle à la réussite de cefe approche. Résultat : un jeu de tests unitaires très complet est développé pour le système enher très peu de code inuhle est développé 53 Réusinage fréquent But : améliorer le code sans changer sa fonchonnalité Idéalement effectué à l aide d ouhls automahsés. Les tests existants permefent de vérifier que le comportement observable demeure inchangé. Exemples de réusinages : restructurer la hiérarchie des classes, éliminer la duplicahon MoHvaHon : la concephon est plus efficace lorsque effectuée près de son uhlisahon Résultat : le système demeure plus simple et plus facile à développer pour une plus longue période (plus de détails à venir dans la 2 e parhe du cours) 54 27

28 IntégraHon conhnue «Diviser, régner et intégrer» : tous les changements doivent être testés et intégrés fréquemment Fréquemment = plusieurs fois par jour Peut nécessiter la résoluhon de conflits si plusieurs programmeurs ont modifié le même code 2 stratégies : IntégraHon asynchrone : les tests sont exécutés après un changement ou à intervalles réguliers, les programmeurs sont avisés si leurs changements causent des régressions. IntégraHon synchrone : les programmeurs exécutent eux- mêmes les tests et afendent les résultats avant de passer à la prochaine étape (permet de conserver le contexte, favorise la communicahon). 55 Propriété collechve du code Une paire de programmeurs peut travailler sur n importe quelle parhe du code et l améliorer Les développeurs ne sont pas responsables d un ou plusieurs modules en parhculier MoHvaHon : si une parhe du code est défectueuse, elle devrait être corrigée le plus tôt possible. AfenHon aux risques par contre! Cefe prahque est à éviter si l équipe n a pas encore développé une responsabilité collechve Un membre de l équipe ne doit pas modifier du code sans se soucier de celui qui aura à le modifier et le maintenir

29 XP Phases de développement 1. ExploraHon But : produire suffisamment de cartes d histoires pour une première version, déterminer si le projet est réalisable. AcHvités : prototypes, programmahon exploratoire (preuve de technologie), écriture de cartes et eshmahon 2. PlanificaHon : But : déterminer la date et les cartes de la première livraison AcHvités : jeu de planificahon (version), écriture de cartes et eshmahon 3. ItéraHons et première livraison : But : Implémenter un système complet prêt à être livré. AcHvités : programmahon, tests, jeu de planificahon (itérahons) élaborahon des tâches et eshmahon 57 XP Phases de développement 4. «ProducHsaHon» But : déploiement AcHvités : documentahon, formahon, commercialisahon, etc. 5. Maintenance But : correchons, améliorahons, nouvelles versions AcHvités : répéhhon des phases précédentes 58 29

30 XP - Valeurs CommunicaHon Des problèmes de communicahon sont à la base de la majorité des difficultés de projet XP fait la promohon de la communicahon : entre programmeurs : programmahon en paires, réunion quohdienne, jeu de la planificahon avec le client : tests d accephon, jeu de la planificahon Simplicité «faire la chose la plus simple qui puisse fonchonner» S applique aux besoins, à la concephon, artéfacts de projet, etc. 59 XP - Valeurs RétroacHon Court terme: développement piloté par les tests unitaires, intégrahon conhnue, cartes d histoires Long terme: tests d acceptahon, itérahons courtes (permefent au client de clarifier les besoins) Courage Le courage de développer rapidement et d effectuer des changements rapides découle des autres valeurs et prahques de la programmahon extrême et des ouhls modernes Par exemple, effectuer des changements architecturaux sans un ensemble de tests et des ouhls automahsés est difficile et risqué

31 Scrum 61 IntroducHon Scrum est une méthodologie agile axée sur la geshon de projet Complémentaire à d autres prahques agiles L origine du nom est un terme de Rugby : mêlée Analogie: les membres de l équipe doivent afeindre l objechf en équipe, comme les joueurs qui se passent le ballon. Source: Wikipedia 62 31

32 CaractérisHques Processus itérahf ItéraHons plus longues que d autres méthodologies (30 jours) Équipe auto- gérée Pas de processus rigide Le développement est adapté empiriquement Réunion debout quohdienne (mêlée, ou scrum) DémonstraHons du système après chaque itérahon PlanificaHon impliquant le client après chaque itérahon 63 Phases 1. PlanificaHon Établir la vision du projet, les afentes et assurer le financement AcHvités : définihon du carnet de produit inihal, eshmés, concephon exploratoire, prototypes 2. Mise en scène (staging) IdenHficaHon de plus de besoins, priorisahon suffisante pour une première itérahon AcHvités : planificahon, concephon exploratoire, prototypes 3. Développement ImplémentaHon d un système par une série d itérahons de 30 jours (sprints) AcHvités : planificahon de sprint, définihon du carnet de sprint, mêlée quohdienne, revue de sprint 4. Livraison d une version du système (release) Déploiement AcHvités : formahon, documentahon, commercialisahon, etc. Avant- match 64 32

33 Rôles «Scrum Master» Élimine les obstacles Idéalement en < 1 jour (avant la prochaine mêlée) Prend des décisions lorsque nécessaire Idéalement en < 1 heure: une mauvaise décision est préférable à aucune décision Agit comme écran (firewall) pour s assurer que l équipe n est pas interrompue par des requêtes venant de l extérieur Renforce la vision du projet Un Scrum Master inefficace doit être remplacé Équipe Scrum recommande que les équipes soient limitées à 7-10 personnes Les grands projets conhennent plusieurs équipes 65 Rôles Propriétaire du produit (Product Owner) Un représentant du client Assigne les priorités dans le carnet du produit Choisit les besoins à inclure dans une itérahon «Chickens» Personnes qui ne parhcipent pas directement au projet mais dont les intérêts doivent être pris en compte Ex: uhlisateurs, clients (autre que le propriétaire du produit), geshonnaires, etc. En référence à une blague : A pig and chicken discussed the name of their new restaurant. The chicken suggested Ham n' Eggs. «No thanks,» said the pig, «I'd be commifed, but you'd only be involved!» 66 33

34 Carnets (Backlogs) Carnet de produit ApparHent au propriétaire du produit ConHent les besoins de haut niveau, leur priorité, leur value d affaire et un eshmé de l effort requis Durant la planificahon d avant- match, tous les intervenants (stakeholders) peuvent ajouter des fonchonnalités, des cas d'uhlisahon, des améliorahons et des défauts au carnet de produit Carnet de sprint ApparHent à l équipe ConHent des tâches et un eshmé de l effort requis / restant 67 Exemple Carnet du produit Besoin Num. Cat. État Pri. Est. Sprint Enregistrement des paiements dans le registre Plan de financement à long terme Calcul de la commission de vente ApprobaHon de crédit lente 17 FoncHonnalité En cours AmélioraHon Terminé Défaut Pas débuté Problème En cours

35 Exemple Carnet de sprint Besoin Resp. État Rencontre pour discuter des objechfs Déplacer les calculs hors du module Obtenir les données Créer et inihaliser la base de données Heures de travail restantes JM/SR Terminé AW Pas débuté TN Terminé GP En cours Sprints Deux réunions sont tenues avant le début d une itérahon (sprint) 1 ère réunion : les intervenants priorisent le carnet de produit, habituellement en fonchon de la valeur d affaires et des risques. 2 ème réunion : le propriétaire du produit et l équipe déterminent comment afeindre les objechfs demandés, et produisent le carnet de sprint Le carnet de sprint est mis à jour à mesure que l itérahon progresse

36 Mêlée quohdienne (scrum) Tenue à chaque jour, à la même heure et au même endroit Doit débuter à l heure, il est fréquent d imposer des amendes aux retardataires qui sont ensuite uhlisées comme dons de charité Doit répondre à 5 queshons : Qu avez- vous fait depuis le scrum précédant? Qu allez- vous faire entre maintenant et le scrum suivant? Qu est- ce qui entrave l afeinte des buts de l itérahon en cours? Y a t il des tâches à ajouter au backlog? Tâche manquantes, pas de nouveaux besoins Avez- vous appris ou décidé quelque chose de nouveau qui serait uhle aux autres membres de l équipe? Aucune autre discussion n est permise Le Scrum Master peut recentre la discussion au besoin 71 Mêlée quohdienne (scrum) Idéalement tenue debout en cercle pour encourager la brièveté. Doit se tenir près d un tableau où les tâches sont inscrites Dure en moyenne minutes pour une équipe de 7-10 personnes Des réunions plus longues sont communes au début d une itérahon Les membres qui sont absents doivent parhciper par haut- parleur Les non- membres de l équipe (chickens) sont à l extérieur du cercle Ils ne parlent pas et ne posent pas de queshons ExcepHon: commentaires des geshonnaires (ex: explicahon de la perhnence du travail de l'équipe) 72 36

37 Revue de sprint À la fin de chaque itérahon, le Scrum Master organise la revue de sprint Maximum 4 heures Tous les intervenants parhcipent à la revue L équipe fait la démonstrahon du système au client Le client est informé des fonchons du système, de la concephon, des forces et faiblesses du système, de l'effort de l'équipe et des problèmes potenhels à venir Le client peut donner ses commentaires Pas de transparents, le produit doit être montré Les engagements sont pris lors de la planificahon du prochain sprint, et non pas lors de la revue. 73 Combinaisons de méthodes 74 37