L Agilité dans le secteur public québécois: Si on si mettait!

Transcription

1 L Agilité dans le secteur public québécois: Si on si mettait!

2 Qui s uis -je? André Rivard arivard@pyxis-tech.com Directeur du bureau de Québec de Pyxis Technologies

3 Agenda de la journée 9H30 à 10H30: Un peu d histoire pour mieux comprendre 10H30 à 10H45: Pause 10H45 à 12H00: La gestion du changement; un grand défi valorisant! 12H00 à 13H30: Lunch libre 13H30 à 14H30: Travailler en mode Agile, c est quoi dans la vraie vie? 14H30 à 14H45: Pause 14H45 à 16H00: La méthode Agile dans le secteur public; si on s y mettait!

4 Qui êtes -vous? Quel est votre rôle dans votre organisation? Que connaissez-vous du développement logiciel Agile? Quelles sont vos attentes quant à cette présentation?

5 Nos objectifs pour aujourd hui Comprendre les valeurs et principes du développement logiciel Agile et en dégager les avantages pour vous et votre organisation Répondre à vos interrogations concernant l application d une approche Agile dans votre organisation S initier à la méthodologie Scrum et aux pratiques de développement logiciel Agile Avoir du plaisir J

6 Objectifs s pécifiques À travers les 4 grands thèmes présentés aujourd hui, nous couvrirons: L introduction au développement Agile Le squelette de Scrum La valeur d affaires au premier plan L équipe Agile Le développement incrémental La conduite d un projet Agile

7 Petite mis e en garde Scrum et l approche Agile ne donnent pas la développement logiciel recette s ecrète du Scrum fournit simplement les mécanismes permettant de mettre en lumière les problèmes et les difficultés que nous rencontrons dans nos projets de développement logiciel afin d être en mesure de les régler Une équipe Scrum apprend à s 'améliorer continuellement

8 Un peu d histoire pour mieux comprendre

9 Pourquoi Agile s elon vous?

10 Quelques constats

11 Quels problèmes rencontrons -nous? S u c c è s : Le projet est réalisé selon le budget et les délais convenus. Il comporte les fonctions et caractéristiques demandées. Dé fi: Le projet est en retard, le budget a été dépassé ou il manque certaines fonctions et caractéristiques demandées. Éc h e c : Le projet a été arrêté avant sa fin ou le logiciel développé a été livré mais n a jamais été utilisé. 11

12 Taux de s uccès Taux de s uccès Coût 61% Moins de 750,000 $ 19% De 750,000 $ à 3 millions $ 2% Plus de 10 millions $

13 13 Livrons -nous du logiciel de qualité?

14 Nos s olutions s ont-elles utiles? Utilisation des fonctionnalités lors du déploiement Jim Johns on, Standis h Group, XP

15 Peut-on livrer plus rapidement? d'après les travaux d'hakan Herdogmus, GUAM 2005

16 Problèmes de communication? Comment communiquez-vous? Le développement logiciel est un jeu coopératif d inventions et de communications. Il est apparenté au développement de produits. Les sources de problèmes dans notre profession sont gens et les interactions dysfonctionnelles plutôt que les processus et les outils. les

17 Quelques pistes

18 Alors pourquoi le développement Agile? Pour satisfaire rapidement notre client avec des s olutions logicielles utile s Pour augmenter la qualité Pour faire face à la complexité Pour réduire les inefficacités Pour éviter les longues périodes de s tabilis ation en fin de projet Pour maximiser la collaboration Pour augmenter la motivation et l engagement des individus Pour avoir du plais ir au travail J

19 Qu es t-ce que l Agilité? L Agilité c est la capacité de créer et de réagir au changement de façon à réaliser des profits dans un contexte commercial chaotique. - Jim Highsmith Certains problèmes sont tout simplement complexes, et certaines personnes sont tout simplement difficiles; les méthodes Agiles ne sont pas infaillibles. - Craig Larman Ce ne sont pas les espèces les plus robustes qui survivent, ni les plus intelligentes. Ce sont plutôt celles qui sont capables de s adapter au changement. - Charles Darwin 19

20 His torique du terme «Agile» En février 2001, dix-sept leaders des approches de développement de logiciels «légers» se sont rencontrés en Utah. Ils ont adopté le terme «Agile» pour définir leur travail. Ils ont créé le manifes te Agile, qui définit les valeurs fondamentales sur lesquelles toutes les méthodologies Agiles devraient être fondées. De ces valeurs, douze principes fondamentaux ont été extraits. Les détails opérationnels sont propres à chaque méthodologie Agile (Scrum, XP,...). 20

21 His torique de l Agilité : Système de production Toyota (TPS) Années 90 : Apparition du terme «Lean» et de méthodologies dites «légères» Septembre 2000: Naissance de Pyxis Février 2001 : Manifeste Agile 2008 : Le développement Agile est maintenant «accepté» 1500 participants à Agile % des organisations ont adopté au moins une pratique Agile (

22 Manifes te Agile Nous sommes à découvrir de meilleures façons de développer des logiciels en aidant les autres et en développant nous aussi. Par ce travail, nous en sommes venu à valoriser ce qui suit : Pers onnes et interactions plutôt que processus et outils Logiciel fonctionnel plutôt que documentation complète Collaboration avec le client plutôt que négociation de contrat Réaction au changement plutôt que suivi d un plan rigide En fait, bien que les éléments de droite soient importants, ceux de gauche le sont encore plus. 22

23 Principes vs pratiques Principe Vérité qui ne change pas dans le temps ou l espace Pratique Application d un principe à une s ituation particulière La compréhens ion des principes est essentielle pour en réussir l implantatio n par un ensemble de pratiques 23

24 Principes Agiles Notre première priorité e s t de s atis faire le c lient en livrant tôt et rég ulièrement du logiciel utile Le chang ement est bienvenu, même tardivement dans le développement. Les processus Agiles exploitent le changement comme avantage compétitif pour le client Le logiciel fonctionnel est la principale façon de mesurer le progrès Les gens d affaires et les développeurs doivent long du projet co llaborer quotidiennement, et ce, tout au 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 c onvers atio n face -à- La méthode la plus efficace de transmettre l information est une face. 24

25 Principes Agiles Les processus agiles favorisent un rythme de développement durable. Développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment Une attention continue à l Agilité l e xce llence te chnique et à la qualité de la conception améliore La s implicité l art de maximiser la quantité de travail à ne pas faire est essentielle Les meilleures architectures, spécifications et conceptions s auto-organis ent émergent d équipes qui Agile favorise le développement à un rythme no rmal Régulière ment, l équipe fait une réflexion sur les façons de devenir plus efficace. s ajus te et modifie s on comporteme nt en conséquence Elle

26 Méthodologies Agiles Scrum Extreme Programming (XP) Adaptive Software Development Crystal Clear Feature Driven Development Dynamic Systems Development Method (DSDM) MSF for Agile Software Development RUP (Agile RUP AUP) 26

27 L Agilité chez Pyxis Qu est-ce qui nous fait vibrer? La communication Le travail d équipe interne La capacité de s adapter au changement La visibilité La relation de partenariat avec notre client 27

28 Et vous, Qu est-ce qui vous fait vibrer dans votre travail? Qu est-ce qui vous fait suer dans votre travail? 28

29 La gestion de changement: un grand défi valorisant!

30 Voici un Scrum

31 Que faire face à la complexité? La dimension humaine ajoute un autre niveau de complexité. Co m p le x ité d e s p ro je ts Strategic Management and Organisational Dynamics: The Challenge of Complexity Ralph D. Stacey

32 Approche définie et approche empirique Plan détaillé avec tous les besoins identifiés Tous les besoins initialement envisagés satisfaits Objectifs précis et besoins les plus importants clarifiés Objectifs atteints 32

33 Une ques tion de bon s ens

34 Proces s us empirique Lorsque la complexité croît, les systèmes de gestion et de contrôle centralisés montrent leurs limites. La solution est d'établir un ensemble de règles s imples Un processus empirique utilise l ins pection et une adaptation subséquente afin d optimiser l atteinte des buts L inspection et l adaptation nécessitent la trans parence La transparence nécessite du courage et des changements au niveau des systèmes de récompenses Pilier I : Proces s us empirique

35 La valeur d affaires au premier plan Processus en cascade Exigences Coût Processus Scrum Calendrier Contraint es Coût Estimatio ns S'appuie sur le plan Calendrier Du plan découle les estimations relatives au coût et au calendrier. Contraint es Estimati on S'appuie sur la valeur ou vision Fonctionnalités De la vision découle les estimations relatives aux fonctionnnalités. 35

36 Qu es t-ce que la valeur d affaires? Collaboration avec le client plutôt que né gociation de contrat Les gens d affaires et les développeurs doivent collaborer et ce, tout au long du projet. quotidienne m ent,

37 Impacts et défis Mettre la valeur d affaires du logiciel à l avant-plan ça semble logique qu il faut s auf Avoir un responsable de produit imputable Maintenir notre carnet du produit Relativiser l analyse trop rapidement des exigences non prioritaires Établir les conditions de s uccès liées à chaque exigence 37

38 Proces s us empirique : le s quelette de Scrum Aquipe Scrum Vis io n 38

39 Itération : le s print Planification de sprint (max. 1 jour) Mêlée quotidienne (max. 15 min.) Démo et rétrospective (max. 1 jour) n Développement : Conception, code, test, documentation Sprint de 30 jours d efforts soutenus et ciblés 39

40 Res pons able de produit ( product owner) Un bon responsable de produit doit : Connaître la valeur commerciale du produit Avoir le pouvoir de réunir des intérêts et désirs variés Être dis ponible Diriger une équipe de gestion de produit Ses res pons abilités sont : Co mmunique rla vision S approprier les s pécifications Évalue r les incréments du produit Collaborer avec l équipe de développement (le plus possible) Collaborer avec l équipe de gestion du produit (le plus possible) 40

41 Ges tion des exigences : le carnet du produit Chaque itération met en œuvre les exigences prioritaires. Chaque nouvelle exigence est insérée dans la liste priorité. selon sa Il est possible en tout temps de priorité des exigences. changer l ordre de Les exigences peuvent être supprimées en tout temps. 41

42 Granularité des exigences De s d é ta ils s o n t a jo u té s a u fil d u te m p s Vision Épisodes Scénarios Tâches 6 mois 2-3 mois 1 mois Implantation Horizon de prévisibilité 42

43 43 Comment faire du développement incrémental?

44 Proces s us en cas cade «Ça ne fonctionne jamais!» Brian Marrick C est un processus imprévisible, ce qui cause des surprises, donc de l insatisfaction. 44

45 45 Proces s us Scrum

46 Suivi de l avancement La courbe du travail restant à faire permet de déterminer la date probable de livraison 46

47 Équipe Scrum Une équipe Scrum comprend uniquement les personnes suivantes : un responsable de produit un ScrumMaster des «équipiers» 47

48 Caractéris tiques d une équipe Scrum S auto-organise Est pluridis c iplinaire et ne comporte pas de rôles prédéterminés Compte 7 membres (+/- 2) Est res pons able de s on engagement Possède l autorité néces s aire respecter ses engagements pour agir de manière à Travaille dans des locaux ouverts et avoisinants Rés out s es propres conflits 48 Observe comportement des règles de bas e de fonctionnement et de

49 Le Scrum Mas ter n'es t pas un chef de projet Imposer Faire confiance Contrôler Faciliter Diriger Accompagner 49

50 Mêlées quotidiennes Paramètres : Tous les jours Durée limitée à 15 minutes Tout le monde debout Pas de résolution de problèmes Trois questions : 1. Qu ai-je fait hier? 2. Quels ont été les obstacles rencontrés? 3. Qu est-ce que je compte faire aujourd hui? Les membres d équipes et personnes externes sont invités Permet d éviter des réunions inutiles Seuls les membres d équipe peuvent s exprimer 50

51 Ques tions s ur les mêlées quotidiennes Pourquoi tous les jours? Comment un projet peut-il avoir un an de retard? Un jour à la fois. Fred Brooks, The Mythical Man-Month. Est-ce que les mêlées quotidiennes peuvent être remplacées par des rapports d activité envoyés par courriel? Non, non et NON! L équipe entière possède une vision complète actualisée quotidiennement Une pression par les pairs incite à faire ce que nous avons dit que nous ferions 51

52 Revue du s print L équipe présente ce qui a été réalisé pendant le sprint La présentation comporte une démonstration des nouvelles fonctionnalités ou de l architecture Ce qui n est pas complété n est pas démontré! Revue informelle Ne pas dépasser 2 heures de préparation Participants Propriétaire du produit Clients Management Équipe 52

53 Rétros pectives du s print Dans le but d améliorer le processus À la fin de chaque sprint Le ScrumMaster est facilitateur Évaluation de ce qui a bien été et ce qui devrait être amélioré Le ScrumMaster établit la priorité des améliorations avec l aide de l équipe L équipe conçoit des solutions aux éléments de haute priorité 2-3 max! L équipe met les solutions en œuvre L équipe s approprie le processus 53

54 Fin d itération Carnet du produit Prototype Technologie et conjoncture actuelles Révis ion, cons idération et organis ation But du prochain sprint

55 Générer de la connais s ance On a besoin d appre ndre à plusieurs niveaux : Do maine d affaire s pour comprendre la vale ur du logiciel Proces s us pour rendre le logiciel plus efficace Technologie pour mieux le maîtris er Équipe pour mieux apprendre à travailler ensemble 55

56 Démo La démo dure plus ou moins 2 heures. L équipe présente au responsable de produit les scénarios terminés. On invite tout le monde! On ne fait pas de cachettes. Logiciel fonctionnel plutôt que docume ntation complè te Le logiciel fonctionnel es t la principale façon de mes urer l avanc e ment.

57 Rétros pective du s print Régulièrement, l équipe fait une réflexion s ur les façons de devenir plus efficace, s ajus te et modifie s on comporteme nt en cons équence. Au terme de chaque sprint, l'objectif est d'améliorer le proces s us. On y présente ce qui s est bien passé ainsi que les éléments pouvant être améliorés. La rétrospective nécessite un climat de confiance. L équipe trouve des solutions à ses problèmes les plus contrariants. Déroulement typique d une rétrospective : Mise en contexte Récupération des faits Analyse des données Plan d action

58 Donc Scrum c es t Processus empirique de gestion fondé sur des boucles de rétroaction mettant en place de l inspection et de l adaptation Méthode de mise en œuvre de projets complexes depuis 1990 Livraison des fonctionnalités en fonction des priorités déterminées par le client Livraison de fonctionnalités tous les 30 jours Méthode reposant sur l intelligence collective Méthode évolutive s adaptant aux longs projets de grande taille et distribués Méthode conforme au CMMI niveau 3 et à ISO 9001 Méthode très s imple mais très difficile à appliquer

59 Travailler en mode Agile: c est quoi dans la vraie vie?

60 Res pons able de produit ( product owner) Doit connaître la valeur commerciale du produit Doit avoir le pouvoir de réunir des intérêts et désirs variés Doit être dis ponible Dirigera une équipe de gestion de produit Doit se rappeler que le sien s ys tème es t celui des utilis ateurs et non pas le 60

61 Res pons abilités du res pons able de produit Co mmunique rla vision S approprier les s pécifications Les écrire, les organiser et les réorganiser Fournir des exemples du comportement souhaité Évalue r les incréments du produit Collaborer avec l équipe de développement (le plus possible) Collaborer avec l équipe de gestion du produit (le plus possible) 61

62 Dé marrag e d un pro je t Ag ile Vision du produit Portée et limites du projet Plan de livraison

63 Objectifs de la phas e de vis ion Fixer la portée et les limites du projet et dégager les compromis ( charte de projet) S'assurer que les experts du domaine et les spécialistes techniques ont une compréhension et un domaine) langage commun (modélisation initiale de Faire l e s timatio n initiale des exigences (carnet initial du produit) Établir le c alendrie r initial (plan de livraison) Être prêt à sprinter

64 Comment on s y prend?

65 Un effort commun Un effort initial est nécessaire au démarrage du projet, mais ce n es t pas un effort is olé Il faut limiter l'effort initial. C'est en commençant à produire le logiciel que l'équipe apprend Il s agit d un processus itératif Les activités peuvent être gérées avec Scrum, lors du premier sprint Les activités doivent être inclus ives Vous visez ce qui es t tout jus te s atis fais ant et ne faites les activités que si elles ont de la valeur Travaillez avec les bonnes personnes : le responsable de produit, les membres de l équipe, le ScrumMaster et les experts

66 Charte de projet C est un document d une page présentant la vision, la mission et les valeurs du projet Elle est préparée par le responsable de produit conjointement avec l équipe de développement Elle présente les résultats attendus : Risques possibles, scénarios d atténuation des risques Compromis Jalons clés Elle permet à l équipe de projet de prendre des décisions éclairées

67 Exemple d une charte de projet Ob je c tifs d u p ro je t Ma tric e P rio rité e t c o m p ro m is 1. Réduire le délai de traitement des RFA de 3 m o is Prio rité 1 Prio rité 2 Co m p ro m is Co m m e ntaire s 2. Simplif ier le processus opérationnels de réception du RFA Objectif X 3. Réduire de 80% des coûts de réception papier et saisie manuelle Échéanc ier X 4. A méliorer le s erv ice à la clientèle / Plan de communication claire et ef f icac e / A méliorer les outils de support RH et R$ X Implique temps supp. 5. Réduire de 80% les demandes d'inf ormation du ministère après réception F a c te u rs d e ré u s s ite s 6. A ssurer la sécurité et confidentialité des données du RFA 1. Le 1er juillet 2005, l'analyse préliminaire doit être complété C lie n t / C u s to m e rs 2. Le 15 septembre 2005, les SG reçoivent la 1ère communication CP E M odule de saisie 3. Le 1er janvier 2006, le guide d'utilisateur est livré aux SG. Garderie conventionnée M odule de saisie 4. Le 1er janvier2006, l'environnement de f ormation est prêt. V érificateurs ex ternes M odule de transm ission 5. Le 1er mars 2006, les SG peuv ent s'enregistrer. DFR M odule de réception 6. Le 15 mars 2006, les vérificateurs externes peuvent s'enregistrer. P ro je c t C o n te x t D ia g ra m 7. Le 1er avril 2006, le système est prêt pour la saisie et l'importation. G e s tion Clie nts S G Attribution code utilisateur et m ot de pass e S aisie des donneés : balance de vérification, donneés de rém unération et données d'occ upation G e s tion Clie nts VE Attribution code utilisateur et m ot de pass e Vérification des donneés Production de rapports GDF : P ES -RFA Tran s m is s ion D éfinition param ètres de transm ission G e s tion Clie n ts inte rne s A ttribution code utilisateur et m ot de passe R é ce ption D éfinition param ètres de réc eption Arrim age aux systèm es du m inistère(sr F -C A FE ) R is q u e s 1. Disponibilité réduite des ressources de la DFR 2. Contrôle de la portée du projet 3. Adhésion des services de garde/gestion du changement 4. Maîtrise des NTIC/Nouveau proces sus 5. Formation des utilisateurs et service support 6. Ress ources partagées avec d'autres projets R e s s o u rc e s d é d ié e s No m Rô le Duré e Patrice Gervais ScrumMaster Durée du projet Norm and A lexin Respons able de produit Durée du projet Johane B lanchet Développement Durée du projet Philippe Jean Développement Durée du projet Louise Hebert Développement Durée du projet Luc ie S ageau Développement Itération 2 à 7 M artin B lanchard Développement Itération 3 à 7 Liv rab le s Te s ts d'a cc. Mis e e n p ro d. Livrable 1 01-F e b Fe b -06 M odule d'enregis trem ent des services de garde Livrable 2 15-F e b Ma r-06 M odule d'enregis trem ent des vérificateurs externes Livrable 3 01-Ma r Ma r-06 M odule s ais ie et l'im portation des données Livrable 4 15-Ma r Ap r-0 6 M odule de transm is sion com plète Livrable Apr Ap r-0 6 M odule de réception com plète

68 Carnet du produit C est un moyen de mettre en œ uvre la vis ion: il capture tout le travail envisagé C est le dé nominate ur c ommun entre le responsable de produit et les membres de l équipe Il comporte la liste de tous les éléments fonctionnels et non fonctionnels ainsi que les problématiques à éclaircir Les éléments ont une valeur d'affaires pour le responsable de produit Les problématiques sont des paramètres qui seront définis plus tard afin d être traités On prépare le carnet du produit, on l évalue, on le met à jour et on fixe l ordre de priorité de ses éléments Il fournit davantage de détails sur les éléments de haute priorité Le res pons able de produit es t celui qui fixe l ordre de priorité du carnet Tous les intervenants peuvent contribuer Le carnet du produit est mis à jour et mis bien en vue des éléments

69 Unité de bas e : les s cénarios utilis ateurs Un scénario utilisateur ( user story) est une courte description d un besoin du point de vue de l utilis ateur: En tant que «acte ur» je veux «fonctionnalité» pour que «besoin d affaires» Format parfait pour le carnet de produit Est un rappel pour avoir une produit convers ation avec le responsable de Peut être de différentes granularités ( Themes, Epics, S tories ) 69

70 70 Exemples de s cénario

71 Inves tir dans des bons s cénarios Mike Cohn nous suggère d INVESTir dans les scénarios de la façon suivante: «I n d e p e n d e n t» : les scénarios dépendants sont plus difficiles à prioriser et estimer «N e g o tia b le» : Les scénarios ne sont pas des contrats! «Va lu a b le» : pour le Product Owner pas pour les développeurs «Es tim a b le» : Les scénarios sont le pilier de la planification agile «S m a ll» : Ne jamais inclure dans une itération un scénario qui consomme plus de 25% de la capacité 71 «Te s ta b le» : Quels sont les conditions de succès?

72 Prioris ation du carnet de produit «La première étape qui est indispensable pour obtenir ce que vous voulez : savoir ce que vous voulez.» Ben Stein Critères de priorisation : Valeur d'affaires Effort de développement Risques Potentiel d apprentissage Pilier I : Proces s us empirique Pilier II : Carnet Prioris é

73 Définir «terminé» La définition de «terminé» capture la actuelle de l'équipe capacité technique Avec le temps, la définition de «terminé» devrait s 'étendre à toutes les activités nécessaires à la livraison en production Le travail qui n'est pas couvert pas la définition de «terminé» (travail «non terminé») doit être identifié et porté au carnet de produit Tout élément qui ne respecte pas la définition de «terminé» n'es t pas prés enté au directeur de produit en fin de sprint 73

74 Étendre la définition de «terminé» Conception révisée Code remanié Code révisé Tests unitaires Tests intégrés Tests de recette Tests de performance Tests d'ergonomie Documentation utilisateur Déploiement en pré-production Acceptation par les utilisateurs 74

75 Cons équence du travail «non terminé» Décision de livrer Livraison Révision Plan Révision Plan Révision Plan Révision Plan Révision Plan dette dette dette dette Sprint de «stabilisation» Crois s ance rapide et non linéaire!

76 Comment faire du développement incrémental?

77 Apprendre à développer de façon incrémentale Faites la conception et les tes ts tout au long du projet... Développez les compétences requises. Augmentez vos connais s ances techniques. Tout ce qui était difficile dans les pratiques d ingénierie en cascade doit maintenant être fait à chaque itération. La conception devrait permettre le changement «La raison justifiant la réécriture d un système devrait être la suivante : les responsables de produit ont une meilleure idée plutôt que les programmeurs ont eu une mauvaise idée!» Ron Jeffries Une bonne équipe Scrum maîtrise toutes les Agile. pratiques d'ingénierie

78 Ingénierie Agile Une attention continue à l excellenc e technique de la conception améliore l Agilité. et à la qualité La majorité des pratiques d ingénierie Agiles provient de XP. Les pratiques d ingénierie Agiles ravivent l intérêt pour les bonnes pratiques d ingénierie de logiciels. Les débats et discussions animés par la communauté XP ont été grandement bénéfiques à notre profession. On pens e à tort que les programmeurs Agiles s ont des cowboys.

79 extreme Programming (XP)

80 Intégration continue Automatisation complète du processus de «build» et de test Avantages Réduit les problèmes de régression Réduit les problèmes d intégration Réduit le temps entre l introduction d un problème et sa manifestation, ce qui facilite la correction Le plus fréquemment possible Outils de plus en plus sophistiqués

81 Développement piloté par les tes ts (TDD) C est une technique de conception et non de validation Pourquoi se donner tout ce mal? Il faut bien tester un jour non? Écrire du meilleur code plus vite Donne la confiance pour effectuer les «refactoring» Devient une documentation exécutable Fait partie de l intégration continue

82 TDD: Le rythme 1. Ajouter un test 2. Exécuter les tests et constater que le nouveau test échoue 3. Ajouter le code nécessaire pour que le test passe 4. Exécuter les tests et constater qu ils passent tous 5. Remanier le code pour éliminer les duplications

83 Es t-ce que la conception es t morte? La s implicité (c.-à-d. l art de maximiser la quantité de travail à ne pas faire) est essentielle. Quelle est la solution la plus simple pour résoudre mon problème? YAGNI (You ain t gonna need it.) On doit garder le code le plus simple et le plus clair possible. Il faut remanier le code dès que vous en sentez le besoin. Il faut utiliser les «patterns» avec discernement. Il faut garder un œil sur le futur. Toutefois, n oubliez pas que les décisions prisent aujourd hui sont appelées à changer. Apprenez à bien communiquer votre design : code, modèles et surtout conversation.

84 Documentation Agile Le point fondamental est la communication, pas la documentation. Assurez-vous de bien évaluer le coût et les avantages liés à l écriture d un document et à sa mise à jour. Documentez au bon moment avec le bon niveau de détail. Faites les mises à jour seulement si nécessaire.

85 Étendre la définition de «terminé» Conception révisée Code remanié Code revisé Tests unitaires Tests intégrés Tests de recette Tests de performance Tests d'ergonomie Documentation utilisateur Déploiement en pré-production Acceptation par les utilisateurs

86 Étendre la définition de terminé Pilier I : Proces s us empirique Pilier III : Livrais on incrémentale Pilier II : Carnet prioris é

87 Recette de l improductivité 1 responsable de produit 4-5 développeurs 1 date (itération ou livraison) 1 graphique d avancement indiquant qu il y a retard 2 tasses de pression additionnelle pour assurer la livraison Mettez un peu de pression sur les développeurs. Laissez mijoter pendant 3 ou 4 itérations. Les développeurs commencent à prendre des raccourcis. Les problèmes commencent à s accumuler. Éventuellement, l improductivité sera à son maximum!

88 Petite simulation

89 Premier tri : s elon la valeur d'affaires Carnet du produit Premier 20 % 20 % s uivant 60 % res tant

90 Carnet du produit Es timation du carnet en points Total : 92 points

91 Plan de livrais on Processus de spéculation Taille du carnet : 97 points Vélocité prévue : 20 points Plan de bas e Livrais on 1 Sprint 1 12 points Sprint 2 16 points Sprint 3 20 points Sprint 4 20 points Sprints 5 et 6 29 points

92 Niveau 2: Planification du s print Analyser, évaluer et sélectionner les éléments du carnet de produit pour le sprint en cours Capac ité de l équipe Évaluer le travail à faire Travail envis agé es timé Carne t du produit Décomposer en spécifications et tâches et évaluer les tâches

93 Es timation du carnet du Sprint En cours de sprint le nombre d heures prévues pour terminer chacune des tâches en cours est mis à jour. Il ne faut pas confondre les estimations du carnet de sprint avec les mécanismes de feuille de temps, qui ne font pas partie de Scrum. Scrum ne comporte aucun mécanisme de suivi des heures travaillées par les membres de l équipe. Le rendement de l équipe se mesure à l atteinte des buts et non à l'effort fourni. Scrum est axé sur les résultats.

94 Suivi de l avancement Ta b le a u d e tâ c h e s

95 Suivi de l avancement: Sprint Burndown

96 Agile s ynthétis é La méthode Agile dans le secteur public: si on s y mettait!

97 Équipe Pers onnes et interactions plutôt que proces s us et outils Les meilleures architectures, s pécifications et conceptions émergent d équipes qui s autoorganis e nt. On recherche du leaders hip : Affaires Technique Processus La qualité est la préoccupation de TOUS! Le leadership doit être au s ervice des gens. Il faut déplacer la prise de décision au plus bas niveau possible. On dit NON aux personnes interchangeables! 97

98 Modèle de collaboration clas s ique Utilisateurs Direction Les responsabilités et les pouvoirs sont divisés clairement. Analyste d affaires Chef de produit Représentant ou agent de commercialisation Les canaux de communication sont définis clairement et sont restrictifs. Gestionnaire de projet La documentation constitue le principal moyen de Développeurs Responsable des tests Architecte Administrateur de bases de données communication. Plusieurs tâches reposent sur des spécialistes. 98

99 ONE TEAM!!!! Équipe de ges tion de produit Utilisateurs Analyste d affaires Développeurs Équipe de développement Direction Chef de produit Gestionnaire de produit Responsable des tests Scrum Master Représentant ou agent de commercialisation Architecte Administrateur de bases de données L équipe provient des organisations coopératives. La composition des équipes n est pas limitée aux titres (généralistes-spécialistes). Les communications sont fluides. Le responsable de produit est à l avant-plan. 99