J’ai apprécié cet article où l’auteur a pris le parti de la complémentarité plutôt que de l’opposition entre les méthodes de développement traditionnelles et plus récentes.

Le choix entre les méthodes « en cascade », RUP et agile, y dépend à la fois de l’expérience de l’équipe, de la culture d’entreprise, du type de projet, de l’environnement, du mode de développement interne/externe, et prend en compte la dimension géographique.

Ce qui représente en soi, un bon exemple d’agilité dans le choix même de l’approche qui pourrait être une combinaison des trois méthodes selon les moments du cycle de développement.

Utilisez vous d’autres critères de choix de l’approche de développement?

En « cascade », RUP et Agile : quelle est la bonne méthode de développement logiciel  pour vous?

Article original de Serhiy Kharytonov, SoftServe © 2009

Http://www.executivebrief.com/software-development/waterfall-rup-agile/

Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mélange des stratégies de développement de logiciels afin de répondre aux besoins spécifiques de votre projet.

Malgré les signes de reprise dans l’économie, la réalité persiste dans le développement logiciel. La plupart des sociétés et clients ont besoin de leur logiciel pour hier avec les fonctionnalités les plus avancées au coût le plus faible possible. Pour atteindre ces buts apparemment contradictoires, les développeurs cherchent à rationaliser la production avec les processus rapides, efficaces qui peuvent donner au client ce qu’il/elle veut en un laps de temps le plus court possible.

Ces faits et les échecs de développement passés ont mené à un changement dans le développement logiciel depuis des méthodes très structurées, séquentielles de développement logiciel du passé, souvent appelé le modèle « en cascade », aux modèles plus itératifs et progressifs tels que « Rational Unified Process (RUP) » et « Agile. »

Les partisans d’Agile sont nombreux et il peut parfois sembler que des processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, des côtés négatifs et leurs environnements de projet favoris. Au bout du compte, la meilleure méthode ou le meilleur mélange de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, la culture business et l’environnement de développement.

En « cascade »

La programmation en « cascade » est un processus fortement structuré qui compte lourdement sur la planification initiale et un ensemble d’étapes séquentielles, prescrites qui coulent de l’une dans l’autre comme une chute d’eau. Chaque étape a typiquement son équipe propre d’experts et des jalons soigneusement préparés d’avance et aucune étape ne peut commencer tant que l’étape précédente n’a pas été complétée. Le but est de recueillir tous vos besoins détaillés tôt dans le processus et de fournir une seule solution complète  avec des résultats qui sont fortement prévisibles.

Typiquement les étapes dans le développement en « cascade » sont :

1. Recueil des besoins et rédaction du cahier des charges
2. Analyse fonctionnelle
3. Développement du code
4. Intégration
5. Test et mise au point
6. Installation
7. Maintenance

Le développement en « cascade » peut marcher très bien pour des applications complexes, critiques à la mission de l’entreprise et qui s’intègrent avec de nombreux autres systèmes ou pour des organisations comme la NASA ou l’armée qui exigent les plus hauts niveaux de fiabilité.

Les détracteurs disent que la « cascade » demande simplement trop longtemps et manque de la flexibilité – ou de l’agilité – requise pour le marché logiciel d’aujourd’hui et un environnement de développement en constant mouvement. Les projets qui suivent la méthode en « cascade » prennent typiquement des mois ou des années et au moment où ils sont finis, on découvre parfois que les besoins ont changé ou que les besoins originaux étaient incorrects depuis le départ. Le résultat peut être des corrections onéreuses, explosant le budget.

RUP

Comme la « cascade », le Rational Unified Process (RUP), produit par Rational Software et plus tard par IBM, est aussi un processus lourd, mais c’est une approche itérative qui prend en compte le besoin d’accommoder le changement et l’adaptabilité pendant le processus de développement.

Comme la « cascade », RUP a une série de phases et des jalons qui coulent l’un dans l’autre. Les phases consistent en :

1. Création (« inception »), où la portée du projet, l’évaluation des dépenses, des risques, le business case, l’environnement et l’architecture sont identifiés.
2. L’élaboration, où les besoins sont spécifiés en détail, l’architecture est validée, l’environnement de projet est détaillé et l’équipe de projet est configurée.
3. La construction, où le logiciel est construit et testé et la documentation de support est produite.
4. La transition, où le logiciel est testé au niveau système et utilisateur, corrigé et déployé.

RUP définit aussi les rôles et les activités de membres de l’équipe en détail et compte à chaque étape sur la production de modèles visuels, qui sont les représentations graphiques riches de systèmes logiciels et des cas d’utilisation spécifiques plutôt que les grandes quantités de documentations requises pour chaque étape de la « cascade ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de directives, modèles, outils et autres articles pour assurer qu’ils partagent les mêmes langage et perspective sur le projet.

Alors que cela apparaît semblable au développement en « cascade » de prime abord, la plus grande différence du RUP est son approche de développement itérative, qui construit le produit dans plusieurs étapes basées sur des revues fréquentes avec les parties prenantes. Les premières itérations RUP sont surtout de la définition de besoin et d’architecture et l’exploration d’idées différentes, tandis que les itérations ultérieures essayent de rassembler un produit complet. Chaque itération est un livrable exécutable et chaque phase RUP peut interagir avec les phases précédentes pour s’adapter au besoin.

Non seulement le processus RUP est itératif dans son ensemble mais RUP suppose aussi que chaque phase ait plusieurs itérations internes basées sur des retours d’utilisateur.

RUP adresse bon nombre des critiques du développement en « cascade » et est une bonne méthode pour des agences gouvernementales et institutions éducatives qui apprécient un cycle de développement de logiciel stable et répétable, ainsi que pour des organisations qui « offshore » dans des pays comme l’Inde et la Chine, ou qui produisent des progiciels.

Les critiques disent que RUP n’est pourtant pas aussi rapide et adaptable que d’autres méthodes, comme Agile et ne marche pas bien quand un délai de mise sur le marché rapide est crucial ou bien pour le Web 2.0 et les environnements Software-as-a-Service (SaaS) où on s’attend à des mises à jour fréquentes et des compléments de fonctionnalités.

Agile

Tandis que la « cascade » et RUP penchent vers la prévisibilité, les buts principaux d’Agile sont la vitesse et l’adaptabilité. Il y a beaucoup de types différents de processus de développement Agile, y compris XP et SCRUM, mais tous s’efforcent de mettre une version de produit basique mais fonctionnelle entre les mains du client aussi vite que possible.

Ils font alors suivre cette version par des versions successives qui ajoutent et changent des fonctions nécessaires au fil du temps pour fournir un produit plus robuste. Chaque module successif est planifié, codé, testé et complété sur de courtes sessions de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme la « cascade » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.

Plutôt que de dépendre de nombreuses équipes d’experts, le processus de développement Agile entier est typiquement entrepris par une seule, petite équipe, cross-fonctionnelle, censément auto-organisée, qui doit inclure un représentant client, qui suit des réunions quotidiennes et s’assure que l’équipe travaille sur les choses dont le business a vraiment besoin. La collaboration en face à face constante est le but, avec le représentant du client utilisé comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à la « cascade » et même à RUP pour sortir quelque chose aussi rapidement que possible.

Avec son approche modulaire, progressive, faite en collaboration, Agile est rapide et fortement adaptative au changement de besoins et des défis compétitifs, qui sont les raisons de tant de partisans. British Telecom est fréquemment cité comme une société qui a utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont rapporté une productivité spectaculaire et des avantages business par rapport aux 18 mois ou plus pris dans le passé pour produire un logiciel utilisable.

Mais même s’il est facile de tomber amoureux d’Agile, elle a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rendent le processus difficile à adapter à l’externalisation des développements, aux clients et développeurs géographiquement distribués, ou aux clients qui n’ont tout simplement pas la main d’œuvre, les ressources ou l’attention nécessaires.

Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas facilement aux clients qui veulent des contrats avec des évaluations fermes et des calendriers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec beaucoup de parties prenantes aux besoins  différents et néglige de prendre en compte du besoin de leadership pendant que les membres de l’équipe s’habituent à travailler ensemble.

De plus, le manque de documentation complète peut rendre la maintenance et les nouveaux développements difficiles quand les membres de l’équipe originale laissent leur place à d’autres. Cela peut mener à des modules aux fonctionnalités et interfaces inconsistantes. Finalement, plus qu’avec la « cascade » et RUP, le développement Agile dépend éminemment de la capacité à recruter des analystes fonctionnels très expérimentés qui savent comment travailler indépendamment et s’interfacer efficacement avec des utilisateurs métiers.

Le meilleur de chaque monde

Si Agile, RUP et des modèles en « cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret au développement logiciel réussi est de comprendre les trois processus dans le détail et sélectionner les parties de chacun qui conviennent le mieux à votre livrable et environnement particuliers. Puis, être agile dans l’approche même du processus, en regardant sans cesse sur ce qui a été réalisé, en réévaluant et révisant le processus de développement jusqu’à ce qu’il s’adapte au mieux à vos circonstances actuelles.

Par exemple, si vous développez du logiciel SaaS ou Web 2.0 dans un marché fortement concurrentiel, alors vous ferez probablement le meilleur choix en penchant vers des méthodologies Agiles. SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour ajouter ou changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateur changeants vous voudrez probablement être capables d’apporter rapidement des changements.

D’un autre coté, si vous produisez pour le médical, l’ingénierie, ou d’autres systèmes qui exigent un haut degré de conception et de certitude, alors il semble logique de commencer par la « cascade ».

Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui doivent être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière au recueil des besoins, à la définition du périmètre et du contenu au début, ainsi que des standards de navigation, et d’interface utilisateur.

Cependant, les développeurs peuvent tout de même utiliser des techniques Agiles pour présenter des prototypes fréquents et des modules progressifs aux chefs de produit de la société pour s’assurer qu’ils sont sur la bonne voie. La fréquence et l’intensité de collaboration entre chefs de produit et développeurs dépendent vraiment de leur proximité et de la culture de société – selon que ces équipes soient plus ou moins habituées à une telle collaboration. Quand la géographie est un problème, les outils de collaboration comme la conférence à plusieurs sur le web et la vidéo peuvent être d’une grande aide.

Ce même mélange de techniques peut être utilisé dans un environnement d’entreprise externalisant le développement en « offshore ». En fait, avec les différences de fuseaux horaires et de cultures, il est important d’intégrer autant d’étapes itératives et progressives et autant de contact de suivi qu’il est possible pour votre projet, la culture de votre société et celle de vos partenaires de développement.

Choisir de partir sur des équipes auto-organisées ou une approche plus « top-down »  de management dépend vraiment du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leader qui va ajouter une certaine urgence, une direction et une gestion des risques du projet jusqu’à ce que les membres de l’équipe s’habituent à travailler ensemble. Alors le rôle de leadership peut être réduit selon les besoins pour les itérations suivantes.

Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et environnements, ni même pour un seul. C’est pourquoi les sociétés doivent intégrer fréquemment « les leçons apprises » pour évaluer et réviser le processus lui-même, qui peut se déplacer d’un bout à l’autre du spectre à différents moments dans le cycle de développement. Bref, en choisissant entre Agile, RUP et en « cascade », adaptez le processus à vos besoins, plutôt que d’adapter votre projet au processus.