Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Méthodologie de conception Objet DSI3. Chapitre 3: les Méthodes Agiles La métho

Méthodologie de conception Objet DSI3. Chapitre 3: les Méthodes Agiles La méthode SCRUM Exemple I. L'approche Agile: Les méthodes agiles caractérisent un mode de gestion des projets informatiques privilégiant le dialogue entre toutes les parties prenantes, clients, utilisateurs, développeurs et autres professionnels du projet, la souplesse en cours de réalisation, la capacité à modifier les plans et la rapidité de livraison. Il s'agit de rompre avec les pratiques plus traditionnelles bien trop rigides et trop exigeantes en matière de spécifications (contractuelles). Pour cela il est important d'accorder la priorité au relationnel et à la communication étendue sur les processus de développement. Le terme "méthode" est trop réducteur pour parler de cette façon d'aborder la gestion de projet. Il s'agit de bien plus qu'une méthode. On parle plutôt de paradigme agile, d'état d'esprit agile, de philosophie agile, de culture Agile ou encore d'approche agile, de mouvement agile, de courant agile, etc On parle cependant de "méthodes agiles" pour définir les méthodes qui relèvent de ce courant. Une approche dite "traditionnelle" attend généralement du client une expression détaillée et validée du besoin en entrée de réalisation, laissant peu de place au changement. La réalisation dure le temps qu'il faut et le rendez-vous est repris avec le client pour la recette. Cet effet tunnel peut être très néfaste et conflictuel. L'approche Agile, tout comme les méthodes Unifiées, propose au contraire de réduire considérablement voire complètement cet effet tunnel en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus itératif et incrémental. NB: voir vers la fin du chapitre une comparaison entre PU et méthode Agile Elle considère que le besoin ne peut être figé et propose au contraire de s'adapter aux changements de ce dernier. Mais pas sans un minimum de règles. 1 II. Le fonctionnement des méthodes Agiles Les méthodes agiles partent du principe que spécifier et planifier dans les détails l'intégralité d'un produit avant de le développer (approche prédictive) est contre- productif. Cela revient à planifier dans les détails un long trajet "ville A –Ville B" en voiture par les petites routes. Spécifiant chaque ville et village traversés, l'heure de passage associée, chaque rue empruntée dans les agglomérations, litres d'essence consommés, kilomètres parcourus, etc. Les imprévus ne manqueront pas d'arriver : embouteillages, déviations, travaux, sens de circulation inversés, voire la panne, etc. Rendant votre planification et vos spécifications très vite obsolètes. Combien de temps aurez-vous passé à planifier cet itinéraire, comment réagirez-vous face à vos frustrations de ne pas pouvoir appliquer votre plan à la lettre ? L'idée consiste à se fixer un premier objectif à courts termes (une grande ville par exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment. Et ainsi de suite jusqu'à atteindre la destination finale. On parle donc d'une approche empirique. Dans le cadre d'un projet de développement logiciel, le client élabore sa vision du produit à réaliser et liste les fonctionnalités ou exigences de ce dernier. Il soumet cette liste à l'équipe de développement, communique directement avec elle (plutôt que par papier) qui estime le coût de chaque élément de la liste. On peut ainsi se faire une idée approximative du budget global. L'équipe sélectionne ensuite une portion des exigences à réaliser dans une portion de temps courte appelée itération. Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c'est nécessaire, de développement et de test. A la fin de chacune de ces itérations, le produit partiel mais utilisable est montré au client. Ce dernier peut alors se rendre compte par lui même très tôt du travail réalisé, de l'alignement sur le besoin. L'utilisateur final quant à lui peut se projeter dans l'usage du produit et émettre des feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clef. Cette transparence peut également apporter davantage de confiance et de collaboration dans la relation client/fournisseur. Les risques quant à eux sont levés très tôt. Si le client a priorisé avec soin son besoin, il peut saisir l'opportunité d'accélérer le "time to market" si il estime que le produit en l'état (partiel) peut aller en production. Économisant ainsi son budget et récoltant un premier retour sur investissement. Il a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n'ont pas encore été développées (prévues pour les itérations futures). Afin de retarder une fonctionnalité dont le besoin n'est pas mûr, ajouter une nouvelle fonctionnalité cruciale en échange du retrait d'une autre (respectant ainsi budget et délais), etc. 2 Cette souplesse ainsi offerte est donc un véritable atout pour le client. III. Historique La première approche de gestion de projet de développement itératif date de 1986. La première mise en œuvre de la méthode Scrum (la méthode Agile la plus utilisée, documentée et éprouvée aujourd'hui) date de 1993. La seconde concerne un événement majeur rassemblant, en 2001, dix sept figures éminentes du développement logiciel pour débattre du thème unificateur de leurs méthodes respectives. De cet événement est né le Manifeste Agile Aujourd'hui ces méthodes ont fait leurs preuves. Tout le monde (dans le monde de l'informatique) ou presque a au moins entendu parler d'une méthode Agile (Scrum, eXtreme Programming, RAD, Chrystal Clear,...). L'outillage associé est maintenant disponible sur le marché y compris dans le secteur Open Source. Les formations, certifications, conférences, livres, blogs se sont multipliés. En 2012, le Gartner (organisme GP) invite à abandonner le Cycle en V. IV. Le manifeste Agile: un changement culturel Le manifeste Agile contient l'essence et la philosophie de l'approche en question. Il illustre à lui seul le changement culturel profond. Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ce qui nous permet de valoriser:  Les individus et leurs interactions plus que les processus et leurs outils  Des logiciels opérationnels plus qu'une documentation exhaustive  La collaboration avec le client plus que la négociation contractuelle  L'adaptation au changement plus que le suivi d'un plan ATTENTION aux idées reçues : La dernière phrase a son importance car si on néglige sa lecture, on peut tomber dans les idées reçues très répandues du style : "Sur un projet agile, il n'y a pas de spécifications, de plan, de processus, d'outil et même pas de contrat". Au passage, passons en revue d'autres idées reçues "Un projet Agile ne fonctionne que sur des projets de développement web, qu'avec une dizaine de personnes maximum, qu'avec des super développeurs" ou encore "sur un projet agile, le client change d'avis tout le temps et on tourne en rond à faire et défaire des choses". 3 V. Agile vs RUP Témoignages d'enseignants à travers le monde :  En 1999, c’était un cycle en V avec plan qualité qui était appliqué.  A partir de 2000, on a introduit le RUP puis des variantes allégées. Les étudiants pratiquent un développement itératif et incrémental.  A partir de 2005, on est progressivement passés d’une approche style RUP à une approche plus agile type Scrum. Beaucoup de principes des méthodes agiles existent dans le RUP cependant ils sont moins , noyés dans la masse d’informations et donc ne sont pas bien appliqués. Quelles sont les différences constatées effectivement dans les projets des étudiants lorsqu’ils appliquent une méthode agile ?  les itérations sont de durée fixe (time boxed) et plus courtes qu’avec le RUP, cela donne un rythme régulier satisfaisant pour l’équipe et facilite le suivi par les enseignants  on a clairement un produit avec des exigences testées à la fin de chaque itération, alors que c’est plus flou pour le RUP  les rôles individuels sont moins marqués avec les méthodes agiles, l’accent est mis sur l’équipe et sur le travail collaboratif. Une équipe agile s’autogère et produit de l’intelligence collective.  il y a moins de documentation (inutile) produite  les estimations ne se font pas que sur des tâches mais aussi sur des exigences  le suivi porte sur le reste à faire uniquement, ce qui évite les compte-rendus où les il faudra présenter pour chaque tâche l’effort estimé au départ et l’effort réel. Cela n’a pas grand intérêt et je trouve même cela contre-productif, cela a tendance à pousser les membres de l'équipe de développement à se conformer à l’estimation initiale plutôt qu’à produire un résultat de qualité  la mesure de l’avancement est bien plus objective : elle se fait sur les exigences réalisées et pas sur les documents produits En revanche, cela demande une participation et un suivi des chefs de projets bien plus conséquents VI. SCRUM Inspirée du privé et de la gestion des projets informatiques, la méthode SCRUM est devenue de nos jours de plus en plus adoptée dans les équipes de développement. Cette méthode "agile" permet la réalisation de projets complexes en favorisant l’interaction avec les membres de l’équipe et les managers, la collaboration du client uploads/Management/ ch-3.pdf