D’hier à aujourd’hui, les développements logiciels continuent leur course à l’agilité

Les méthodes utilisées pour optimiser le processus de livraison des applicatifs logiciels ont évolué au fil du temps. Toutes cherchent à répondre au même impératif : rendre le développement logiciel plus agile.

Les considérations sur l'agilité du développement logiciel traduisent les préoccupations des différents acteurs du cycle de vie des applications. Si l'attention reste toujours centrée sur le respect des délais et la qualité des livrables, d'autres exigences sont apparues au fil des mutations technologiques et de l'évolution des méthodes de conception et de développement. Les équipes doivent accroître sans cesse la valeur ajoutée des développements opérés, livrer plus vite, élever le niveau de qualité (SLA), favoriser le brassage de technologies variées, intégrer les évolutions de manière continue, utiliser des ateliers collaboratifs et évolutifs, accepter les changements tardifs dans le cycle de développement, etc. - l’objectif étant de sortir plus rapidement de nouvelles versions des logiciels et applications pour couvrir les besoins exprimés par les équipes métier.
Il ne faut pas perdre de vue que les opérations de maintenance absorbent jusqu’à 80% du budget d’une DSI, un taux stable depuis 25 ans, dans un contexte où se sont renforcées la complexité des applications et systèmes, la sophistication des développements, ainsi que la combinaison entre progiciels et développements propriétaires.
Pour rendre les développements logiciels à la fois plus efficaces et plus souples, les équipes informatiques, sous l’impulsion de leurs responsables applicatifs, se sont appuyées sur diverses méthodes. Jusque dans les années 1990, AXIAL et MERISE étaient les plus employées. A ces méthodes correspondaient un cycle de développement en V au sein duquel chaque phase du développement était associée à une phase de test spécifique et à un cortège de procédures et de protocoles générant une quantité prodigieuse de documentation, bien souvent inexploitée. En 1991, la méthode RAD (développement rapide d'applications) a apporté souplesse et réactivité, répondant aux besoins de petites équipes de développement évoluant avec les technologies client-serveur alors en plein essor.
Aujourd'hui, les méthodes agiles sont entrées dans les mœurs des petites et grandes entreprises, même si pour ces dernières, leur champ d'application n'est pas généralisé. La plus connue est SCRUM, pour la gestion de projets et d'exigences. Il y a aussi XP (eXtreme Programming) pour les projets techniques ; Agile UP (Unified Process), la plus prescriptive, est surtout utilisée dans les grandes structures ; et enfin Crystal rassemble des méthodes agiles adaptées à la taille et la portée  des projets. Introduisant un nouveau paradigme dans la gestion de la relation MOA-MOE, ces méthodes nécessitent une transformation de cette relation en un partenariat étroit où la communication directe remplace les formalités.
Par exemple, le choix du terme rugbystique SCRUM (mêlée) sous-entend les notions d'engagement, de solidarité et d'effort commun pour atteindre l'objectif. Savoir réagir, s'adapter, innover, se dépasser sont les exigences du monde sportif... et des entreprises. Rapportées au niveau des équipes informatiques, cela signifie que le compartimentage formel des rôles et compétences doit laisser place à une structure de projet dynamique, promouvant la communication entre toutes les parties prenantes du projet.

De façon naturelle, les développeurs d'applications Java, .NET et Web2.0 qui sont plébiscitées par "la génération Y" ont adopté les méthodes agiles et les organisations de travail qui s'y rapportent. La situation était différente il y a 20 ou 30 ans lors de l'informatisation massive des grandes et moyennes entreprises : les développeurs étaient formés aux mêmes technologies et intervenaient sur des plates-formes mainframe, Unix ou mini-systèmes. Pour ces applications dites patrimoniales qui forment aujourd’hui le cœur des SI, l'instauration de nouveaux canaux de communication (C/S, Web, ERP...) a bousculé  les méthodes de développement et de tests, car la population de développeurs est devenue hétérogène et ne partage plus une même vision du développement. L'urbanisation du SI et la mise en place de services applicatifs ont donc progressivement abouti à la notion de contrat entre silos de développeurs spécialisés, chaque silo disposant de son propre cycle de développement.
Aussi doit-on parler plus volontiers de méthodologies agiles et privilégier la méthode la plus appropriée au type de projet et à sa durée, en intégrant les spécificités de l'organisation. L’utilisation de ces méthodes incite à une évolution de la gouvernance des projets et à une collaboration accrue que facilite la mise en transparence des enjeux du projet et des responsabilités de chacun.

Les technologies pour gérer le cycle de vie des applications offrent une réponse logicielle au besoin de créer une dynamique de projet. Elles existent désormais pour tout type de développement et d'organisation. Certaines ciblent les activités de codage et d'aide à la détermination d'erreur à la source ou en "run" ; d’autres s'attachent à normaliser et fluidifier les échanges entre donneurs d'ordres et équipes de réalisation ; d’autres encore sont consacrées à la gestion de référentiels de cas de tests fonctionnels nécessaires à la réalisation de tests unitaires et de campagnes de tests, ou délivrent une vision instantanée de l'avancement des projets via des tableaux de bord exprimant le statut des différentes briques logicielles composant la future version/release de l'application...
Dans les faits, les développeurs utilisent l'une des deux IDE majeures que sont Eclipse et Microsoft Visual Studio, et effectuent par itération des développements ou maintenances évolutives, indépendamment de la plate-forme cible (LUW, mainframe) avec utilisation optimale des capacités de sa station de travail. De leur côté, les responsables applicatifs disposent d’indicateurs qui mesurent la qualité des développements réalisés, point particulièrement critique dans les centres de services des SSII.