Univesité de Khmis-Miliana (W.
Ain-Defla)
FACULTE DES SCIENCES ET DE LA TECHNOLOGIE
DEPARTEMENT MATHEMATIQUES & INFORMATIQUEL3 Informatique (SI)2016/2017
Module : Génie Logiciel 2
Cours 3 : Les méthodes agiles de développement logiciel
1. Introduction
Les méthodes agiles sont des groupes de pratiques de pilotage et de réalisation de projets. Les
principales methodes de gestion de projet sont : découpage en phases (voir cycle en V), découpage en
activités WBS (WorkBrakedown Structure), nouveau : Les méthodes Agiles.
2. Méthodes agiles
Les méthodes de développement dites « méthodes agiles »(en anglais Agile Modeling, noté AG)
visent àréduire le cycle de vie du logiciel (donc accélérer son développement) en développant une
versionminimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client
et destests tout au long du cycle de développement. L'origine des méthodes agiles est liée à l'instabilité
del'environnement technologique et au fait que le client est souvent dans l'incapacité de définir ses
besoinsde manière exhaustive dès le début du projet. Le terme « agile » fait ainsi référence à la
capacitéd'adaptation aux changements de contexte et aux modifications de spécifications intervenant
pendant leprocessus de développement.
2.1 Quatre valeurs fondamentales : Les méthodes agiles prônent 4 valeurs fondamentales :
L'équipe : (Les individus et leurs interactions avant les processus et les outils ): leurs
compétences, leurs capacités est beaucoup plus important que les méthodes de travail, les outils de
travail (les processus), toute l’organisation.
Exp : les experts chacun dans son domaine.
L'application (Des logiciels opérationnels, plus qu'une documentation exhaustive) : Des
fonctionnalités opérationnelles avant la documentation (écrites);
La collaboration : (La collaboration avec les clients, plus que la négociation
contractuelle)Collaboration avec le client plutôt que contractualisation des relations (le client doit
nous donne un feedback toute suit à chaque partie réalisée par l’équipe).
L'acceptation du changement : (Adaptation au changement plutôt que conformité aux plans). 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 livraisons du logiciel vont souvent
provoquer des demandes d'évolution.
1
2.2 Les principes de l'Agilité :
Notre priorité est de satisfaire le client par des livraisons rapides et continues de logiciel utile.
Accepter le changement dans les exigences, même tard dans le cycle de vie, pour garantir la
compétitivité du client.
Livrer fréquemment du logiciel opérationnel, de quelques semaines à quelques mois en visant
les délais courts.
Client et développeurs doivent coopérer quotidiennement tout au long du projet.
Élaborer des projets autour d’individus motivés. Leur procurer l’environnement et le support
nécessaire et leur faire confiance pour réaliser le travail.
La méthode la plus efficace de communiquer des informations a une équipe et entre ses
membres reste laconversation en face à face.
Le fonctionnement de l'application est le premier indicateur d'avancement du projet.
Agile favorise le développement a rythme "normal" ou soutenable.
Les gestionnaires, développeurs et utilisateurs devraient être en mesure de maintenir un
rythme constant et ce, indéfiniment.
Porter une attention continue à l’excellence technique et a la conception améliore l’agilité.
La simplicité garantit l'évolutivité du système
Les meilleures architectures, exigences et designs prennent naissance dans des équipes qui se
gèrent elles-mêmes.
Régulièrement, l’équipe fait une réflexion sur les façons de devenir plus efficace, s’ajuste et
modifie son comportement en conséquence. .
2.3 Les différentes méthodes Agiles
Adaptative Software Development (ADS); Crystal; Scrum; „X Extreme Programming (XP)..
2.3.1 XP - eXtremeProgramming
La méthode XP (pour eXtremeProgramming) définit un certain nombre de bonnes pratiques
permettant dedévelopper un logiciel dans des conditions optimales en plaçant le client au cœur du
processus dedéveloppement, en relation étroite avec le client.
L'eXtremeProgramming est notamment basé sur les concepts suivants :
Les équipes de développement travaille directement avec le client sur des cycles très courts
d'une à deux semaines maximum.
Les livraisons de versions du logiciel interviennent très tôt et à une fréquence élevée pour
maximiser l'impact des retours utilisateurs.
L'équipe de développement travaille en collaboration totale sur la base de binômes..
Le code est testé et nettoyé tout au long du processus de développement.
Des indicateurs permettent de mesure l'avancement du projet afinde permettre de mettre à
jour le plan de développement.
L‘eXtremeProgramming repose sur des cycles rapides de développement (des itérations de quelques
semaines) dont les étapes sont les suivantes :
2
Structure d’une équipe XP et leur rôle
Les profils :Client.:Testeur.:Manager.:Coach.:Tracker.:Programmeur.
1. Le client : Membre à part entière de l’équipe, Présence physique imposé dans l’équipe tout au
long du développement, Spécifie les fonctionnalités à implémenter et tests fonctionnels,Rôle
pouvant être tenu par une ou plusieurs personnes
2. Le testeur :Assistant du client, Un programmeur, Implémente (code) les tests de recette le plus tôt
possible,valide le fonctionnement du code et vérifie la non régression.
3. Le manager :Responsable de l’infrastructure dans laquelle l’équipe travaille, S’assure la non
existence de problèmes étrangers au projet oulogistiques (espace de travail, outillage,
documentation, etc.).
4. Le coach :S’assure de la bonne compréhension de la méthode XP et deson application correcte
par les différents acteurs du projet, Généralement « expert méthode » et bon
communicateurdoublé d’un technicien crédible et respecté, A pour objectif de se faire oublier.
5. Le tracker :Contrôle l’avancement des tâches à l’intérieur d’une itération, S’entretient
fréquemment avec chaque programmeur pours’enquérir des difficultés rencontrées et du travail
déjà effectué, Construit régulièrement une vision fiable de l’avancement destâches afin de détecter
le plus tôt possible les dérives et delancer une nouvelle phase si nécessaire.
6. Le programmeur : Estime la charge nécessaire à l’implémentation d’un scénariodans le cadre du
jeu de la planification, Implémente les scénarios en s’appuyant sur l’écriture de tests unitaires, Est
aussi analyste, concepteur.
Les avantages de l’XP
Concept intégré et simples.
Pas trop de management.
pas de procédures complexes.
pas de documentation à maintenir.
communication directe.
programmation par paires.
Gestion continuelle du risque.
Estimation permanente des efforts à fournir.
Insistance sur les tests : facilite l’évolution et la maintenance.
Les inconvénients de l’XP
Approprié pour de petites équipes (pas plus de 10développeurs), ne passe pas à l’échelle.
Pour des groupes plus gros, il faut plus de structure et dedocumentation (ceremony).
Risque d’avoir un code pas assez documenté.
Des programmeur qui n’auraient pas fait partie de l’équipe dedéveloppement auront sans doute du
mal à reprendre lecode.
Pas de design générique.
Pas d'anticipation des développements futurs.
2.3.2 La méthode DSDM(Dynamic System DevelopmentMethod)
La méthode DSDM (nom donné au consortium commercialisant la méthode RAD en Angleterre) se
particularise par la spécialisation des acteurs du projet dans une notion de « rôles ». Ainsi, l'on trouvera dans les
réunions DSDM des sponsors exécutifs, des ambassadeurs, des utilisateurs visionnaires, des utilisateurs conseillers,
sans oublier l'animateurfacilitateur, des rapporteurs et bien évidemment des développeurs.
2.3.3 La méthodeScrum
3
Scrum est une méthode agile dédiée à la gestion de projetsinformatiques. Son objectif est d'améliorer la
productivité des équipes.
Scrum est une méthode Agile qui permet de produire la plus grande valeur métier dans la durée la plus courte.
Du logiciel qui fonctionne est produit à chaque sprint, c’est à dire toutes les 3 / 4 semaines.
Le métierdéfinit les priorités, l’équipe s’organise elle-même pour déterminer la meilleure façon de produire les
exigencesles plus prioritaires.
A chaque fin de sprint (Cycle itératif= 30 jours), tout le monde peut voir fonctionner leproduit courant et décider
soit de le livrer dans l’état, soit de continuer à l’améliorer pendant un sprint supplémentaire.
[Link] Cycle de vie de Scrum
[Link] Les rôles dans une équipe Scrum
Un directeur de produit (productowner) qui est soit le client,soit une personne représentant le client, il:
définit les fonctionnalités du produit.
choisit la date et le contenu de la release.
responsable du retour sur investissement.
définit les priorités dans le backlog (listedefonctionnalités,)en fonction de lavaleur métier
ajuste les fonctionnalités et les prioritésà chaque sprint sinécessaire
accepte et rejette les résultats.
Un Scrum Master qui:
représente le management de projet
est responsable de faire appliquer les valeurs et les pratiques de Scrum par l’équipe
résout les problèmes
s’assure que l’équipe est complètement fonctionnelle et productive
facilite une coopération poussée entre tous les rôles et fonctions
protège l’équipe des interférences extérieures.
Les équipiers qui:
Se composent de 5 à 10 personnes
Regroupent tous les rôles: architecte, concepteur,
Analyste, développeur, testeur,
Sont à plein temps sur le projet
S’organisent eux-mêmes
4
Ne changent pas de composition pendant un sprint
Se concentrent sur un sprint à la fois (sprint courant).
[Link] Les réunions dans Scrum
1. Planification du Sprint (2 à 4h)
Définir le but du sprint
Définition du périmètre du sprint
Identification les tâches à partir des éléments sélectionnés
Estimation des tâches
Attribution des tâches
Obtenir l'engagement de l'équipe.
2. Scrum quotidien (15mn debout)
Qu’as-tu fait depuis la dernière fois ?
Que prévois-tu de faire jusqu'à la prochaine réunion ?
Qu'est-ce qui te gène pour réaliser ton travail aussi efficacement que possible ?
3. Revue de sprint (2 à 4h)
Préparer la démonstration
Rappeler les objectifs du sprint
Effectuer la démonstration
Evaluer les résultats du sprint
Calculer la vélocitéréelle et ajuster le plan de release.
Avantages de SCRUM
Méthode itérative et incrémentale.
Adaptabilité maximale pour le 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
AVANTAGES DE LA MÉTHODE SCRUM AGILE
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.
RISQUES ET SOLUTIONS DE LA MÉTHODE
La méthode SCRUM Agile 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 :
5
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.
2.4 Critères d'éligibilité (toutes de méthodes agiles)
De multiples facteurs contextuels peuvent être pris enconsidération pour valider ou invalider la
possibilitéd'application d'une méthode agile. Les principaux critèresd'éligibilité pourraient être les
suivants :
1. Favorisant :
Besoin rapide de mise à disposition du produit
Imprévisibilité des besoins du client
Nécessité de changements fréquents
Besoin de visibilité du client sur l'avancement des développements
Présence de l'utilisateur assurant un feedback immédiat
2. Défavorisant :
Indisponibilité du client ou de l'utilisateur
Dispersion géographique des ressources humaines
Inertie des acteurs du projet ou refus des changements
Gouvernance complexe de la DSI
Ne jamais arriver à fournir et donc vendre quoi que ce soit.
Dans les cas où les critères d'éligibilité de l'utilisationd'une approche agile n'ont pas été respectés, un
risquede dérive lié à un formalisme léger peut apparaître.
2.5 Principales critiques
Dans la réalité de leur mise en œuvre, toutes les méthodes ne respectent pas à l'identique les
principes fondamentauxagiles.
Scrum nécessite une importante spécification préalable àla mise en production (backlog produit), ce qui le
classeraiten partie du côté prédictif des méthodes. Certainsestiment que ce point ne serait pas un
problèmesi Scrum disposait d'une métrique formelle de gestiondes modifications. Mais l'objectif de
Scrum est essentiellementorienté sur la maîtrise d’une livraison d’incréments(sprint). Son processus
réfute donc la possibilitéde modifier les fonctionnalités en cours de réalisation(à l'exception d'un simple
affinement depuis la version2011). Pour cette raison, certains prétendent que Scrumne peut être alors
considéré comme réellement itératif etadaptatif.
6
Par ailleurs, comme Scrum ne propose aucune techniqued'ingénierie du logiciel, il est indispensable de
faire appelà une autre méthode pour assurer la qualité et la fiabilitédes développements informatiques.
D'aucuns expliquent, notamment lors de projets complexes,qu'il serait nécessaire d'ajouter à Scrum
comme àeXtremeProgramming les pratiques de structuration desexigences qui leur font défaut.
Bibliographie :
Aubry Claude « Scrum : le guide pratique de la méthode agile la plus populaire», Ed. Dunod, 2013