11.0 Waterfall vs. Gestion de projet cyclique (Partie 4) – Cycle de vie et résultats du projet

Des méthodes de gestion de projet cycliques #

En raison des problèmes évoqués ci-dessus, diverses techniques alternatives de gestion de projet se sont développées ces dernières années. Ces techniques sont particulièrement bien adaptées aux initiatives de développement des technologies de l’information.

Gestion de projet cyclique est une méthode pour atteindre l’objectif du projet via une série de cycles brefs et séquentiels. Chaque cycle est bref et dure idéalement moins d’un mois. Chaque cycle complète une partie du projet. Chaque cycle comprend l’analyse, la conception, la mise en œuvre et les tests. Ceci est très différent de l’approche en cascade, dans laquelle chacune de ces tâches se produit dans sa propre phase distincte. De plus, l’approche en cascade spécifie un nombre limité de moments distincts pour le concept, la conception, la mise en œuvre et les tests. Cela se produit plusieurs fois de suite dans l’approche cyclique.

Entente Logiciel de gestion de projet Cycle #

Divers composants logiciels sont implémentés tout au long des cycles, qui sont donc autonomes. Chaque cycle est évalué une fois terminé. Si des besoins nouveaux ou alternatifs pour le projet émergent à la suite d’une meilleure compréhension, les activités des cycles futurs sont ajustées pour les inclure.

Un cycle commence par l’établissement ou la modification d’un horaire. Ensuite, les besoins de production du cycle sont évalués. Un design est développé, codé et validé. Ensuite, une évaluation a lieu et, dans certains cas, le nouveau programme est mis en œuvre. Ensuite, le cycle suivant peut commencer afin de compléter les composantes suivantes du projet. (Pour une discussion plus détaillée des techniques cycliques et de leurs distinctions, voir, par exemple, Kroll, 2004 ; Chromatic, 2003 ; Stapleton, 2002.)

Voici les principaux avantages de l’utilisation de la méthode cyclique:

  • Amélioration de la qualité des produits et de la mise en œuvre des fonctionnalités;
  • Amélioration de la qualité des produits et de la mise en œuvre des fonctionnalités;
  • Des estimations de temps et de coûts plus réalistes;
  • Moins de pression sur l’équipe de projet;
  • Meilleure qualité.

Les chapitres précédents montrent à quel point il est difficile, voire impossible, de définir correctement les capacités requises dès les premières phases d’un projet. Les techniques cycliques implémentent la fonctionnalité requise dans une série de cycles brefs. Chaque cycle non seulement étudie, mais conçoit, implémente et teste également une infime partie des fonctionnalités requises. La succession rapide de la conception, de l’exécution et des tests est essentielle à l’amélioration de la qualité. En conséquence, les équipes sont en mesure d’apporter des changements. Si une conception ne fonctionne pas dans la réalité, elle devient apparente tout au long du cycle, permettant des modifications. De plus, ce type d’opération permet aux consommateurs de demander des modifications.

Maintien de la qualité #

Une autre raison pour laquelle la gestion de projet cyclique améliore la qualité est que chaque cycle nécessite une coopération intense entre le client, les concepteurs et les programmeurs. Une équipe multidisciplinaire développe et exécute des solutions ensemble. Le client est principalement engagé au début, dans l’élaboration des exigences ; Ensuite, les concepteurs créent un design, et enfin, les programmeurs construisent le logiciel. Le chef de projet agit en tant qu’agent de liaison entre toutes les différentes parties et est responsable de s’assurer que les informations fournies sont livrées au destinataire approprié. En réalité, de nombreux programmeurs et concepteurs ne rencontrent jamais le client, qui ne fait que réapparaître tout au long du processus de développement logiciel.

Les techniques cycliques de gestion de projet sont particulièrement bien adaptées aux projets dont l’objectif final ne peut pas être clairement défini à l’avance, comme les initiatives artistiques ou de recherche. Travailler par cycles avec une équipe diversifiée qui comprend des utilisateurs finaux permet à l’équipe de déterminer le véritable objectif du projet et la meilleure façon de l’accomplir. Chaque cycle offre une occasion de réflexion et de correction.

Une cible est définie à l’avance pour les projets en cascade. La réflexion sur l’objectif initial est moins probable. L’objectif initialement formé n’est jamais (complètement) réalisé, et ni le but initialement conçu ni le but réalisé ne sont susceptibles d’être précisément ce qui était prévu.

Enfin, les méthodes de gestion de projet cyclique offrent des résultats supérieurs puisque le client effectue des tests d’acceptation. De plus, la qualité est améliorée en incluant des tests comme critère de fonctionnalité haute performance dès le départ. Par conséquent, les programmeurs doivent créer des «tests ayant échoué» (ou des tests unitaires) avant d’écrire leur code. Seul le code qui réussit le test échoué est jugé acceptable.

Tests cohérents #

Le travail orienté test exige des programmeurs qu’ils démontrent que le nouveau code est exempt de bogues avant de l’écrire. Ils le font en créant un test (test d’échec) qui identifiera les failles potentielles avant de commencer à coder. Considérons le cas où un logiciel doit être développé pour déterminer la quantité appropriée de monnaie à recevoir d’une machine à bonbons. Pour commencer, la présence d’une fonction capable de provoquer un changement doit être vérifiée. Cette fonction peut être appelée « rendre la monnaie ». Un test simple pourrait être exécuté et il révélerait que la fonction « rendre la monnaie » n’existe pas encore. Le test réussira si le programmeur crée la fonction mais ne lui fournit pas encore de substance.

L’étape suivante consiste à déterminer si la machine retourne le bon montant d’argent lorsqu’un article est acheté. Insérez soixante cents dans la machine et achetez un article à cinquante cents. Le test échouera car la fonction reste vide. Après cela, le programmeur écrit le code. Il précise dans la fonction « rendre la monnaie » que la quantité de monnaie à rendre est égale à la somme d’argent mise dans la machine, moins le coût du bonbon sélectionné. Le test devrait maintenant réussir. Cette procédure doit être répétée pour chaque composante du programme.

Non seulement le code doit être testé techniquement ; les fonctions doivent également être testées (c’est-à-dire des tests d’acceptation). Avant de commencer le codage, le client établit les critères selon lesquels les capacités à développer peuvent être approuvées (par exemple, la vitesse à laquelle un ordinateur doit réagir à une certaine action de l’utilisateur). Auparavant, la définition des critères selon lesquels la capacité supplémentaire peut être approuvée s’est avérée très complexe et chronophage. Néanmoins, la participation active des consommateurs aux tests est essentielle à la réussite du projet.

Estimations de temps et d’argent #

La compréhension des fonctions à mettre en œuvre n’est pas prédéterminée au démarrage d’un projet cyclique. Le temps disponible est indiqué. Des accords sont conclus sur l’orientation du projet, et tout au long du processus, il est établi ce qui est vraiment nécessaire, bénéfique et faisable en termes de programme à créer. Parce que les fonctions à mettre en œuvre ne sont pas des objectifs fixés, les projets cycliques minimisent le risque que les heures nécessaires, et donc l’argent, ne deviennent incontrôlables. Pour éviter ce scénario, le temps disponible est utilisé comme point de départ, et ce qu’il est raisonnable d’anticiper dans ce laps de temps est établi tout au long du processus.

De plus, les techniques de gestion de projet cyclique sont considérablement plus acceptables pour l’équipe de projet. L’équipe fait tout ce qu’elle peut dans les délais impartis, mais n’est pas contrainte d’atteindre des délais déraisonnables ou de fonctionner avec un budget insuffisant.

De plus, les techniques cycliques simplifient l’administration des prestataires étrangers. Avec l’approche en cascade, un projet peut devenir dépendant d’un seul fournisseur jusqu’à ce que le projet soit terminé, quelles que soient les performances du fournisseur. Il est théoriquement possible de conclure de nouveaux accords pour chaque cycle voire pour chaque composant à fournir selon une technique de travail cyclique et, si nécessaire, de changer de fournisseur.