_______ ________ __ __ ________
| | | | | | | | | |
| __ | | _____| | | | | | _____|
| |__| | | | ___ | | | | | |___
| __ | | |_|_ | | | | |_____ | ___|_
| | | | | | | | | | | |
|__| |__| |________| |__| |________| |________|
Methode Agile et Genie Logiciel
agile.txt 14/03/2024
ultimecool.com
Sommaire
Introduction
CHAPITRE 1 - Les valeurs d'Agile
1.1. Les 4 valeurs fondamentales
1.2. Les principes
1.3. Les méthodes
CHAPITRE 2 - Extreme Programming (XP)
2.1. Pratiques extrêmes
2.2. Ouverture au changement
2.3. Cycle de développement
2.4. Programmation pilotée par les tests
2.5. Les valeurs d'XP
CHAPITRE 3 - Méthodologie Agile - SCRUM
3.1. Principe et différentes phases
3.2. Organisation
3.3. Avantages
3.4. Risques et solutions
3.5. A qui s'adresse ce type d'organisation ?
CHAPITRE 4 - Les méthodes Agile
4.1. Crystal Clear
4.2. Dynamic systems development method
4.4. Développement rapide d'applications
- Agile manifesto and practices
- Overview of Extreme Programming
- Software development planning
- Test-driven development
- Refactoring
- Principles of agile design
- Single-Responsibility Principle (SRP)
- Open/Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Dependency-Inversion Principle (DIP)
- Interface Segregation Principle (ISP)
- UML overview
- Object diagrams
- Use cases
- Sequence diagrams
- Class diagrams
- Design patterns
- Template method and Strategy
- Facade and Mediator
- Singleton and Monostate
- Null Object
- Factory
- Observer
- Proxy and Gateway
- Visitor
- State
Introduction
Le développement agile est la capacité à développer des logiciels rapidement, face à des exigences qui changent rapidement. En suivant les principes et les pratiques agiles, une équipe de développement de logiciels est encouragée à évoluer vers un groupe auto-organisé et interfonctionnel, améliorant ainsi la qualité du code, la qualité des livraisons et, en fin de compte, la satisfaction du client. En général, les concepts agiles favorisent une planification adaptative, un développement et une livraison évolutifs, une approche itérative limitée dans le temps, et encouragent une réponse rapide et flexible au changement. Les principes de conception aideront à garder le logiciel flexible et maintenable, tandis que les modèles de conception représenteront des outils pratiques pour appliquer ces principes pour des problèmes spécifiques.
Les principes inspirateurs du cadre agile ont été introduits par le Manifeste agile signé par 17 personnalités (parmi lesquelles Ward Cunningham, l'inventeur du Wiki), créateurs de méthodes ou dirigeants de sociétés. Dès les premières étapes du processus de développement, la collaboration ouverte et continue avec les clients et la capacité à répondre rapidement aux demandes de modifications des exigences, même à un stade avancé du développement.
Il existe plusieurs méthodes qui tentent de mettre en pratique ces principes, l'eXtreme Programming (XP) étant l'un des plus célèbres et des plus largement adoptés. XP se concentre sur des cycles de développement courts, des tests d'acceptation et un développement piloté par les tests. La simplicité de la conception est généralement privilégiée par rapport à la complexité inutile et à la surconception.
Six principes fondamentaux du génie logiciel sont décrits en détail pour aider les développeurs à éliminer les symptômes d'une mauvaise conception. Le principe de responsabilité unique (SRP), le principe d'ouverture/fermeture (OCP), le principe de substitution de Liskov (LSP), le principe de dépendance/inversion (DIP) et le principe de ségrégation des interfaces (ISP) sont le fruit de décennies d'expérience dans le domaine du génie logiciel. Ils ne sont pas le fruit d'un seul esprit, mais représentent l'intégration des réflexions et des écrits d'un grand nombre de développeurs de logiciels et de chercheurs. Bien qu'ils soient présentés ici comme des principes de conception orientée objet, ils sont en réalité des cas particuliers de principes de génie logiciel établis de longue date.
CHAPITRE 1 - Les valeurs d'Agile
1.1. Les 4 valeurs fondamentales
L'équipe ("Personnes et interaction plutôt que processus et outils"): Dans l'optique agile, l'équipe est bien plus importante que les moyens matériels ou les procédures. Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu'une équipe composée d'individualistes, même brillants. La communication est une notion fondamentale.
L'application ("Logiciel fonctionnel plutôt que documentation complète"): Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication).
La collaboration ("Collab. avec le client plutôt que négociat. de contrat"): Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes.
L'acceptation du changement ("Réagir au change. plutôt que suivre un plan"): La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d'évolution.
1.2. Les principes
Ces 4 valeurs se déclinent en 12 principes généraux :
"Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles".
"Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client".
"Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte".
"Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet".
"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".
"La méthode la plus efficace de transmettre l'information est une conversation en face à face".
"Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet".
"Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment".
"Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité".
"La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle".
"Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent".
"À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens".
1.3. Les méthodes
Adaptive software development (ASD) Crystal clear Dynamic systems development method (DSDM) Extreme programming (XP) Feature driven development Processus Urbanisant les Méthodes Agiles (PUMA) Rapid Application Development (RAD) Scrum
CHAPITRE 2 - Extreme Programming (XP)
L'Extreme Programming (XP) est une méthode agile de gestion de projet informatique adaptée aux équipes réduites avec des besoins changeants. Elle pousse à l'extrême des principes simples. L'Extreme Programming a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries pendant leur travail sur un projet "C3" de calcul des rémunérations chez Chrysler. Kent Beck, chef de projet en mars 1996 commenca à affiner la méthodologie de développemment utilisée sur le projet. La méthode est née officiellement en octobre 1999 avec le livre " Extreme Programming Explained " de Kent Beck.
2.1. Pratiques extrêmes
Dans le livre "Extreme Programming Explained" la méthode est définie comme:
- une tentative de réconcilier l'humain avec la productivité
- un mécanisme pour faciliter le changement social
- une voie d'amélioration
- un style de développement
- une discipline de développement d'applications informatiques
Son but principal est de réduire les coûts du changement. Dans les méthodes traditionnelles, les besoins sont définis, et souvent fixés, au départ du projet infomatique, ce qui accroît les coûts ultérieurs de modifications. XP s'attache à rendre le projet plus flexible et ouvert au changement en introduisant des valeurs de base, des principes et des pratiques. XP propose une réponse originale à ces questions, avec un ensemble de pratiques organisées autour des principes suivants :
Le client (maîtrise d'ouvrage) pilote lui-même le projet, et ce de très près grâce à des cycles itératifs extrêmement courts (1 ou 2 semaines).
L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de nouvelles versions s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback maximal sur l'avancement des développements.
L'équipe s'organise elle-même pour atteindre ses objectifs, en favorisant une collaboration maximale entre ses membres.
L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle développe, ce qui garantit au produit un niveau de robustesse très élevé.
Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles et rapides.
Les principes de cette méthode existent dans l'industrie du logiciel depuis longtemps. L'originalité de la méthode est de les pousser à l'extrême :
puisque la revue de code est une bonne pratique,
- elle sera faite en permanence (par un binôme) ;
puisque les tests sont utiles,
- ils seront fait systématiquement avant chaque implémentation ;
puisque la conception est importante,
- elle sera faite tout au long du projet (refactoring) ;
puisque la simplicité permet d'avancer plus vite,
- nous choisirons toujours la solution la plus simple ;
puisque la compréhension est importante,
- nous définirons et ferons évoluer ensemble des métaphores ;
puisque l'intégration des modifications est cruciale,
- nous l'effectuerons plusieurs fois par jour ;
puisque les besoins évoluent vite, nous ferons des cycles de développement
- très rapides pour nous adapter au changement.
2.2. Ouverture au changement
Puisque le changement est une composante incontournable de tout projet de développement logiciel, pourquoi ne pas l'accepter ? N'existe-t-il pas un moyen pour que les équipes de développement n'opposent plus de rigidité excessive aux demandes de leur maîtrise d'ouvrage ? Les créateurs d'XP ont trouvé une réponse à ces questions en découvrant que certaines pratiques d'organisation d'équipe et de programmation, appliquées ensemble, permettent de rendre le logiciel extrêmement malléable - à tel point qu'il devient plus avantageux de le faire évoluer progressivement que de chercher à le spécifier et le concevoir complètement dès le départ. Partant de ce constat, ils ont conçu une démarche qui diffuse le processus de décision tout au long du projet grâce à l'enchaînement de cycles itératifs très courts :
Le grand gagnant de cette démarche est d'abord le client du projet. Plutôt que de voir son intervention cantonnée à la phase initiale de recueil du besoin, il intègre véritablement le projet pour en devenir le pilote. A chaque itération, il choisit lui-même les fonctionnalités à implémenter, collabore avec l'équipe pour définir ses besoins dans le détail, et reçoit une nouvelle version du logiciel qui intègre les évolutions en question.
Cette démarche présente de nombreux avantages en termes de conduite de projet :
Le client jouit d'une très grande visibilité sur l'avancement des développements.
Le client utilise le logiciel lui-même comme support de réflexion pour le choix des fonctionnalités à implémenter - il peut en particulier intégrer très tôt les retours des utilisateurs pour orienter les développements en conséquence.
La première mise en production du logiciel intervient très tôt dans le projet, ce qui avance d'autant le moment à partir duquel le client peut en tirer des bénéfices.
L'ordre d'implémentation des fonctionnalités n'est pas guidée par des contraintes techniques, mais par les demandes du client. Celui-ci peut donc focaliser les efforts de l'équipe sur les fonctionnalités les plus importantes dès le début du projet, et ainsi optimiser l'utilisation de son budget.
La démarche itérative d'XP est donc son principal atout du point de vue de la maîtrise d'ouvrage. Elle est présentée plus en détail dans les sections qui suivent.
2.3. Cycle de développement
L'Extreme Programming repose sur des cycles rapides de développement (des itérations de quelques semaines) dont les étapes sont les suivantes :
une phase d'exploration détermine les scénarios clients qui seront fournis pendant cette itération ;
l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels ;
chaque développeur s'attribue des tâches et les réalise avec un binôme ;
lorsque tous les tests fonctionnels passent, le produit est livré.
Le cycle se répète tant que le client peut fournir des scénarios à livrer. La première livraison est généralement plus importante et n'est réalisée qu'après quelques itérations. Après la première mise en production, les itérations peuvent devenir plus courtes (une semaine par exemple).
Le rôle de « client XP »
Le pilotage du projet est assuré par un membre spécifique de l'équipe projet : le « client ». Le client détermine les fonctionnalités du logiciel, gère les priorités, définit les spécifications précises du produit - en somme, ce rôle correspond à ce que nous nommons en France la maîtrise d'ouvrage du projet. Dans un projet XP, ce représentant de la maîtrise d'ouvrage rejoint le projet à plein temps.
Le choix de cette personne dépend très fortement du type de projet. Dans les contextes les plus simples, il pourra s'agir d'une personne qui est à la fois donneur d'ordre et utilisateur final. Dans d'autres contextes, le client pourra être le représentant d'un groupe plus large réunissant un comité de direction, des architectes, etc.
La phase initiale d'exploration
Le projet démarre par une phase d'exploration volontairement très courte (typiquement un mois maximum), qui a pour triple objectif de définir le contenu fonctionnel de l'application, établir un premier plan de développement pour le projet, et produire la toute première version du logiciel.
Au cours de cette phase, le client explore et définit le contenu fonctionnel qu'il souhaite voir implémenté dans le produit. Il établit ainsi une liste de fonctionnalités, qui prennent en XP la forme de « scénarios client ».
Un scénario client décrit en quelques mots un besoin particulier du client. Par exemple, pour un logiciel de gestion de carnet d'adresses le client pourrait écrire les scénarios suivants :
"Je rentre un nom ou prénom, et le logiciel affiche la liste de toutes les personnes qui possèdent ce nom ou ce prénom"
"Je peux exporter mon carnet d'adresses au format HTML."
Les scénarios sont rédigés dans le langage du client, et décrivent des fonctionnalités dont l'implémentation paraît assez rapide - un scénario doit en effet pouvoir être complètement implémenté en une itération. Si un scénario paraît trop vague ou trop complexe, il est décomposé en scénarios plus simples. A l'inverse, des scénarios trop courts peuvent être regroupés en un seul pour obtenir la granularité souhaitée.
Au cours de la phase d'exploration, le client et l'équipe se forgent ainsi une idée assez précise du périmètre fonctionnel souhaité de l'outil. Ils établissent alors le premier plan de développement du projet.
La création d'un bon scénario repose sur 4 règles:
- Indépendante d'un autre scénario
- Negociable peut être réutilisation d'une autre fonction existante
- Valuable pour éviter les scénarios proposés par les développeurs qui n'ont pas
d'interet en terme de valeur ajoutée (pour le client)
- Estimable: si le scénario est trop dur à évalué
- moins de 26 mots
ex : As Who… I want to … so that …
Planification du projet
La planification est réalisée au cours d'une réunion dédiée, qui réunit l'équipe et le client et se déroule comme suit :
Le client présente les différents scénarios à l'équipe, qui tente de se faire une idée de la charge de travail de chacun d'entre eux.
L'équipe donne pour chaque scénario une estimation de son coût d'implémentation, en « points » abstraits : tel scénario coûte 3 points, tel autre 1 point, etc. Liste des points: 1-2-3-5-8-13-20-40-100
L'équipe donne au client une estimation de sa « vélocité », c'est-à-dire du nombre de points de scénarios qu'elle s'estime capable de traiter en une itération - par exemple 10 points.
Au tout début du projet cette vélocité est seulement estimée, mais après les premières itérations elle est réajustée en adoptant la règle suivante : la vélocité estimée pour une itération donnée correspond exactement au nombre de points effectivement traités à l'itération précédente.
Le client établit lui-même le plan de développement en affectant les différents scénarios aux itérations à venir, de sorte qu'à chaque itération la somme du nombre de points des scénarios choisis soit égale à la vélocité annoncée.
Remarque
La vélocité ne représente en aucun cas le niveau de "performance" de l'équipe, dans la mesure où elle dépend en grande partie de la façon dont les développeurs font leurs estimations. Cependant, ses variations peuvent indiquer des problèmes passagers : si la vélocité baisse brutalement, c'est peut-être que l'équipe a été ralentie pour une raison ou une autre, et il ne faut pas ignorer cette information.
Côté outillage, on donne la priorité à l'aspect participatif de la démarche en notant les scénarios sur des fiches cartonnées que l'on colle sur un grand tableau ou un mur :
Cette pratique peut surprendre dans des contextes où les documents ont souvent une forme électronique, mais les séances de planification jouent avant tout sur l'aspect humain du projet, la communication directe entre l'équipe et le client permettant d'aligner les deux parties sur l'objectif à atteindre.
Le plan de développement ainsi constitué est disposé à proximité de l'endroit où travaille l'équipe, de manière à ce que celle-ci ait une vision toujours à jour de ses engagements.
Première mise en production
Comme nous l'avons évoqué plus haut, la phase d'exploration se termine par la première livraison du logiciel.
Cette première mise en production intervient aussi tôt que possible dans le projet : il faut trouver le contenu fonctionnel minimal qui commence à avoir un sens pour les utilisateurs, quitte à faire preuve d'imagination en amenant par exemple le nouveau logiciel en complément d'un système existant dans le cadre d'une fonctionnalité bien précise.
Livraisons suivantes
Les mises en production s'enchaînent ensuite à un rythme régulier, toujours fixé par le client. L'objectif est d'obtenir un feedback très rapide sur le développement - en pratique toutes les une à six itérations selon la complexité de déploiement du produit.
Le plan de développement est continuellement mis à jour si nécessaire pour tenir compte des événéments suivants :
L'équipe de développement progresse à une vitesse différente de celle prévue (dans le bon ou le mauvais sens)
Le client décide de changer le contenu des itérations restantes. Il peut ainsi permuter des scénarios en fonction de nouvelles priorités, ou encore remplacer certains scénarios du plan par de nouveaux.
Suivi du projet
Le suivi « haut niveau » du projet peut par exemple s'appuyer sur des graphes inspirés de celui représenté ci-dessous, dans lequel on note le nombre de points de scénarios restant à implémenter.
(Image non disponible)
Tous les scénarios imaginés par le client ne sont pas nécessairement représentés dans ce graphe. Seuls y figurent ceux qui ont été retenus pour la prochaine grande échéance - typiquement la prochaine version majeure du produit, ou encore la fin du projet pour un développement de type forfait.
Cette courbe permet par projection d'estimer si les objectifs du projet seront tenus, et elle permet aussi d'identifier certains « patterns » dans le fonctionnement de l'équipe (1) - par exemple une tendance à la sur- ou sous -estimation des tâches.
Tests de recette automatiques
Pour chaque scénario planifié, un ensemble de tests de recette est écrit. Ces tests ont pour but de vérifier de manière automatique (c'est-à-dire sans intervention ou interprétation humaine) chacune des fonctionnalités demandées
par le client. Le client définit ces tests et participe éventuellement à leur implémentation, assisté pour cela d'un certain nombre de testeurs.
Ces tests peuvent prendre plusieurs formes. Il peut s'agir de jeux de données, sous forme par exemple de feuilles de tableur ou de fichiers XML, qui définissent une transformation effectuée par le logiciel : « pour telle entrée, le logiciel doit produire tel résultat ». Il peut s'agir également de scripts pour les cas plus complexes, ces scripts décrivant par exemple des séquences d'interactions de l'utilisateur avec l'interface graphique du produit.
Ces tests représentent dans un projet XP les spécifications détaillées de l'outil - des spécifications formelles, toujours en phase avec le développement. Dans un contexte « pur XP », ce sont les seules spécifications : il n'y a pas de document de spécifications à proprement parler. En pratique, cependant, des documents peuvent être exigés par l'organisation qui encadre le projet. Des documents synthétiques sont alors réalisés par le client.
Les tests de recette sont lancés fréquemment, et tous les participants du projet (client, direction, développeurs) sont informés en permanence de leurs résultats
(2).
2.4. Programmation pilotée par les tests
La démarche extrêmement itérative proposée par XP n'est viable que si l'équipe est en mesure de garder la maîtrise technique de l'application, c‘est-à-dire de faire en sorte que les modifications du code restent longtemps faciles et rapides malgré les nombreuses évolutions. Cette maîtrise n'est pas le fruit du hasard, elle est le résultat d'une discipline de développement qui s'appuie sur les pratiques suivantes :
Mise en place intensive de tests unitaires
En complément des tests de recette, qui servent à prouver au client que le logiciel remplit ses objectifs, XP utilise intensivement les tests unitaires de non-régression. Ces tests sont écrits par les développeurs en même temps que le code lui-même, pour spécifier et valider le comportement de chaque portion de code ajoutée.
Quasiment chaque classe de l'application possède une classe jumelle de test. Lorsque des développeurs doivent ajouter une nouvelle méthode à la classe applicative, ils commencent par ajouter à la classe de test un ensemble d'assertions qui décrivent le comportement de la méthode à ajouter. La méthode n'est implémentée qu'ensuite, pour que ces tests passent. Il est important de noter que les tests s'exécutent sans aucune interprétation de la part du développeur : les assertions en question doivent vérifier automatiquement si le code testé fonctionne ou non.
Les classes de tests ne sont pas jetées après usage : elles sont gérées par un framework dédié (3) qui permet de les exécuter individuellement ou en totalité. La batterie de tests de l'application ne cesse donc de s'enrichir, et forme avec le temps un filet de sécurité qui permet aux développeurs d'effectuer des modifications dans le code existant sans crainte de régression.
Ces tests sont lancés à longueur de journée par les développeurs - en fait, à chaque compilation. Tous les tests unitaires doivent passer à 100% dans l'environnement d'un binôme avant tout report de modifications dans la version d'intégration du logiciel.
Cette pratique constitue l'une des pratiques centrales de XP. Ses avantages sont tels que chaque équipe, XP ou non, se doit de s'y pencher avec la plus grande
attention :
Les erreurs sont très vite détectées et localisées.
Les tests donnent une vision précise de la tâche à réaliser et aident les développeurs à aller droit au but.
Les tests placent les développeurs dans un contexte réduit qui leur permet de s'abstraire de la complexité du reste de l'application.
Il est possible de s'assurer du fonctionnement global du système très rapidement, après toute modification du code, avant ou après toute intégration dans la version officielle du système.
Ce que l'on constate au final, c'est que les développeurs d'une équipe XP passent plus de temps à ajouter des fonctionnalités, et moins de temps à investiguer des défauts dans le code existant.
Remaniement du code
L'application est toujours maintenue aussi malléable que possible grâce à une activité permanente de remaniement (refactoring). Le remaniement consiste à retoucher ou réorganiser des portions de code existantes, à comportement fonctionnel identique, en vue d'améliorer la structure d'ensemble de l'application.
L'une des motivations principales de remaniement est l'absence de duplication dans le code : tout doit y apparaître "Once and Only Once". Lorsqu'un développeur doit coder une nouvelle fonction proche d'une fonction déjà existante dans le code, il remanie l'application de manière à pouvoir utiliser directement le code existant. De la sorte les modifications de l'application n'impactent généralement que peu d'endroits dans le code, ce qui allège d'autant le travail.
Le remaniement est également utilisé pour rendre le code plus clair : lorsqu'un développeur intervient sur une partie donnée du code, il la modifie si nécessaire afin de faciliter le travail de ceux qui passeront après lui.
Le remaniement est plus qu'un moyen de dépoussiérer le code : c'est une façon de faire émerger une conception aussi adaptée que possible aux besoins de l'application, en supprimant au fur et à mesure tout ce qui nuit à sa simplicité et peut ralentir l'équipe. Comme les tests unitaires, le remaniement est pratiqué à longueur de journée - il s'agit d'une discipline quotidienne de qualité, et non d'une activité épisodique de réécriture.
Conception simple
"You ain't gonna need it!" : on ne fait de conception que pour les fonctionnalités existantes, pas pour les fonctionnalités futures. En corollaire:
- On ne fait de généralisations dans la conception que lorsque des besoins
concrets se font sentir.
- On n'introduit pas d'optimisations si elles ne sont pas demandées par le client.
En somme, plutôt que de préparer le logiciel pour un futur hypothétique, XP préconise de s'assurer que le travail actuel soit toujours bien fait (code testé, simple, lisible et sans duplications) de sorte que les changements restent faciles et rapides le moment venu.
Contrairement à ce que l'on pourrait penser au premier abord, cette position n'est pas celle de développeurs désireux de se consacrer à l'implémentation sans perdre de temps à concevoir. Il s'agit plutôt de l'inverse : en s'interdisant d'avoir un code médiocre, une équipe XP fait de la conception une activité vitale pour son fonctionnement. On observe d'ailleurs en pratique que les développeurs d'une équipe XP passent la plupart de leur temps à travailler sur cette conception.
2.5. Les valeurs d'XP
Tout en mettant l'accent sur les bonnes pratiques de programmation, XP préconise un déroulement par itération courte et géré collectivement, avec une implication constante du client. Il en découle une redéfinition de la relation entre client et fournisseur, avec de surprenants résultats en termes de qualité de code, de délais et de satisfaction de la demande du client. L'Extreme Programming repose sur 4 valeurs fondamentales :
Communication : XP favorise le contact humain, la communication directe, plutôt que le cloisonnement des activités et les échanges de courriers électroniques ou de documents formels. Les développeurs travaillent directement avec la maîtrise d'ouvrage, les testeurs sont intégrés à l'équipe de développement, etc. Les tests, la programmation en binôme et le jeu du planning obligent les développeurs, les décideurs et les clients à communiquer. Si un manque apparait malgré tout, un coach se charge de l'identifier et de remettre ces personnes en
contact.
Feedback : qu'il s'agisse d'itérations courtes, de livraisons fréquentes, de travail en binômes ou de tests automatiques éxécutés en permanence, la plupart des pratiques XP sont conçues pour donner un maximum de feedback sur le déroulement du projet afin de corriger la trajectoire au plus tôt. En particulier, les points de début d'itération offrent à l'équipe le moyen de prendre du recul sur son fonctionnement et de l'améliorer sans cesse au fil des itérations.
Simplicité : comme nous l'indiquions au début de ce dossier, XP relève le défi suivant : « que pouvons-nous arrêter de faire tout en continuant à créer efficacement un logiciel qui réponde aux besoins réels du client ? ». Cette recherche de simplification touche le processus lui-même, mais aussi l'outil fabriqué (la mécanique de planification incite le client à focaliser les efforts sur les fonctions prioritaires) ou encore la conception de l'application (guidée par un principe de « You ain't gonna need it »). La façon la plus simple d'arriver au résultat est la meilleure. Anticiper les extensions futures est une perte de temps. Une application simple sera plus facile à faire évoluer.
Courage : Certains changements demandent beaucoup de courage. Il faut parfois changer l'architecture d'un projet, jeter du code pour en produire un meilleur ou essayer une nouvelle technique. Le courage permet de sortir d'une situation inadaptée. C'est difficile, mais la simplicité, le feedback et la communication rendent ces tâches accessibles.
La programmation comme discipline collective
Ces 4 valeurs se déclinent en 13 pratiques qui se renforcent mutuellement :
Client sur site
Un représentant du client doit, si possible, être présent pendant toute la durée du projet. Il doit avoir les connaissances de l'utilisateur final et avoir une vision globale du résultat à obtenir. Il réalise son travail habituel tout en étant disponible pour répondre aux questions de l'équipe.
Jeu du Planning
Le client crée des scénarios pour les fonctionnalités qu'il souhaite obtenir. L'équipe évalue le temps nécessaire pour les implémenter. Le client sélectionne ensuite les scénarios en fonction des priorités et du temps disponible.
Intégration continue
Lorsqu'une tâche est terminée, les modifications sont immédiatement intégrées dans le produit complet. On évite ainsi la surcharge de travail liée à l'intégration de tous les éléments avant la livraison. Les tests facilitent grandement cette intégration : quand tous les tests passent, l'intégration est terminée.
Petites livraisons
Les livraisons doivent être les plus fréquentes possible. L'intégration continue et les tests réduisent considérablement le coût de livraison.
Rythme soutenable
L'équipe ne fait pas d'heures supplémentaires deux semaines de suite. Si le cas se présente, il faut revoir le planning. Un développeur fatigué travaille mal.
Tests de recette (ou tests fonctionnels)
À partir des scénarios définis par le client, l'équipe créé des procédures de test qui permettent de vérifier l'avancement du développement. Lorsque tous les tests fonctionnels passent, l'itération est terminée. Ces tests sont souvent automatisés, mais ce n'est pas toujours possible.
Tests unitaires
Avant d'implémenter une fonctionnalité, le développeur écrit un test qui vérifiera que son programme se comporte comme prévu. Ce test sera conservé jusqu'à la fin du projet, tant que la fonctionnalité est requise. À chaque modification du code, on lance tous les tests écrits par tous les développeurs, et on sait immédiatement si quelque chose ne fonctionne plus.
Conception simple
L'objectif d'une itération est d'implémenter les scénarios sélectionnés par le client, et uniquement cela. Envisager les prochaines évolutions nous ferait perdre du temps sans avoir la garantie qu'on en gagnera plus tard. Les tests nous permettront de changer l'architecture plus tard si nécessaire. Plus l'application est simple, plus il sera facile de la faire évoluer lors des prochaines itérations. De même, la documentation doit être minimale : on préfèrera un programme simple qui nécessite peu d'explications à un système complexe.
Utilisation de métaphores
On utilise des métaphores et des analogies pour décrire le système et son fonctionnement. Le fonctionnel et le technique se comprennent beaucoup mieux lorsqu'ils sont d'accord sur les termes qu'ils emploient.
Refactoring (ou remaniement du code)
Amélioration régulière de la qualité du code sans en modifier le comportement. On retravaille le code pour repartir sur de meilleures bases tout en gardant les mêmes fonctionnalités. Les phases de refactoring n'apportent rien au client mais permettent aux développeurs d'avancer dans de meilleures conditions, et donc plus vite.
Appropriation collective du code
L'équipe est collectivement responsable de l'application. Chaque développeur peut faire des modifications dans toutes les portions du code, même celles qu'il n'a pas écrites. Les tests diront si quelque chose ne fonctionne plus.
Convention de nommage
Puisque tous les développeurs interviennent sur tout le code, il est indispensable d'établir et de respecter des normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc.
Programmation en binôme
La programmation se fait par deux. Le premier, appelé driver (ou pilote), a le clavier. C'est lui qui va travailler sur la portion de code à écrire. Le second, appelé partner (ou co-pilote), est là pour l'aider, en suggérant de nouvelles possibilités ou en décelant d'éventuels problèmes. Les développeurs changent fréquemment de partenaires, ce qui permet d'améliorer la connaissance collective de l'application et d'améliorer la communication au sein de l'équipe.
Autres principes
Ne pas ajouter de fonctionnalités plus tôt que prévu ; N'optimiser qu'à la toute fin.
Cette méthode s'appuie sur :
une forte réactivité au changement des besoins du client ; un travail d'équipe ; la qualité du code ; la qualité des tests effectués au plus tôt.
Environnements défavorables
La méthode XP n'est pas utilisable dans tous les environnements et, parfois, seule une partie des pratiques peut être réalisée. Les principaux contextes défavorables sont[1] :
- un blocage culturel, quand le client ou les développeurs ont l'habitude de fonctionner autrement et ne veulent rien changer
- une équipe de 20 développeurs ou plus car la communication devient difficile
- un coût de changement exponentiel car "XP nécessite du code propre et simple"
- un feedback long ou difficile à obtenir
- un aménagement qui empèche la communication ou la programmation en binôme
source:http://medina.developpez.com/cours/extreme-programming/ source:http://www.techno-science.net/?onglet=glossaire&definition=723
CHAPITRE 3 - Méthodologie Agile - SCRUM
3.1. Principe et différentes phases
Le principe de la méthodologie SCRUM est de développer un logiciel de manière incrémentale en maintenant une liste totalement transparente des demandes d'évolutions ou de corrections à implémenter (backlog). Avec des livraisons très fréquentes, toutes les 4 semaines en général, le client reçoit un logiciel à chaque fois, un logiciel possédant toujours plus de fonctionnalités et en parfait état de fonctionnement. Pour cela, la méthode s'appuie sur des développements itératifs à un rythme constant d'une durée de 2 à 4 semaines. Les évolutions peuvent donc être plus facilement intégrées quand dans un cycle en V.
Concrètement, cette méthode nécessite 4 types de réunions :
Les réunions quotidiennes : chaque jour, toute l'équipe se réunit, généralement debout, pendant 15 minutes environ pour répondre aux 3 questions suivantes : qu'ai-je fait hier ?, Que vais-je faire aujourd'hui ? Y a-t-il un obstacle gênant aujourd'hui ?
Les réunions de planifications : toute l'équipe se réunit pour décider des fonctionnalités qui vont composer le sprint suivant et mettre à jour la liste générale.
Les réunions de revue de travail : lors de cette réunion, chacun présente ce qu'il a fait pendant la durée du sprint. Une démonstration des nouvelles fonctionnalités ou de présentation de l'architecture est organisée. Il s'agit d'une réunion informelle de 2 heures environ à laquelle participe toute l'équipe.
Les réunions de rétrospectives : à chaque fin de sprint, l'équipe fait le point sur ce qui à bien fonctionné et sur ce qui a moins bien fonctionné. Lors de cette réunion d'une durée de 15 à 30 minutes où chacun est invité et parle en son nom, un vote de confiance est organisé pour décider des améliorations à apporter.
L'avantage de la méthode est de réduire au strict minimum la documentation afin de gagner en productivité. L'idée ici est de ne faire que la documentation minimale qui permet de garder l'historique des décisions prises sur le projet et de pouvoir facilement intervenir sur le logiciel lorsqu'il sera entré en phase de maintenance.
3.2. Organisation
La méthodologie SCRUM fait intervenir 3 rôles principaux qui sont :
Product owner : Dans la majorité des projets, le responsable produit (product owner) est le responsable de l'équipe projet client. C'est lui qui va définir et prioriser la liste des fonctionnalités du produit et choisir la date et le contenu de chaque sprint sur la base des valeurs (charges) qui lui sont communiquées par l'équipe.
ScrumMaster : Véritable facilitateur sur le projet, il veille à ce que chacun puisse travailler au maximum de ses capacités en éliminant les obstacles et en protégeant l'équipe des perturbations extérieures. Il porte également une attention particulière au respect des différentes phases de SCRUM.
Equipe : d'une taille allant de 4 à 10 personnes en général, l'équipe regroupe tous les rôles habituellement nécessaires à un projet, à savoir l'architecte, le concepteur, le développeur, le testeur, etc. L'équipe s'organise elle-même et elle reste inchangée pendant toute la durée d'un sprint.
3.3. Avantages
Scrum se différencie des autres méthodes de développement par ses avantages qui font de ce procédé une réponse pragmatique aux contraintes actuelles des chefs de produits :
Méthode itérative et incrémentielle : cela permet d'éviter "l'effet tunnel", c'est-à-dire le fait de ne voir le résultat qu'à la livraison finale et rien ou presque rien pendant toute la phase de développement, si fréquent dans les développements avec le cycle en V.
Adaptabilité maximale pour du développement de produits et d'applications : la composition séquentielle du contenu des sprints permet d'ajouter une modification ou une fonctionnalité qui n'était pas prévue au départ. C'est principalement cela qui rend cette méthode "agile".
Méthode participative : chaque membre de l'équipe est invité à s'exprimer et il peut participer à toutes les décisions prises sur le projet. Il est donc plus impliqué et plus motivé.
Augmentation de la communication : en travaillant dans la même salle de développement, ou en étant connecté avec différents moyens de communication, l'équipe peut communiquer facilement et échanger sur les obstacles afin de les supprimer au plus tôt.
Maximisation de la coopération : les échanges quotidiens entre le client et l'équipe Pentalog permettent un rapprochement et une entraide se met logiquement en place.
Augmentation de la productivité : en supprimant certaines "contraintes" des méthodes classiques comme la documentation ou la formalisation exagérée, SCRUM permet d'augmenter la productivité de l'équipe. En ajoutant à cela la qualification de chaque module permettant d'en déterminer un chiffrage, chacun peut se positionner par rapport à la productivité moyenne de l'équipe.
3.4. Risques et solutions
La méthodologie SCRUM n'est pas une réponse miracle à tous les problèmes inhérents au développement de logiciels informatiques. Il faut rester vigilant sur les risques ci-dessous, risques qui possèdent néanmoins, une réponse systématique puisée dans l'extrapolation de la méthode :
Taille de l'équipe : généralement limitée à 7 ou 10 personnes, la taille de l'équipe peut devenir un obstacle si elle dépasse ces préconisations. L'organisation des réunions devient alors impossible et les fondements mêmes de la méthode sont alors mises à mal. La solution consiste à réaliser des Scrum de Scrum. Il s'agit ici de constituer de scinder le projet en équipes de taille recommandée et d'ajouter une instance de niveau supérieure regroupant les ScrumMaster de chaque Scrum.
Demandes multiples : Les demandes peuvent émaner de multiples canaux sur un projet et peuvent parfois être difficile à gérer du fait de leur aspect contradictoire. Au niveau de la recette des livraisons, ces contradictions peuvent alors ralentir le processus de validation. Pour remédier ce problème, il est impératif d'utiliser un outil unique de gestion des demandes, outil qui est proposé en standard sur les projets Pentalog.
Qualité des développements : Plus le nombre d'équipes augmente, plus la qualité est difficile à maîtriser. Ce postulat est d'autant plus vrai dès lors que le projet est réparti sur plusieurs sites. Les risques sont particulièrement liés à la qualité du code et au nombre de défauts répertoriés au moment de l'intégration. Pour cela, il est important d'avoir une politique qualité rigoureuse et un plan qualité projet qui définit précisément les règles du projet. Des audits de code fréquents et la mise en place d'indicateurs mesurant la performance des développeurs permettent de minimiser ce risque.
3.5. A qui s'adresse ce type d'organisation ?
Ce type d'organisation peut être utilisée dans la plupart des projets. Néanmoins, elle est particulièrement adaptée pour les projets ne répondant pas à un périmètre stricte et pour lesquels le client souhaite un suivi et une visibilité, en d'autres termes, une implication, très important dans le cycle de développement.
L'aspect "disponibilité" coté client est un critère déterminant dans le choix de cette méthode de développement. En effet, nous estimons un ETP proche de 1 le temps nécessaire au product owner pour répondre aux exigences de cette méthode : transfert de certaines actions du chef de projet dans une méthode classique vers le product owner (distance entre l'équipe et le besoin).
source: http://www.pentalog.fr/notre_demarche/methodologie_agile_scrum.htm
CHAPITRE 4 - Les méthodes Agile
Ce chapitre regroupe toutes les méthodes permettant de mettre en oeuvre les principes d'Agile.
4.1. Crystal Clear
Crystal clear est une méthode de gestion de projet. Sa méthodologie est très fortement adaptable aux spécificités de chaque projet. Plusieurs principes doivent être partagés par l'ensemble de l'équipe :
La communication est omniprésente pour réussir le " jeu coopératif " que représente un projet comme le fait remarquer le créateur de cette méthode : Alistair Cockburn.
Le nombre de membres d'une équipe est limité à six personnes afin que l'équipe soit solidaire.
Tous les membres de l'équipe doivent travailler dans une même pièce afin de faciliter la communication par proximité.
Les schémas de modélisation doivent être réalisés en groupe et sur tableau blanc car cela améliore la communication et la collaboration.
La collaboration avec le client est elle aussi très importante, notamment grâce à de nombreuses conversations entre utilisateurs et développeurs.
Livrer des parties exécutables de l'application le plus fréquemment possible afin que le client se rende compte du travail en cours et propose des changements.
Crystal reste très souple tant au niveau des procédures à suivre que des normes à utiliser (comme par exemple les normes de codage). Cette méthode possède une procédure découpée en différentes étapes :
La spécialisation consiste à observer les utilisateurs dans leur travail pour mieux connaître leurs besoins et leur environnement. Ensuite, les différents cas d'utilisation sont classés par ordre de priorité en collaboration avec les utilisateurs, ce qui permet de savoir quelles fonctionnalités ont le plus de valeur et doivent être développées en premier.
Une ébauche de conception est réalisée au tout début du projet, cela inclut les choix des technologies à utiliser et implique une ébauche d'architecture.
Le planning consiste à prévoir vers quelles dates les itérations vont se suivre, il est recommandé de définir des itérations d'une longueur de 2 à 3 mois, chacune produisant un produit à livrer fonctionnel.
Les itérations, c'est au cours de cette phase que se fait la réalisation proprement dite de l'application, en suivant un ordre de phase indiqué dans le schéma ci-dessous.
Crystal présente tout les avantages des méthodes agiles : flexibilité par rapport au changement, rapidité, livraisons fréquentes, etc. Elle convient tout à fait pour des petites structures (taille inférieure à 6 personnes), mais ce qui fait son efficacité dans les projets de petite taille cause son inadéquation pour des projets plus importants.
4.2. Dynamic systems development method
Dynamic systems development method (DSDM) est une méthode de gestion de projet de la catégorie des méthodes agiles. Cette méthode a été développée en Grande -Bretagne à partir de 1994.
La méthode DSDM s'appuie sur 9 principes de base :
Implication des utilisateurs durant tout le cycle de développement. Ils sont considérés comme des membres à part entière de l'équipe projet.
Autonomie. L'équipe projet doit avoir un pouvoir de prise de décision concernant l'évolution des besoins.
Visibilité du résultat. L'application doit être livrée le plus souvent possible afin de permettre un feed-back rapide. Les délais entre les livraisons doivent être le plus court possible.
Adéquation. L'objectif est de livrer une application en adéquation avec le besoin metier du client.
Développement itératif et incrémental. L'évolution du développement est basé sur le feed-back des utilisateurs.
Réversibilité. Toute modification effectuée durant le développement doit être réversible.
Synthèse. Un schéma directeur défini de manière préalable fixe les grandes lignes du projet, notamment son périmètre.
Tests. Les tests sont continus durant tout le développement. Ils permettent de garantir le bon fonctionnement de l'application, à chaque étape du développement.
Coopération. Les acteurs du projet doivent faire preuves de souplesse concernant les modifications des fonctionnalités demandées.
Processus
image:Dsdm.png
Etude de faisabilité : Le but de cette étape est de déterminer s'il est opportun de faire le projet en question. On évalue les coûts, la valeur ajoutée attendue. Dans cette étape, on produit un Rapport de Faisabilité ainsi qu'un Plan Global de Développement. On développe parfois un prototype afin de démontrer la faisabilté technique.
Etude business : Cette étape sert à la définition des spécifications. On définit quelles sont les fonctionnalités que l'application doit apporter, en les priorisant, dans un document appelé Définition du Domaine Industriel, mais aussi quels types d'utilisateurs sont concernés par l'application, de manière à pouvoir les impliquer. On définit également l'architecture du système, dans un document appelé Définition de l'Architecture Système. Enfin, à partir du Plan Global de Développement, on définie un Plan Global de Prototypage.
Modèle fonctionnel itératif :
Conception et réalisation itératives :
Mise en œuvre :
4.4. Développement rapide d'applications
La méthode RAD, acronyme de Rapid Application Development (développement rapide d'applications en français), est une méthode de développement de logiciels où le cycle de développement est plus court que celui des méthodes Cascades. La méthode RAD fut initialement développée par James Martin pendant les années 1980. À partir de 1994, Vickoff Jean-Pierre pour l'aspect francophone, notamment avec le Processus RAD2 publié par le Gartner Group, et Jennifer Stapleton en Grande-Bretagne, avec DSDM, introduisirent des compléments et des actualisations. L'objectif de la méthode RAD restant d'obtenir un applicatif adéquat à partir d'un prototypage impliquant l'utilisateur final.
Cette méthode inclut la réalisation, et les tests d'une application en mode itératif-incrémental. La méthode sans être liée aux outils recommande l'utilisation d'outils de programmation à interface graphique (CASE), qui permettent d'obtenir rapidement des prototypes.
Il ne faut pas confondre la méthode RAD (d'où sont issues les approches Agiles actuelles) qui recherche la qualité applicative fonctionnelle et technique avec les outils RAD dont la production de code est souvent qualifiée de "sale".
Structure de la méthode
Pour rappel (et en synthèse), la méthode RAD implique :
Un cycle de développement sécurisant et court fondé sur un phasage simple : Cadrage, Design, Construction et l’absolu respect d’une dimension temporelle (90 jours optimum, 120 jours maximum) [Martin 1991].
Une architecture de communication engageant des groupes de travail de structure et de composition variable selon les besoins des phases et respectant un mode opératoire précis structuré en trois étapes : pré-session, session, post-session [Mucchielli 1987].
Des méthodes, techniques et outils permettant de définir et d’appliquer des choix portant sur quatre natures d'objectifs potentiellement contradictoires : budget, délais, qualité technique, qualité fonctionnelle et visibilité [Vickoff 1998].
Une architecture de conception s’appuyant sur les techniques de l'objet et particulièrement sur celles qui permettent une conception " en vue de modifications " [McCarty 1997].
Une architecture de réalisation qui impose, pour garantir la qualité technique, des normes minimales, des revues de projet, des jalons zéro-défaut et qui recommande, pour garantir la qualité fonctionnelle, le prototypage actif et les Focus de visibilité [McConnell 1996]. Description globale des phases
La méthode RAD structure le cycle de vie du projet en 5 phases :
L’Initialisation définit l’ organisation, le périmètre et le plan de communication.
Le Cadrage définit un espace d’objectifs, de solutions et de moyens.
Le Design modélise la solution et valide sa cohérence systémique.
La Construction réalise en prototypage actif (validation permanente).
La Finalisation est un contrôle final de qualité en site pilote.
Dans un second niveau de détail (figures 1), ces phases comprennent :
- INITIALISATION (préparation de l’organisation et communication )
Cette phase permet de définir le périmètre général du projet, de structurer le travail par thèmes, de sélectionner les acteurs pertinents et d’amorcer une dynamique de projet. Cette phase représente environ 6% du projet en charge.
- CADRAGE (analyse et expression des exigences)
La spécification des exigences est du ressort des utilisateurs. Ils expriment leurs besoins lors d’entretiens de groupe. Il est généralement prévu de 2 à 5 jours de sessions par commission (thème). Cette phase représente environ 9% du projet.
- DESIGN (conception et modélisation)
Les utilisateurs sont également impliqués dans cette étape. Ils participent à l’affinage et à la validation des modèles organisationnels : flux, traitements, données. Ils valident également le premier niveau de prototype présentant l’ergonomie et la cinématique générale de l’application. Il est prévu entre 4 et 8 jours de sessions par commission. Cette phase représente environ 23% du
projet. A partir de la phase de Design la parallélisation du travail est possible.
- CONSTRUCTION (réalisation, prototypage)
Durant cette phase, l’équipe RAD (SWAT) doit construire l’application module par module. L’utilisateur participe toujours activement aux spécifications détaillées et à la validation des prototypes. Plusieurs sessions itératives sont nécessaires. Cette phase représente environ 50% du projet. A partir de la phase de Construction, à la parallélisation du travail peut s’ajouter la sérialisation.
- FINALISATION (recette et déploiement)
Des recettes partielles ayant été obtenues à l’étape précédente, il s’agit dans cette phase d’officialiser une livraison globale et de transférer le système en exploitation et maintenance. Cette phase représente environ 12% du projet. Le site francophone de référence dédié à la méthode RAD est RAD.fr ((lien))
En ce qui concerne les outils RAD
Delphi (ainsi que le Visual Basic) est un outil RAD en ce sens qu'il permet assez facilement de créer des programmes à l'aide d'une interface graphique dotée de nombreux outils et de modules prêts à l'emploi.
WinDev (ainsi que WebDev) est un outil RAD plus avancé car il permet à partir d'une analyse Merise ou UML de produire un applicatif final et opérationnel. WinDev Mobile permet lui de créer rapidement des applications pour les matériels mobiles.
Authorware crée lui-aussi un applicatif final en dessinant un diagramme à l'aide d'icônes.
JBuilder
C++ Builder
C# Builder
Leonardi est un outil RAD adapté au développement des IHM.
http://www.techno-science.net/?onglet=glossaire&definition=797