Comparaison RUP SCRUM Donc, en comparant des outils, on se doit d'être prudent.

Comparaison RUP SCRUM Donc, en comparant des outils, on se doit d'être prudent. Comparez pour mieux comprendre et non pour juger. Aucun outil n'est complet, aucun outil n'est parfait Comme tout outil, Scrum et RUP ne sont ni parfaits ni complets. Ils ne vous disent pas tout ce que vous avez à faire, ils vous fournissent juste quelques contraintes et quelques directives. Par exemple, Scrum vous contraint à avoir des itérations de durée fixe et des équipes multidisciplinaires, Fait intéressant, l'intérêt d'un outil est qu'il limite les options . Un outil de processus qui vous permet de faire n’importe quoi n'est pas très utile. On pourrait appeler ce processus “Faire N’importe Quoi” ou même “Faire La Bonne Chose”. Le processus “Faire La Bonne Chose” est garanti pour marcher, c'est comme une baguette magique ! Si ça ne marche pas, c'est parce que vous n'êtes manifestement pas en train d'appliquer le processus Utiliser les bons outils vous aide à réussir, mais ce n'est pas une garantie de succès pour autant. Il n'est pas facile de discerner entre la réussite/l’échec d’un projetet la réussite/l'échec d’un outil. •Un projet peut réussir grâce à un très bon outil. •Un projet peut réussir malgré un mauvais outil. •Un projet peut échouer à cause d’un mauvais outil. •Un projet peut échouer malgré un très bon outil. Scrum est moins normatif que RUP On peut comparer les outils en regardant le nombre de règles qu’ils fournissent. Normatif : signifie “plus de règles à suivre” Adaptatif : signifie “moins de règles à suivre”. 100% de normatif signifie que vous n'avez pas besoin d'utiliser votre cerveau, il y a une règle pour tout. 100% d’adaptatif équivaut à faire n’importe quoi, il n'y a aucune règle ni aucune contrainte. Comme vous pouvez le deviner, les deux extrêmes de l'échelle sont ridicules. Les méthodes agiles sont parfois qualifiées de méthodes légères, en particulier parce qu'elles sont moins normatives que les méthodes traditionnelles. D’ailleurs, le premier principe du Manifeste Agile est “Les Individus et leurs Interactions plutôt que les Processus et les Outils”. Scrum est adaptatif. Scrum vous donne moins de contraintes et par conséquent vous laisse plus de possibilités. Par exemple Scrum prescrit l'utilisation d'itérations de durée fixe. Comparons quelques outils sur une échelle normatif vs adaptatif : RUP est assez normatif – avec plus de 30 rôles, plus de 20 activités et plus de 70 artefacts ; une énorme quantité de choses à apprendre. Vous n'êtes cependant pas censé tout utiliser, RUP encourage à sélectionner le sous-ensemble adapté à votre projet. Malheureusement, cela semble être difficile dans la pratique. Exemple de normes RUP à discuter : Aurons-nous besoin de l'artefact ? Aurons-nous besoin d’un rôle de Responsable de contrôle du changement ? Pas sûr, mais prenons lesjuste au cas où.” C’est une des raisons pour lesquelles les implémentations de RUP sont finalement généralement très lourdes par rapport à des méthodes agiles telles que Scrum et XP. XP (eXtreme Programming) est plus normatif que Scrum. Il inclut une majorité de règles de Scrum + un ensemble de pratiques d’ingénierie bien spécifiques comme le développement piloté par les tests et la programmation en binôme. Scrum est moins normatif que XP puisqu’il ne recommande aucune pratique d’ingénierie particulière. Scrum impose des itérations et des équipes multidisciplinaires. Une des différences principales entre Scrum et RUP est qu’avec RUP vous vous retrouvez avec beaucoup trop de règles et vous êtes censé supprimer ce dont vous n’avez pas besoin. Avec Scrum, vous partez petit, et vous êtes censé ajouter ce qui manque. Ne vous limitez pas à l’emploi d’un seul outil ! Combinez les outils dont vous avez besoin ! Il est difficile pour une équipe Scrum réussir sans inclure la plupart des éléments de XP, par exemple. Certaines équipes Scrum rédigent leurs éléments de backlog sous forme de cas d'utilisation (une pratique RUP) ou limitent la taille de leurs files d'attente (une pratique Kanban). Prenez tout ce qui peut marcher pour vous. 1. Méthode de gestion de projet 3.1 Choix de la méthodologie Dans le domaine de gestion de projets il existe principalement deux types de méthodologie, classique et agile. Selon les approches traditionnelles, dites en cascade ou «waterfall», tout est planifié avant le début du projet. Une fois le cahier des charges créé et le contrat signé, les développeurs ont la responsabilité de livrer ce qui est prévu. À l’opposé des approches traditionnelles, la gestion de projets Agile propose de vérifier au fur et à mesure que le projet évolue dans la bonne direction. Son principe est simple : il s’agit de découper le projet en plusieurs étapes ou petits projets. Chacune de ces étapes doit aboutir à la création d’un élément fonctionnel de l’ensemble, qui s’inscrit dans les objectifs du projet. Les méthodes agiles se basent sur 4 valeurs fondamentales [8] : — Les individus et interactions plutôt que processus et outils — Développement logiciel plutôt que documentation exhaustive — Collaboration avec le client plutôt que négociation contractuelle 17 2. 28. Chapitre 2. Étude préalable — Ouverture au changement plutôt que suivi d’un plan rigide Après une étude comparative entre les méthodes agiles les plus répandues, nous avons décidé d’utiliser Scrum pour la gestion du processus du développement. Webographie https://docplayer.fr/141190-Kanban-et-scrum-tirer-le-meilleur-des-deux.html uploads/Ingenierie_Lourd/ comparaison-rup-scrum.pdf

  • 25
  • 0
  • 0
Afficher les détails des licences
Licence et utilisation
Gratuit pour un usage personnel Attribution requise
Partager