Menu

Étude de cas: Comment éliminer les failles des processus de développement en cascade et agiles à l'aide d'un modèle hybride

  • Principal
  • Test Agile
  • Étude de cas: Comment éliminer les failles des processus de développement en cascade et agiles à l'aide d'un modèle hybride

case study how eliminate flaws waterfall

Essayez Notre Instrument Pour Éliminer Les Problèmes

Modèle hybride Agile Waterfall

modèles de cycle de vie de développement de logiciels en cascade

Le modèle Waterfall a été le choix idéal pour le développement de logiciels. Dans ce modèle, une idée devient un logiciel utilisable dans un processus séquentiel qui passe en cascade à travers les étapes d'initiation, d'analyse, de mise en œuvre, de test et de maintenance.

Mais le modèle Waterfall présente certains inconvénients.

Le développement logiciel agile a évolué pour éliminer les problèmes du modèle Waterfall. Il a un tout nouveau cadre. Alors que le modèle Waterfall a une conception séquentielle, le modèle Agile a suivi une approche incrémentale.

Lorsque les clients qui suivaient le modèle Waterfall sont passés à Agile, la transition a entraîné de nombreux problèmes. La raison en est l'inadaptabilité à une approche différente du développement logiciel. Le produit final s'est avéré être un désastre.

Modèle hybride Agile Waterfall

Une nouvelle méthodologie a donc évolué, que l'on peut appeler un «hybride», pour garantir un produit final robuste en choisissant les avantages des modèles Agile et Waterfall.

Commençons par connaître les modèles de développement Waterfall et Agile, puis passez au «Modèle hybride Agile Waterfall» avec les avantages et les inconvénients de chacun.

Ce que vous apprendrez:

Modèle de cascade

Le modèle Waterfall est une approche de développement de logiciel qui divise un projet en phases finies. On ne devrait passer à la phase suivante que lorsque sa phase précédente est revue et vérifiée.

Dans le modèle en cascade, les phases ne se chevauchent pas.

=> En savoir plus sur le modèle de cascade ici.

La figure 1 montre le modèle Waterfall:

Modèle de cascade

Avantages du modèle de cascade:

  • Simple et facile à comprendre et à utiliser.
  • Modèle rigide - Chaque phase a des livrables et des processus d'examen spécifiques.
  • Documentation et artefacts méticuleusement entretenus.
  • Convient aux projets où les exigences sont bien comprises.

Inconvénients du modèle Waterfall:

  • Ne convient pas aux projets où les exigences risquent de changer.
  • Le coût de la réparation des défauts est très élevé lorsqu'il est détecté à un stade ultérieur.
  • Pas un bon modèle pour les projets complexes et longs.
  • Aucun logiciel opérationnel n'est produit jusqu'à la fin du cycle de vie.

Modèle agile

Wikipedia définit le modèle Agile comme «un groupe de méthodes de développement logiciel basées sur un développement itératif et incrémental, où les exigences et les solutions évoluent grâce à la collaboration entre des équipes inter-fonctionnelles auto-organisées».

Le modèle a ses propres principes qui ont tendance à ramener les processus à l'arrière.

=> Lisez plus d'articles sur la méthodologie Agile ici.

(Cliquez sur l'image pour l'agrandir)

Modèle agile

Avantages du modèle Agile:

  • Implication du client dans le processus.
  • Un retour sur investissement élevé car le logiciel de travail est livré fréquemment.
  • Même les modifications tardives des exigences peuvent être facilement prises en compte.
  • Amélioration continue du produit et du processus.

Inconvénients du modèle Agile:

  • Manque d’accent mis sur la conception et la documentation.
  • L'équipe doit être stable et qualifiée.

Modèle collaboratif (hybride)

Le modèle collaboratif vise à combiner les deux modèles - Waterfall et Agile. Tirer parti à la fois de l'approche Waterfall et Agile garantit le succès du projet. Il supprime les inconvénients des deux modèles; tout en réunissant les avantages des deux.

Le modèle collaboratif peut être implémenté dans un projet en exécutant:

Modèle collaboratif (hybride)

Ainsi, le modèle collaboratif peut être représenté schématiquement comme ci-dessous:

Modèle collaboratif (hybride) 2

Avantages du modèle hybride

  • Combine les avantages des processus Agile et Waterfall.
  • La conception de haut niveau est prête à appliquer les principes de la cascade.
  • Le codage et les tests sont effectués à l'aide d'une méthodologie agile.

Modèle hybride Agile Waterfall - Apprendre par l'exemple -Une étude de cas

La société de logiciels «ABC Software Service» fournit des services à un client, une université nommée «XYZ University», pour développer, tester et maintenir son logiciel (support de production en direct).

Les principales caractéristiques du compte sont:

  1. ABC Software Services doit mettre à niveau les applications de l'Université XYZ. La base de données doit être mise à niveau et toutes les applications doivent être re-développées avec la dernière technologie disponible sur le marché.
  2. Jusqu'à présent, tous les projets traités par ABC Software étaient exécutés en modèle Waterfall.
  3. Deux des applications à fort trafic et à haute priorité devaient maintenant être redéveloppées. Le premier étant les «inscriptions en ligne», le second étant les «examens en ligne».
  4. Le client XYZ University voulait maintenant que ces applications soient travaillées en utilisant le modèle Agile de développement logiciel.

Le premier projet dans un modèle Agile pour ABC Software était les inscriptions en ligne. Après l'exécution de ce projet, il a été réalisé dans une série de rétrospectives qu'il y avait de nombreuses failles dans les processus suivis.

Ces failles ont été corrigées lors de l'exécution du deuxième projet «examens en ligne» et il a donc été exécuté en modèle hybride.

Comment éliminer les failles des processus de développement en cascade et agiles à l'aide d'un modèle hybride:

Discutons-en en détail un par un.

#1. Pas de documentation:

quel type de test est utilisé pour vérifier que tous les programmes d'une application fonctionnent correctement ensemble?

L’un des principes agiles du manifeste agile stipule que: L’agilité donne plus de valeur au «logiciel de travail que la documentation complète». La méthodologie Agile estime que la documentation devrait être «à peine suffisante», et que l’accent est mis davantage sur l’expédition d’un logiciel fonctionnel. Peu d'efforts sont faits sur la documentation, mais pour des comptes comme l'Université XYZ, avec une équipe de support dédiée pour travailler sur les défauts trouvés sur des projets en direct, cette habitude peut s'avérer un obstacle si nous l'analysons sur le long terme.

Au fil des ans, lorsque les projets ont été exécutés dans le modèle Waterfall, les documents ont été maintenus et mis à jour pour que l'équipe de support les comprenne et travaille en conséquence. La conception de la solution, la conception technique, les documents de présentation, etc. étaient quelques-uns des documents préparés. Une fois le projet terminé, la même chose a été transférée à l'équipe de support.

Mais dans le cas du projet «inscriptions en ligne», aucun document de ce type n’a été préparé et cela s’est avéré coûteux. Lorsque le projet a été lancé, de nombreux tickets ont été collectés par les utilisateurs finaux et l'équipe d'assistance n'avait aucune idée de la manière de travailler dessus. L'équipe n'avait aucun document à référencer.

Il s’agit d’une leçon majeure apprise et pour le prochain projet, des documents d’examen en ligne ont été rédigés et transposés efficacement.

=> Lisez plus ici pourquoi la documentation est importante.

#deux. Pas de test UAT / de bout en bout:

Dans le mode Agile de développement logiciel, les testeurs font tester les versions par incréments. Ces versions continuent à s'intégrer jusqu'à ce que la version finale soit complètement construite. Les testeurs testent les exigences couvertes dans chaque sprint et continuent de faire des tests de régression de la version qui continue de s'additionner.

Mais une fois que tous les sprints sont terminés et que la version finale est prête et entièrement intégrée, le testeur doit tester le système complet et effectuer des tests de bout en bout. Cela devrait être fait dans un environnement complètement nouveau.

=> Test de bout en bout sur un projet en direct.

Cela a ses propres avantages:

  • Le système complet est déployé dans un nouvel environnement et le testeur teste le flux complet.
  • Cela renforce la confiance car, en fin de compte, la version doit être déployée dans son ensemble dans un environnement réel.

Lorsque le projet des inscriptions en ligne a été testé, cela a été fait dans l'environnement de test. Après avoir testé le système et retesté tous les défauts, il a été déclaré pour approbation. Idéalement, cela n'a pas été promu dans un autre environnement pour un autre cycle de test du système. (Idéalement, UAT se produit après le test du système , mais dans ce cas, les membres de l'équipe UAT ont été impliqués dans le premier cycle de tests donc aucun deuxième cycle n'a été programmé)

Lorsque le projet d'examens en ligne a commencé, le SIT (test d'intégration de système) a été effectué et le code a été promu dans un environnement UAT où le deuxième cycle de test a été effectué. Résultat: tous les défauts hautement prioritaires ont été capturés et résolus. La version était stable avant la mise en service.

# 3. Pas de Scrum Master:

Le Scrum Master est responsable de s'assurer qu'une équipe vit selon les valeurs et les pratiques de Scrum. Le Scrum Master est considéré comme un coach pour l'équipe en aidant l'équipe à faire le meilleur travail possible. Le Scrum Master peut également être considéré comme un propriétaire du processus pour l'équipe.

L'équipe des inscriptions en ligne a été formée sans Scrum Master. L'importance d'avoir un Scrum Master dédié n'était pas considérée comme importante. Cela a abouti à de nombreux problèmes qui n'ont pas été résolus à temps et, à son tour, le temps de terminer le projet a souvent dépassé la date limite.

Cependant, un Scrum Master dédié a été impliqué dans le projet des examens en ligne. Les problèmes et défis du projet ont été pris en charge par le Scrum Master. Les rapports de projet / sprint ont été préparés et l'équipe a pu voir leurs progrès.

De plus, des réunions de planification de sprint appropriées et des réunions rétrospectives de sprint ont eu lieu pour chaque sprint qui a amélioré les performances de l'équipe. L'équipe se concentrait uniquement sur son travail et a terminé ses tâches assignées pour ce sprint. Tout le ménage supplémentaire était géré par le Scrum Master.

# 4. Conversion des documents de projet en backlog produit:

Les documents de projet initiaux qui sont préparés dans un modèle en cascade sont la spécification des exigences commerciales (BRS), la conception de haut niveau, la conception fonctionnelle, etc. Ces documents doivent être transformés en un backlog de produit afin d'exécuter les étapes de codage, de test et de mise en œuvre en mode agile. Ceci est une étape très importante.

Le backlog produit est le point de départ d'un projet agile. Le backlog de produit est une liste hiérarchisée des exigences qui est gérée pour un produit. Il se compose de fonctionnalités, de corrections de bogues, d'exigences non fonctionnelles, etc. C'est un document en croissance qui devient de plus en plus grand en fonction des commentaires des clients, des exigences changeantes, etc.

ouvrir les fichiers .jar windows 10

Étant le premier artefact de tout projet, il est très important de répertorier les exigences et de leur attribuer des priorités. La conversion des documents de projet en cascade en backlog produit est une tâche importante en soi et nécessite un brainstorming de toute l'équipe avec le client / partie prenante.

Une fois que toutes les exigences sont répertoriées et acceptées par le client, la tâche suivante consiste à les hiérarchiser afin de les relever dans les sprints.

# 5. Matrice de traçabilité:

Un autre artefact important qui est généralement conservé dans le modèle de cascade est la matrice de traçabilité. Donc, afin de garantir qu'aucune exigence ne soit manquée; une matrice de traçabilité doit également être conçue et maintenue . Habituellement, en agile, aucune matrice de ce type n'est conçue.

Il s'agit d'une meilleure pratique dans n'importe quel projet. Une matrice de traçabilité doit être préparée parallèlement au carnet de commandes. Et il doit être vérifié par rapport aux cas de test exécutés lors des tests d'acceptation utilisateur / tests de bout en bout (cette étape est expliquée dans mon point suivant). Même si une exigence est omise, elle peut être facilement intégrée même dans les derniers stades de développement, car l'agilité offre cette flexibilité et cette adaptabilité supplémentaires.

Après la mise en ligne du projet d'inscription en ligne, les utilisateurs finaux ont accédé à l'application (les étudiants souhaitant s'inscrire). Ils ont été confrontés à de nombreux problèmes dans l'application. Cela a abouti à un grand nombre de tickets envoyés à l'équipe de support de production. Les tickets soulevés peuvent être classés comme incidents, problèmes ou changements. De nombreux problèmes ont été résolus, prévoyant que l'application deviendra stable. Mais même dans ce cas, plus d'une douzaine de demandes de changement / améliorations ont été planifiées dans les versions suivantes. Ces améliorations visaient à stabiliser l'application et à améliorer l'expérience de l'utilisateur final.

Donc, finalement, le coût du projet a augmenté de plusieurs plis. Par conséquent, si un projet ne passe pas correctement à l'agilité, cela peut entraîner un dépassement du budget. Ceci est très nécessaire pour planifier une transition approfondie d'un projet vers Agile. En outre, la planification doit être effectuée dans la mesure où le projet a besoin pour être exécuté en mode agile. Des modèles hybrides appropriés doivent être conçus pour un projet particulier.

Avant le début du projet d'entrée aux examens, cet aspect était bien pris en compte. Un modèle hybride a été pensé et il a été décidé que la phase d'analyse des exigences et la phase de conception de haut niveau devaient être exécutées dans un modèle en cascade et le reste des étapes dans un modèle agile.

Le modèle hybride adopté peut être représenté graphiquement comme ci-dessous:

Modèle collaboratif (hybride) 3

Conclusion:

Il est évident que le modèle Waterfall et le modèle Agile ont leurs propres inconvénients. Il est donc assez réaliste d'opter pour un modèle hybride, qui est une approche tirer parti du meilleur des deux mondes.

L'aspect le plus important du démarrage de tout projet est de décider du modèle que l'équipe va adopter. Cela nécessite une planification approfondie. Des facteurs tels que le budget, le temps, l'utilisation des ressources, la complexité des exigences, etc. doivent être pris en compte lors de l'adoption d'un modèle logiciel.

Le modèle hybride en est encore à ses débuts. Au fur et à mesure que de plus en plus d'entreprises l'adopteront, nous en apprendrons davantage sur ce concept.

Le manifeste Agile nous demande de valoriser:

  • Individus et interactions sur les processus et les outils
  • Logiciel de travail sur une documentation complète
  • Collaboration client sur la négociation de contrat
  • Répondre au changement plus de suivre un plan

Alors que le modèle hybride n'adhère pas à ce 100%. Cela suggère que tous les aspects sont d'égale importance. Il appartient aux clients / chefs de projet de décider quels aspects valoriser le plus et quels aspects ne pas valoriser.

A propos de l'auteur: Ceci est un article invité par Harshpal Singh. Il a plus de 7 ans d'expérience dans les tests manuels, de bases de données, d'automatisation et de performance et travaille actuellement en tant que chef d'équipe dans un grand multinational. Il a travaillé sur de nombreux projets QA suivant les modèles de développement Waterfall, Agile et hybride.

Avez-vous une expérience de travail sur ce modèle de développement et de test hybride? Discutons-en dans les commentaires.

lecture recommandée

^