Soutenance mémoire
Sélection de la méthode Agile Scrum
Depuis ces dernières années, les méthodes agiles sont très fortement utilisées pour le développement logiciel. Comme, il a été montré plus haut, il existe plusieurs méthodes agiles (Scrum, DSDM, Kaban, XP, FDD, etc). Selon le 10e rapport annuel de VersionOne sur l’utilisation des méthodes agiles, la méthode Scrum continue d’être la méthode agile la plus utilisée. En effet, selon l’enquête (VERSIONONE, 2016) 70 % des équipes utilisent Scrum ou les méthodes hybrides Scrum/XP. Selon le 9e rapport de la même institution, la méthode Scrum est utilisée à 56 % (VERSIONONE, 2015), nous notons donc une utilisation de plus en plus accrue de la méthode Scrum par les équipes. Aussi, la méthode Scrum est l’une des méthodes qui répond le mieux aux caractéristiques énoncées dans le chapitre précédent (minimal, adaptative, collaborative et configurable). Sur cette base, nous avons choisi d’utiliser la méthode Scrum pour l’adapter au contexte de gestion des projets de développement d’applications dans le cloud. Le choix de la méthode Scrum et du modèle PaaS n’est pas original, mais nous permet d’analyser l’applicabilité des méthodes agiles dans le cloud en fonction de ces pratiques, rôles et artéfacts. En effet d’autres auteurs comme Singhal ont proposé en 2016 la méthode ESCAM qui est une extension de la méthode Scrum dans le cloud.
Adaptation de la méthode Scum au contexte du cloud PaaS Pour adapter le développement agile d’application au cloud computing, dans ce mémoire il a été choisi la méthode Scrum. Cette dernière basée sur la version 2016 du guide du SBOK, présente l’ensemble des évènements, des pratiques et des rôles nécessaires à la gestion de projet agile dans le cloud. Le développement d’applications pouvant se faire sur les 3 couches (SaaS, IaaS, PaaS) couches fondamentales du cloud, nous nous sommes limités à la couche plateforme (PaaS) du cloud dans ce projet de recherche. Ainsi, l’implication du PaaS est analysée dans chacun des évènements de développement d’applications abordées.
Implication du PaaS
La plupart des fournisseurs de plates-formes PaaS sont choisis en fonction des paramètres décisionnels montrés ci-haut. En fonction des besoins d’affaires et de la complexité de l’application à développer, une grille d’évaluation et de sélection est établie. La méthode d’analyse AHP peut être utilisée afin d’identifier le ou les fournisseurs qui répondent aux exigences du projet. En termes d’avantage, cet évènement permet de prendre en compte l’ensemble des contraintes du projet afin de mieux sélectionner les fournisseurs. Une mauvaise sélection des fournisseurs peut entrainer des conséquences sur la qualité du logiciel à réaliser ou sur l’atteinte des objectifs. Ceci est dû au fait que le PaaS offre moins de contrôle que dans les environnements IaaS ou autres environnements classiques de développement. Le changement de fournisseurs de services PaaS en cours de développement peut être préjudiciable au succès du projet avec possibilité de blocage par le fournisseur ou des retards dans la livraison des incréments.
Backolg de produit
Le Backlog de produit représente la liste dynamique des exigences, fonctions et améliorations nécessaires à la réalisation de l’application. Ces différents items sont continuellement actualisés et ordonnés. L’utilisation de l’environnement de PaaS n’implique pas de changements au niveau du contenu du Backlog et de son fonctionnement. Néanmoins la plupart des fournisseurs de services PaaS offrent des applications SaaS qui permettent de gérer le Backlog de produit et surtout de faire le lien avec l’environnement PaaS de développement pour faciliter le suivi en temps réel des activités.
Backolg de Sprint Comme le Backlog de produit, le Backlog de Sprint retrace l’ensemble des items nécessaires pour livrer l’incrément. Cette liste est plus détaillée que celle du Backlog de produit. Les applications SaaS sont aussi proposées pour gérer avec transparence cet outil.
Gestion de l’avancement Pour suivre la progression du projet, plusieurs outils de projections de tendances comme le « Burn Down Chart » et le « Burn Up Chart » sont utilisés. Ces 2 outils sont utilisés pour mesurer l’évolution de chaque itération et de l’ensemble de l’incrément (« Realease »). Plusieurs formes et types de diagrammes sont exploités pour représenter ces outils. D’autres techniques comme celui de la « Valeur acquise » sont aussi utilisées. Cette dernière mesure l’avancement dans le temps en fonction des prévisions et des efforts réels effectués. La figure 6.1 nous montre un exemple de « Burn Down chart » pour une itération. Elle présente la somme des efforts restants à effectuer et la progression idéale des efforts. Ces derniers sont évalués en heures (parfois en points). Sur cette figure on observe qu’à la date du 2017-09-18, l’itération est en retard, car l’effort restant dépasse l’idéal.
Gestion des changements
L’un des principes clés des méthodes agiles et en occurrence de Scrum est l’acceptation des demandes de changement en tout temps lors de la réalisation de l’application. Ces demandes peuvent intervenir pendant tous les évènements présentés dans notre méthode. Les demandes de changements sont souvent faites par les parties prenantes pour répondre à la volatilité du marché, la concurrence ou d’autres facteurs déterminants pour le succès du projet. Parfois ces projets font partie de programme ou de portefeuille qui ont des contraintes particulières. Ces Figure 6.1 Exemple de « Burn Down Chart » pour une itération demandes peuvent être mineures ou majeures (influençant l’issu du projet). Les demandes mineures peuvent être approuvées par le Product Owner, par contre celles qui sont majeures nécessitent l’intervention des parties prenantes (commanditaire, client, etc.). Pour une bonne gestion de ces demandes, il est important d’adopter des processus formels de gestion.
Communication sur les risques La communication sur la rentrée est la dernière étape de la gestion des risques. Elle s’effectue tout au long du cycle de développement et permet d’assurer la transparence du projet et d’impliquer davantage l’ensemble des parties prenantes. Les risques peuvent être aussi abordés par l’équipe de développement lors des rencontres quotidiennes. Le principal outil utilisé pour la communication sur les risques est le « Risk Burndown Chart ». La figure ci-dessous nous montre l’exemple d’un graphe d’évolution des risques en fonction des itérations. Elle présente l’évolution des probabilités cumulées de 6 risques jusqu’à la cinquième itération. Elle montre aussi une diminution progressive de la sévérité des risques.
Gestion des approvisionnements Lors de l’exécution des projets, certains approvisionnements sont faits pour assurer la livraison des produits. Dans le cas du développement dans un environnement PaaS, les approvisionnements sont essentiellement liés à l’acquisition des services cloud et à la gestion des contrats. Un bon plan de gestion des contrats notamment les Cloud Service Agrement (CSA) afin gérer au mieux ces services cloud et faciliter leur évaluation.
|
Table des matières
INTRODUCTION
CHAPITRE 1 CONCEPTS DE BASE
1.1 Introduction
1.2 Le cloud et ses caractéristiques
1.2.1 Définition
1.2.2 Caractéristiques
1.2.3 Catégories de services
1.2.4 Modèles de déploiement
1.2.5 Rôles et activités
1.3 Les méthodes de développement agiles
1.3.1 L’agilité
1.3.2 Les méthodes agiles en développement logiciel
1.3.2.1 eXtreme Programming (XP)
1.3.2.2 Dynamic Systems Development Method (DSDM)
1.3.2.3 Scrum
1.3.3 Synthèse
1.4 Conclusion du chapitre
CHAPITRE 2 REVUE DE LITTÉRATURE SUR LE DÉVELOPPEMENT LOGICIEL DANS LE CLOUD
2.1 Introduction
2.2 L’agilité en gestion de projet
2.2.1 Le succès des projets
2.2.2 Les facteurs de succès des projets
2.3 Les limitations des méthodes agiles
2.4 Les avantages du développement de logiciels dans le cloud
2.4.1 Réduction des coûts
2.4.2 Réduction du temps de développement
2.4.3 Rétroactions des utilisateurs plus rapides
2.5 Le développement d’applications dans le cloud
2.6 Les tests d’applications dans le cloud
2.6.1 Conclusion du chapitre
CHAPITRE 3 L’APPROCHE DEVOPS
3.1 Introduction
3.2 Présentation
3.2.1 Avantages
3.2.2 Fonctionnement
3.3 Architecture
3.4 Les pratiques de DevOps
3.5 DevOps et le cloud computing
3.5.1 Apports du cloud
3.5.2 Modèles de services cloud
3.6 Conclusion du chapitre
CHAPITRE 4 DÉVELOPEMENT D’APPLICATIONS DANS LE CLOUD
4.1 Introduction
4.2 Les processus de développement d’applications
4.3 Le développement d’applications dans le cloud (norme ISO/IEC 17789)
4.4 Le développement d’applications au niveau des 3 couches du cloud
4.5 Caractéristiques des processus de développement dans le cloud
4.5.1 Rapide
4.5.2 Configurable
4.5.3 Adaptable et évolutive
4.5.4 Minimal
4.5.5 Collaborative
4.5.6 Fiable
4.5.7 Orienté vers le cloud
4.6 Conclusion du chapitre
CHAPITRE 5 ADAPTABILITÉ DES MÉTHODES AGILES DE DÉVELOPPEMENT DANS LE CLOUD (PAAS) : CAS DE SCRUM
5.1 Introduction
5.2 Sélection de la méthode Agile Scrum
5.3 Modèle d’utilisation de Scrum
5.4 Méthode Scrum (SBOK
5.4.1 Flux de projet Scrum
5.4.2 Pratiques
5.5 Adaptation de la méthode Scum au contexte du cloud PaaS
5.5.1 Méthode Scrum adaptée au PaaS
5.5.2 Description de la méthode
5.5.2.1 Les évènements
5.5.2.2 Rôles
5.5.2.3 Pratiques Scrum + PaaS
5.6 Conclusion du chapitre
CHAPITRE 6 ANALYSE DE L’IMPCAT DU PAAS SUR LES OUTILS DE GESTION SCRUM
6.1 Introduction
6.2 Impact du PaaS sur les outils de gestion de Scrum
6.2.1 Backolg de produit
6.2.2 Backolg de Sprint
6.2.3 Gestion de l’avancement
6.2.4 Gestion des changements
6.2.5 Gestion des risques
6.2.6 Gestion des approvisionnements
6.3 Conclusion du chapitre
CHAPITRE 7 CONTRIBUTIONS DE LA RECHERHCE
7.1 Retour sur la méthode proposée
7.2 Nos contributions
CHAPITRE 8 DISCUSSIONS
8.1 Limitation de notre méthode
8.2 Continuation de la recherche
CONCLUSION
BIBLIOGRAPHIE
Télécharger le rapport complet
